| 13:42 | <bradleymeck> | shu: do weakrefs allow finalizers on the value of a private field if there is no references to the private identifier anymore? |
| 13:44 | <bradleymeck> | e.g. `function hmmm(a) { class O { #a; constructor(a) {this.#a = a;} }; return new O(a); }` would that prevent `a` from having finalizers run? |
| 13:44 | <bradleymeck> | would s/that/the return value/ |
| 14:33 | <devsnek> | I guess that sort of requires treating private symbols like ephemerons |
| 14:34 | <bradleymeck> | i'm completely fine with it never running finalizers personally |
| 14:35 | <bradleymeck> | i just am struggling to understand this situation |
| 14:35 | <devsnek> | if a private field is created but there are no references around to observe it did it ever really happen |
| 14:37 | <bradleymeck> | well it is `unreachable` isn't super clearly defined |
| 14:52 | <shu> | bradleymeck: not sure i understand |
| 14:53 | <shu> | bradleymeck: what value is the finalized registered to in the example, a? |
| 14:53 | <bradleymeck> | shu: so if I have an Object `a` and it has a private field `#foo` |
| 14:54 | <bradleymeck> | if `a.#foo` is no longer reachable since all code that has the identifier `#foo` in scope has been collected, can you collect `a.#foo`/run its finalizer |
| 14:55 | <bradleymeck> | this was brought up when discussing symbols in weak collections yesterday in Realms call @_o |
| 14:55 | <shu> | oh i see |
| 14:55 | <shu> | that depends on the optimizations an engine does around private fields |
| 14:56 | <shu> | seems to reduce to escape analysis in general, so unlikely to be done in the interpreter and baseline tiers |
| 14:56 | <bradleymeck> | i'd agree there, just more trying to see if it was prohibited for some reason |
| 14:56 | <shu> | no not prohibited |
| 14:56 | <bradleymeck> | ok |
| 14:57 | <shu> | just seems unlikely to happen in practice to me |
| 16:25 | <jmdyck> | question re TemplateCharacter :: `\` NotEscapeSequence |
| 16:27 | <jmdyck> | There are early error rules that disallow it in untagged TemplateLiterals, but it's allowed in tagged TemplateLiterals, right? |
| 16:27 | <Bakkot> | right |
| 16:28 | <Bakkot> | per https://github.com/tc39/proposal-template-literal-revision |
| 16:28 | <Bakkot> | s/per/as a consequence of/ |
| 16:29 | <devsnek> | good consequences |
| 16:30 | <jmdyck> | Ok, so the TV of `\` NotEscapeSequence is *undefined*, and that'll come up when you invoke TemplateStrings with _raw_ = *false*, right? |
| 16:31 | <Bakkot> | sounds right to me |
| 16:32 | <jmdyck> | So in GetTemplateObject, an element of _cookedStrings_ might be *undefined*? |
| 16:32 | <Bakkot> | indeed |
| 16:32 | <Bakkot> | that's observable in userland, even: |
| 16:32 | <jmdyck> | but it also says "Let _cookedValue_ be the String value _cookedStrings_[_index_]." |
| 16:32 | <Bakkot> | console.log`\x` is an array with `0` element `undefined` |
| 16:33 | <Bakkot> | ah, yup, looks like that is stale |
| 16:33 | <Bakkot> | it is a String or `undefined` |
| 16:33 | <Bakkot> | probably easier to just say `be cookedStrings[index]`, and not assert on the type |
| 16:34 | <jmdyck> | right |
| 16:34 | <Bakkot> | this was an oversight in https://github.com/tc39/ecma262/pull/773, looks like |
| 16:34 | <Bakkot> | nice catch |
| 16:35 | <devsnek> | i should figure out a nice way to put those assertions in engine262 |
| 16:35 | <Bakkot> | someday we'll build type checking into the CI |
| 16:36 | <Bakkot> | probably not this year, hopefully this decade |
| 16:36 | <Bakkot> | it would catch so many editorial bugs |
| 16:36 | <Bakkot> | jmdyck: are you inclined to make the PR fixing the above? I'll do it if not. |
| 16:37 | <jmdyck> | Yeah, I can do it some time today. |
| 16:37 | <Bakkot> | sweet, thanks |
| 16:38 | <jmdyck> | My static type checking exploded in TemplateStrings, which led me (eventually) to that step in GetTemplateObject |
| 18:02 | <devsnek> | jorendorff: re your slides, v8's opinion was that using generators would be the same or faster, not the same or slower |
| 18:02 | <jorendorff> | ok, i'll edit that out before the presentation |
| 18:02 | <jorendorff> | thanks for the feedback |
| 18:02 | <devsnek> | well if other engines have concerns it could be slower that's useful too |
| 18:02 | <devsnek> | just want to make sure we have all the info |
| 19:47 | <jorendorff> | devsnek: I just deleted it. I noticed that the screenshot I have of your sketch of option 3 has a typo |
| 19:47 | <devsnek> | typo? |
| 19:47 | <jorendorff> | devsnek: step 3 calls %SyncMap% with one this-value and one argument, but %SyncMap% takes two positional arguments, no this |
| 19:48 | <devsnek> | doesn't it do "IteratorHelperStart" or something |
| 19:48 | <jorendorff> | oh, it does |
| 19:48 | <jorendorff> | then that could work! no worries |
| 19:48 | <devsnek> | i'm imagining that calls the generator and skips next() |
| 19:49 | <jorendorff> | I was imagining that it would call .next() once on the generator, yes |
| 19:50 | <jorendorff> | and discard the result |
| 19:50 | <devsnek> | yep |
| 19:50 | <jorendorff> | but i don't understand yet why it's helpful to have the arguments in a different form |
| 19:50 | <jorendorff> | than, say, Call() |
| 19:50 | <devsnek> | hmm |
| 19:50 | <devsnek> | the this value isn't used |
| 19:51 | <devsnek> | IteratorHelperStart doesn't technically exist yet so we are free to do whatever we want |
| 19:51 | <jorendorff> | right, i agree |
| 19:51 | <jorendorff> | this can definitely be made to work |
| 21:05 | <jmdyck> | wow, PR 1519 is a blast from the past. Took me a while to page that all back in. |
| 21:27 | <Bakkot> | Yup! |
| 21:27 | <Bakkot> | I'm trying to get some of the older outstanding ones in |
| 21:28 | <Bakkot> | Particularly since we might restructure a bunch of stuff as a consequence of https://github.com/tc39/ecma262/issues/1950 |
| 21:30 | <jmdyck> | indeed |
| 21:31 | <jmdyck> | any idea of when 1950 might land? |
| 21:34 | <Bakkot> | we're going to talk about it at the meeting next week, to give the delegates the opportunity to raise objections, and then it will depend on one of us having the time to do the work |
| 21:34 | <Bakkot> | well, and there's a few more details to work out |
| 21:34 | <Bakkot> | e.g. I think it might make sense to keep Evaluation and Early Errors together with the grammar, as they currently are |
| 21:35 | <devsnek> | i wish they were grouped together |
| 21:35 | <devsnek> | its impossible to find early errors |
| 21:35 | <Bakkot> | hmmmm |
| 21:35 | <Bakkot> | Does grouping them make it any easier? |
| 21:35 | <devsnek> | the only way to find an early error if you don't know the exact prose |
| 21:35 | <Bakkot> | My thinking was, at least for Evaluation, you want to be able to click on a production to see how it evaluates |
| 21:35 | <devsnek> | is to grep through every single early error section |
| 21:36 | <Bakkot> | well, right, but is that... any harder than scrolling through all of them in one place? |
| 21:36 | <Bakkot> | always just C-f "Semantics: Early" and then C-g across all of the sections |
| 21:36 | <Bakkot> | I don't think scrolling through a single section would be any easier than that |
| 21:37 | <devsnek> | i think the problem rn is |
| 21:37 | <devsnek> | they seem to be written by people who already know what they are |
| 21:38 | <devsnek> | for someone reading the spec to try to figure out what semantics need to be applied, it is very difficult |
| 21:39 | <Bakkot> | grouping would help with this, you think? |
| 21:39 | <devsnek> | i think it would be a good first step |
| 21:39 | <devsnek> | i'm not sure i have a perfect solution |
| 22:11 | <jmdyck> | Bakkot: https://github.com/tc39/ecma262/pull/2022 has the cookedStrings fix. |
| 22:12 | <jmdyck> | (and others) |
| 22:17 | <jmdyck> | re 1590: if you keep Evaluation together with the grammar, would you also keep things like NamedEvaluation and LabelledEvaluation? |
| 22:19 | <jmdyck> | devsnek, when you say "grouped", you mean "close to the corresponding grammar"? |
| 22:19 | <devsnek> | i meant have one section for all the early error stuff |
| 22:20 | <jmdyck> | ah, ok. |
| 22:27 | <jmdyck> | Maybe, after each chunk of defining grammar (or after each production? hm), there could be a list of SDOs that are defined on those productions, and clicking the SDO-name would take you to the appropriate portion of that SDO's section. |
| 22:28 | <jmdyck> | (You'd want the list generated automatically, presumably.) |
| 22:30 | <Bakkot> | hmm, named evaluation is interesting |
| 22:30 | <Bakkot> | yeah, I think it might make more sense to have backreferences |
| 22:30 | <Bakkot> | I could also probably get `evaluating |Production|` to link to the right place |
| 22:31 | <jmdyck> | (That should maybe be re-cast into a proper SDO-call.) |
| 22:33 | <Bakkot> | Maybe. It does read nicely, currently. |
| 22:38 | <Bakkot> | jmdyck: re: 1950, another consideration is that https://github.com/tc39/ecma262/pull/2007 almost certainly needs to land first |
| 22:38 | <Bakkot> | since it is a pretty pervasive change |
| 22:39 | <jmdyck> | yep |
| 22:40 | <Bakkot> | (I am assuming that 545 won't be too hard to rebase, since it's automatically generated, but let me know if this is not so.) |
| 22:42 | <jmdyck> | yeah, i think it'll be okay. |