Message: 11
Date: Fri, 1 Jan 2016 14:21:35 -0800
From: Ethan Diamond <[email protected]>
To: Chris Lattner <[email protected]>
Cc: [email protected]
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 <[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
>