2021-02-03 [09:04:56.0000] ystartsev: ping [09:33:29.0000] hi shu [09:33:31.0000] whats up [09:34:54.0000] ystartsev: i just wanted to confirm that FF will implement the cycleroot fix now and ask for consensus next meeting [09:35:20.0000] ystartsev: since chrome is shipping TLA to 89 stable, doing my due diligence before doing a backmerge into the stable branch [09:35:47.0000] It is already implemented actually [09:35:56.0000] so yes, that fix will be merged [09:36:37.0000] the only open question I've got on my plate right now wrt top level await going to stage 4 in march is if we need to do this: https://github.com/tc39/proposal-top-level-await/pull/159 [09:37:03.0000] this would be a normative change that we need consensus from the committee on -- part of the reason for this coming up is chrome and firefox diverge in their behavior with regards to multiple parents [09:37:34.0000] idk if you already spent some time with the related issue: https://github.com/tc39/proposal-top-level-await/issues/158 [09:37:38.0000] ystartsev: which one does what right now? [09:37:42.0000] ystartsev: i have not spent time with either issue [09:37:57.0000] v8 does this: [09:38:05.0000] ystartsev: first, are there 3 behaviors (FF behavior, Chrome behavior, and #159 behavior), or are there 2? [09:38:11.0000] #159 behavior = proposed #159 behavior [09:38:40.0000] yep that is right, they are all divergent [09:38:50.0000] ha [09:39:05.0000] okay, then we don't need to go through it now [09:39:13.0000] so i want to investigate if there is a bug in ff code that would get the expected behavior -- if not, if the expected behavior violates the web platform tests, and if not if it nakes sense [09:39:13.0000] we can wait a release to converge [09:39:37.0000] yeah, I kinda want to deal with 159 after stage 4... i will work on that tomorrow, today got packed with other work pretty quickly [09:39:41.0000] this part of the V8 code implements the spec quite literally [09:39:47.0000] and it sounds like in SM as well [09:39:50.0000] so it might be a spec thing [09:39:50.0000] yeah same with us [09:39:57.0000] well, the cycle root thing was a bug [09:40:06.0000] right [09:40:16.0000] on my todo for tomorrow is to re-execute 159 on the fixed version and see what happens [09:40:29.0000] anyway -- to answer your first question i think you are probably in a good position [09:40:55.0000] okay, cool [09:40:57.0000] if 159 significantly changes behavior from the existing spec, we have a problem anyway and it would need to be discussed [09:41:14.0000] yep, sounds reasonable. thanks for the confirmation, have a good night! [09:41:22.0000] cheers! [10:59:39.0000] ystartsev, ljharb: I've done some decent edits to the proposal i linked y'all to, in case you read it immediately after the meeting (or have it open to read later) [11:08:06.0000] "decent" meaning minor (no large-scale restructuring), but still, if you were looking at something and thinking something was missing/inconsistent, hopefully it's no longer so [11:27:08.0000] thanks, will take a look [14:39:51.0000] I'm trying to use Matrix but I'm getting errors when I try sending messages. The web inspector says: "Error sending event Error: Failed to execute 'transaction' on 'IDBDatabase': The database connection is closing." Anyone else having this problem? [14:42:01.0000] Hmm, I can post in #tc39-general:matrix.org but I can't send IMs 2021-02-04 [17:13:00.0000] sffc: element.io? [17:13:07.0000] it uses web storage [17:14:17.0000] Yeah 2021-02-08 [08:02:06.0000] shu: incubator call? [09:24:46.0000] oops, i missed this one :-/ [14:03:08.0000] Bakkot: could you remind me what disallows `for (async of [1])`? [14:06:26.0000] ah, found https://github.com/tc39/ecma262/pull/2256 [14:06:55.0000] my memory is terrible these days [14:15:42.0000] technically nothing disallows it! 😄 [14:17:32.0000] right, nothing right now 2021-02-09 [16:31:53.0000] Bakkot: did we not need to disallow `for await (async of`? [16:32:28.0000] we did not [16:32:42.0000] if `for await` is valid, `async` isn't a valid identifier, right? [16:32:42.0000] because the ambiguity only arises for `;;` vs `of` loops [16:33:16.0000] that is, since `for await (async of => 0;` isn't the valid start of a statement, there's no ambiguity [16:33:39.0000] devsnek alas, no [16:33:42.0000] only `await` [16:33:47.0000] :( [16:35:56.0000] ah, because there's no for await (;;), ok [16:35:58.0000] cool 2021-02-10 [17:46:09.0000] ljharb, others: Oh dang, Python just accepted a structural pattern-match syntax (PEPs 634/635/636). It's *virtually identical* to my proposal. I wrote up a comparison at (this is also linked from my proposal doc). [17:51:19.0000] i saw, but hadn't done a comparison yet, thanks [18:07:07.0000] TabAtkins where is your proposal? [18:07:09.0000] gist doesn't liink t [18:07:18.0000] *link it, ugh, gotta get my keyboard fixed [18:35:54.0000] Oh yeah I didn't link back, huh [18:36:00.0000] Bakkot: https://gist.github.com/tabatkins/5c336285c7f6d7d6522561e97f4d98fb [19:06:29.0000] TabAtkins neat! [12:00:58.0000] does anyone remember the history around the motivatioon for RegExp.prototype[@@split] special-casing empty strings? [12:02:02.0000] are there observable differences with vs without that special case? [12:02:22.0000] allen has said that he put a lot of effort into ensuring that the observable behavior of existing string regex methods didn't change in es6 [12:03:46.0000] ljharb: there is, in that for strings with length 0, the splitter regexp is executed _at_ the length (since lastIndex is 0). for strings with length > 0, the splitter is always executed at a lastIndex < length [12:05:21.0000] my guess then is that "that's how it used to work", so the special case was to preserve that semantic [12:06:00.0000] either that, or "we didn't think about consistency" explain most of the weird things in the regex methods [12:07:05.0000] there is a paragraph in the note that calls out the empty String behavior, but nothing in way of motivation 2021-02-11 [11:10:07.0000] shu Bakkot ljharb in which meeting we present the RC for 2021? March or April? [11:12:05.0000] leobalter_ic march [11:12:12.0000] Thanks 2021-02-17 [09:03:44.0000] rbuckton: i imagine https://github.com/tc39/proposal-class-static-block/pull/38 is waiting on other reviews before you want to merge, right? [09:04:12.0000] rbuckton: i've implemented it and it's making reviewing of the code difficult given the rendered spec doesn't match the consensus yet, would be nice to get it in soon 2021-02-20 [13:51:25.0000] devsnek: while iterating on a PR, force-pushing makes it hard for reviewers to tell what you've changed [13:52:01.0000] or, at least, hard for me [13:52:47.0000] oh uh [13:52:51.0000] you can click "force pushed" to see the diff [13:53:14.0000] oh right I forget about that [13:53:31.0000] after gh added that i gave up on squash/fixup commits [14:21:24.0000] whoa wattttt, TIL [14:21:32.0000] why the hell doesn't that have the affordance of a link [14:22:22.0000] yeah they should make it more visible [14:23:37.0000] i just put a complaint in the suggestion box about it (read: i tweeted) 2021-02-21 [09:58:48.0000] how come the next meeting is only 2 days [12:17:39.0000] devsnek we're experimenting with a different schedule this year [12:17:46.0000] you'll note it's also earlier than usual [12:18:02.0000] I think the original idea was to try having some shorter remote meetings [12:18:15.0000] a plan we made before 2020 happened [12:27:16.0000] hmm I thought it was supposed to be shorter meetings spread out over more days [12:27:26.0000] oh well, no problems either way 2021-02-22 [02:39:11.0000] devsnek: I presented the schedule a couple of times last year. https://docs.google.com/presentation/d/1vsOSn9alFLnmtYStNt71_KJU6uDW1nm-GsqRRIfajTw/edit But it wasn't very memorable - slides had no memes or jokes at all. Not even comic sans. 2021-02-25 [06:56:29.0000] rkirsling: since you're all paged in with typed array stuff, do you have thoughts on https://github.com/tc39/ecma262/pull/1556 ? is it still needed, a bad change, a change that's already happened, something else? [08:41:53.0000] devsnek: looks like if you can make this last change, this PR and then the spec one can land? https://github.com/tc39/test262/pull/2878#issuecomment-786010018 [08:47:01.0000] ljharb: done [09:02:40.0000] Incubator call for module blocks starting now [09:02:44.0000] ljharb: Do you want to join? [09:02:51.0000] or, anyone else? DM me for the link [09:04:10.0000] i've got another meeting this hour, sorry [11:26:52.0000] ljharb: hmm, interesting [11:26:59.0000] looks like JSC still differs as before [11:28:33.0000] oh wow also somehow I overlooked the fact that I was pinged on this yesterday [11:29:18.0000] I guess if shu already got consensus and the current engine results are the same as before, then we should go forward with the PR, yeah [11:45:23.0000] shu: is https://github.com/tc39/ecma262/pull/1556 what you got consensus for? [12:06:00.0000] yeah https://github.com/tc39/ecma262/issues/1541#issuecomment-785508810 [12:11:53.0000] nice, ok 2021-02-26 [18:45:48.0000] tfw first day of new job is the same day as tc39 [19:09:15.0000] ouch [19:25:05.0000] if no one else wants to take the extends null item i'll move it to next meeting [19:33:51.0000] are the choices basically, 1) do nothing, let things suck; 2) allow `new class extends null {}` to work by making `super()` a noop when it'd be invoking `null`? or is there a third choice [19:57:03.0000] ljharb: 1) do nothing 2) super noop 3) remove extends null somehow [19:57:12.0000] maybe not compatible [19:57:16.0000] web compatible* [20:02:42.0000] how could we do that [20:03:02.0000] since i could do `let f = function () {}; class C extends f {} ; f = null; new C()` [20:03:11.0000] or do you mean a runtime error as part of construction [20:03:20.0000] idk [20:03:24.0000] i don't want to do that [20:03:30.0000] but its technically an option [20:03:42.0000] i'd like to lean on previous consensus here and actually figure out something that works though [20:04:06.0000] super noop seems ideal to me but there is a conflict [20:04:37.0000] some people say super() with extends null should throw, some say super(), if syntactically valid, should never throw [20:05:01.0000] i say the latter, and i'm aware of at least one person who says the former [20:05:09.0000] but the former pretty much guarantees extends null can never work [20:05:15.0000] yeah [20:06:12.0000] so i put a nice 30m chunk to discuss it [20:09:11.0000] fun issue that bradley just opened 😅 [08:53:05.0000] devsnek: looks like https://github.com/tc39/ecma262/pull/2216 now just needs to address 3 more small comments 2021-02-27 [13:46:45.0000] reminder that the next meeting is earlier than usual and there's less than 24 hours before the advancement eligibility deadline [13:47:27.0000] but also the next meeting will be April, not May, so don't worry too much [13:47:31.0000] this meeting will be short anyway 2021-02-28 [21:15:40.0000] the deadline was yesterday (friday) [21:19:24.0000] hmmm [21:19:31.0000] the agenda probably should not say "Deadline for advancement eligibility: February 28th, 2021, 10:00 PST" then [21:22:50.0000] hm [21:23:32.0000] you're right, the agenda is off. it's set to 8 days ahead instead of 10. i'll fix that. [21:24:09.0000] 9, not 8, I think? [21:24:19.0000] but also, I was going off the listed deadline, planning to add a thing tonight [21:24:29.0000] oh right, because it's tuesday [21:24:31.0000] I think we gotta stick with what's listed; we can't just move it back [21:25:48.0000] the agenda has always said "Note: this time is selected to be precisely 10 days prior to the start of the meeting" but i'm sure the mistake means there can be some wiggle room [21:26:10.0000] the reflector issue had the same mistake as the agenda, so confusion is fair [10:45:59.0000] devsnek: i was willing to talk about extending null ftr [10:47:42.0000] oh [10:47:47.0000] feel free to put it back on the queue