(x) => {foo: bar}
Caitlin Potter
caitpotter88 at gmail.com
Mon Jan 5 12:06:30 PST 2015
> You mean replace the footgun with a smaller one, maybe one so small it
doesn't matter. Saying that the proposal doesn't get rid of the footgun
means it still remains impossible to write x => {p: x} and not get what
Frankie and others want: an arrow returning an object. But the proposal
does fix that footgun.
>
> How often do you really want an empty object instead of a block with no
statements?
Okay, good point about the (lack of) ambiguity in terms of how
it's interpreted, but what I'm talking about is how it looks like it should
work. It looks like a function body and an object literal, and it doesn't
matter which one is used more frequently, because it's going to bite people
one way or the other. Rules about what sorts of statements are allowed as
the first statement in a block is also going to bite people some times.
Because it bites fewer people, there will be fewer people who have dealt
with it and are able to explain it, so it becomes one of those "gotchas" of
the language.
This is my personal opinion, but I think the "wrap object literals in
parentheses for concise bodies" is much simpler to explain to people than
more complicated rules. Simple is good :>
On Mon, Jan 5, 2015 at 2:54 PM, Brendan Eich <brendan at mozilla.org> wrote:
> Caitlin Potter wrote:
>
>> The strawman changes to the grammar are still ambiguous :(
>>
>> `() => {}` -> noop or Object or SyntaxError? If SyntaxError, ...why?
>>
>
> No, the strawman addresses this: "An empty pair of braces |*{}*| other
> than at start of /Statement/ is an /ObjectLiteral/." The grammar is
> unambiguous. Notice the meta-? in the first production RHS below, and the
> non-empty-producing nature of the second:
>
> Block:
> { UnlabeledStatementFirstList? }
> { WellLabeledStatement StatementList? }
>
> UnlabeledStatementFirstList:
> UnlabeledStatement
> UnlabeledStatementFirstList Statement
>
>
> The final piece of the puzzle is here:
>
> We retain the |[lookahead ∉ {*{*, *function*}]| restriction in
> /ExpressionStatement/. At the start of a statement, |*{*| can be the start
> of a block only, never an object literal.
>
> I think hacking around this would not get rid of the footgun, but would
>> just make it more complicated to understand the footgun, personally.
>>
>
> You mean replace the footgun with a smaller one, maybe one so small it
> doesn't matter. Saying that the proposal doesn't get rid of the footgun
> means it still remains impossible to write x => {p: x} and not get what
> Frankie and others want: an arrow returning an object. But the proposal
> does fix that footgun.
>
> How often do you really want an empty object instead of a block with no
> statements?
>
> /be
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150105/601a7ec5/attachment-0001.html>
More information about the es-discuss
mailing list