>>>> But my primary point was just that in Rick's examples, there doesn't
>>>> appear to be any reliance on TCP at all. Had => supported blocks on the
>>>> RHS as in the original arrow proposal, all the code samples would be
>>>> simpler, simply removing the 'do'. I believe this will generally be true
>>>> too.
>> All of the cases that use () => do { } are doing so where they require
>> multiple statement expressions that inherit lexical |this|.
Right. In the original arrow syntax [1] proposal "() => { this.foo(); }" gave
lexical this with a statement body, which covers the use cases I saw in the
examples you shared. The point I was trying to make here is that lexical this
is a separate issue from TCP. If we deem it important to address lexical this
with a different variant of arrow, we can do that without needing to add TCP
preserving blocks. These can be separate concerns.
I actually think it's worth starting simple here (maximal minimalism again).
There is a lot of value in just having shorthand for exactly what 'function' is
used for today. Only statement bodies, no lexical this, nothing fancy for
nullary parameter lists. That alone would be a huge win, and would add
effectively no additional complexity/concept count.
Luke
[1]
http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax&rev=1307297899
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
