[swift-evolution] Lambda function syntax

Chris Lattner clattner at apple.com
Mon Dec 21 17:24:56 CST 2015


> On Dec 21, 2015, at 2:44 PM, Alexander Regueiro <alexreg at gmail.com> wrote:
> 
> Okay, I assume you are aware this essentially the same syntax as used in languages like C# and Python, yes? I’m not sure there are any problems in those languages with it.
> 
>> If you dig through (very early) history you’ll see that we had this.  There are a couple of problems with it:
>> 
>> 1) It punishes simple cases like “X.sort { $1 < $0 }”, along with lots of simple map and filter closures.
> 
> Not really. The above example would just be `X.sort func { $1 < $0 }” or "X.sort \ { $1 < $0 }` in my proposed syntax. Also, it would be nice to have all operators implicitly convertible to functions, or at the very least have corresponding function definitions for all built-in & standard library operators. Haskell does this really nicely (functions and operators are basically interchangeable, and either can be used in prefix or infix mode). Anyway, your above example might look something like `X.sort (>)` (since `(<)` would take arguments in the opposite order).

Swift already supports this.  X.sort(>) works fine today.  I don’t think that that detracts from the point, since there are lots of other simple closures :-)

> 
>> 2) It reads really weird in trailing closure cases.
> 
> Honestly, I strongly dislike trailing closures. I don’t think they add much, and moreover they use a confusing syntax that make the whole function call look superficially like a function declaration (or indeed the whole thing being a closure).

Ok, but you’re going to have to grapple with the fact that they are an important aspect of swift design.  If you want your proposal to be seriously considered, it needs to consider them.

>> Lets step back: What problems are you trying to solve with the current closure syntax?
> 
> Readability, mainly. I think this is a big improvement. Also, consistency of semantics. Everything else between curly braces represents a list of statements and is conceptually the “body” of something (a function, a conditional, a loop). The current closure syntax rather embeds the head into the body! Then there’s similarity with other languages, which is minor, but nice. I don’t know any language that uses a syntax like the current one of Swift.

Since your recent proposal has serious tradeoffs, you should explain how each of the changes it forces measures on this.

Further, keep in mind that swift supports nested functions, which yield a very similar experience to what you’re proposing.

-Chris


More information about the swift-evolution mailing list