(x) => {foo: bar}

[Dean Landolt]

On Mon, Jan 5, 2015 at 6:06 PM, Brendan Eich <brendan at mozilla.org> wrote:

> Jasper St. Pierre wrote:
>
>> Unless
>>
>>     x => {foo: bar}
>>
>> and
>>
>>     x => {}
>>
>> both parse as object literals, I'm against your proposal. Either
>> un-paren'd braces are consistently a block, or they're consistently an
>> object literal. Python has had major pains with "i before e except after c"
>> rules to make the language nicer to use, and it's easier to tell people
>> "always add the parens".
>>
>
> Fair.
>
>  A third option is to make x => {foo: bar} a syntax error to steer people
>> away from an accidental footgun, while still making {} a block, and keeping
>> the consistency of "parens around object literals".
>>
>
> Just about too late for ES6, though. Eep!


Is it though? ISTM there's consensus that this is a footgun -- isn't that a
kind of spec bug? If it's too late to properly vet a change which narrowly
excludes from arrow bodies any `LabeledStatement` that isn't a
`WellLabeledStatement`, would it be feasible to simply exclude any
`LabeledStatement` for now? I doubt there's much code in the wild that
would be affected by this change -- certainly not yet. That'd buy plenty of
time to add back proper support for `WellLabeledStatement` arrow bodies in
es7.

Implicitly returning object literals would still require paren wrapping, of
course -- and in light of the empty object / empty block ambiguity this
seems inevitable. And we'll get a fail-fast compile error for the common
case (non-empty objects) to would help educate and remind us all of the
distinction.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150106/5900fafe/attachment-0001.html>