Questions re. final fat arrow syntax

# Angus Croll (13 years ago)

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:

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

  2. 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?

  3. Are parenthese required for zero arguments or will let a = => doThis();

syntax be permitted (in line with CS)

thank you Angus

# Brendan Eich (13 years ago)

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:

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

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

esdiscuss/2012-March/021879

  1. 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?

# Axel Rauschmayer (13 years ago)
  1. 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

# Brendan Eich (13 years ago)

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.

# Axel Rauschmayer (13 years ago)

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?

# Brendan Eich (13 years ago)

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.