On Dec 31, 2015, at 6:16 PM, Ethan Diamond via swift-evolution
<[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
