+1 to not introduce ^ for closure syntax. On Thu, Dec 31, 2015 at 11:26 PM, Chris Lattner via swift-evolution < [email protected]> wrote:
> 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 > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
