<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On Dec 31, 2015, at 6:16 PM, Ethan Diamond via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div style="font-size:12.8px" class=""><div style="font-size:12.8px" class=""><i style="font-size:12.8px" class="">There are three pieces at play here IMHO:</i><br class=""></div><div style="font-size:12.8px" class=""><i class="">1. How functions (global and on types) are declared and implemented</i></div><div style="font-size:12.8px" class=""><i class="">2. How function specifications are indicated as types</i></div><div style="font-size:12.8px" class=""><i class="">3. How anonymous functions are declared and implemented</i></div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class="">Agreed, so lets flush out the rules a little more and see if we can find a common language for all three, since they're interconnected. For the sake of clarity, I'm going to refer to closures as blocks, since they're effectively the same thing. I think we should begin with these three rules:</div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class="">1. Let's try to keep precedent for function calls, since blocks are pretty much functions</div><div style="font-size:12.8px" class="">2. A ^ signifies that we are now entering a block context with regards to syntax</div><div style="font-size:12.8px" class="">3. Just as in a lot of the rest of Swift, let's infer information we can, but optionally allow it to be respecified if it makes the syntax clearer</div></div></div></div></blockquote><br class=""></div><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 "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 class=""></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 class=""></div><div>-Chris</div></body></html>