Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

await is only treated as a FutureReservedWord sometimes #362

Closed
jmdyck opened this issue Feb 5, 2016 · 8 comments
Closed

await is only treated as a FutureReservedWord sometimes #362

jmdyck opened this issue Feb 5, 2016 · 8 comments
Labels

Comments

@jmdyck
Copy link
Collaborator

jmdyck commented Feb 5, 2016

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
Copy link
Member

allenwb commented Feb 5, 2016

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

FutureReservedWord ::
         enum

@littledan
Copy link
Member

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
Copy link
Collaborator Author

jmdyck commented Feb 5, 2016

@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
Copy link
Member

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
Copy link
Collaborator Author

jmdyck commented Feb 11, 2016

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
Copy link
Member

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
Copy link
Collaborator Author

jmdyck commented Feb 18, 2016

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

@jmdyck
Copy link
Collaborator Author

jmdyck commented Jul 30, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants