> 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
