I initially had similar concerns to Mishal, but I worked my way through it and found I was wrong.<div><br></div><div>In current Swift you can have a function:</div><div>A -&gt; B -&gt; C</div><div><br></div><div>Adding brackets for clarity, that is equivalent to this (current Swift):</div><div>A -&gt; (B -&gt; C)</div><div><br></div><div>After this proposal this will become:</div><div><font size="2"><span style="background-color:rgba(255,255,255,0)">(A) -&gt; ((B) -&gt; C)</span></font><br><br>Which can also be expressed (with proposal):</div><div><font size="2"><span style="background-color:rgba(255,255,255,0)">(A) -&gt; (B) -&gt; C</span></font><br><br>I don&#39;t think this is making it harder to do what you want. I think that&#39;s what Chris meant. <font size="2"><span style="background-color:rgba(255,255,255,0)">Please correct me if I&#39;m wrong Chris :)</span></font></div><div><br></div><div>By my interpretation it is just removing the syntactic ambiguity between:</div><div> * a single argument that is a tuple of type: (A, B, C)</div><div> * multiple arguments: A, B, C</div><div><br></div><div> This is a small change with a big win.</div><div><br>On Wednesday, 27 April 2016, Ryan Lovelett via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>




<div><blockquote type="cite"><div><div>SE-0066 is a very narrow proposal - it only affects syntax, not semantics.  The type system semantics that you seem interested in are unlikely to happen regardless of the syntax changes SE-0066 imply, and SE-0066 doesn’t have anything to do with that.<br></div>
</div>
</blockquote><div> <br></div>
<div>It is most disappointing to read these sorts of statements.<br></div>
<div> <br></div>
<div>One of the things that I have noticed over the last year or so of working with Swift is a trend in the community of libriaries being written for Swift towards some of these &quot;system semantics&quot; (i.e., functional paradigms) like applicatives and such.<br></div>
<div> <br></div>
<div>Granted I may have a selection bias towards these sorts of libraries. That is, I tried one library that did some of this stuff so then I tried more. Eventually stumbling into an enclave of functional practioners of Swift. I&#39;m willing to admit that I have not conducted a scientific survey.<br></div>
<div> <br></div>
<div>But from my vantage we have a minority of Swift users participating in these evolution discussions. Albeit, judging from the e-mail volume, an extremely _vocal_ minority. I worry that these things become an echo chamber and those not involved will look at some of the &quot;writing on the wall&quot; and think differently about Swift going forward. Indeed for those people they may look at Swift 3 and say &quot;I did not leave Swift; Swift left me.&quot;<br></div>
<div> <br></div>
<div>What is more is that those not participating in these discussions now may leave them with no recourse to be heard. Because apparently Swift 3 is a do-or-die release (or as the author of this evolution put it: &quot;It is
now or never.&quot;). I wonder what portion of Swift developers, the ones who want to see Swift be their go-to language for the forseable future, understand the implications or justifications for a Swift 3 release.<br></div>
<div> </div>
<div>All that having been said, I get it, decisions are made by those who show up. Roger that. I also understand and agree with the desire to make Swift its own language. To show restraint at the urge to turn the language into a hodge podge of the &quot;greatest hits&quot; of language paradigms. I sincerely appreciate the difficulty of the task for the Swift core team.<br></div>
<div> <br></div>
<div>I realized at the end that I do not really have a point. Apparently I&#39;m feeling philosphical this Wednesday morning.<br></div>
</div>

</blockquote></div>