Sorry Chris, seems as though I misinterpreted. I guess I was arguing the principle more than the specific example here; apologies if I derailed the thread a bit. <span style="font-size:13px">At the risk of derailing the thread further, since I still have your attention and am not sure where else to raise such a suggestion: have you or other members of the Swift team considered talking to the team behind Kotlin? Kotlin has been loosely touted as &quot;Swift for the JVM/android&quot; and may share some motivation with Swift--modern functionality and interoperability with a very well-known, older language. In spite of how much the two languages differ in key areas, maybe the two teams could share and discuss motivation behind previous language decisions. Not sure if there is a precedent for that kind of interaction so feel free to disregard. </span><div><br><div class="gmail_quote"><div dir="ltr">On Sun, Jan 10, 2016, 12:30 AM Chris Lattner &lt;<a href="mailto:clattner@apple.com">clattner@apple.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">On Jan 9, 2016, at 7:50 PM, Dennis Lysenko &lt;<a href="mailto:dennis.s.lysenko@gmail.com" target="_blank">dennis.s.lysenko@gmail.com</a>&gt; wrote:</div><div style="word-wrap:break-word"><div><blockquote type="cite"><div><div dir="ltr">Chris, perhaps there is a disconnect in our perceptions of the commonly proposed list. Based on the way you and others have referenced the commonly proposed list, it comes off as a blacklist of sorts. That is, &quot;it&#39;s on the commonly proposed list&quot; seems to be seen as an argument against a proposal. I only worry that the mere presence of something on the commonly proposed list will serve as a deterrent to legitimate proposals involving it in the future. </div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>Hi Dennis,</div><div><br></div><div>I’m sorry for the confusion on this.  The very first paragraph of that page says:</div><div><br></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div>… If you&#39;re interested in pursuing something in this space, please familiarize yourself with the discussions that we have already had. In order to bring one of these topics up, you&#39;ll be expected to add new information to the discussion, not just say &quot;I really want this&quot; or &quot;This exists in some other language and I liked it there&quot;.</div></div></blockquote><div><div><br></div><div>The intention is to avoid re-treading old ground, not to say that something is impossible.</div></div></div><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><div dir="ltr"><div>If you have taken that into consideration when deciding to place infix functions on the commonly proposed list then fair enough. I just feel that infix functions have not been discussed nearly as much as, say, &quot;indentation over brace syntax&quot; or &quot;getting rid of ternary&quot;, and it&#39;s a bit preemptive to put such a dent in potential future discussion because you personally cannot imagine a use case warranting the language change.</div><div><br></div><div>Out of curiosity, has there even been a top-level proposal for infix functions that generated significant discussion?<br></div></div></div></blockquote></div></div><div style="word-wrap:break-word"><div></div><br><div>Yes, it has come up several times in different contexts.  The advantage of “x foo bar” (potentially with sigils around foo) over “x.foo(bar)” has consistently been seen as not worth adding complexity for.  Perhaps you are thinking of something else?</div></div><div style="word-wrap:break-word"><div><br></div><div>-Chris</div></div></blockquote></div></div>