(x) => {foo: bar}

[Marius Gundersen]

I don't see how wellLabeledStatement will protect against object literals
with shorthand properties, like (x, y, z) => {x, y, z}.

The solution to the block vs object problem today is to wrap the object in
parenthesis, but not the block. The only alternative that is easy for
humans to understand and not ambiguous for machines is to wrap or prefix
the block, but not the object, for example with do:

x => do {
  let a = 5;
  return a*x;
}

AFAIK do expressions are not in ES6, but might be in ES7.

Marius Gundersen
On 6 Jan 2015 19:42, "Brendan Eich" <brendan at mozilla.org> wrote:

> Sorry, sent too soon.
>
> Dean Landolt wrote:
>
>> 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.
>>
>
> The ES6 grammar has not been refactored per my old strawman. It has no
> WellLabeledStatement non-terminal.
>
> For ES6, we would need another production parameter to FunctionBody,
> FunctionStatementList, and StatementList (at least) by which to restrict a
> ConciseBody : { FunctionBody } such that the FunctionBody :
> FunctionStatementList (via FunctionStatementList : StatementList[opt],
> StatementList StatementListItem, etc.) doesn't start with a
> LabelledStatement.
>
> Cc'ing Allen and Waldemar for their thoughts.
>
> /be
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150106/41e4adfe/attachment.html>