Expression Closures as Compliment to Arrow Functions

Brendan Eich brendan at mozilla.org
Wed Mar 25 13:30:28 UTC 2015


Jacob Parker wrote:
>
> Could the comma not be the delimiter, as I think works with arrow 
> functions, or is that more precedence issues?
>

No precedence issue, due to AssignmentExpression (not Expression) being 
the right-most non-terminal produced by the unbraced alternative for 
ConciseBody.

In a class body, comma is the wrong separator (delimiter? trailing comma 
allowed in most JS contexts, but still) -- see the live ES7 proposal 
from Jeff Morrison, inspired by TypeScript and Flow:

https://gist.github.com/jeffmo/054df782c05639da2adb

Class bodies are not object initialisers, in notable ways, even though 
concise methods have the same syntax and (parameterizing `super` 
differently according to context) semantics.

Class bodies are not block statements, either, of course. But this 
doesn't rule out ; or favor , instead. It just means no ASI insanity. ;-)

/be
>
> On Wed, 25 Mar 2015 8:37 am Brendan Eich <brendan at mozilla.org 
> <mailto:brendan at mozilla.org>> wrote:
>
>     Jacob Parker wrote:
>     > In the context of only objects and classes, is this format no-go?
>
>     Without the } that closes a concise method body, there's a new problem
>     to-do with computed property names:
>
>     class C {
>        m() this._m
>        [Symbol.iterator]() {/*...*/}
>     }
>
>     We need a delimiter. Could use ; without ASI, so it'd look like this:
>
>     class C {
>        m() this._m;
>        [Symbol.iterator]() {/*...*/}
>     }
>
>     I haven't checked for other problems, but wanted to throw this out and
>     see if anyone else sees a live one.
>
>     /be
>


More information about the es-discuss mailing list