| 00:20 | <shu> | i'm looking at `await`-as-identifier rules in v8's implementation of static blocks and i'm kind of confused |
| 00:21 | <shu> | it seems like the intention was that `await` is allowed as an identifier in both named function expressions and named class expressions |
| 00:21 | <shu> | but |ClassExpression| has BindingIdentifier[?Await] |
| 00:22 | <shu> | |FunctionExpression| has BindingIdentifier[~Await] |
| 00:25 | <shu> | also |FunctionExpression| has FunctionParameters[~Await] while |ArrowFunction| has ArrowParameters[?Await] |
| 00:52 | <Bakkot> | so there's a couple things going on there |
| 00:53 | <Bakkot> | > `await` is allowed as an identifier in both named function expressions |
| 00:53 | <Bakkot> | true, because it's a function boundary |
| 00:53 | <Bakkot> | > and named class expressions |
| 00:53 | <shu> | oh, i think the spec has been updated since i last looked at it |
| 00:53 | <Bakkot> | no, class bodies inherit the ability to `await` from the surrounding environment - e.g. in a class within an async function, you can do `class { [await x](){} }` or whatever |
| 00:53 | <shu> | it's now specced as an [~Await] on every statement item |
| 00:54 | <Bakkot> | > also |FunctionExpression| has FunctionParameters[~Await] while |ArrowFunction| has ArrowParameters[?Await] |
| 00:54 | <shu> | sorry, i didn't mean as identifiers _inside_ class bodies, i meant as the names |
| 00:55 | <Bakkot> | the reason `ArrowParameters` has `?Await`, unlike `FunctionParameters`, is because of the cover grammar - you don't know you're parsing arrow parameters until you get to the end, and you don't want to have to go back and re-parse, so they're parsed with `?Await` and then there's an early error for arrow parameters containing AwaitExpression |
| 00:55 | <shu> | right |
| 00:55 | <shu> | i suspect the BindingIdentifier[?Await] for the named class expressions is a spec bug? |
| 00:56 | <Bakkot> | why would it be? class bodies inherit async-ness, no reason the name shouldn't |
| 00:56 | <shu> | i see, okay, so... |
| 00:56 | <shu> | if the intention is that static blocks be parsed like async function bodies for future-proofing await inside static blocks... |
| 00:57 | <shu> | then `(class await {})` should not be allowed, even though `(function await() {})` is? |
| 00:58 | <Bakkot> | > if the intention is that static blocks be parsed like async function bodies for future-proofing await inside static blocks |
| 00:58 | <Bakkot> | yup |
| 00:58 | <Bakkot> | > then `(class await {})` should not be allowed, even though `(function await() {})` is? |
| 00:58 | <Bakkot> | that's my intuition, yes |
| 00:58 | <Bakkot> | (assuming you are in an async context for both those last code snippets) |
| 00:59 | <shu> | now, `async function f() { ((await)=>1); }` doesn't parse, right? that is, `await` is not parsed as identifiers for arrow function parameters inside async function bodies? |
| 00:59 | <Bakkot> | correct |
| 00:59 | <Bakkot> | because `ArrowParameters` has `?Await` |
| 00:59 | <shu> | right, exactly |
| 01:00 | <shu> | okay, then i think some of these test262 tests are wrong, as are some items in https://github.com/tc39/proposal-class-static-block/issues/43#issuecomment-812224819 |
| 01:00 | <shu> | but this is all good news |
| 01:00 | <shu> | i am very much against a _new_ kind of context for determining where awaits are allowed as identifiers |
| 01:00 | <shu> | and static block == async function body is eminently workable |
| 01:01 | <Bakkot> | yeah I see that comment has `(class await {}); // legal`, which is wrong |
| 01:02 | <Bakkot> | otherwise I think it is correct |
| 01:04 | <shu> | yeah, ron's example doesn't have arrow params, https://github.com/tc39/test262/pull/2968#pullrequestreview-660291176 does unfortunately |
| 01:04 | <Bakkot> | oh, the next comment in that thread calls out that discrepancy, I see |
| 01:04 | <shu> | but not merged yet! so still time |
| 01:05 | <shu> | anyway i think the constraint must be "parsing `await` inside static blocks as you would inside async function bodies" |
| 01:07 | <Bakkot> | yeah |
| 01:07 | <Bakkot> | I really want it to be specified that way: https://github.com/tc39/proposal-class-static-block/issues/27#issuecomment-724955380 |
| 01:07 | <Bakkot> | but that is not how it is currently written |
| 01:09 | <shu> | yeah, definitely +1 from me now for that approach after trying to understand these tests |
| 01:17 | <Bakkot> | I really ought to have insisted on it for stage 3 |
| 01:17 | <Bakkot> | I would've if I'd remembered how many edge cases there are, with arrow parameters and so on |