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 <[email protected]> wrote:
>
>
>> On Dec 21, 2015, at 1:33 PM, Alexander Regueiro <[email protected]> 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 <[email protected]> wrote:
>>>
>>>>
>>>> On Dec 21, 2015, at 11:20 AM, Alexander Regueiro via swift-evolution
>>>> <[email protected]> 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
>>
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
