(x) => {foo: bar}

Dean Landolt dean at deanlandolt.com
Tue Jan 6 07:34:14 PST 2015

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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150106/5900fafe/attachment-0001.html>

More information about the es-discuss mailing list