Advertisement
Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- Message: 11
- Date: Fri, 1 Jan 2016 14:21:35 -0800
- From: Ethan Diamond <edgewood7558@gmail.com>
- To: Chris Lattner <clattner@apple.com>
- Cc: swift-evolution@swift.org
- Subject: Re: [swift-evolution] Closure Syntax
- Message-ID:
- <CA+TuH2kozmhFMVKWrjMarc0C9B_Z2mCB=D+GZ10=BC=Kj1fFLA@mail.gmail.com>
- Content-Type: text/plain; charset="utf-8"
- FWIW I don't think the backlash to the use of ^ with Obj-C blocks was
- because of the carat itself, but because of the inconsistency of the syntax
- in different contexts. Sometimes the return type was after the ^, sometimes
- before. Sometimes you had to use (^). Sometimes the carat had the name of
- the block with it ^functionName. None of it fit in with the [object
- methodName] syntax of the language itself.
- However, none of those problems exist with block syntax in Swift - it would
- be consistent all the way through. I guess what I'm getting at is that I
- hope when Swift was being designed that the carat syntax wasn't considered
- because of some benefit of the current syntax, and not from fear of the
- initial backlash from people who didn't like Obj-C block syntax. I can't
- speak to language design with respect to the compiler since I have no
- experience in that area, but from a programming perspective, there are a
- lot of benefits of block syntax over closure syntax and no benefits of
- closures over block syntax.
- - Block syntax clarifies some hard to read function declarations such as:
- func makeIncrementer(forIncrement amount: Int) -> () -> Int"
- - There is no other syntax in Swift where the body's parameters are named
- inside the body. Everyone else has the ( inputs are named ) { body } syntax
- - (some of these are implied):
- for (index in indices) { //Something with index }
- func doThing(index: Int) { //Something with index }
- if (let index = index) { //Something with index }
- - You save the in keyword for for-in loops
- - I showed earlier how it allows for parameter naming when defining a
- closure type, which would be useful for autocompletion of blocks
- Anyway, if closure syntax is unofficially set in stone then that's that. I
- still appreciate you taking the time to listen.
- -E
- On Thu, Dec 31, 2015 at 9:26 PM, Chris Lattner <clattner@apple.com> wrote:
- > On Dec 31, 2015, at 6:16 PM, Ethan Diamond via swift-evolution <
- > swift-evolution@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
- >
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement