Editorial: Fix return value logic for async arrow functions

[TimothyGu]

Introduce a new production ExpressionBody for both plain and async arrow functions, and allow correctly handling return value logic for both. Currently, AsyncFunctionStart does not correctly handle the return value of async arrow functions correctly.

[zenparsing]

This is a bug with the current specification, correct?

[TimothyGu]

@zenparsing Yes I believe so

[anba]

I wonder if a better approach to fix this issue is to add a new runtime semantics to evaluate AssignmentExpressions for arrow-function like contexts.

14.2.15 Runtime Semantics: EvaluateBody has:

1. ...
2. Let exprRef be the result of evaluating AssignmentExpression.
3. Let exprValue be ? GetValue(exprRef).
4. Return Completion { [[Type]]: return, [[Value]]: exprValue, [[Target]]: empty }.

which is exactly what we need here for async arrow functions, i.e. evaluate an AssignmentExpression and then convert the result into a Return completion. (Plus it also handles GetValue which also seems to be missing for async arrow functions.).

The same steps are executed in the class fields proposal at https://tc39.github.io/proposal-class-fields/#runtime-semantics-class-public-field-definition-evaluation, so we soon have three places which could use a single shared definition.

---

I haven't verified if this works, but the quick'n dirty approach to get this working may be to add a wrapper around AssignmentExpression, so we get:

FunkyAssignmentExpression[In, Yield, Await]:
  AssignmentExpression[In?, Yield?, Await?]

ConciseBody[In]:
  [lookahead ≠ {] FunkyAssignmentExpression[?In, ~Yield, ~Await]
  { FunctionBody[~Yield, ~Await] }

AsyncConciseBody[In]:
  [lookahead ≠ {] FunkyAssignmentExpression[?In, ~Yield, +Await]
  { AsyncFunctionBody }

FieldDefinition[Yield, Await]:
  ClassElementName[?Yield, ?Await] FieldInitializer opt

FieldInitializer:
  = FunkyAssignmentExpression[In, ~Yield, ~Await]

with:

Runtime Semantics: Evaluation

FunkyAssignmentExpression: AssignmentExpression
1. Let exprRef be the result of evaluating AssignmentExpression.
2. Let exprValue be ? GetValue(exprRef).
3. Return Completion { [[Type]]: return, [[Value]]: exprValue, [[Target]]: empty }. 

[TimothyGu]

@anba I went with your approach. @tc39/ecma262-editors please take a look.

[ljharb]

@TimothyGu can you rebase this and resolve the conflicts?

[TimothyGu]

@ljharb Rebased

[ljharb]

ping @waldemarhorwat

[syg]

Musing: I wonder if we should have ecmarkup auto-generate chain production expansions somehow so the reader can get a clickable link for the RHS.

[jmdyck]

Theoretically possible, but I think it would go substantially beyond ecmarkup's current capabilities just to deduce the chain rules that have been left implicit.

[ljharb]

Rubberstamp based on existing approvals.