| 00:00 | <rkirsling> | so even though direct eval might feel conceptually simpler (and perhaps even be simpler in implementation), the spec change really would involve "adding a new direct eval case"? |
| 00:01 | <rkirsling> | i.e. because an optional call isn't a CallExpression we'd actually need to duplicate the algo text corresponding to the direct call? |
| 00:04 | <rkirsling> | i.e. we'd need to copy all of step 6 @ https://tc39.es/ecma262/#sec-function-calls-runtime-semantics-evaluation or make it an AO |
| 00:04 | <rkirsling> | I can see why people would feel hesitant about that |
| 00:04 | <rkirsling> | (even if it's potentially backwards wrt priority of constituencies) |
| 00:07 | <rkirsling> | hmm also |
| 00:08 | <rkirsling> | 6. If Type(ref) is Reference, IsPropertyReference(ref) is false, and GetReferencedName(ref) is "eval", then |
| 00:08 | <rkirsling> | a. If SameValue(func, %eval%) is true, then |
| 00:08 | <rkirsling> | does that mean a local `eval` is still direct eval? |
| 00:19 | <bakkot_> | yup |
| 00:20 | <bakkot_> | `{ let a = 0; let eval = window.eval; eval('a') }` // 0 |
| 00:23 | <shu> | as long as it's the same thing and is spelled e-v-a-l, yeah |
| 00:24 | <shu> | (not sure if any other way is implementable, unless eval() was specced as special syntax like import()) |
| 00:27 | <devsnek> | reminder of #tc39 |
| 00:30 | <rkirsling> | right right, failing right off the bat, we can move |