[swift-evolution] Closure Syntax

[Ethan Diamond]

*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

>From there, I think the solution to your #2 (*How function specifications
are indicated as types) *naturally presents itself. This is a normal
function declaration:

func funcName(param) -> return_type

A block is effectively a function without a name - an anonymous function.
So we remove the name. I also agree with your earlier points that func is
inappropriate terminology for what we're trying to do so we remove that
too. Using the ^ rule to signify a block, we get these options, which I
think should both be valid:

^(param) -> return_type
^((param) -> return_type)

Which I find to be easier to read than the current closure type:

(param) -> return_type

because it shares syntax with tuples up until the ->, the () are optional
making the param share syntax with whatever type the param is, and because
when nested closure type syntax become particularly nasty to read.

Indeed, I think it gives us the opportunity for one more gain here. We have
functions with named parameters because of Swift's goal of clarity. This
gives us the opportunity for blocks to also have named parameters. Which
one of these is better?

func fetchHTML(callback: (String, Int) -> Error?)

or

func fetchHTML(callback: ^(url: String, allowedResponseCode: Int) -> Error?)

The named params aren't enforced when the block is defined, but provides
hints for the Swift user who defines the block body. They can rename those
params if they want, but it gives them a hint on how those params will be
used, and will autocomplete when they go to write the body with those names.

>From there, I think we have the answer to your question #1 as well (*How
functions are declared and implemented) *in that aside from using our new
block type syntax for their params, they are completely unchanged. However,
the new block type syntax makes function declarations easier to read.

As I listed before, we take this, which I find hard to read at a glance:

func makeIncrementer(forIncrement amount: Int) -> () -> Int { ... }

and replace it with something better:

func makeIncrementer(forIncrement amount: Int) -> ^() -> Int { ... }

or, what I feel should be an option with the ^ syntax:

func makeIncrementer(forIncrement amount: Int) -> ^(() -> Int) { ... }

I don't think you can look at that and tell me it's not clearer to read.

Your point 3 (*How anonymous functions are declared and implemented) *is a
bit trickier to explain, but I think the explanation arises naturally from
the three rules.

Let's start with rule 1, and look at the way we already define an call a
function:

func isNumberFour(number: Int) -> Bool {
    return number == 4
}
isNumberFour(4)

Because we already know the param type and the return type, we don't need
to respecify that information when we call the function. Using the same
logic we used to come up with the block type syntax - removing "func" and
since it has no name, basically using ^ as a signifier - we're going to be
able to reason out exactly what this would look like:

^(number: Int) -> Bool {
    return number == 4
}

Let's take the case where a function has a block as a parameter:

func isNumberFour(calculateNumber: ^((Int) -> Int)) -> Bool

How do I call this? If we're not using rule 3, inferring what we can, we
would write out this, which I think should be valid syntax if desired by
Swift's users:

let isFour: Bool = isNumberFour(calculateNumber: ^(number: Int) -> Int {
    return number * 2
})

But there's no reason to be that verbose. We have the isNumberFour
declaration. Much like we don't need to specify that isFour is a Bool,
Swift should also allow this:

let isFour = isNumberFour(calculateNumber: ^(number) {
   return number * 2
})

The compiler already knows enough about the block for that to work. We
named the Int param for the calculateNumber block, so autocomplete can
finish this for us. However, I also think it should be valid to be able to
change the name when the block's body is defined. So this would also be
valid:

let isFour = isNumberFour(calculateNumber: ^(amount) {
   return amount * 2
})

So the rules we follow are pretty simple. When the block's body is defined,
we only require users to specify the data the compiler can't infer, while
having the option to specify the rest. I believe this is exactly what we're
doing already with closures, we're just moving the part preceding the "in"
to the outside of the method and prefixing it with a ^. It makes closures
easier to reason about the syntax, and easier to read.

There are a few shorthands that would go with it. Let's take the var /
property case. Without using rule 3, removing syntax we can infer, we get
this:

var isNumberFour: ^(number: Int) -> Bool = ^(number: Int) -> Bool {
    return number == 4
}
isNumberFour(4)

But we already know the parameters, return type, and name of the
parameters. So following rule 3, we can reduce this to:

var isNumberFour: ^(Int) -> Bool = ^(number) {
    return number == 4
}

But I would propose we allow this shorthand, since it's nicer to read:

var isNumberFour: ^(number: Int) -> Bool = {
    return number == 4
}

As previously said, if there's no return type specified, we assume void.
Also, if there's no params and returns void, you can bypass the ^() all
together. So:

func async(_ callback: ^())

async(^() {
  //Do the callback
})

