Questions re. final fat arrow syntax
Angus Croll wrote:
Apologies if this is not yet nailed down. I'm looking for the following details re. the arrow function grammar which I was unable to determine from the strawman proposal:
- Will the syntax support more than an expression in the function body? The proposal appeared to be veering towards expression only syntax - although this could be mitigated by the ES 6 proposed do {} syntax.
The grammar at
strawman:arrow_function_syntax
is clear enough: both expression and braced block body alternatives.
- Will the grammar allow for implicit returns in the manner of Ruby, CoffeeScript. Seems to be the case for expression bodies.
Only for that case.
If multiple statements are allowed (within block syntax) will implicit return apply to the last statement or does explicit return become necessary?
No, please read the sub-thread starting at
- Are parenthese required for zero arguments or will let a = => doThis(); syntax be permitted (in line with CS)
This too is clearly specified by
strawman:arrow_function_syntax#grammar_changes
ArrowFormalParameters, second right-part.
Thanks for writing. I take it from twitter you want soft-bound-|this| so a .call or .apply (or new?) can override lexical-this?
- Are parenthese required for zero arguments or will let a = => doThis(); syntax be permitted (in line with CS)
This too is clearly specified by
strawman:arrow_function_syntax#grammar_changes
ArrowFormalParameters, second right-part.
That seems useful. What’s the rationale for not support it?
Thanks!
Axel
Not given. TC39ers (not all, just ones near me) started blenching (or is it blanching? no, blenching). The issue was muddled because the optional body-block was mixed in (i.e., the minimal arrow function, as in CoffeeScript, was just |=>| in the previous version of the strawman).
As I've said a couple of times here, we could try again to reach consensus on making () as empty arrow formal parameter list optional, and separately consider making an empty body-block optional. I'll work on the nearby blenchers before the May meeting and see about putting it on the agenda.
As I've said a couple of times here, we could try again to reach consensus on making () as empty arrow formal parameter list optional,
Seems useful, but not worth upsetting anyone over.
and separately consider making an empty body-block optional.
Sorry if I missed this, but: What would this be used for?
Axel Rauschmayer wrote:
As I've said a couple of times here, we could try again to reach consensus on making () as empty arrow formal parameter list optional,
Seems useful, but not worth upsetting anyone over.
The issue may not be undiagnosed upset-ness, rather ASI.
Leaving out () in front of => in a language such as CoffeeScript, which
has significant newlines, is easier than making the empty arrow formal parameters optional in JS. True, a parenthesized expression statement usually won't be mistaken for a parameter list, and an arrow usually won't start a statement.
But code generators and machine or human editors might manage to produce
( a, b ) => c ( d );
I'm not very worried about this biting anyone, but it's a potential objection and one I suspect blenching TC39ers near me would make.
and separately consider making an empty body-block optional.
Sorry if I missed this, but: What would this be used for?
Just a short-hand for returning undefined, for a stub function.
Apologies if this is not yet nailed down. I'm looking for the following details re. the arrow function grammar which I was unable to determine from the strawman proposal:
Will the syntax support more than an expression in the function body? The proposal appeared to be veering towards expression only syntax - although this could be mitigated by the ES 6 proposed do {} syntax.
Will the grammar allow for implicit returns in the manner of Ruby, CoffeeScript. Seems to be the case for expression bodies. If multiple statements are allowed (within block syntax) will implicit return apply to the last statement or does explicit return become necessary?
Are parenthese required for zero arguments or will let a = => doThis();
syntax be permitted (in line with CS)
thank you Angus