>>>> Great to see the arrow syntax proposal moving forward.
>>>>
>>>> I think I missed a step though in the reasoning for moving to this
>>>> proposal vs. the previous arrow proposal. What problem did the previous
>>>> proposal have that is addressed with the new proposal?
>> The ambiguity between a block body and an object literal expression body,
>> which we would prefer to resolve in favor of object literal. The solutions
>> considered before this edit were:
>> * http://wiki.ecmascript.org/doku.php?id=strawman:block_vs_object_literal
>> * Two-token lookahead restriction per
>> http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax&rev=1307297899#grammar_changes
>> Both are hairy and not near consensus in TC39. The first isn't
>> backward-compatible on edge cases that probably exist on the web. The second
>> is future-hostile.
Got it. I understood that ambiguity to be fully addressed by the two-token
lookahead proposal that was detailed in the wiki.
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. My understanding is that that is very
unlikely, and not the primary future hostility concern - is that right? 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?
Alternatively - resolving the ambiguity in favor of the block body feels
acceptable if it keeps the proposal simple in other key ways. As you noted,
except in the {} case, this will produce early errors that point to the
solution.
Luke
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
