Luke Hoban wrote:
The future hostility concern doesn't seem so serious as to kill this proposal -
especially relative to the value of simple short function syntax. The future
hostility would only seem to come in if we introduced new object literal syntax
which was truly ambiguous with blocks.
That was proposed for ES6, and while the particular proposal was
withdrawn (the ~, !, and other prefixes on property names in object
literals), the general issue is freedom in the future to extend object
literal syntax in a way that is ambiguous with block syntax.
Right now, because a { at start of statement must be the start of a
block, there's no new hardship and only the long-standing (ES3 era)
one-token lookahead restriction.
Adding new restrictions, IIRC, did not fare well last year at a TC39
meeting. I can't find a record in the notes about this other than
https://mail.mozilla.org/pipermail/es-discuss/2011-May/014758.html
Cc'ing Waldemar.
My understanding is that that is very unlikely, and not the primary future
hostility concern - is that right?
I think it's the only hostility concern.
If the new syntax does not have true ambiguities, it can be addressed in the
future by expanding lookahead if needed. Perhaps there is a concrete syntactic
extension that has caused concern?
Adding lookahead is risky because of ASI and regular expression vs.
division "/" modality. I haven't worked through all the issues myself,
and that is one reason I simplified arrow function syntax today.
Alternatively - resolving the ambiguity in favor of the block body feels
acceptable if it keeps the proposal simple in other key ways.
TC39 members rejected this approach. An expression-bodied short function
should admit the entire expression being an object literal, no extra
parentheses required. Doug was quite outspoken on this point.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