could still be written as:

async {
  //Do the callback
}

Much like closures in current Swift, if we want to use the $0 $1 shorthand,
we can also skip the block param piece:

func sort(_ comparator:^((a: Int, b: Int) -> Bool))

sort(^(a, b) {
  return a > b
})

could be written as:

sort {
  return $0 > $1
}

And to answer your question, "Would this syntax still support single
expression implicit returns, e.g. current Swift," the answer is still yes:

[1,2,3].map(^(number) {number == 3})

I feel like this syntax feels intuitive, gets rid of the weird "in" syntax,
and is closer to the function syntax people are used to. It also makes
reading block types easier, particularly when nested. I know there's a lot
of closure momentum to overcome at this point, but I really the time it
would take to change this would be worth it down the road.

-E


On Wed, Dec 30, 2015 at 6:48 PM, David Waite <david at alkaline-solutions.com>
wrote:

> For clarity's sake, there's really two syntactic issues that I think would
> be good to address. The first, which I think is the far bigger problem,
> which is that right now a list of params with closures is very hard to
> read. For example, this requires mental effort to decode whether this is
> returning an Int, or a closure returning an Int:
>
> func makeIncrementer(forIncrement amount: Int) -> () -> Int {
>
> }
>
> I look at currying like a right-associative operator (like the ternary
> operator, or assignments in languages like C). There is a function that
> takes no arguments and returns an int, that you get from a function that
> takes an int argument.
>
> Changing this to say
>
> func makeIncrementer(forIncrement amount: Int) -> func () -> Int {
>
> feels like it is changing the behavior to that of a non-associative
> operator.
>
> One interesting result would be if by removing the ternary operator as it
> stands today and changing how currying heppens, swift wound up having no
> right associative operators left in core.
>
> And the second being that stylistically, having the params on the inside of the closure is breaking precedent of params outside of the block of code without gaining much.
>
> Perhaps we could adopt the Obj-C ^ as a closure indicator. I think with existing Swift syntax, a lot of the confusion that caused www.fuckingblocksyntax.com would be avoided.
>
> <snip>
>
> makeIncrementer(forIncrement: ^(number: Int) {
>
>    if (number == 3) { return true }
>
> })
>
> Why does the block now have to be declared within the function parameters?
> Why do I have to declare the type of number now?
> Why do I *not* have to declare the return type as being a boolean?
> Would this syntax still support single expression implicit returns, e.g.
> current Swift
>
> > [1,2,3].map() { number in number == 3 }
> $R0: [Bool] = 3 values {
>   [0] = false
>   [1] = false
>   [2] = true
> }
>
> By having ^ mark an upcoming closure, I think it's a lot easier to follow what's going on with declarations because as you read left to right, you're prepped that a closure syntax is coming up as you read left to right. It also allows you to keep the params outside of the closure, which I think is a win. Closure params would also have the same syntax everywhere, and be extremely similar to normal method calls which would be easier for new Swift users.
>
> 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
>
> When I declare a global or type-specific function, I can specify its name
> and arguments, assign external names to them (as well as internal names),
> and declare my return value. The types, even if generic, must be known for
> the function implementation to pass semantic checks.
>
> The syntax for functions as types are really just a list of input and
> output types. There are not (for instance) named parameter requirements on
> the implementing functions. But the input and return types must be known to
> declare a new function type.
>
> Anonymous functions assume a great deal of type information from the
> context in which they are used. This is why you can get away with not
> declaring input types or even input names (using $0, $1, etc), the return
> type or even if a value is returned. The code is mapped into the context it
> is needed, then semantic evaluation is done.
>
> You are attempting to change #2 and #3 at the same time, when really they
> have quite different needs. I assume the reason anonymous functions (aka
> closures in Swift) have their argument names on the inside of the block is
> because the argument names have no external bearing whatsoever. Considering
> I may or may not declare type information or even give all the parameters
> names, this makes a certain kind of sense. If you were to move the argument
> names outside the block, you would need a syntax specifically for that.
> There are enough options that reusing the same base syntax between 1 and 3
> or 2 and 3 would likely just _feel_ wrong.
>
> There are enough rules about escape analysis to possibly make sense to
> have function blocks, do blocks, repeat blocks, switch blocks, for…in
> blocks, etc all be considered ‘kinds’ of blocks, and for closure blocks to
> be on that list. It possibly makes sense for them to have a keyword just
> like all the other blocks to simplify compiler and human visual parsing.
> But I don’t envy the effort of redesigning and redecorating that particular
> bike shed :-)
>
> -DW
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151231/da11afeb/attachment.html>