[swift-evolution] Closure Syntax

[Joseph Bell]

+1 to not introduce ^ for closure syntax.

On Thu, Dec 31, 2015 at 11:26 PM, Chris Lattner via swift-evolution <
swift-evolution at swift.org> wrote:

> 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
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160101/9b7e0847/attachment.html>