<div dir="ltr">+1 to not introduce ^ for closure syntax.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 31, 2015 at 11:26 PM, Chris Lattner via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class="">On Dec 31, 2015, at 6:16 PM, Ethan Diamond via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<div><blockquote type="cite"><div><div dir="ltr"><div style="font-size:12.8px"><div style="font-size:12.8px"><i style="font-size:12.8px">There are three pieces at play here IMHO:</i><br></div><div style="font-size:12.8px"><i>1. How functions (global and on types) are declared and implemented</i></div><div style="font-size:12.8px"><i>2. How function specifications are indicated as types</i></div><div style="font-size:12.8px"><i>3. How anonymous functions are declared and implemented</i></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Agreed, so lets flush out the rules a little more and see if we can find a common language for all three, since they&#39;re interconnected. For the sake of clarity, I&#39;m going to refer to closures as blocks, since they&#39;re effectively the same thing. I think we should begin with these three rules:</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">1. Let&#39;s try to keep precedent for function calls, since blocks are pretty much functions</div><div style="font-size:12.8px">2. A ^ signifies that we are now entering a block context with regards to syntax</div><div style="font-size:12.8px">3. Just as in a lot of the rest of Swift, let&#39;s infer information we can, but optionally allow it to be respecified if it makes the syntax clearer</div></div></div></div></blockquote><br></div></span><div>I can’t believe that you’re seriously considering use of ^ for closure syntax, it is one of the most hated aspects of ObjC’s blocks. :-) :-)  FWIW, I’m the one to blame for the use of caret in ObjC’s block’s syntax.  In my defense, this was necessary to fit blocks into the C grammar - everything everyone hates about blocks declaration syntax is shared with C function pointer syntax.  That &quot;problem to be solved” doesn’t exist in the Swift grammar, so I don’t see why we’d carry it over.</div><div><br></div><div>More generally, we are extremely unlikely to make a change to the basic declaration syntax of swift (e.g. func, var, etc) or closure expressions.  They have been carefully considered, and work well in practice.  I don’t see a reason to make a change here.</div><div><br></div><div>-Chris</div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=L0OvF2p-2FxVELFUNex-2F-2F6EukXLEXHYK3CCbXZzS8MQlWWDxAANtfaNQdfm1kqTRUcaSM-2F1BYUiLVE9Ncegdyeq0TAW-2BssbLm1z3CiOFXb4ygPxlsJfPvZPIkkRSBVqcvikloadgO9hEPwIPbq2EI4fF5FjOfqdu8v6WE7K9XZ6T516RArBKqF5A5Q8A35shnc6showH41UEX8ZWz8OEbWuQ-3D-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
</div>
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>