arrow function syntax simplified

Luke Hoban lukeh at microsoft.com
Tue Mar 27 16:01:31 PDT 2012


>>>> 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



More information about the es-discuss mailing list