On Dec 21, 2015, at 2:26 PM, Alexander Regueiro <[email protected]> wrote:
> 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 }
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.
2) It reads really weird in trailing closure cases.
Lets step back: What problems are you trying to solve with the current closure
syntax?
-Chris
> 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
