<div dir="ltr">FWIW I don&#39;t think the backlash to the use of ^ with Obj-C blocks was because of the carat itself, but because of the inconsistency of the syntax in different contexts. Sometimes the return type was after the ^, sometimes before. Sometimes you had to use (^). Sometimes the carat had the name of the block with it ^functionName. None of it fit in with the [object methodName] syntax of the language itself. <div><br></div><div>However, none of those problems exist with block syntax in Swift - it would be consistent all the way through. I guess what I&#39;m getting at is that I hope when Swift was being designed that the carat syntax wasn&#39;t considered because of some benefit of the current syntax, and not from fear of the initial backlash from people who didn&#39;t like Obj-C block syntax. I can&#39;t speak to language design with respect to the compiler since I have no experience in that area, but from a programming perspective, there are a lot of benefits of block syntax over closure syntax and no benefits of closures over block syntax.<div><br></div><div>- Block syntax clarifies some hard to read function declarations such as:</div><div> <span style="font-family:monospace,monospace;font-size:12.8px;white-space:pre-wrap">   </span></div><div><span style="font-family:monospace,monospace;font-size:12.8px;white-space:pre-wrap">  func makeIncrementer(forIncrement amount: Int) -&gt; () -&gt; Int&quot;</span></div><div><br></div><div>- There is no other syntax in Swift where the body&#39;s parameters are named inside the body. Everyone else has the ( inputs are named ) { body } syntax - (some of these are implied):</div><div>  </div><div><span style="font-family:monospace,monospace">  for (index in indices) { //Something with index }</span></div><div><font face="monospace, monospace">  func doThing(index: Int) { //Something with index }</font></div><div><font face="monospace, monospace">  if (let index = index) { //Something with index }</font></div><div><br></div><div>- You save the in keyword for for-in loops</div><div>- I showed earlier how it allows for parameter naming when defining a closure type, which would be useful for autocompletion of blocks</div><div><br></div><div>Anyway, if closure syntax is unofficially set in stone then that&#39;s that. I still appreciate you taking the time to listen.</div><div><br></div><div>-E </div><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 31, 2015 at 9:26 PM, Chris Lattner <span dir="ltr">&lt;<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</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><span class="HOEnZb"><font color="#888888"><div><br></div><div>-Chris</div></font></span></div></blockquote></div><br></div>