`await` is only treated as a FutureReservedWord sometimes

[jmdyck]

11.6.2.2 says:

FutureReservedWord ::
    `enum`
    `await`

`await` is only treated as a |FutureReservedWord| when
|Module| is the goal symbol of the syntactic grammar.

However, there's nothing that actually accomplishes what the prose says.

E.g., should there be a grammatical parameter 'Await' analogous to 'Yield'? Or should there be an Early Error that disallows 'await' as an identifier when it's within a Module?

[allenwb]

The normative text you quoted is what accomplish that. When parsing for goal symbol Script the definition for FuturseReservedWord is just

FutureReservedWord ::
         enum

[allenwb]

The normative text you quoted is what accomplish that. When parsing for goal symbol Script the definition for FuturseReservedWord is just

FutureReservedWord ::
         enum

[littledan]

My understanding of the motivation here is that we unfortunately can't go back and add reserved words to Script strict mode, as that may impact web compatibility. The async/await draft spec does add such a parameter analogous to yield: http://tc39.github.io/ecmascript-asyncawait/

[littledan]

My understanding of the motivation here is that we unfortunately can't go back and add reserved words to Script strict mode, as that may impact web compatibility. The async/await draft spec does add such a parameter analogous to yield: http://tc39.github.io/ecmascript-asyncawait/

[jmdyck]

@allenwb said:

The normative text you quoted is what accomplish that.

Okay, it just seems odd to have semi-formal mechanisms to specify when 'yield' is a reserved word, and not use them to specify when 'await' is a reserved word.

@littledan said:

The async/await draft spec does add such a parameter analogous to yield

Interesting. So would the ModuleItem production be changed?

  ModuleItem :
    ...
    StatementListItem[Await]

[jmdyck]

@allenwb said:

The normative text you quoted is what accomplish that.

Okay, it just seems odd to have semi-formal mechanisms to specify when 'yield' is a reserved word, and not use them to specify when 'await' is a reserved word.

@littledan said:

The async/await draft spec does add such a parameter analogous to yield

Interesting. So would the ModuleItem production be changed?

  ModuleItem :
    ...
    StatementListItem[Await]

[bterlson]

I don't think this has to change because whether or not the parameter is present, await will be parsed as a keyword when Module is the goal symbol.

[bterlson]

I don't think this has to change because whether or not the parameter is present, await will be parsed as a keyword when Module is the goal symbol.

[jmdyck]

I don't think this has to change because whether or not the parameter is present, await will be parsed as a keyword when Module is the goal symbol.

I wasn't (most recently) saying that the ModuleItem production has to change now, I was saying it would have to change when the Async Functions proposal is merged in. Because even with the magical sentence saying that await is a FutureReservedWord when Module is the goal symbol, that won't be enough to allow you to recognize an AwaitExpression. For that, you'll need to create a '+' setting for the Await param somewhere in the grammar, and ModuleItem seems like the logical place. (And incidentally, once you have that, you won't need the magical sentence any more. Not normatively, anyhow.)

[jmdyck]

I don't think this has to change because whether or not the parameter is present, await will be parsed as a keyword when Module is the goal symbol.

I wasn't (most recently) saying that the ModuleItem production has to change now, I was saying it would have to change when the Async Functions proposal is merged in. Because even with the magical sentence saying that await is a FutureReservedWord when Module is the goal symbol, that won't be enough to allow you to recognize an AwaitExpression. For that, you'll need to create a '+' setting for the Await param somewhere in the grammar, and ModuleItem seems like the logical place. (And incidentally, once you have that, you won't need the magical sentence any more. Not normatively, anyhow.)

[bterlson]

I think I understand what you're saying, but I think what you suggest is necessary if we want to allow await at top-level. Otherwise, the async function productions turning on the await parameter should be sufficient?

[bterlson]

I think I understand what you're saying, but I think what you suggest is necessary if we want to allow await at top-level. Otherwise, the async function productions turning on the await parameter should be sufficient?

[jmdyck]

Ah, okay, AsyncFunctionBody :: FunctionBody[Await] is where the Await param is 'turned on'. (I blame the difficulty of searching on grammar params!)

[jmdyck]

Ah, okay, AsyncFunctionBody :: FunctionBody[Await] is where the Await param is 'turned on'. (I blame the difficulty of searching on grammar params!)

[jmdyck]

Commit 18e18cf added the suggested Early Error.
PR #818 (and then #926) removed the sentence in question.

[jmdyck]

Commit 18e18cf added the suggested Early Error.
PR #818 (and then #926) removed the sentence in question.