optional "function" keyword

Herby Vojčík herby at mailbox.sk
Fri Mar 9 14:19:30 PST 2012

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


More information about the es-discuss mailing list