[swift-evolution] Closure Syntax
clattner at apple.com
Thu Dec 31 23:26:28 CST 2015
On Dec 31, 2015, at 6:16 PM, Ethan Diamond via swift-evolution <swift-evolution at swift.org> wrote:
> There are three pieces at play here IMHO:
> 1. How functions (global and on types) are declared and implemented
> 2. How function specifications are indicated as types
> 3. How anonymous functions are declared and implemented
> 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:
> 1. Let's try to keep precedent for function calls, since blocks are pretty much functions
> 2. A ^ signifies that we are now entering a block context with regards to syntax
> 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
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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution