-
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
Most implementations seem to have missed that await x ** 2
is not legal
#2197
Comments
Incidentally I'd be happy with making this legal, since |
My vote is more to keep things as is and fix implementations if possible, as it's more inconsistent otherwise. |
As an extra step, this proves that each browser is parsing it as (async function f() {
const obj = {
valueOf() {
console.log('Parsed as `await (X ** 2)`');
return 1;
},
then(f) {
console.log('Parsed as `(await X) ** 2`');
f(2);
},
};
const value = await obj ** 2;
return value;
})() |
Does it the same order for "await x + y" (await x) + y not await (x + y)? |
Yes, |
Another fun case: (async () => {
await -x ** 2;
})(); The tools which forbid |
Are there test262 tests for this case? |
…and side of an exponentiation expression. r=yulia We simply missed to classify `await` expressions as unary expressions. Spec issue: tc39/ecma262#2197 Depends on D101014 Differential Revision: https://phabricator.services.mozilla.com/D101015
…and side of an exponentiation expression. r=yulia We simply missed to classify `await` expressions as unary expressions. Spec issue: tc39/ecma262#2197 Depends on D101014 Differential Revision: https://phabricator.services.mozilla.com/D101015 UltraBlame original commit: 63f1d59a1cef6405af9caf9f0d20b60eb40c137c
…and side of an exponentiation expression. r=yulia We simply missed to classify `await` expressions as unary expressions. Spec issue: tc39/ecma262#2197 Depends on D101014 Differential Revision: https://phabricator.services.mozilla.com/D101015
Consensus from discussion in plenary was that we should leave it as-is but add a test262 for it. Speaking as editor, I also think it warrants a note in the spec itself. |
Just to clarify, you mean leave the spec text as-is, right? |
The normative text, yes. I think it warrants an editorial note. |
Moving discussion from microsoft/TypeScript#40916.
Quoting @DanielRosenwasser:
My reading (now that I look) matches his. But V8, SpiderMonkey, JavaScriptCore, engine262, babel, shift, flow, and acorn all seem to have missed this. (But not TypeScript or XS!) We should probably call it out with a big note in the spec, or, since it might now be web reality, possibly change the spec to match implementations.
The text was updated successfully, but these errors were encountered: