We didn't talk about this change. It is yet another migration early-error to
consider. It's certainly simpler than a more powerful parsing algorithm than
LR(1), but we might want to cross that bridge anyway for arrow functions. If we
succeed there, we may not need such an incompatible restriction on labels.
/be
On May 28, 2011, at 1:49 AM, Jorge wrote:
> On 27/05/2011, at 12:24, Brendan Eich wrote:
>> On May 27, 2011, at 2:36 AM, Jorge wrote:
>>
>>> Also, I wonder if in order to make blocks first class, do we need any new
>>> syntax ?
>>>
>>> function f() {
>>> a.forEach({ return 3 });
>>
>> The problem is that a block statement is ambiguous with an object
>> initialiser. See
>> http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax#grammar_changes
>> in particular the "To enable unparenthesized ObjectLiteral expressions as
>> bodies of arrow functions, without ambiguity with Block bodies, restrict
>> LabelledStatement as follows..." section.
>
> As labels are seldom used in JS, perhaps the easiest way to avoid ambiguities
> would be to forbid blocks from beginning with a label ?
>
> Would it be too much (or too ugly) to require the programmer to disambiguate
> (only) in this corner case ?
>
> An object:
> { label: expression }
>
> An error:
> { label: return 5 }
>
> A block:
> { ; label: expression }
>
> A block:
> { noLabelHere ... }
> --
> Jorge.
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
