[swift-evolution] Lambda function syntax

[Chris Lattner]

> On Dec 21, 2015, at 1:33 PM, Alexander Regueiro <alexreg at gmail.com> wrote:
> 
> Hi Chris,
> 
> Don’t you think the suggestion is better? I’m happy to formula it in terms of an E(BNF) grammar if you like. Is this published/available anywhere, for the current version of Swift?

My personal opinion is “no”, because it will look very weird in trailing closure, in the argument lists for function calls, etc.

Further, it would not permit dropping ()’s on closure arguments, you wouldn’t be able to write this:

foo({ lhs, rhs in … })

because the  comma would be exposed out to the function call.

The grammar is described in the reference section of TSPL:
https://swift.org/documentation/

In addition to proposing EBNF, please consider the existing grammar so that the new proposal isn’t completely ambiguous.  What you are proposing would be an extremely tricky thing to do.

-Chris


> 
> Thanks.
> 
>> On 21 Dec 2015, at 19:22, Chris Lattner <clattner at apple.com> wrote:
>> 
>>> 
>>> On Dec 21, 2015, at 11:20 AM, Alexander Regueiro via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> Does anyone not like the current syntax for this?
>>> 
>>> I would propose changing it from:
>>> 
>>> { (param_list) -> return_type in … }
>>> 
>>> to something cleaner like:
>>> 
>>> (param_list) -> return_type => { … }
>>> 
>>> where I’m not so bothered about the `=>` separator (could be `:`, `,`, or indeed `in`).
>>> 
>>> The braces being around the type specifier as well as function body rather bothers me. Surely it would be more consistent just to have the braces around the function body, and then the type specifier preceding this?
>> 
>> Hi Alexander,
>> 
>> We’re open in principle to replacing closure syntax with something better, but A) it needs to be actually better, and B) it needs to fit with the swift grammar.  If you’re interested in pushing forward in this area, please familiarize yourself with the structure of the grammar and propose what you’re thinking in terms of a diff to it.  Thanks,
>> 
>> -Chris
>