-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Comments
The normative text you quoted is what accomplish that. When parsing for goal symbol Script the definition for FuturseReservedWord is just
|
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/ |
@allenwb said:
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:
Interesting. So would the ModuleItem production be changed?
|
I don't think this has to change because whether or not the parameter is present, |
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 |
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 |
Ah, okay, |
11.6.2.2 says:
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?
The text was updated successfully, but these errors were encountered: