Async arrow syntax

[lukehoban]

Several folks have raised concerns about the async arrows syntax in this proposal. In particular:

http.createServer(async (req,res) => { 
  await delay(1000); 
  res.end('Hello World\n') 
});

There are generally two issues:

1. Can this deal with ASI such that there are not ambiguities and such that this is forward compatible with the option of leaving off the argument list entirely?
2. Is this sufficiently readable as a syntax?

For the first, the concern is something like:

async ()
  => 3

Under a future proposal that allowed eliding arrow parameter lists, this would have to parse as two statements. So we would need to ensure it was not legal in the current proposal. I believe that can be managed by adding a [NoLineTerminator] between the parameter list and the => of the async arrow grammar. This would additionally mean that async arrows themselves could not elide their parameter lists, as this would be interpreted as a single parameter arrow in ES6 already.

For the 2nd, I personally believe this is syntactically okay. It is challenging to parse since it is not a reserved keyword, but it is possible to do using a cover grammar, and is something implementations can reasonably do. For users, this is very similar to "function", and when colorized in editors as a keyword or contextual keyword will be similarly easy to read.

Opening as issue to track feedback.

[zenparsing]

@lukehoban Was there a third issue?

1. In addition to what you've already stated, in my opinion there is really little incentive to move forward with optional-param arrows.
2. From my experience with https://github.com/zenparsing/esparse, I know that parsing your proposed syntax with a cover grammar is really not that difficult once you've already figured out how to parse arrows correctly. And as you state, users (and editors and highlighters) will think of "async" as a keyword going forward, so readability isn't going to be a problem.

Also, a big plus for this syntax is that it's completely generalizable to other potential function modifiers, should the need arise.

[zenparsing]

Also, your syntax doesn't include a paren-free version. I believe it can safely be added like:

async [NoNewLine] BindingIdentifier => ...

I think it would be surprising to leave this form out. What do you think?

[lukehoban]

Good points. I agree that this syntax has a nice generalizability.

Here's what the proposed grammar extensions would be:

AsyncArrowFunction :
    async [no LineTerminator here] ArrowParameters  [no LineTerminator here] => ConciseBody

AssignmentExpression :
    ...
    AsyncArrowFunction

[zenparsing]

Minor points:

The [no LineTerminator here] is not strictly required before a left paren since:

async 
()

is always parsed as a function call (no ASI rules apply).

If we're really trying to preserve the option of elided arrow params, do we want to add that second [no LineTerminator here] restriction to regular arrow functions in ES6? (I don't see that restriction in the current draft.)

// Successfully parses with ES6 grammar
x = y
=> 1;

My personal opinion is that the second [no LineTerminator here] is overly pandering to ASI. Discarding it isn't really that hostile to elided arrow params.

[lukehoban]

Opened https://bugs.ecmascript.org/show_bug.cgi?id=2654 on the ES6 point.

The feedback at TC39 meeting last week was to keep async arrow sytnax as is, but to stay with the conservative [no LineTerminator here] annotations.