2023-01-01 [15:26:40.0665] i agree that stuff needs to be figured out, but it's not a blocker - it wasn't a blocker for ecmarkup either. 2023-01-03 [11:32:21.0252] is there any recent news on the "rm subclassing" proposal? [11:47:26.0557] arguably set methods to Stage 3 is a pretty strong milestone to establishing how these things should work in the future [11:47:56.0798] beyond that, I haven't heard of any progress in the assessments to how web-compatible it'd be to remove some of the ES6 cruft [11:51:57.0772] I seem to remember that someone said last time that Set methods wasn't intended to be a precedent? [12:24:23.0316] firefox said there were incompats and i have vague memory of waiting on the data there for next steps, but it's been a bit [12:34:34.0195] Set methods were explicitly intended to be a precedent https://docs.google.com/presentation/d/1HCqPMsWiTtsn92gA3b1luVpnVHWVVR0iKaAE0marxkA/edit#slide=id.g13a69787e9f_0_13 [12:36:05.0708] I do think we should have gone with Symbols rather than strings, and might fight about that when that particular question comes up, but IIRC that was the only point of contention [12:36:14.0581] we were all on board with the subclassing behavior, I believe [12:36:25.0675] * I do think we should have gone with Symbols rather than strings, and might fight about that when that particular question comes up, but IIRC that was the only point of contention [12:40:34.0884] https://github.com/tc39/notes/blob/6f7e075341e435f22777b07a3ee5141442d2d8a7/meetings/2022-03/mar-31.md#extending-built-ins is a better link I guess, since that's the presentation where we talked about subclassing in particular rather than Symbol vs string [12:41:29.0269] well, though that was less focused on Symbol.species, actually [12:41:32.0689] there's a lot of parts of this... 2023-01-04 [15:11:07.0475] Ashley Claymore: what's the status of change-array-by-copy? if it's shipping in two places do you want to go for stage 4 in January? [15:11:18.0315] I ask because we're going to cut the next edition sometime in the next few months [15:14:27.0483] littledan: same question as ^ re: symbols as weakmap keys (not sure if you're the right champion but you're listed first) 2023-01-05 [19:53:35.0828] Thanks for the ping, we will discuss both of these proposals within Bloomberg and get back to you (possibly via an agenda PR) [09:32:00.0344] Where's the proposed schedule of the year's meetings posted again? I kinda expected it on the agendas repo, but I only see the upcoming Jan meeting there. [09:33:12.0172] will message you [09:45:25.0743] TabAtkins: bottom of https://github.com/tc39/agendas/blob/main/2023/01.md#dates-and-locations-of-future-meetings 2023-01-06 [16:10:21.0237] danke, y'all, suggesting we copy it to a more obvious place https://github.com/tc39/agendas/pull/1295 [15:13:21.0400] can anyone help me come up with values that would trigger the returns on steps 6 and 8 in https://tc39.es/ecma262/#sec-makeday ? [15:24:04.0148] step 6 would return for `Date.UTC(Number.MAX_VALUE, Number.MAX_VALUE)` [15:25:28.0404] step 8 is not clear about what would return and there's an issue open about it: https://github.com/tc39/ecma262/issues/1087 [15:26:13.0370] but in any case it seems likely that `Date.UTC(-271821, 3, 19)` ought to make step 8 return [15:26:20.0866] hm, using MAX_VALUE seems to hit step 8 but not step 6 in my impl [15:26:37.0556] (the AO only takes number values, to be clear) [15:27:10.0291] and `+Date.UTC(-271821, 3, 19)` returns NaN for me in Safari and node :-/ [15:31:00.0605] aha, but using MAX_VALUE for both the year and month seems to hit step 6, thanks! 2023-01-09 [11:21:37.0612] Chairs: The January TC39 was moved to January 30th, making the agenda deadline January 20th, correct? The link in the "Agenda topic rules" labeled "CALCULATE TIME HERE" is calculating the time until January 30th, not January 20th. I assume this is in error? [11:22:18.0366] Checking... [11:25:48.0916] You are correct. Here's the fix: https://github.com/tc39/agendas/pull/1296 [11:26:33.0287] Thank you for noticing. 2023-01-10 [13:45:47.0524] ljharb: what's the preferred way to publish rendered specs in proposal repos? [13:45:55.0287] a branch or a subdir? [13:46:08.0342] definitely a gh-pages branch [13:46:12.0655] there isn't consensus. the template i built does neither, it auto-publishes to the root [13:46:21.0561] michael and some others prefer a separate gh-pages branch [13:46:38.0416] i don't really care, i just want the least amount of work possible [13:46:45.0831] i didn't know it could just use a single file? [13:46:54.0088] it can [13:47:03.0335] you can make a proposal repo from the template for the "root" approach [13:47:34.0035] oh i see, you can just serve the entire root directory [13:47:59.0379] yep [13:48:37.0735] the pros of this approach are that you can switch commits to specific ecmarkup and the rendered html is largely right there. cons are that the commit history will be slightly more crowded. [13:51:51.0136] reviewing PRs becomes annoying [14:07:08.0459] how so? [14:08:13.0199] the built spec HTML changes are mixed in with the source spec ecmarkup changes [14:08:37.0560] ah, when i used a subdir i always just push another commit called "Update render" or the like [14:12:27.0313] that gets annoying when there's multiple commits though [14:12:50.0863] strongly prefer the approach the spec takes, where there's a different branch with the rendered spec and you never have to think about it [14:13:31.0708] you can use https://github.com/tc39/template-for-proposals/pull/32 as a basis for this and then never think about it; commits to the main branch will automatically update the gh-pages branch [14:26:56.0064] wfm [14:43:40.0439] `.gitattributes` auto-collapses the diff in the PR for the HTML changes 2023-01-11 [16:13:32.0032] ljharb: okay, initial spec for transfer up at https://tc39.es/proposal-arraybuffer-transfer/ if you'd like to review [16:18:52.0721] huh i wonder why it says January 11, what timezone is GH on [16:19:29.0783] probably UTC [21:18:46.0334] yeah, it's utc, it's really annoying [21:19:13.0009] there's an env var kevin added to ecmarkup that lets you set the modified time, but unfortunately i haven't worked out an ergonomic way to use it so that the date is deterministic :-/ [22:11:36.0054] well [22:11:59.0581] it's easy to make it deterministically 1970-01-01 or whatever [22:12:29.0176] lol ok well, deterministic and increasing as time itself increases :-p [22:12:29.0465] but deterministically "date of last file modification" is trickier yes [22:12:57.0622] * lol ok well, deterministic and increasing as time itself increases :-p [22:14:28.0590] for CI it's probably fine to have it do the commit date [22:14:43.0681] if you want it to be deterministic and increasing [08:01:27.0662] that date isn’t known until after the committed build is generated tho [08:58:37.0646] if you commit changes to the spec and then CI generates a separate commit with the build for that spec, CI can use the date of the "changes to the spec" commit to generate the date for the build [09:00:06.0693] that would help with the "CI rebuilds spec and causes merge conflicts" issue [09:00:24.0903] because the default template has this really irritating issue [09:01:07.0754] GH actions tries to rebuild the spec everytime, even if the commit already updates the built spec and adds fixup commits that need to be addressed but at the very least would cause merge conflicts [09:01:48.0835] so it's pretty much impossible to merge multiple PRs in a row. You have to always rebase all PRs on top of the main branch once you merge anything, it's quite irritating at times. [09:05:22.0921] ryzokuken: that's already fixed by https://github.com/tc39/template-for-proposals/pull/32, which puts the built spec on its own branch [09:05:57.0540] oh nice [09:06:06.0770] how can I incorporate this into an existing proposal repo? [09:06:08.0625] * ryzokuken: that's already fixed by https://github.com/tc39/template-for-proposals/pull/32, which puts the built spec on its own branch [09:06:16.0917] * how can I incorporate this into an existing proposal repo? [09:07:10.0823] uhhh basically just apply that PR as a patch [09:07:52.0108] ah cool! Wasn't sure that'd just work. Will try this and let you know how it went [09:07:52.0756] and then change the repo settings to deploy from the gh-pages branch once the new CI runs and generates it 2023-01-12 [15:25:10.0100] in case folks haven't seen: https://blog.sigplan.org/2023/01/12/from-research-prototypes-to-continuous-integration-guiding-the-design-and-implementation-of-javascript/ [15:32:22.0529] I never thought that me saying "I sat through the presentation with my mouth open the whole time" would make it into an academic conference paper [15:34:33.0008] the real takeaway is edit the notes [15:34:49.0588] lest you want speech2text errors make it into publications! [15:35:56.0864] (i say that as someone who does not edit the notes very well) [15:40:36.0670] Did we record that presentation? 2023-01-13 [23:01:21.0000] oh wow i didn't realize esmeta was running on test262 [23:01:23.0693] guess i can retire engine262 [23:03:10.0493] it even implements my idea of showing how each line of js executes in the spec better than i could do in engine262 😄 [07:20:38.0750] from next plenary onwards, we should have professional stenography 🤞 [07:21:59.0653] hah. the thing that tripped me up was whenever I had to pause to look up stuff 2023-01-16 [08:43:54.0543] Please can everyone fill in this super-quick survey for the March 2023 plenary to see if we have enough interest in the meeting being in-person at the F5 Tower in Seattle, US. [Survey link](https://github.com/tc39/Reflector/issues/457) Responses are requested by Monday 23 January 2023. It will take less than 60s to complete. 2023-01-18 [08:24:36.0399] A reminder: Please add your response to [the March 2023 plenary survey](https://github.com/tc39/Reflector/issues/457) (it will likely be the quickest survey you have completed in your life - only one question) [12:42:32.0688] We had a whole bunch of topics which didn't make it last meeting. Shouldn't we add them all to the agenda for this meeting? [12:42:38.0043] in the overflow slot [12:42:45.0902] it looks like we only have AsyncContext there for now [13:18:14.0761] i used to add them automatically, but often presenters didn't realize it and weren't there to present them the next meeting. it's probably best if the presenters add themselves to the overflow slot [13:38:40.0905] Ah OK I was unaware of the change, thanks for the history; I'll add my topics [14:03:31.0007] no worries, wasn't really a policy either way, just something i did on my own. open to do it differently if it's easier on anyone 2023-01-19 [08:50:31.0643] FYI, for anyone intending to read the Async Resource Management proposal spec text, GitHub is having issues with Pages deployments currently so the spec text at https://tc39.es/proposal-async-explicit-resource-management is not up to date. Until the issue is resolved, the spec text at https://tc39.es/proposal-async-explicit-resource-management/pr/6 is the most up to date version. [13:31:17.0796] Richard Gibson: are you planning to bring https://github.com/tc39/proposal-json-parse-with-source/issues/39 to the january plenary? [13:31:51.0303] it'd be nice to get it fixed, as there're multiple implementations already [13:53:28.0086] > <@rbuckton:matrix.org> FYI, for anyone intending to read the Async Resource Management proposal spec text, GitHub is having issues with Pages deployments currently so the spec text at https://tc39.es/proposal-async-explicit-resource-management is not up to date. Until the issue is resolved, the spec text at https://tc39.es/proposal-async-explicit-resource-management/pr/6 is the most up to date version. GitHub pages is working again, so the spec text at https://tc39.es/proposal-async-explicit-resource-management is now up to date. [14:22:43.0783] > <@shuyuguo:matrix.org> Richard Gibson: are you planning to bring https://github.com/tc39/proposal-json-parse-with-source/issues/39 to the january plenary? yes, expect an agenda item today [14:33:37.0691] awesome, thanks 2023-01-21 [18:02:18.0778] I think the getIntrinsic is too niche. It is useful for language experts, but it shouldn't be a thing in the language imo [22:27:36.0849] lots of things are like that tho - atomics and weak references, for example [22:28:06.0516] or Proxy [22:28:11.0552] iow, there's lots of things that are useful for language experts that in turn benefit hundreds of millions of users even though they never interact with them directly. getIntrinsic is one such thing. [22:28:15.0420] * iow, there's lots of things that are useful for language experts that in turn benefit hundreds of millions of users even though they never interact with them directly. getIntrinsic is one such thing. [01:35:49.0575] > <@robpalme:matrix.org> Please can everyone fill in this super-quick survey for the March 2023 plenary to see if we have enough interest in the meeting being in-person at the F5 Tower in Seattle, US. > > [Survey link](https://github.com/tc39/Reflector/issues/457) > > Responses are requested by Monday 23 January 2023. It will take less than 60s to complete. Final reminder! Please complete the the survey. 2023-01-24 [03:45:59.0701] Thanks all for the survey responses. The Seattle meeting is now confirmed for March 🎉 https://github.com/tc39/Reflector/issues/457#issuecomment-1401791367 2023-01-26 [21:56:34.0255] i just realized that overlaps with GDC [21:56:37.0359] :( [00:54:02.0309] If you check the Reflector (I don't want to link here), we have a spreadsheet for collecting plenary scheduling constraints. Clashes to avoid etc. You are welcome to add GDC to that so that we try to avoid it for future years. [13:21:34.0497] ryzokuken: i see in the draft schedule that ron's `using` update is on day 2; i'd love to have my topic on SuppressedError be directly before or after that if possible (currently on day 3), since they're about the same proposal [13:38:12.0627] > <@ljharb:matrix.org> ryzokuken: i see in the draft schedule that ron's `using` update is on day 2; i'd love to have my topic on SuppressedError be directly before or after that if possible (currently on day 3), since they're about the same proposal Could you please add that to the constraints? I'll try to reorganize in a bit. [13:46:06.0074] bakkot: Do you know if `esmeta` supports multiple constraints preceding a RHS? In the `using await` proposal I have a `[+Using, +Await] `using` ...` production, which both `grammarkdown` and `ecmarkup` support, but when I run `esmeta` it stops immediately with `[ESMeta v0.1.0] [Parser (List[spec.Production])] [14.110] failure: end of input expected` [14:02:26.0806] I've filed https://github.com/es-meta/esmeta/issues/133 for the issue. [15:11:47.0671] Yeah, I believe they did basically a clean-room reimplementation of the parsing, so I would not be surprised if it doesn't. I don't know offhand but the devs are pretty responsive. 2023-01-27 [06:41:13.0650] It looks like they fixed it last night in https://github.com/es-meta/esmeta/pull/134 2023-01-28 [16:17:01.0302] apparently typescript is going to add extra non-standard syntax for decorators (specifically, allowing them before `export` as well as after) [16:19:39.0188] yep, it's very unfortunate :-/ [00:41:10.0649] I think others have had this issue; trying to commit GH suggestions on ecma262 PRs it always errors with "This diff has recently been updated". Any ideas/tips? [08:24:31.0663] Ashley Claymore: nope, it just doesn't work [09:25:05.0379] seems to be a consequence of the large file size, which hopefully will be fixed at some point like the context expansion was [14:05:06.0805] Thanks for confirming it's not just me being dumb! 2023-01-30 [19:40:00.0058] 11 hours until the meeting, woo [20:55:54.0211] Wow I thought there was going to be a huge amount of under flow but it is not so much in the end [01:00:31.0442] Reminder: Today's meeting is remote, starting at 10am in the New York timezone. That is 6 hours from now. [06:31:23.0176] The sign-in link for Jitsi is now available via the entry form. Please don't post URLs into this publicly logged channel! Find it on the Reflector: https://github.com/tc39/Reflector/issues/454 [06:41:19.0067] Please note that we will have stenography support at this meeting. You can find an explanation/disclaimer here: https://github.com/tc39/Reflector/issues/460 [06:42:31.0920] Due to legal/GDPR concerns raised about stenography support, I want to reinforce that we will remove any information from the notes at participants' request (or direct edits). Further, any participant can feel free to either opt out of appearing in the notes, or object to the use of the stenographer overall. I will explain this at the beginning of the meeting [06:44:05.0017] We will still need delegate note-correctors to ensure accuracy, but we expect their load to be considerably lightened, as in our previous experiment here. [06:55:16.0326] *** The plenary meeting begin in 5 minutes *** [07:01:06.0118] hm, the jitsi link is timing out for me in my browser [07:02:11.0655] nvm, just took a few tries [07:03:33.0960] we have 25 participants now - no tech problems so far [07:06:21.0675] Please add your name, abbreviation and organization to the top of the notes. [07:08:16.0888] have we started? i don't hear anything on the jitsi still [07:08:32.0512] We are underway [07:08:33.0731] i just hear the sound effects of joins [07:08:38.0239] hm, i'll try to restart the app [07:08:41.0045] can you refresh? [07:09:04.0888] disconnecting and reconnecting worked [07:15:30.0519] btw that is not a picture of F5 Tower [07:16:00.0028] Sorry it was just supposed to be generic Seattle [07:16:17.0679] I hope we don't disappoint anyone with the shape of the tower. [07:16:44.0312] it is still a pretty building, but it is no space needle [07:17:03.0165] I wonder how hard it would be go get chatGPT to re-format the notes... [07:17:05.0457] the space needle is diminuitive and puny [07:19:50.0359] Did the meeting start? I am not getting audio or video [07:19:51.0838] The notes are a mess [07:20:08.0879] waldemar: we're working through technical difficulties [07:21:01.0753] davethegr8: yes, try reconnecting [07:21:17.0422] currently on the secretary's report [07:22:37.0390] bakkot: that didn't help [07:24:35.0644] davethegr8: You can select your audio device by clicking the upwards array next to the Microphone icon. [07:27:58.0379] we did used to have these nice "summary" docs volunteer-prepared by the chairs https://github.com/tc39/notes/blob/main/meetings/2020-07/summary.md but that's the most recent one, and they weren't always consistent before that either [07:31:41.0399] Rob Palmer: I think I'm getting into a load failure loop on every browser [07:37:24.0001] Is it possible you have some odd VPN/network? [07:37:40.0518] Rob Palmer: was finally able to access via the ipad app, but the browser experience was impossible [07:38:32.0147] I think we actually want more that just the summary in the Ecma minutes. We should include key points in the discussions and any concerns raised. The minutes should include the resolution of those concerns. [07:38:54.0013] * I think we actually want more that just the summary in the Ecma minutes. We should include key points in the discussions and any concerns raised. The minutes should include the resolution of those concerns. [07:39:17.0360] msaboff: I agree, but this is a baseline that is already possible [07:39:21.0524] i believe that the secretariat was suggesting that the champions summarize it [07:39:50.0098] for each of their topics [07:39:56.0474] I think it's important that we publish these abbreviated minutes somewhere more prominent than the Ecma filer [07:40:07.0835] this all has been done in the past; we're just behind on it due to a lack of volunteers [07:40:08.0955] Putting it on Istvan is not the answer [07:40:19.0590] also we are still looking for a TG3 chair! [07:40:22.0262] well, it is literally the secretary's job to prepare the minutes.... [07:40:27.0643] anyway it's fine if we do it as a committee [07:40:58.0289] I agree we need committee participation. Any of us could help prepare these summaries. I do like the idea of involving champions. We would also need someone to somehow organize the effort. [07:41:02.0335] * I agree we need committee participation. Any of us could help prepare these summaries. I do like the idea of involving champions. We would also need someone to somehow organize the effort. [07:44:04.0268] Note that the budget for the TC39 secretary is significantly higher than the budget for the transcriptionist, and there isn't much by way of deliverables beyond preparing the minutes [07:44:15.0756] If we had the secretary taking minutes, they wouldn't be transcriptions. [07:44:37.0046] Yes, we're talking about something higher level [07:44:37.0550] it is likely a good practice anyway as it will ensure that the champions understood the major points brought up in committee. I think what might be a good idea is dedicating 5 minutes for the champions that can also be used as a bio break. [07:45:13.0361] summarization and rephrasing is a good way to ensure understanding [07:45:33.0133] sounds good. yeah, I like the idea of doing it on-line, rather than a later homework assignment, to ensure shared understanding [07:46:22.0175] This could be in the form of an extended conclusion section, so we'd include a summary of the discussion in addition to the conclusion, collected on-line in the same tehcnical notes document. [07:46:23.0106] yes, with dedicated time we can ensure that this happens, plus it may give a much needed separation between topics -- sometimes (like now) we bleed in previous topics while the next one is being presented) [07:46:38.0497] this is a good meeting to trial that, given that we have extra time [07:47:09.0268] ^ cc Rob Palmer ryzokuken bterlson [07:49:03.0846] I think it's sufficient to just link to the slides for update topics [07:49:28.0057] > <@michaelficarra:matrix.org> I think it's sufficient to just link to the slides for update topics folks seemed to be saying not enough above? [07:49:31.0288] yeah or a copy/past of the bullets from the slide [07:49:32.0771] I've never asked myself what the conclusion was to an update topic when reviewing notes [07:49:38.0258] indeed, we usually don't have any kind of conclusion unless decisions were made [07:49:49.0438] I think a copy-paste of bullets would be not helpful if it's not a subset [07:50:49.0686] If the update was just the bullet points with no discussion, would we be able to say more than that? [07:51:16.0701] a "conclusion" requires that we concluded something. what could we conclude from an update? [07:51:42.0492] maybe lets turn this around. we are communicating to a broader public, what is important for them to know from each update? [07:51:50.0249] conclusion: committee has understood the update [07:52:15.0010] in the case of the ecma262 -- perhaps it is something along the lines of : we are doing minor editorial updates in line with the editorial plan, here are the summarized issues. [07:52:19.0687] ideally that'd be in the slides [07:52:49.0098] this way, we can point to a general strategy (which we've seen for example the editors do) and say, here is the work that was done related to this [07:53:16.0345] because the public will not be following at all times, and having something to get re-centered on will be useful [07:54:31.0091] when i do summarizations for my team, i am usually copy pasting the general topic of a proposal, plus bullet points of what is mentioned in the slides [07:55:00.0846] we have a similar situation with people dropping in and out and this has been good for team knowledge. we are just now thinking about the public and my summaries don't work for that [07:55:32.0547] * when i do summarizations for my team, i am usually copy pasting the general topic of a proposal (pulled from the repo + general notes over the years of discussion), plus bullet points of what is mentioned in the slides [07:57:31.0408] * we have a similar situation with people dropping in and out and this has been good for team knowledge. we are just now thinking about the public post factum (we do pre with post additions) and our summaries don't work for that. overall the strategy works though [07:58:20.0736] I think we should develop guidelines in how-we-work to describe the ideal way to write a conclusion. [07:58:37.0302] The suggestions here seem a great start. [07:59:29.0208] It would also be great to pause a little bit when moving between topics. It's a bit intense sorting the notes putting in the footer/header [07:59:37.0151] just a 30sec pause to settle would be great [07:59:48.0100] or a couple of minutes honestly [08:00:59.0370] I'm kind of in favour of a stage between 3 and 4 [08:01:35.0774] "stage 3: impl experience, stage 3.5: web compat experience, stage 4: standard" [08:02:41.0674] that also gives us a nice place to add a test262 entrance requirement [08:02:46.0704] stage 4 is not the right place for that [08:03:03.0036] but stage 3 is maybe unnecessarily early [08:03:47.0902] ljharb: I was too late 😅 [08:03:56.0992] also the comment was so vague there was no way to guess! [08:04:09.0840] lol no worries, i was looking at the previous tcq link - i hadn't refreshed the reflector issue [08:10:00.0475] what if instead of arguing about what the current wording in the document means we figure out what we want it to mean and then find wording that everyone agrees means that [08:10:22.0517] I agree with what dan is saying here, we are deliberately ambiguous about this. +1 to bakkot's comment [08:10:26.0615] dan's point is that we have tried and failed to find consensus [08:10:29.0655] i think the challenge is that we don't have consensus on what we want it to mean [08:10:32.0158] > <@bakkot:matrix.org> what if instead of arguing about what the current wording in the document means we figure out what we want it to mean and then find wording that everyone agrees means that we tried, and we can't even agree on what qualifies as an implementation [08:10:32.0784] for a wording that everyone agrees with [08:10:43.0123] the current wording *allows for* both viewpoints [08:11:01.0582] but it does not imo allow for an interpretation that something _must not_ be shipped pre-stage-4 [08:12:23.0399] * but it does not imo allow for an interpretation that something _must not_ be shipped pre-stage-4 [08:13:02.0347] it sounds like Apple's stance is only compatible with a strategy of us adding a new stage between 3 and 4 [08:13:47.0354] I have always been of the opinion that Stage 3 should mean "ready to implement", and Stage 4 should mean "ready to ship". If an implementer ships prior to Stage 4, it is the responsibility of the implementer to adjust to consensus changes. As it stands, Stage 4 just seems to be pro forma and has no real meaning. [08:13:56.0502] * I have always been of the opinion that Stage 3 should mean "ready to implement", Stage 4 means "ready to ship". If an implementer ships prior to Stage 4, it is the responsibility of the implementer to adjust to consensus changes. As it stands, Stage 4 just seems to be pro forma and has no real meaning. [08:14:03.0179] i won't agree with a new consensus seeking stage for when a browser can flip a flag [08:14:19.0149] you literlaly cannot gather compat feedback on canary populations [08:14:23.0150] * I have always been of the opinion that Stage 3 should mean "ready to implement", and Stage 4 should mean "ready to ship". If an implementer ships prior to Stage 4, it is the responsibility of the implementer to adjust to consensus changes. As it stands, Stage 4 just seems to be pro forma and has no real meaning. [08:14:41.0937] rbuckton: stage 4 means people can reliably program against the standard and expect it to run correctly on any compliant implementations [08:14:45.0783] > <@shuyuguo:matrix.org> you literlaly cannot gather compat feedback on canary populations for the last few web compat issues, we've caught those on nightly though? [08:17:56.0812] yulia: good point, but it had to be unflagged at least [08:18:12.0076] and in the past there were changes we didn't really see compat issues until it hit stable? [08:18:18.0618] yes, agreed -- thats how we fin them [08:22:00.0294] > <@shuyuguo:matrix.org> and in the past there were changes we didn't really see compat issues until it hit stable? interesting -- do you happen to remember which ones? it might be useful to learn from those cases [08:23:32.0564] let's see... [08:23:35.0093] Precisely. That to me indicates "ready to ship" for both engines _and_ user code that depends on that functionality. Based on my observations over that past few years, Stage 3 seems to mean a feature is mostly stable but there could still be changes that impact syntax/semantics, especially regarding oversights or compatibility concerns. I've always been concerned that an engine shipping a Stage 3 feature that potentially gains mass adoption before it reaches Stage 4 can result in consensus changes in Stage 3 becoming impossible because of the potential to break the web. [08:24:05.0343] > <@michaelficarra:matrix.org> rbuckton: stage 4 means people can reliably program against the standard and expect it to run correctly on any compliant implementations * Precisely. That to me indicates "ready to ship" for both engines _and_ user code that depends on that functionality. Based on my observations over that past few years, Stage 3 seems to mean a feature is mostly stable but there could still be changes that impact syntax/semantics, especially regarding oversights or compatibility concerns. I've always been concerned that an engine shipping a Stage 3 feature that potentially gains mass adoption before it reaches Stage 4 can result in consensus changes in Stage 3 becoming impossible because of the potential to break the web. [08:24:47.0147] "ready to ship" and "ready to rely on" needn't be the same thing tho [08:24:58.0766] and those kinds of changes happen after stage 4 too, just, ideally less often [08:25:09.0745] > <@ljharb:matrix.org> "ready to ship" and "ready to rely on" needn't be the same thing tho words are difficult -- people will understand it based on what they expect [08:25:17.0829] can't, really, because developers can't rely on something until it _is already shipping_ and has been for a while [08:25:28.0702] * can't, really, because developers can't rely on something until it _is already shipping_ and has been for a while [08:25:56.0983] littledan: so do we have a conclusion for that one? [08:27:08.0830] rename of the column to indicate not shipping, but that we need coordination [08:27:16.0663] is my understanding? [08:27:54.0978] ok - i think if we don't precisely mention "do not ship this" in some way it won't achieve the goal [08:28:04.0448] because the thing we need coordination FOR is "shipping" [08:28:07.0513] I disagree [08:28:17.0062] because we already do this coordination without this label [08:28:32.0723] otherwise we already have plenary and the reflector as a way to coordinate [08:28:33.0577] temporal, private fields, etc. have all had an unofficial agreement [08:28:41.0142] right - for known implementations and participants [08:29:01.0521] the column would include implementations that aren't part of tc39, or, specific implementor people who aren't [08:29:26.0481] afaik those do not impact web compat as significantly as the three major browsers [08:29:42.0046] sure [08:29:44.0360] though im open to being surprised, it would need evidence though [08:30:09.0045] so how do we communicate to the broader public, then, that the three major browsers have agreed not to ship something yet? [08:30:22.0866] * so how do we communicate to the broader public, then, that the three major browsers have agreed not to ship something yet, without mentioning "shipping"? [08:30:36.0612] i believe that the public gets this information in other ways, for example -- many will get it from looking at chrome logs, or can-i-use [08:30:53.0104] they _can_, sure. whether they _do_ or not is i think more vague [08:30:59.0972] by coordinating, the signal that something is shipping by default in a major browser never happens [08:31:06.0951] caniuse tells them that it hasn't shipped, but not why [08:31:07.0551] so the signal that you are citing never happens [08:31:20.0565] the proposal's advancement to stage 3 is that signal [08:31:29.0080] wait i don't care about the wording [08:31:34.0704] despite michael's interpretation, devs _do_ interpret stage 3 as "will be shipping" [08:31:36.0475] stage 3 is not a sign that users can use a feature [08:31:47.0022] i'm happy with whatever wording other people can live with if the thing being signalled is the same [08:31:53.0991] right, stage 3 is a sign to implementers [08:32:08.0022] but it's also become a signal to users, that implementors will be shipping soon [08:32:16.0663] > <@yulia:mozilla.org> stage 3 is not a sign that users can use a feature this can be easily determined by trying to start using a feature in any browser on the day that it hits stage 3. it pretty much never happens [08:32:28.0182] > <@ljharb:matrix.org> but it's also become a signal to users, that implementors will be shipping soon again, there are many counter examples to this [08:32:29.0830] ljharb: also agree, but a small degree relatively [08:32:33.0060] for example private fields. [08:32:37.0905] that was 5 years [08:32:38.0430] there are some. not many. [08:32:40.0551] or something likethat [08:32:53.0016] private fields, and temporal, are certainly notable examples. but they're rare. [08:32:56.0117] the stronger signal is that a browser is shipping unflagged [08:32:57.0456] i have another mtg i gotta drop for 30min [08:33:29.0264] right. and when a proposal hits stage 3 - something that takes many many years sometimes - users get excited that at some point in the near term, browsers will be shipping it and they can use it [08:33:59.0722] i've fielded hundreds of questions on irc and slack about "why hasn't temporal shipped yet‽ it's stage 3!" [08:34:49.0008] im not really sure where this is going... the reason for temporal was stated pretty early [08:34:54.0942] i think at stage 3 advancement [08:35:00.0418] yes but it's not stated on the proposals page. where users look. [08:35:19.0290] giving contextual information is always useful [08:35:26.0535] i think it is a different topic though [08:36:02.0417] in practice there's a huge difference for users between stage 3 proposals that have this unofficial agreement, and don't. i see the column dan proposed as a clear way to label those [08:36:19.0584] ooohh I *really* like the idea of explicitly soliciting non-blocking dissent [08:36:21.0749] im not sure where we are disagreeing? [08:36:21.0974] HUGE +1 to that [08:36:51.0867] ha, maybe we aren't :-) i'm saying that the wording on such a column needs to imply shipping (or not shipping) somehow, to be clear to users. [08:36:59.0216] * ha, maybe we aren't :-) i'm saying that the wording on such a column needs to imply shipping (or not) somehow, to be clear to users. [08:37:05.0141] * ha, maybe we aren't :-) i'm saying that the wording on such a column needs to imply shipping (or not shipping) somehow, to be clear to users. [08:37:33.0739] ah, this is where we disagree -- i don't think it should, as per ron bucktons comment -- shipping can be misunderstood. i would say that a better place for "this is not shipping because .." information is in the proposal repo itself. [08:38:15.0090] my experience is that the current scenario is what's most often misunderstood, not the meaning of "shipping". [08:38:58.0742] i think you are looking to solve a different problem. and it can be solved, but not by forcing the wording as you are suggesting [08:39:04.0679] there are other places with that information [08:39:13.0147] can we just add a ⚠️ emoji? [08:39:25.0686] honestly that would work for me [08:39:27.0688] lol yes but with what column header :-p [08:39:37.0731] 🤔 [08:40:02.0977] 🚢 [08:40:26.0986] I am happy with "don't block a proposal from stage 1 because you dislike the current shape of the proposed solution", and less happy with "don't block a proposal from stage 3 because you dislike the major API decision \[which are made in the process of getting stage 2\]" [08:40:54.0030] * I am happy with "don't block a proposal from stage 1 because you dislike the current shape of the proposed solution", and less happy with "don't block a proposal from stage 3 because you dislike the major API decision \[which are made in the process of getting stage 2\]" [08:41:14.0013] (altho major API decisions are often made in stage 2) [08:41:22.0597] regrettably, yes [08:41:40.0936] Was there a conclusion for "Stage 3 ready to ship" talk? [08:41:59.0099] (In a company meeting, so missed that and the current talk) [08:42:17.0690] i would say that all stages should be blockable for any reason, except stage 3 to 4 transition [08:42:28.0466] but, explicit discussion is better than silence [08:42:40.0233] blocking stage 1? [08:42:52.0109] yes, you should be able to block stage 1 [08:42:58.0412] not for any reason tho [08:42:59.0282] the only reason to block stage 1 is generally that the committee doesn't want to spend time solving the problem [08:43:14.0560] or doesn't agree it's a problem, sure [08:43:17.0346] right [08:43:40.0696] imo there exists reasons to block any transition, even 3 to 4, it's just that the list of those reasons gets rapidly smaller as things advance [08:43:46.0523] * imo there exists reasons to block any transition, even 3 to 4, it's just that the list of those reasons gets rapidly smaller as things advance [08:43:51.0730] yes, you should be able to. I think the goal of diversity is not very well achieved by allowing everything into stage 1 -- in particular i believe we block previously discussed proposals that are already stuck on the same problem, things that break significant properties of the language, and others [08:44:13.0940] > <@ljharb:matrix.org> imo there exists reasons to block any transition, even 3 to 4, it's just that the list of those reasons gets rapidly smaller as things advance there are reasons to block stage 3 to 4, but given the cost of implementation, it should not be "because i don't like it" [08:44:14.0122] 3 to 4 it is not clear there is any valid reason to block, if it's web reality [08:44:37.0145] well... there may be reasons... [08:44:48.0806] yes, absolutely "i don't like it" is not a valid reason to block stage 4 [08:44:55.0680] similar to degrading 4 (like we did with i think it was implicit eval?) [08:45:06.0399] but "i don't believe there's been sufficient shipping experience to ameliorate compat risk" is a valid one [08:45:09.0774] this is already in the process doc fwiw [08:49:26.0605] unfortunately we don't have anchor tags, but its under tips for consensus here: https://tc39.es/process-document/ [08:49:48.0993] we can add anchors anywhere we want :-) i'll take a look at that later today [08:53:54.0287] this is great, thanks littledan for driving this [08:54:12.0410] A small, unimportant question while the meeting is in session, but who is the maintainer for the TCQ app and is it open contribution? [08:54:50.0269] > <@anthonybullard:matrix.org> A small, unimportant question while the meeting is in session, but who is the maintainer for the TCQ app and is it open contribution? https://github.com/bterlson/tcq [08:55:01.0524] nicolo-ribaudo: beat me to it [08:55:14.0205] Thanks Nicolo [08:55:40.0487] Noticed that it does not show the navigation on narrower screen widths, which should be quick to fix [08:57:14.0394] thanks for bringing forward this process change littledan [09:05:04.0881] what was the conclusion to the consensus item? [09:05:38.0014] is there a change to process? [09:07:23.0658] afaik it is to the how we work document? [09:07:56.0029] to encourage more explicit support from non-champions? [09:08:03.0924] (i had to drop for a different call, trying to understand what we concluded from the notes) [09:08:19.0536] yes, this was my understanding. More explicit support, and more explicit non-blocking concerns [09:08:40.0413] thanks [09:09:46.0011] My understanding is that there are two changes: 1.) a non-normative change to make time for encouraging non-blocking concerns to be raised during the advancement-seeking part, and 2.) a normative change to require explicit support from at least two non-champions during the advancement-seeking phase in order for a proposal to advance stages [09:10:45.0393] Are we at lunch? [09:11:12.0665] Yes [09:13:08.0641] > <@jridgewell:matrix.org> Was there a conclusion for "Stage 3 ready to ship" talk? Ping, was there a conclusion for this? [09:15:44.0367] and Dinner too [09:16:40.0229] I will update the conclusion in the notes (after I have lunch) [09:18:01.0261] the conclusion was, "we can land something like the how-we-work PR but we need to switch out the column title to be compatible with multiple interpretations of Stage 3" [09:51:29.0291] I'm off this afternoon, see you all tomorrow morning [09:58:54.0049] We are restarting plenary in 1 minute! [10:00:11.0316] The transcribers are human as well [10:00:19.0747] yes! [10:03:48.0593] > <@msaboff:matrix.org> The transcribers are human as well Was this in response to something in particular? [10:04:48.0514] I know it's not 'standard', but just to say it is also super helpful when people put their acronym in their Matrix display name (as many people already have, thank you!!) [10:05:12.0671] I've memorized as many voices->acronyms as my brain can handle now ;) [10:05:13.0118] littledan: Rob was saying stuff like "people doing the human part of the notetaking" to mean the people adding delegate names and so on [10:05:23.0479] which made sense when the main notetaking was done by a bot, less now [10:05:35.0186] ah! I logged in while he was in the middle of clarifying [10:07:10.0127] * I've memorized as many voices->acronyms as my brain can handle now ;) [10:19:14.0899] someone who can take a mitigation action for this attack can also change their data structure to `{ __proto__: null }` or `new Map` [10:19:57.0417] i agree, that's my queue item in a nutshell [10:20:18.0474] Ashley Claymore: what's the transcription suggestion? [10:20:31.0879] > A note to the transcriber, if you go to Tools > Preferences you should be able to uncheck the "Automatically capitalize words" option and this newline behavior should go away [10:23:51.0707] a directive wouldn't make sense for this because it's not syntactically bounded [10:24:08.0114] CVE-2022-46164 appears to be, the client sends messages like `["user.getUserByUID",1]`, with the path to a method and its arguments - so that message would get translated to `Namespaces.user.getUserByUID(1)` - and the attack is to send the message `["constructor.assign", params]` - https://github.com/stephenbradshaw/CVE-2022-46164-poc/blob/8a4169293158673403002a807a5ce4a8cb329217/poc.py#L95 - https://github.com/NodeBB/NodeBB/blob/48d143921753914da45926cca6370a92ed0c46b8/src/socket.io/index.js#L115-L163 [10:24:36.0066] making that one not work requires specifically cutting off dynamic access to `Object.prototype.constructor`, not `.prototype` [10:25:31.0259] * CVE-2022-46164 appears to be, the client sends messages like `["user.getUserByUID",1]`, with the path to a method and any additional arguments - so that message would get translated to `Namespaces.user.getUserByUID(socket, 1)` - and the attack is to send the message `["constructor.assign",{uid: adminUID}]` - https://github.com/stephenbradshaw/CVE-2022-46164-poc/blob/8a4169293158673403002a807a5ce4a8cb329217/poc.py#L95 - https://github.com/NodeBB/NodeBB/blob/48d143921753914da45926cca6370a92ed0c46b8/src/socket.io/index.js#L115-L163 [10:25:40.0562] the `__proto__` and constructor accessors are already normative optional [10:25:46.0194] * the `__proto__` and constructor accessors are already normative optional [10:26:26.0410] `Object.prototype.constructor` is not optional and is also not an accessor [10:26:28.0656] node has a flag to remove the proto one, but ofc it breaks things to use it. [10:26:31.0390] ohh right sorry [10:26:34.0283] the `__proto__` accessor is though [10:33:31.0149] > <@ljharb:matrix.org> node has a flag to remove the proto one, but ofc it breaks things to use it. Deno disables the `__proto__` accessor (with no opt out). Even in Node compat, we can run essentially all commonly used code. For this most commonly used code, all of the accesses to `__proto__` were happening in very few third party modules (which we managed to get fixed up with the maintainers over about a year). I am sure there is a long chain of rarely used modules that would still break, so I agree with your "this will break the web". But with an opt-in mode, this seems pretty viable nowadays. [10:34:16.0786] i agree that via evangelism it's potentially tractable - altho much less so on the web than on a server - but without enabling it by default i'm skeptical it will actually prevent the problems it aims to [10:34:58.0678] ljharb: The presenters have explained why an opt-in mode can be helpful in practice; did you find their explanation persuasive? [10:34:59.0270] > <@ljharb:matrix.org> i agree that via evangelism it's potentially tractable - altho much less so on the web than on a server - but without enabling it by default i'm skeptical it will actually prevent the problems it aims to yeah - that's why we enable it by default. force people to fix their stuff [10:35:17.0733] but i agree, that does not solve the adoption problem on the web [10:35:56.0782] no, because if you know to opt in you've already had solutions for decades. eg i just stick a `$` in front of all my keys on write or read and the problem is fixed [10:36:02.0296] > <@littledan:matrix.org> ljharb: The presenters have explained why an opt-in mode can be helpful in practice; did you find their explanation persuasive? * no, because if you know to opt in you've already had solutions for decades. eg i just stick a `$` in front of all my keys on write or read and the problem is fixed [10:37:13.0464] this is like SES lockdown. I open lockdown() and found libraries crashes, but that's still better than works but security holes [10:37:45.0985] I think the key property was, the opt-in is global whereas those mitigations are local and distributed [10:37:53.0493] > <@ljharb:matrix.org> no, because if you know to opt in you've already had solutions for decades. eg i just stick a `$` in front of all my keys on write or read and the problem is fixed * I think the key property was, the opt-in is global whereas those mitigations are local and distributed [10:37:57.0955] oh, it's not per scope, it's global? [10:38:02.0486] yeah [10:38:04.0965] > <@ljharb:matrix.org> no, because if you know to opt in you've already had solutions for decades. eg i just stick a `$` in front of all my keys on write or read and the problem is fixed I don't see how that solves the problem? [10:38:14.0445] well, maybe undefined for now, but that is one possibility [10:38:29.0964] > <@ljharb:matrix.org> oh, it's not per scope, it's global? I hope it's global otherwise it looks like useless. [10:38:34.0551] > <@jridgewell:matrix.org> I don't see how that solves the problem? at the callsite it does, because then there's no possible overlap with special builtin key names. not globally tho. [10:38:53.0334] yeah one of the potential things is "a header that changes behavior of all JS on the page" [10:38:57.0716] if it's global, then i agree that it would work, but i'd be even more confident that it wouldn't be web compatible to enable it by default, and potentially not practical for many to enable anyways - like CSP. [10:39:11.0194] well, right, but the proposal would be opt-in, as they say [10:39:15.0427] * if it's global, then i agree that it would work, but i'd be even more confident that it wouldn't be web compatible to enable it by default, and potentially not practical for many to enable anyways - like CSP. [10:39:34.0998] and yeah many people wouldn't, but, I see CSP a _lot_, so these opt-in mitigations are seeing use [10:39:37.0361] at least on, like, banks [10:39:45.0498] another thing to worry about is, HTTP header is longer and longer 🤔 [10:40:12.0964] CSP COOP COEP ... [10:40:20.0139] and we're going to add more [10:40:21.0857] This problem is worth researching, but I doubt any of the proposed solutions are feasible. My bet is that we can let this solve itself. As people start using Maps, the problem will subside. And I expect Maps to start being used more as older browsers without Maps die off. [10:40:35.0409] I do not expect Maps to start being used more, since their UX is worse [10:41:05.0302] maybe making their UX better can be pursued as part of this effort [10:41:21.0016] Not as part of this effort, surely... [10:41:40.0947] why not? [10:41:58.0542] re: feasibility, I suspect that the "`__proto__` does not work in computed keys" thing would be compatible with almost all apps, so I think that at least is likely to be feasible [10:42:03.0167] using a Map would be a callsite-based mitigation, no? [10:42:05.0761] * re: feasibility, I suspect that the "`__proto__` does not work in computed keys" thing would be compatible with almost all apps, so I think that at least is likely to be feasible [10:42:57.0848] I am much more skeptical of the feasibility of making `prototype` and `constructor` not work in computed keys, though [10:43:20.0417] many common features force you to write vulnerable code, like copying properties from one object to another, reading from postMessage, etc. - that makes hoping for the issue to go away with maps a lot more convoluted, I think [10:43:51.0994] nitpick: `postMessage` works with Maps, people just don't [10:43:53.0542] how does SES address the stratification issue? [10:44:01.0737] (I think, anyway?) [10:44:22.0831] This may be my lack of knowledge and experience here, but could many of these issues not be solved by running third party code in separate Realms? [10:44:45.0841] I thought that was part of the Realms proposal. [10:44:47.0194] Anthony Bullard: very few of these are about third-party code [10:45:02.0432] at least in the traditional sense of "code" [10:45:10.0468] here's es6-shim, deployed on lots of websites, using `__proto__` dynamically: https://github.com/paulmillr/es6-shim/blob/98a175f41849f9894a21794a3e2767cdfc421a19/es6-shim.js#L1538-L1587 [10:45:43.0194] Tell me more :-) [10:45:47.0486] well, since it is opt-in, you can upgrade/patch the library [10:46:03.0584] this is how we adopt lockdown() to freeze primorials [10:46:43.0068] right - but it means even the proto changes couldn't be by default. [10:46:44.0818] ljharb: does that code run in environments which support modern features? [10:46:54.0923] Yeah I think no one has proposed making this on by default [10:46:56.0183] yes, shims are typically ran unconditionally so they can patch behavior as needed via feature detection [10:47:04.0390] * yes, shims are typically ran unconditionally so they can patch behavior as needed via feature detection [10:47:33.0936] assume the feature detects as present - does the linked section of code still run? [10:48:01.0506] sorry, by "the feature" I mean `setPrototypeOf` [10:48:24.0291] I guess this is maybe the code which detects the feature? [10:48:36.0305] oh, i see what you're asking. presumably if the one that's present behaved, then it wouldn't install anything - but the detection code itself, that always runs, relies on the feature, yes. [10:48:38.0229] > <@bakkot:matrix.org> sorry, by "the feature" I mean `setPrototypeOf` yes. many people don't aware of that. they just write `__proto__` because it's shorter [10:50:06.0427] in this specific code, the original author seems to have used a variable solely to avoid having to repeat the ugly `__proto__` multiple times [10:50:09.0857] reading the code I think it still would end up working - you'd hit the `_call(set, {}, null)` line, and either that would not throw (and so you get the accessor you wanted) or it throws and you hit `Object.prototype !== {}[magic]` (and it gives up) [10:50:11.0883] either way it works out [10:50:39.0316] > <@ljharb:matrix.org> oh, i see what you're asking. presumably if the one that's present behaved, then it wouldn't install anything - but the detection code itself, that always runs, relies on the feature, yes. * reading the code I think it still would end up working - you'd hit the `_call(set, {}, null)` line, and either that would not throw (and so you get the accessor you wanted) or it throws and you hit `Object.prototype !== {}[magic]` (and it gives up) [10:51:14.0889] interesting, you may be right [10:51:36.0135] that was just the first place i looked, i'll check some other packages [10:51:41.0953] yeah [10:51:55.0448] I mean, I am sure there would be at least some breakage from changing this behavior [10:52:10.0483] but I think it likely to be small enough to be feasible to opt-in in a lot of places [10:52:20.0021] * but I think it likely to be small enough to be feasible to opt-in in a lot of places [10:52:47.0112] > <@ljharb:matrix.org> in this specific code, the original author seems to have used a variable solely to avoid having to repeat the ugly `__proto__` multiple times (and that make the code more confusing lol, _what is magic??_) [10:54:24.0512] lol i agree, but i added it nearly a decade ago ( https://github.com/paulmillr/es6-shim/commit/792b0d58015e58773ff988fe4a3373c74c200fae ) and haven't touched it meaningfully since [10:55:45.0853] it's stuff like this: https://matrixlogs.bakkot.com/TC39_Delegates/2023-01-30#L227 [10:56:06.0953] where you're passing around dynamic paths and then accessing those [10:57:43.0404] why is `__proto__` factored out into `magic` [10:57:48.0116] just out of curiosity [10:57:54.0502] * why is `__proto__` factored out into `magic` [10:58:37.0431] probably manual minification [10:58:56.0836] > <@devsnek:matrix.org> why is `__proto__` factored out into `magic` https://matrix.to/#/!WgJwmjBNZEXhJnXHXw:matrix.org/$pQ1ymwshj2WpCwRiGJTjO2yD6sB2GqXPbndtspDa4Lk?via=matrix.org&via=igalia.com&via=mozilla.org [11:02:26.0641] Oh, I see. [11:02:48.0729] So very unintentionally polluting the prototype chain within your own code [11:03:16.0841] matrix message links do not work very well [11:03:22.0029] but i managed to find the message, ty [11:04:05.0245] +100 support for this change lol [11:04:26.0735] is kevin's voice robotting for anyone else, or just me? [11:04:34.0167] it sounds ok for me [11:04:42.0521] i mean not great but like normal jitsi quality [11:04:47.0005] it might be just me then, i've been having internet trouble [11:04:47.0984] no more than usual ljharb [11:04:58.0141] kevin sgtm [11:05:08.0615] there's a little static but his voice is unmodulated to me [11:05:23.0507] i'm spoiled by google meet and discord voice call quality, jitsi always sounds like robots [11:07:00.0616] zoom for me, but true [11:07:43.0121] there's uhhh no solution that works for everyone 😅 [11:08:13.0274] conference phone call [11:08:19.0391] SIP /s [11:08:23.0675] * SIP /s [11:08:25.0207] "so-and-so, your line is now open" [11:08:37.0171] I suppose next meeting would be zoom, so we'd see how it goes [11:08:50.0973] but I'm terrified already, fingers crossed [11:09:35.0133] we would prefer Zoom, but Rob has asked us to try Meet first [11:10:11.0778] if that'd be possible, I'd be personally grateful to you [11:10:31.0052] tbc i'm totally fine with jitsi, i was not saying we need to switch [11:11:46.0546] littledan: It is not a consensus-seeking matter. The editor group believes this is fully within our control. We are just looking for feedback before making the change, in case there are things we didn't think of. [11:15:05.0855] by "all my hats" i meant something like, i recuse myself as editor [11:15:23.0186] on the scale of refactorings we've done recently, this actually isn't all that big lol [11:15:24.0776] but as implementer and mentor for new folks to the spec on V8, this will be a lot clearer [11:15:41.0802] * but as implementer and mentor for new folks to the spec on V8, this will be a lot clearer [11:25:08.0337] unfortunately, identity isn't the appropriate concept for intuition either [11:25:20.0523] liveness is, but it's tied to identity [11:25:22.0489] identity by itself isn't [11:25:38.0930] forgability [11:25:54.0331] the intuition i think is something like can be reasonably considered to have liveness [11:26:00.0373] which is like... idk you tell me [11:43:20.0001] i would unship TA#sort if i could! [11:43:31.0535] i will die on the hill that there is no use case for sorting your bytes [11:43:51.0315] middle-endian [11:44:21.0588] chef's kiss would've been if by default, it used lexicographic sort [11:48:16.0960] speaking of TAs, there was a request from the W3C ColorWeb CG for float16-TAs if anyone wants to pick that up https://github.com/tc39/proposals/issues/453 [12:08:03.0765] Yeah Anne had written me about this, it is a Googler who wanted to push it forward I think [12:08:49.0415] I previously asked the former champions to work more on web platform integration, and now the request is coming from that side directly, so it is completely met [13:54:28.0033] who wants it? webgpu? [13:55:08.0819] i have some vague memory of Kai Ninomiya mentioning this but i may be misremembering [14:04:02.0764] i'd be happy to pick it up, but tbh i can't commit to unfunded time on it rn (i am available with funding tho) 2023-01-31 [06:54:55.0416] shu, waldemar: Were you able to review the Async Explicit Resource Management proposal specification text? [06:58:54.0301] Plenary begins in T-minus 1 minute encounting. [06:59:31.0595] rbuckton: i didn't have a chance to review the whole thing, but i did look at the `using await` sections of the draft spec [07:02:14.0268] > <@shuyuguo:matrix.org> rbuckton: i didn't have a chance to review the whole thing, but i did look at the `using await` sections of the draft spec The rest of the spec text that isn't `using await` is the same as the sync-version prior to carving `AsyncDisposableStack` and @@asyncDispose out in the November plenary. [07:02:58.0908] were there changes to using await? it looked like an exact mirror of the sync case, except plumbing through the `~async-dispose~` hint and awaiting disposable resources with that hint on block exit [07:03:06.0414] * were there changes to using await? it looked like an exact mirror of the sync case, except plumbing through the `~async-dispose~` hint and awaiting disposable resources with that hint on block exit [07:05:18.0306] > <@shuyuguo:matrix.org> were there changes to using await? it looked like an exact mirror of the sync case, except plumbing through the `~async-dispose~` hint and awaiting disposable resources with that hint on block exit No. The `~async-dispose~` plumbing was there when you reviewed Explicit Resource Management prior to Stage 3 since I'd left it in to support `AsyncDisposableStack`. The only changes I've made aside from adding the `using await` syntax were to incorporate editorial feedback that I already received on the sync version of the proposal since creating https://github.com/tc39/ecma262/pull/3000, so that the spec text shared between the two remains consistent. [07:05:42.0706] cool, that makes sense [07:06:44.0305] I should clarify, there were minor changes to address Mathieu Hofman and erights concerns about any evaluated `using await` forcing an explicit `await` even if the initialized value is `null` or `undefined`, but that should be about it. [07:08:43.0654] hmm, it would be nice if `useGrouping` had a string specifier for all options so you could ignore that it also takes undefined/Booleans [07:09:05.0076] it doesn't currently have a `"never"` option, just `false` [07:17:03.0189] Is Frank Tang here? His agenda item is next. [07:23:11.0615] bterlson: Should TCQ have a "Comment on topic" action that implies no further commentary is necessary? [07:23:39.0670] Maybe action is the wrong term. Maybe "queue item"? [07:25:51.0240] It's more like a flag on the queue topic I would say (since it could be a reply or a new topic) [07:26:05.0513] but yeah it could be added [07:36:50.0147] we could also just leave those comments here in Matrix and the chairs could read them aloud at their discretion [07:37:21.0541] adding "EOM" at the end seems like it's been a workable convention [07:38:26.0082] what "optional" and "allow" mean in the example? [07:38:47.0071] yeah, the status quo is also not bad [07:39:46.0613] > <@haxjs:matrix.org> what "optional" and "allow" mean in the example? it could mean anything, it's just an example [07:41:01.0749] yeah, I just curious how to explain the example [07:41:43.0690] Would be interesting if you could just 👍️ the current topic, since we often get a lot of `+1 ` comments [07:42:13.0154] > <@rbuckton:matrix.org> Would be interesting if you could just 👍️ the current topic, since we often get a lot of `+1 ` comments "react to current topic" as opposed to reply, I guess [07:42:19.0810] I don't understand if downgrade to stage 2 why not unship... [07:42:20.0499] That's what I was going for rbuckton . Just a lightweight mechanism to register feedback on the current topic [07:42:29.0546] where you could use some basic emotes like 👍️ 👎️ etc [07:43:15.0312] if we have a 👍️ react, we must also have a 💩 [07:43:50.0511] > <@haxjs:matrix.org> what "optional" and "allow" mean in the example? HE Shi-Jun: You could imagine that in a runtime like Deno, Node.js, or others, `allow` could restrict permissions when importing a certain library. So you could give the library file-system access, but not access to make network requests [07:44:00.0709] Yeah, that's why I thought free text for it is still important so we don't fall down the emoji reaction rathole [07:44:04.0269] Not sure if I'd go as far as adding 👎️, since a negative reaction or concern is better represented as a topic. [07:45:00.0006] That's a good point [07:45:10.0055] Plus we already have an emoji reaction thing that I don't think we've ever actually used correctly. [07:45:17.0559] Maybe then just "Support current topic" [07:45:46.0857] > <@anthonybullard:matrix.org> Maybe then just "Support current topic" Basically, yes. [07:46:00.0639] One problem I can think of is that it goes against our very recent discussion about explicit support [07:46:14.0282] I guess it's still explicit though [07:46:18.0193] > <@danielrosenwasser:matrix.org> HE Shi-Jun: You could imagine that in a runtime like Deno, Node.js, or others, `allow` could restrict permissions when importing a certain library. So you could give the library file-system access, but not access to make network requests the example is to import a css module so i don't understand how a css module relate to fs access... [07:47:15.0361] Yeah, the example might have been meant to be written with a `.js` extension, or the runtime has special behavior [07:47:30.0757] it's for your imagination :D [07:48:11.0629] maybe it disallow `@import "https://...."` in css? 😅 [07:54:50.0730] btw for folks less involved in this discussion, we have a response here: https://github.com/whatwg/html/issues/7233#issuecomment-1407049226 [08:06:09.0863] I prefer status quo to adding reacts on the agenda item. I don't want negative reacts, and would rather positive reacts have SOME context. [08:07:05.0476] "the proposal is great EOM" is better than a random thumb up IMO. [08:07:45.0790] (I agree but could not resist showing agreement by a random thumb up) [08:10:06.0831] shu: If you want to do a temperature check, state the question clearly [08:10:15.0583] yes i will craft a question when we do it [08:10:15.0820] the chairs have a recommended process for this now [08:10:22.0994] but i want to do it after justin's item [08:10:32.0100] We discussed this internally and one of our suggestions matches what @shu just said. Change semantics of `assert`, add `with` keyword to replace it (i.e., `assert` as an alias to `with`), phase out `assert`/forbid via lint [08:14:27.0638] Maybe we can just think of `assert` as a cast with implicit type coercion. (half j/k, half serious) [08:14:52.0359] yeah i honestly believe we have shoehorned ourselves into one particular meaning of "assert" [08:14:57.0902] and are not being flexible [08:15:10.0983] which is... a psychological thing, not a semantics thing [08:15:33.0823] Can whoever is typing mute? [08:15:54.0999] think that was me, sorry [08:19:55.0290] my understanding re process: > Withdrawing Proposals, Reverting to Earlier Stages, and Adopting Proposals > At any point in the process, a proposal champion may propose that a proposal be downgraded to an earlier stage or withdrawn. Consensus of the committee is necessary for these transitions. [08:20:05.0449] that doesn't mean *only* a champion may propose it. [08:20:34.0058] anyone can propose any changes at any time, whether they achieve consensus or are procedurally valid is a separate thing. [08:21:36.0037] As a new delegate in a new member organization, is there a document I can read to learn more about in-band and out-of-band? [08:21:37.0411] my view is that a downgrade should have the champions involved. forcing something to stage 1 is what i am objecting to here. I find this very concerning [08:21:48.0866] nothing can be forced because champions participate in consensus [08:21:58.0981] only *proposed*. which forces nothing. [08:22:02.0192] yeah we just don't have consensus for re-opening IB/OOB [08:22:19.0129] yep, agreed. I am responding to what you were proposing and saying that it would be inappropriate. I am surprised it was brought up i guess? [08:22:29.0543] like, that is a huge leap [08:22:36.0749] wait what i said? [08:22:45.0185] sorry, no, what jordan said [08:22:52.0227] ah yes agreed, i was also surprised [08:23:12.0907] I don't think so, but you can add the terms to the glossary at https://github.com/tc39/how-we-work/blob/main/terminology.md [08:23:56.0542] in this context, in-band means within the source text, specifically within the import declaration [08:24:13.0269] out-of-band would be things like HTTP headers, CLI flags, browser config, etc [08:26:29.0555] OOB would be something like import maps: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script/type/importmap [08:26:30.0696] sorry i may have overreacted there [08:28:33.0754] So basically with OOB configuration of the behavior happens outside of the ECMAScript source but is applied within the execution of said source? [08:28:50.0267] * So basically the configuration of the behavior happens outside of the ECMAScript source but is applied within the execution of said source? [08:29:29.0725] * So basically with OOB configuration of the behavior happens outside of the ECMAScript source but is applied within the execution of said source? [08:29:30.0691] yes, just like CSP and import maps [08:29:56.0645] Sounds good. Adding these terms to the above document will be good practice for going through the process here [08:30:22.0040] Anthony Bullard: PRs welcome [08:40:12.0635] if we had a temperature check for using in eval, I would give it a 👍️ [08:40:37.0031] but I don't feel strongly enough to even add a topic to TCQ [08:42:30.0477] Yeah I feel like we could go either way on eval; it's fine to prohibit or support [08:42:55.0667] I don't think most JS developers have internalized that they can use let at the top level of a direct eval [08:43:30.0504] +1 to doing a temperature check [08:44:35.0526] Anthony Bullard: in case you are looking for other stuff on tcq, maybe adding a temp check question isn't a bad idea... (i can help, i did the original implementation of the temp check) [08:45:33.0975] Working on it [08:45:46.0395] Just trying to find a good reference for the term in-band [08:47:05.0835] I will reach out if I have any questions. Haven't any took a peek at the repo yet [08:47:14.0355] is this being temp checked? [08:47:29.0119] Yes [08:47:36.0950] Jack Works: yes, on TCQ [08:47:57.0746] i can't see a vote UI, did I miss that? [08:48:15.0342] By the way, does the TCQ "Log" go anywhere? [08:48:47.0054] > <@jackworks:matrix.org> i can't see a vote UI, did I miss that? try reloading [08:48:56.0543] or there may be a bug [08:49:04.0251] I just refreshed and the temp check is gone now [08:49:22.0229] oh [08:49:26.0539] tried many time but see nothing [08:49:31.0756] 😬 [08:49:45.0242] current state [08:49:46.0369] It's gone for me as well after a refresh [08:49:50.0788] i support to reject `using` directly in eval [08:50:03.0460] ill vote on your behalf jack [08:50:09.0701] why only ban await,not ban yield? [08:50:28.0328] because there's the async `using await` ron will present later, i presume [08:51:35.0662] ok. so if syntax is `async using`, no need to ban `await`? [08:51:53.0999] 🤷 [08:52:23.0483] I would be happy to ban `yield` and for that matter also `undefined`, as long as we're banning stuff [08:52:28.0361] alright, if anyone wants to discuss anything from this meeting, i'll be around for the next hour. I won't make the afternoon session [08:52:41.0033] `{ using undefined = x } // oh no` [08:54:41.0594] I really hope we banned `let undefined` and `const undefined` in ES6 (only allow `var undefined` for webcompat). [08:55:05.0760] Michael Ficarra: Any conventions on commits / branches for this repo that I'm not seeing? [08:55:15.0615] `const undefined` is banned because consts need a value :-p but `let undefined` works fine [08:57:27.0061] just not at the top level of scripts because it's a global non-configurable property [08:58:00.0733] Seems like there are not. https://github.com/tc39/how-we-work/pull/127 [09:01:41.0117] Of course it's written in the one popular framework I haven't used in 5 years [09:02:33.0424] yulia: Temp check question would be adding an item to the queue for a temp check, but the temp check ui also displaying the question? [09:02:38.0207] * yulia: Temp check question would be adding an item to the queue for a temp check, but the temp check ui also displaying the question? [09:04:56.0523] temp check ui showing the question [09:05:02.0515] so, the chair would need to enter it [09:09:25.0041] right now non-chairs can't start a temp check [09:13:55.0385] Gotcha [09:14:51.0238] Let me fork, clone, and learn Vue real quick and hopefully we can have this ready for the Seattle meeting [09:36:54.0658] > <@bakkot:matrix.org> just not at the top level of scripts because it's a global non-configurable property That would never be disposed, because it never goes out of scope. [09:38:30.0561] > <@rbuckton:matrix.org> That would never be disposed, because it never goes out of scope. sorry, that was re: `let undefined` failing if you just type it in the console because it's attempting to redeclare a non-configurable global property, not about `using` [09:39:36.0188] Ah, my bad. [09:46:28.0735] > <@haxjs:matrix.org> ok. so if syntax is `async using`, no need to ban `await`? We might need to ban `async using` in other places instead. See https://tc39.es/ecma262/#prod-ForInOfStatement, which needs to ban `async of` because `async of => {}` is a legal arrow. `async using` would potentially require a complex cover grammar to deal with similar cases. [09:48:22.0491] are there any contexts in which `async [no lineterminator here] using` is currently legal? [09:48:38.0801] other than the horrible async arrow one [09:49:01.0666] within double quotes!!! [09:49:08.0527] or a regexp [09:49:10.0116] > <@bakkot:matrix.org> I would be happy to ban `yield` and for that matter also `undefined`, as long as we're banning stuff I'm less concerned about `yield` because I don't see a `using yield` declaration being a thing. [09:49:22.0929] > <@littledan:matrix.org> or a regexp or a method name. [09:49:43.0821] ah, yes, method names also [09:50:52.0310] I think the async arrow case is the only one likely to be problematic, but that one would be a problem, certainly [09:50:58.0502] Where as `using [no LineTerminator here] await` isn't legal anywhere outside of string/regexp literal contexts. [09:54:24.0440] please don't make me write a bunch more string comparisons on every binding identifier parse :( [09:54:49.0475] what about only the binding identifier parses in `using` declarations [09:54:53.0267] cycles are precious and come dear [09:54:53.0986] i mean how many of those can there be [09:55:04.0835] that's a new feature so we can start with a lower bar [09:55:23.0482] can't break people's expectations if we start super low! [09:55:32.0128] https://www.w3.org/2023/01/pressrelease-w3c-le-launched.html.en [10:00:54.0129] https://tc39.es/proposal-async-explicit-resource-management/#sec-suppressederror [10:14:06.0063] * waldemar: note i'm not talking about `suppressed`, which is the suppressed error, i'm talking about `error`, which is the cause of the suppression (re your queue item) [10:14:45.0508] I should have clarified re: https://github.com/tc39/proposal-explicit-resource-management/pull/140 whether it requires consensus. Given the algorithm changes in ForBodyEvaluation and CreatePerIterationEnvironment are essentially no-ops, removing them has no observable effect on runtime semantics. [10:19:07.0809] am warming up to the option of prohibiting '.cause' on SuppressedErrors - I think it's a conceptual mismatch for SuppressedError [10:19:34.0161] i'm still not clear on why it's not a cause when we all keep describing it as the thing that caused the suppression [10:19:40.0908] (i.e., read the options bag and throw if it's a present) [10:20:10.0602] it doesn't cause the suppression - the use of the syntax causes the suppression [10:20:44.0682] in `using`, sure. but not necessarily in every use of SuppressedError [10:20:51.0737] that's the only use of SuppressedError [10:21:09.0989] in the spec, but this is something users will use separately [10:21:39.0658] ok but it is a mismatch for the only case it gets used in the spec, so it's bad fit [10:21:47.0850] even if users might do a different thing where it would get used in a different way [10:21:51.0122] ljharb: perhaps you're thinking of "cause" to mean "caused mechanically the SuppressedError to be created and thrown" [10:21:57.0990] yes, that's what i'm thinking of [10:22:05.0642] the cause is what caused the SuppressedError [10:22:20.0990] whereas waldemar and kevin (and myself) think of "cause" as, like, the conceptual reason of an error [10:22:21.0580] which in the case kevin mentioned is a SyntaxError, right? [10:23:07.0993] yes, what ron is saying right now [10:23:11.0830] it is not a linear relationship [10:23:36.0281] the core disagreement i think is how do developers understand "cause" [10:23:58.0193] is it this linear causality chain, or is it a simpler "whatever effected it to be thrown mechanically" [10:24:06.0693] i would argue the latter [10:24:31.0247] yeah so far we've had folks on both sides [10:24:39.0169] I think the only acceptable use for "cause" is "we hit an error condition because of a prior error condition", and that is _not_ what it means here - here it is "we had an error, and then a different error which would prevent surfacing the first one" [10:24:47.0987] * I think the only acceptable use for "error" is "we hit an error condition because of a prior error condition", and that is _not_ what it means here - here it is "we had an error, and then a different error which would prevent surfacing the first one" [10:24:57.0432] I think the fact there is such disagreement is evidence of reusing `cause` being confusing. [10:24:57.0459] * I think the only acceptable use for "cause" is "we hit an error condition because of a prior error condition", and that is _not_ what it means here - here it is "we had an error, and then a different error which would prevent surfacing the first one" [10:25:30.0326] to be clear my core motivation here is "it should not be possible to have an error that has two potential conceptual causes - .error and .cause" [10:25:43.0684] there are some good argument being made that `.cause` may not be right to replace `.error` [10:25:59.0860] but that still doesn't mean it makes sense to have an error instance with all of cause/error/suppressed [10:26:27.0317] `error` is not the "cause", neither is `supressed` the "cause". My use of the term "causes a suppression" does not imply `cause` in this case, it implies the cause of a behavior. [10:27:12.0570] > <@ljharb:matrix.org> to be clear my core motivation here is "it should not be possible to have an error that has two potential conceptual causes - .error and .cause" `SuppressedError` _does_ have two conceptual causes. I'm more in favor of banning `cause` because it results in _three_ conceptual causes. [10:27:24.0661] sure, i can accept that reframing [10:29:38.0549] My understanding is `cause` should be used by developers to specify the low-level "cause" of a high-level error. So `SuppressedError` is not the case. [10:32:15.0223] shu: We don't use arguments.length, we generally use "not present" as in AOs. [10:32:29.0763] no we actually check arguments length in some places [10:32:32.0140] like `Array#splice` [10:32:34.0232] it is cursed [10:32:35.0734] i hate it [10:33:05.0712] Ah. I was looking at reduce/reduceRight as an exemplar [10:34:50.0068] tbc I'm fine with the status quo also but very mildly prefer removing InstallErrorCause [10:34:57.0980] * tbc I'm fine with the status quo also but very mildly prefer removing InstallErrorCause [10:35:09.0327] Seems a little odd to not support it silently. but maybe ok. Can't imagine people using this constructor directly very often [10:35:49.0253] yes the silent nop is weird [10:35:55.0461] but also convinced it doesn't matter in practice [10:36:09.0640] Please could someone add a summary to the notes [10:36:34.0407] error conditions in error constructors are kind of painful [10:36:40.0526] Its the nature of the language. Even before `{ cause }` was supported anyone could pass that into an `Error` constructor without issue, they just wouldn't get the benefit. [10:36:48.0329] I think I don't understand the result of removing InstallErrorCause, what's the difference? [10:36:51.0344] tru nuf [10:36:57.0426] > <@bakkot:matrix.org> error conditions in error constructors are kind of painful See `new AggregateError()` [10:37:09.0193] Only throws because `undefined` isn't iterable. [10:37:43.0118] HE Shi-Jun: the consequence of removing InstallErrorCause is, the `options` parameter is ignored, so if you do `new SuppressedError('foo', null, null, { cause })` the `cause` property is not read or installed on the resulting error [10:37:45.0832] (compared to other native errors, most of which check for `undefined` for things like `message`). [10:38:04.0595] * HE Shi-Jun: the consequence of removing InstallErrorCause is, the `options` parameter is ignored, so if you do `new SuppressedError('foo', null, null, { cause })` the `cause` property is not read or installed on the resulting error [10:38:19.0269] it's only relevant if you're attempting to construct a SuppressedError manually [10:38:30.0360] > <@aclaymore:matrix.org> Please could someone add a summary to the notes bump... [10:38:38.0351] I primarily added `InstallErrorCause` to SuppressedError for consistency with other native errors. Not having it is not an issue to the proposal. [10:39:07.0779] > <@bakkot:matrix.org> HE Shi-Jun: the consequence of removing InstallErrorCause is, the `options` parameter is ignored, so if you do `new SuppressedError('foo', null, null, { cause })` the `cause` property is not read or installed on the resulting error ok, it's a little weird to ignore `cause`, but i guess it's harmless? [10:42:29.0745] Process question: Does the above change I mentioned in my update before the break need consensus? [10:42:40.0212] > <@rbuckton:matrix.org> I should have clarified re: https://github.com/tc39/proposal-explicit-resource-management/pull/140 whether it requires consensus. Given the algorithm changes in ForBodyEvaluation and CreatePerIterationEnvironment are essentially no-ops, removing them has no observable effect on runtime semantics. * Process question: Does the above change I mentioned in my update before the break need consensus? [10:42:45.0224] Oh, I forgot to mention we'll be cutting the next annual edition of the spec shortly [10:43:04.0725] oh yeah [10:43:13.0588] presumably after this week's stage 4s are merged [10:43:24.0639] rbuckton: I generally think changes with no observable changes do not require consensus [10:44:03.0555] agree, if it's not observable then the only folks you may want to check with first are the editors :-) [10:46:02.0658] other advantage of removing `cause` from SuppressedError - browsers don't have to figure out how to render it [10:46:42.0117] diverging paths bro [10:46:52.0763] a slider that has notches at each suppression point, that branches into a different slider [10:51:46.0282] ohhh maybe we did async generators wrong, I remember debating this around [10:52:08.0192] well, I think Kevin (zenparsing) had good reasons for all the details he chose [10:53:05.0512] ljharb: I created https://github.com/tc39/proposal-explicit-resource-management/issues/147 to track the consensus change to SuppressedError [10:53:42.0021] rbuckton: ok, i'd already filed https://github.com/tc39/proposal-explicit-resource-management/pull/146 :-) [10:54:46.0109] Ah, I put together a PR as well. Thanks [10:55:20.0714] wait isn't it technically possible to do a reentrant .next() call with sync iterator helpers? (not sure what that would do but you can construct it) [10:55:33.0027] i definitely think it is [10:55:48.0843] i was going to comment that but realized that wouldn't be the _consumer_ calling next twice, so it probably isn't relevant here [10:56:05.0461] it successfully nerdsniped me for a few minutes tho [11:08:05.0015] we could add an agenda section ahead of the other proposal-related items for demotions only [11:08:21.0839] so that they are not only called out but also prioritised [11:09:18.0641] why do we need a new section [11:09:28.0048] could just order it ahead of others by convention [11:09:32.0135] as we order stuff by convention now [11:09:39.0729] i'd hope it's not so frequent that a section is needed [11:09:46.0545] sure, we could change the ordering rules also [11:09:59.0870] they're just already complicated enough that they are often broken [11:10:50.0616] > <@littledan:matrix.org> well, I think Kevin (zenparsing) had good reasons for all the details he chose as a historical note, one of the relevant details (`yield` being `yield await`) was decided in later and Kevin was in favor of a different option than we went with (in https://docs.google.com/presentation/d/1U6PivKbFO0YgoFlrYB82MtXf1ofCp1xSVOODOvranBM/edit#slide=id.g223fba4116_0_155 - he wanted option 2) [11:15:26.0190] yeah, I remember that discussion. I guess if we went the other way, then async generators would be more parallel by default. [11:15:35.0270] yeah, a little bit [11:15:41.0683] only if you `yield`'d a promise though [11:16:07.0730] oh so it wouldn't quite be enough for the semantics you're proposing? [11:16:12.0496] right [11:16:31.0661] or, well, you _could_ get to the semantics I'm proposing, but you basically wouldn't be able to use the `await` syntax [11:17:39.0327] like in `map`, you wouldn't be able to do `for await (item of inner) yield fn(item)` because that would do at most one call to the underlying iterator at once (because `for await` is sequential) [11:18:29.0185] right [11:18:42.0647] you'd have to do like `yield inner.next().then(p => p.done ? { done: true } : Promise.resolve(p.value).then(fn).then(value => { done: false, value}))` [11:18:55.0326] which, like, not much point to having syntax at that point [11:19:08.0715] the iterator protocol is to scary to contemplate this [11:19:08.0850] * you'd have to do like `yield inner.next().then(p => p.done ? { done: true } : Promise.resolve(p.value).then(fn).then(value => { done: false, value}))` [11:19:13.0617] * the iterator protocol is to scary to contemplate this [11:20:21.0290] We definitely had conversations about another repo, I believe it exists. [11:20:44.0517] https://github.com/js-temporal/proposal-temporal-v2 I think [11:20:51.0027] Yep [11:30:00.0791] littledan: i didn't understand if philip was proposing _allowing_ truncation or _requiring_ truncation [11:30:14.0675] if requiring truncation to microsecond then there's no compat matrix, but that's still kinda weird? [11:33:02.0418] IIUC, pdunkel's proposal was to underspecify the underlying data model and specifying the interface with nanoseconds so that implementations could change the data model in the future, it just being an implementation detail at that point. [11:33:25.0728] * IIUC, pdunkel's proposal was to underspecify the underlying data model and specifying the interface with nanoseconds so that implementations could change the data model in the future, it just being an implementation detail at that point. [11:33:27.0758] then that sounds like a compat matrix and i share dan's concerns [11:33:48.0939] we remain unconvinced by the use cases [11:34:16.0713] for including precision higher than microseconds? [11:34:25.0561] yes [11:35:53.0079] ryzokuken: longish discussion here https://github.com/tc39/proposal-temporal/issues/1700#issuecomment-896368225 [11:36:50.0690] our previous position was "maybe we can live with it" but upon rediscussion and scoping out work for eventually shipping temporal, using int64s is something we really want [11:44:17.0309] > <@shuyuguo:matrix.org> littledan: i didn't understand if philip was proposing _allowing_ truncation or _requiring_ truncation either way it sounds like a bad idea? [11:44:38.0372] presumably requiring truncation would be to enable an evolution path which later doesn't require it (or requires non-truncation) [11:45:08.0977] i agree it's not a good idea [11:45:16.0963] but i'm not gonna die on that hill if that's the compromise? [11:52:14.0158] how could ID be an initialism? what is the D? [11:52:41.0926] identity document [11:52:52.0097] wow, TIL [11:53:09.0312] but it's also that outside of programming, it is always `id` or `ID` and never `Id` (which is the freudian concept when at the start of a sentence) [11:53:44.0035] > <@shuyuguo:matrix.org> but i'm not gonna die on that hill if that's the compromise? sure, me neither [11:53:57.0245] in my experience `getElementById` is one of the most "gross" naming conventions i've heard folks complain about on the web behind XMLHttpRequest and "referer" [11:54:26.0878] i like Id [11:54:59.0520] Id is consistent with DOM naming which is an environment this will be used. [11:55:15.0278] afaik it's just the single function, unless there's more i missed [11:55:26.0690] and nowadays folks use querySelector instead of the older getElementBy* functions [11:55:36.0154] IIRC, "referer" isn't a naming convention, per se, but a typo we are stuck with. [11:55:43.0438] I'd always assumed it was an abbreviation for "Id-entity", not a titlecasing of "ID" [11:56:01.0034] * I'd always assumed it was an abbreviation for "Id-entity", not a titlecasing of "ID" [11:56:08.0477] Michael Ficarra: I think it is [11:58:18.0116] it's also been part of the airbnb style guide for a long time (not a part i authored) and nobody's complained about the requirement, ftr https://github.com/airbnb/javascript#naming--Acronyms-and-Initialisms [11:59:32.0436] ljharb: that doesn't cover abbreviations like "Id" though [11:59:50.0922] fair point, not even in the examples [12:00:04.0928] i don't think it's really an abbreviation at this point tho, any more than "email" is. [12:00:41.0683] I mean, are you arguing that it's its own word now? Because that would have the same capitalisation [12:00:49.0638] at any rate i feel very strongly against "Id" but "identifier" or "code" seem fine to me [12:01:38.0803] sorry for jumping in outside of the queue [12:04:18.0889] Chris de Almeida: For the timezoneId/calendarId issue, see this thread https://github.com/tc39/proposal-temporal/issues/1808#issuecomment-1373987231 [12:04:35.0567] (not sure what the most representative comment is, but scroll up and down from there) [12:06:50.0197] > <@ljharb:matrix.org> it's also been part of the airbnb style guide for a long time (not a part i authored) and nobody's complained about the requirement, ftr https://github.com/airbnb/javascript#naming--Acronyms-and-Initialisms more relevant precedent I think is the w3c rules: https://w3ctag.github.io/design-principles/#casing-rules [12:07:15.0478] Given the immediate context of "timeZoneId", I see the capitalization of "Id" as a result of using camelCase, and therefore completely fine. [12:07:21.0934] "Initialisms in APIs: All caps, except when the first word in a method or property, for example HTMLCollection, innerHTML, bgColor" [12:07:31.0890] `timeZoneId` is also something i dislike. [12:07:32.0930] but "Id" is not an initialism so [12:07:48.0709] and yes, but we're not bound by the w3c principles, and in this case i think they result in less clear names [12:07:55.0035] it specifically mentions `Id` [12:08:01.0979] yes, i know w3c does [12:08:07.0614] it doesn't change my opinion [12:08:26.0532] apologies, I just found out about this doc and was just exclaiming [12:09:00.0151] while I do not exactly consider myself _bound_ by these rules, I am not going to want to deviate them without very, very strong reason [12:09:34.0119] sure, a number of folks seem unwilling to provide consensus for `ID`. that's fine, but i'm not willing to provide it for `Id`. [12:09:46.0521] but `identifier` and `code` seem perfectly workable [12:09:47.0421] isn't that what they're named now [12:09:50.0741] either way, it's definitely a document that affects us more strongly than everything else I see so far [12:09:52.0316] `Id` i mean [12:10:35.0287] the accessor is `.id` and the property is `.calendar`, and one proposal changes that to `.calendarId`. if there's already `.timeZoneId` then i missed it, and i can't prevent that one, obviously. [12:11:03.0455] i don't hear an argument from you jordan [12:11:07.0590] i hear "i don't like it" [12:11:48.0273] i find it confusing, and decades of complaints from random devs on irc/slack/etc complaining about the capitalization of the three things i mentioned reinforces my belief [12:11:50.0792] if `timeZoneId` already exists, that's an even compelling reason... I'd be against anything _other than_ `calendarId` in that case for internal consistency. [12:11:56.0812] * if `timeZoneId` already exists, that's an even compelling reason... I'd be against anything _other than_ `calendarId` in that case for internal consistency. [12:12:13.0496] unless we also changed `timeZoneId` to match whatever else is chosen [12:13:01.0422] > <@ljharb:matrix.org> i find it confusing, and decades of complaints from random devs on irc/slack/etc complaining about the capitalization of the three things i mentioned reinforces my belief is that really a problem lately with modern tooling/autocomplete? [12:13:51.0154] yes, it's about readability [12:14:23.0947] I really think `id` is the right name here [12:14:33.0961] or `calendarId` etc [12:14:37.0333] * or `calendarId` etc [12:15:44.0126] I concur with `Id`. `Id` is not an initialism, its an abbreviation. [12:17:31.0383] `ID` is like using `STATS` rather than `Stats` as the abbreviation for "Statistics" [12:19:21.0719] we need a reasonable argument for lone objections, i.e. "i understand but disagree" [12:19:36.0645] AFAICT _no other delegate_ considers jordan's objection here reasonable [12:19:48.0054] my argument is already stated: i think "Id" is confusing and i would prefer to avoid confusion [12:19:48.0811] so i really do not understand what more deliberation can get us [12:19:55.0724] that is not an argument! [12:20:01.0034] that is "i don't like it" [12:20:02.0454] Though I think Jordan was advocating for using `calendarIdentifier` and `timeZoneIdentifier` vs choosing `Id` or `ID`. [12:20:10.0523] and sure we make decisions based on "i don't like it" all the time [12:20:17.0934] but this is so very clearly onesided [12:20:19.0675] and you are wasting time [12:20:26.0896] `calendarId` is fine, please let's not waste more committee time on a capitalization debate [12:20:28.0309] which is, unfortunately, just another color to paint the bikeshed :( [12:20:45.0670] This is a very poor reason to be a lone blocker [12:20:50.0571] css should have been colour [12:21:25.0515] i have a concrete next step here as well [12:22:36.0904] so as to break the logjam: i remain convinced `calendarId` is the right name, and i will ship with that name, as a willful violation if need be, (unless, of course, a _reasonable_ counterargument is given) [12:22:42.0941] * so as to break the logjam: i remain convinced `calendarId` is the right name, and i will ship with that name, as a willful violation if need be, (unless, of course, a _reasonable_ counterargument is given) [12:24:21.0184] I hate `Id` and everyone that uses it is WRONG, but I've long since put down that sword and use it under duress [12:25:55.0032] calendarID > calendarId > calendarCode so if we can't have the first, then go to the 2nd [12:26:09.0137] In English, `ID` (as in, "show me your ID") is an initialism, not an abbreviation, for "Identity Document", https://en.wikipedia.org/wiki/Identity_document, if that matters. [12:26:25.0249] > <@shuyuguo:matrix.org> so as to break the logjam: i remain convinced `calendarId` is the right name, and i will ship with that name, as a willful violation if need be, (unless, of course, a _reasonable_ counterargument is given) so we’re just abandoning pretense of equality between browsers and non-browser participants of tc39? [12:26:44.0432] > <@rbuckton:matrix.org> In English, `ID` (as in, "show me your ID") is an initialism, not an abbreviation, for "Identity Document", https://en.wikipedia.org/wiki/Identity_document, if that matters. And Id is the abbreviation for Identifier or Identity [12:27:27.0447] It’s also the dual of ego. [12:27:27.0723] Precisely. Though `id` is a psychological term. [12:29:19.0940] ljharb: not at all. i believe _some_ action is needed than continuing bikeshedding on the name [12:29:37.0858] Unfortunately, `ID` vs `Id` is a very long-running debate. I lean on the side of `ID` makes sense if you're using SCREAMING_SNAKE_CASE (e.g., for constant values), because you are capitalizing every letter, while `Id` should be what you use for camelCase/PascalCase identifiers. [12:30:01.0144] and a perfectly reasonable option is “identifier or code”. Let’s just do one of those - i don’t want to argue about it either, but that doesn’t mean i want to concede. [12:30:05.0695] and if you think my trying to make progress on a name bikeshed is equivalent to discarding all non-browser participants' opinions, i don't know what to tell you [12:31:05.0563] i think that any claim of intending to ship a willful violation that disregards consensus is a dangerous precedent to set, and isn't worth buying a few weeks or months of a faster decision. [12:32:45.0303] does it matter that there's already precedent for `Id` in the spec? [12:33:12.0181] I would say yes. What is the precedent? [12:33:13.0842] > <@softwarechris:matrix.org> does it matter that there's already precedent for `Id` in the spec? * I would say yes. What is the precedent? [12:34:05.0487] I didn't think there was any precedent in ECMA-262 or ECMA-402 [12:34:10.0268] https://tc39.es/ecma262/#prod-SingleNameBinding [12:34:17.0751] The current ECMA-262 spec uses `timeZoneIdentifier` in AO arguments. [12:34:22.0199] `2. Let lhs be ? ResolveBinding(bindingId, environment).` [12:34:31.0702] `i. Set v to ? NamedEvaluation of Initializer with argument bindingId.` [12:34:39.0546] heh I don't think spec-internal things count [12:34:50.0678] * heh I don't think spec-internal things count [12:34:57.0117] Yeah, unfortunately I concur. The spec is inconsistent in naming in many places. [12:35:47.0454] spec-internal names are terrible [12:36:06.0853] lots of single-letter variables, I think in at least one place with both `_C_` and `_c_` in the same algorithm [12:36:49.0693] If it helps, not only does the DOM use `Id` capitalization, so does NodeJS. [12:37:23.0037] https://nodejs.org/dist/latest-v19.x/docs/api/async_hooks.html#async_hooksexecutionasyncid [12:38:00.0816] sure... `Id` convention is fairly standard in many languages and libs [12:38:01.0315] > <@ljharb:matrix.org> i think that any claim of intending to ship a willful violation that disregards consensus is a dangerous precedent to set, and isn't worth buying a few weeks or months of a faster decision. if only i believed that a sensible compromise was possible. but practically speaking there is definitely time, chrome isn't going to ship in a few weeks or even months [12:38:32.0526] so the two largest JS ecosystem conventions use `Id` fairly consistently. [12:39:23.0775] i can temper my response as "by shipping time, if there isn't consensus, i'm going to ship `calendarId` instead of let that block shipping Temporal" [12:39:37.0893] NodeJS isn't _entirely_ consistent on how they handle initialisms, but `Id` seems fairly consistent. [12:40:19.0972] > <@rbuckton:matrix.org> If it helps, not only does the DOM use `Id` capitalization, so does NodeJS. Yeah @rbuckton that was my argument, the ecosystem (whether web or server side) are already using that capitalisation, theres quite large precedent for it already. [12:48:15.0580] it does seem like a foregone conclusion doesn't it? I must say I have a hard time understanding the controversy [12:50:10.0020] cleaning up the notes, I'm just sort of shocked how reasonable we all sound, and how we're making clear logical arguments on all sides. I sometimes get caught up in the emotions in the moment and lose track of that! And it's been amazing to work with the transcriptionist--when I was helping with notes, there was so little to fix. [12:50:54.0297] like, how do we all make such interesting coherent comments improvised? We're pretty good! [12:51:51.0312] I was wondering how it must feel like to transcribe a meeting like ours [12:51:56.0580] with no context whatsoever [12:54:23.0105] well, I think they were reading our corrections and getting better over the course of the meeting [12:54:50.0793] anyway it'd be great to get more feedback from everyone, especially people correcting notes, on the transcriptionists this time [12:55:22.0598] i appreciate the tempering [12:56:12.0781] my feedback is that I love the transcriptionists [12:56:24.0265] notes require much less work to fix, and also I don't have to run the bot [12:56:58.0486] it's so much better. there's always going to be tiny things to polish but none of that detracts from how much better the experience is with the transcriptionist. [13:11:26.0497] > <@pipobscure:matrix.org> And Id is the abbreviation for Identifier or Identity At least wikipedia article also use ID as the abbr for identifier or identity ( https://en.wikipedia.org/wiki/Identifier ) [13:48:36.0193] re: notes, I do hope we can fix up the linebreaks before publishing [13:48:45.0724] that's the main thing I would want to change [13:53:11.0867] Yeah, I'll definitely be in touch with the firm to see if we can get that fixed before next meeting (and I'm fixing the line breaks for the topics where I presented) [13:55:00.0523] That, at least, we can probably handle with a very small script [13:55:59.0835] Yah, I was thinking a regex could convert the line breaks into paragraphs [13:56:02.0725] there's often duplicated words (or small corrections) on subsequent lines [14:11:06.0482] actually even more, i'm going to walk back chrome unilaterally doing anything with a willful violation. the right next step on my end, in the case of no TC39 consensus, is an HTML spec PR to document the willful violation [14:11:40.0052] if other browsers have concerns, then we'll hash it out there, as interop is still paramount at the end of the day, but the `Id` spelling is definitely the right one to use on the web platform [15:58:34.0372] c++ apparently considering pipeline, directly referencing the JS proposal https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2672r0.html