[swift-evolution] Lambda function syntax

[Alexander Regueiro]

Thanks for clarifying.

In that case, I would propose grammar for capture expressions, which should drop in without modifications elsewhere (I say tentatively):

 closure-expression → “func" closure-signature_opt { statements }
‌ closure-signature → parameter-clause function-result_opt
‌ closure-signature → identifier-list function-result_opt
‌ closure-signature → capture-list parameter-clause function-result_opt
‌ closure-signature → capture-list identifier-list function-result_opt
‌ closure-signature → capture-list
‌ capture-list → [ capture-list-items ]
‌ capture-list-items → capture-list-item | capture-list-item , capture-list-items
‌ capture-list-item → capture-specifier_opt expression
‌ capture-specifier → weak | unowned | unowned(safe) | unowned(unsafe)

I am open to whether the introducing keyword is “func” (overloading the existing keyword but in an evidently separate context, and unambiguously I believe) – or “lambda” (like Python), or “\” (like Haskell) – or even something like “cl” (for Closure). Note that the aforementioned adds an additional keyword, but also removes the the “in” keyword. For reasons mentioned in my previous message, I believe this syntax is both clearer and more consistent. It’s also more in line with other widespread languages (in my experience).

For reference, the current grammar is:

 closure-expression → { closure-signature_opt statements }
‌ closure-signature → parameter-clause function-result_opt “in"
‌ closure-signature → identifier-list function-result_opt “in"
‌ closure-signature → capture-list parameter-clause function-result_opt “in"
‌ closure-signature → capture-list identifier-list function-result_opt "in"
‌ closure-signature → capture-list “in"
‌ capture-list → [ capture-list-items ]
‌ capture-list-items → capture-list-item | capture-list-item , capture-list-items
‌ capture-list-item → capture-specifier_opt expression
‌ capture-specifier → weak | unowned | unowned(safe) | unowned(unsafe)

Also, I didn’t bother making braces optional, since I hear that the original language designers wanted to avoid the problems that optional braces have the potential to introduce (e.g. in C-style languages). There are no round brackets used in my above syntax either, which is consistent with their absence in expressions in conditional and loop statements.

Thoughts?

> On 21 Dec 2015, at 21:47, Chris Lattner <clattner at apple.com> wrote:
> 
> 
>> 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
>> 
>