Brendan Eich wrote:
If we buy into the cover grammar approach, used so far in ES6 drafts
(see "Supplemental Syntax"), then we still have some trouble if we want
to prefer
(x,y) => {p:x*y} // return an object literal
over parsing the body as a block statement. The problem is that the p:
looks like a label. For the arrow function syntax strawman,
This problem with {...} exists in this or that form in other places,
too... I don't see is as a big problem... You should parethesize because
{ implies code block. We should be already used to it. IMO.
http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax#grammar_changes
I wrote a two-token lookahead restriction. It seemed simpler than
alternatives, but it's a step up from k=1 lookahead.
An alternative, mostly-compatible change I drafted:
http://wiki.ecmascript.org/doku.php?id=strawman:block_vs_object_literal
The fundamental trade-off remains: object literals cannot grow extra
features (~ or ~ prefixes to property names, e.g.) that make them
ambiguous with block statements. This restriction is arguably not
future-hostile, rather user-friendly!
It is subjective, I think. I value expressiveness more.
/be
Herby
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
