[swift-evolution] Closure Syntax

[Chris Lattner]

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.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151231/6a89b54f/attachment.html>