2023-11-01 [18:00:02.0504] i think torque could support suspend points natively with a desugaring [18:00:27.0639] this was one of the things i had in mind when i originally suggested the builtin async functions/generators [18:40:29.0736] by all means, i'd love someone to implement it [18:40:40.0476] * by all means, i'd love for someone to implement it [23:30:07.0012] If anyone wants to give feedback ahead of the 'state of JS' survey: https://github.com/Devographics/surveys/issues/224 [02:13:41.0650] How long has test262.report been down for? are there plans to bring it back up? [03:54:00.0400] test262.fyi :) [03:55:17.0593] Aaaahhh [08:47:06.0769] base64 proposal is updated to remove streaming, fill out spec text, and settle outstanding questions about the API: https://github.com/tc39/proposal-arraybuffer-base64 see playground for overview and a polyfill in the console: https://tc39.es/proposal-arraybuffer-base64/ other than removing streaming, the most significant change is that the base64 decoder is now permissive by default (ignores whitespace, does not require padding), with a `strict: true` options bag argument which makes it strict (does not allow whitespace, enforces padding) would appreciate eyes on it, and especially if anyone wants to volunteer to review before the November plenary so I can ask for stage 3 (assuming Peter no longer objects); otherwise I'll be asking in January [09:09:19.0031] I’ll volunteer to review 2023-11-02 [10:39:25.0273] Now that we have dates & time zones for the next meetings, could we add them to the calendar? [10:39:26.0580] (or I can do it by myself but I don't know how to add events to the calendar) [14:18:56.0001] i'll make sure they're on there 2023-11-07 [23:04:55.0799] openai announced a new Whisper model, but still no streaming support :( all the services which offer real-time transcription, including those which just wrap whisper with some hacks, are basically garbage relative to whisper. google has a new model (Chirp) this year, but it doesn't work with real-time transcription either. whisper gets near-perfect transcriptions for content like our meetings, everyone else misses one word in five. but using whisper without any of the streaming hacks (which lower quality a lot) means transcriptions will necessarily be 30 seconds behind (+ time to transcribe and network latency, so in practice more like 40 seconds). I don't think automatic transcription is going to be viable until something in this landscape changes. (cc littledan) I might set up a separate 40-second-latency transcription notes doc at the next meeting to help with fixing things the human transcriptionists miss. anyone happen to have played with any other promising real-time transcription services recently? [03:03:37.0883] > <@bakkot:matrix.org> openai announced a new Whisper model, but still no streaming support :( > > all the services which offer real-time transcription, including those which just wrap whisper with some hacks, are basically garbage relative to whisper. google has a new model (Chirp) this year, but it doesn't work with real-time transcription either. > > whisper gets near-perfect transcriptions for content like our meetings, everyone else misses one word in five. but using whisper without any of the streaming hacks (which lower quality a lot) means transcriptions will necessarily be 30 seconds behind (+ time to transcribe and network latency, so in practice more like 40 seconds). > > I don't think automatic transcription is going to be viable until something in this landscape changes. (cc littledan) > > I might set up a separate 40-second-latency transcription notes doc at the next meeting to help with fixing things the human transcriptionists miss. > > anyone happen to have played with any other promising real-time transcription services recently? saminahusain: [03:04:04.0429] Thanks for the report, bakkot . Let's check up on this again at the end of next year. [03:04:16.0687] sounds like we need to repeat the budget request for transcriptionists [03:04:33.0931] Are you saying we get good accuracy with a 40-second delay? [03:04:58.0007] it would be accurate, yeah IIUC [03:05:17.0188] the 40 second delay is whisper's only shortcoming [03:06:32.0966] actually, I haven't tried it myself. Wonder how well it does with various accents [03:07:44.0331] they have an example with a pretty thick accent though, fun [03:07:45.0834] https://openai.com/research/whisper [07:11:54.0820] right. Whisper is very accurate in my tests, but it fundamentally operates on 30-second chunks of audio and takes a little while to run (say 10 seconds per chunk), so trying to stream it to the notes doc would mean that every 30 seconds we get a high-quality transcript of the portion of the meeting starting 40 seconds ago and running through 10 seconds ago. I haven't actually set that up but I expect it to work. [07:12:19.0097] unfortunately 40 seconds of lag is a lot of lag [07:25:11.0927] > I might set up a separate 40-second-latency transcription notes doc at the next meeting to help with fixing things the human transcriptionists miss. That would be *so* helpful! [07:45:46.0531] bakkot: What will this cost per meeting? Even if it's only like $10, we should lump in that funding with the transcription costs. [07:47:22.0958] for actual Whisper it'll be free; it runs locally [07:49:09.0748] I could maybe cut a few seconds of lag off by using the API which would cost ~$6/meeting (somehow the API manages to be substantially faster than running locally), but the difference between 35 seconds and 40 seconds probably isn't worth worrying about [10:11:18.0457] if the model is in fact pretty much perfect in terms of accuracy, why not record the meeting and postprocess for transcription? then delete the recording afterwards [10:12:33.0097] shu: some people like to edit the notes immediately after speaking [10:12:56.0149] but is that because the accuracy is in doubt? [10:13:36.0028] I think some people make minor rephrasings, remove stumbles, etc [10:13:57.0511] fair enough [10:22:25.0010] personally, if the transcription is very accurate, I would be fine waiting until the end of the day (or week) to do my reviews [10:23:31.0363] but having the two docs sounds like a great compromise [10:25:05.0324] the worst part about reviewing notes for me is when the notes are either incomprehensible (our previous automatic transcription) or missing entire sentences (human transcription) and I can't remember what was said [10:25:27.0737] having a more accurate document to refer to would be so helpful for that [10:38:32.0085] the transcripts are also missing paragraph breaks and speaker assignments, and you really want to do those in real time [10:40:03.0578] * the computer-generated transcripts are also missing paragraph breaks and speaker assignments, and you really want to do those in real time [11:02:35.0177] Another thing that we try and edit in live are when people post code snippets into TCQ or matrix. As the verbatim transcription of only the audio without the code can be almost meaningless [11:40:43.0124] oh yeah, speaker attribution is actually pretty tricky to do after the fact [12:29:30.0025] Simply get everyone to commit to saying their acronym at the start of each sentence [12:29:56.0361] 😅 2023-11-09 [11:34:40.0186] rbuckton: `using` declarations are supposed to be early errors at script toplevels, right? is the TS playground allowing that incorrectly? [11:47:45.0787] Yes, it should be an early error. The playground is wrong. [12:04:29.0255] thanks for confirming [12:08:13.0820] IIRC we should report an error in that case, but I'm not sure what settings the playground uses offhand. If you send me a playground link, I'll try to look at it tomorrow as I'm traveling today 2023-11-10 [16:35:06.0286] Feature-Sensitive Coverage for Conformance Testing of Programming Language Implementations: https://dl.acm.org/doi/pdf/10.1145/3591240 [16:35:16.0977] > We extend JEST, the state-of-the-art JavaScript conformance test synthesizer using coverage-guided mutational fuzzing, with various FS and FCPS coverage criteria. For the latest JavaScript language specification (ES13, 2022), our tool automatically synthesizes 237,981 conformance tests in 50 hours with five coverage criteria. We evaluated the conformance of eight mainstream JavaScript implementations (four engines and four transpilers) with the synthesized conformance tests and discovered bugs in all of them. The tool detected 143 distinct conformance bugs (42 in engines and 101 in transpilers), 85 of which were confirmed by the developers and 83 of which were newly discovered bugs. 2023-11-11 [08:56:01.0380] > <@bakkot:matrix.org> the computer-generated transcripts are also missing paragraph breaks and speaker assignments, and you really want to do those in real time We just need another AI to merge the human annotated transcript with the recording. [09:05:29.0394] I have actually seriously considered hooking up a special-purpose speaker diarization model; that's definitely a thing [09:06:32.0754] but the whole system is a bit of a mess already 2023-11-13 [09:21:50.0269] The Interest Survey for the 100th TC39 meeting in February in San Diego is posted 🎉 - https://github.com/tc39/Reflector/issues/512 Please add yourself by Tuesday 21st November. [09:23:53.0218] is there more info on where in SD? [09:24:07.0888] ah it's on the top of the sheet, thanks [09:32:58.0216] I am intrigued as to whether the precise part of SD makes a difference to your choice. [09:36:48.0497] if timezone is not inconvenient to be remote, i personally do not want to go somewhere where either i'll have to rent a car or take taxis everyday to get to the venue, or have to stay, like, near some office park outside of the city [09:38:56.0105] ah I see [10:45:25.0271] Same, bike share or walkability is super important for me. I will not rent a car, and would prefer not to take 5-minute Ubers multiple times a day. SD doesn't appear to have a bike share program, so I may end up trying out those electric scooters for the first time. [10:47:20.0211] how navigable is San Diego without a car in general? never been there [10:59:04.0516] > <@michaelficarra:matrix.org> Same, bike share or walkability is super important for me. I will not rent a car, and would prefer not to take 5-minute Ubers multiple times a day. SD doesn't appear to have a bike share program, so I may end up trying out those electric scooters for the first time. yeah i say "rent a car" in the general sense, i will also not rent a car [11:07:03.0514] i don't mind ubers but scooters/walkability is a huge plus [11:07:08.0969] * i don't mind ubers but scooters/walkability is a huge plus. def not renting a car [12:42:19.0125] Let's see if we can coordinate on hotels to maximise lift-sharing. [12:57:26.0258] San Diego is real nice. it’s more spread out than SF so depending on hotel<->venue location scooters may not be feasible 2023-11-14 [17:00:03.0117] interesting [17:00:46.0495] I assumed rent-a-car would be unavoidable for SD but if multiple people are opposed it'd be sweet to find another solution [17:00:52.0494] I too don't enjoy driving [11:05:42.0782] can only member companies host [11:06:33.0583] > <@devsnek:matrix.org> can only member companies host no [11:09:36.0580] https://github.com/tc39/how-we-work/blob/main/host.md [11:11:31.0917] neat [13:00:14.0835] man, "give me all of the own enumerable string + symbol keys of this object" is a _surprisingly_ annoying task for something I want to do pretty often [13:01:53.0008] ``` let desc = Object.getOwnPropertyDescriptors(obj); return [...Object.getOwnPropertyNames(desc), ...Object.getOwnPropertySymbols(desc)] .filter(x => desc[x].enumerable); ``` is the best I've got [13:02:54.0564] do you figure we could add get away with making `Object.keys`/`entries` take a options bag argument like `{ symbols: true }` [13:05:07.0271] alternative I guess is a `Object.symbolKeys` / `Object.symbolEntries` so you could at least do `[...Object.keys(x), ...Object.symbolKeys(x)]` [13:10:11.0499] `Reflect.ownKeys` doesn't do it? [13:10:18.0109] * `Reflect.ownKeys` + a filter doesn't do it? [13:10:52.0770] (also why would you use gOPN if you want only enumerable? that's what keys already gives you) [13:22:48.0439] wasn't that sort of the point, that symbols are supposed to be pseudo-private so it should be annoying to reflect over them? [13:22:49.0060] ljharb: keys is strings only [13:23:11.0224] or was that just a compat decision? [13:23:21.0599] ``` [13:23:38.0671] * let keys = Object.entries(Object.getOwnPropertyDescriptors(input)) .filter(([, desc]) => desc.enumerable) .map(([k]) => k); [13:23:57.0352] * ``` let keys = Object.entries(Object.getOwnPropertyDescriptors(input)) .filter((\[, desc\]) => desc.enumerable) .map((\[k\]) => k); [13:24:12.0270] * ``` let keys = Object.entries(Object.getOwnPropertyDescriptors(input)) .filter(([, desc]) => desc.enumerable) .map(([k]) => k); ``` [14:16:05.0568] > <@ljharb:matrix.org> `Reflect.ownKeys` + a filter doesn't do it? that's `Reflect.ownKeys` an improvement on using `getOwnPropertyNames` + `getOwnPropertySymbols`, sure [14:16:18.0697] > <@ljharb:matrix.org> `Reflect.ownKeys` + a filter doesn't do it? * ah, `Reflect.ownKeys` is an improvement on using `getOwnPropertyNames` + `getOwnPropertySymbols`, sure [14:16:39.0167] > <@ljharb:matrix.org> (also why would you use gOPN if you want only enumerable? that's what keys already gives you) keys doesn't include symbols, is the reason [14:16:47.0435] > <@ljharb:matrix.org> (also why would you use gOPN if you want only enumerable? that's what keys already gives you) * `Object.keys` doesn't include symbols, is the reason [14:16:48.0037] > <@michaelficarra:matrix.org> ljharb: keys is strings only Object.keys is Object.getOwnPropertyNames, but only enumerables [14:17:05.0153] > <@bakkot:matrix.org> `Object.keys` doesn't include symbols, is the reason right but you're using getOwnPropertySymbols for the symbols. gOPN's only use is if you want non-enumerable strings, which you don't [14:17:24.0037] sure, yes, that does end up being equivalent here [15:16:52.0556] https://github.com/endojs/endo/blob/master/packages/pass-style/doc/copyRecord-guarantees.md#how-do-i-enumerate-thee-let-me-list-the-ways 2023-11-15 [08:19:41.0747] Yeah I was going to suggest `Reflect.ownKeys({...obj})` [08:22:48.0615] * Yeah I was going to suggest `Reflect.ownKeys({...obj})` but only if you don't mind accessors being triggered [08:32:28.0617] why do you need the spread (which is what triggers the accessors)? [08:51:40.0746] presumably to get only the enumerable properties [13:03:13.0918] let's say I wanted to rebase and resuscitate https://github.com/tc39/ecma262/pull/1498 - should I try to get access to push to that branch, or start a new PR? [13:32:45.0054] > <@pchimento:igalia.com> let's say I wanted to rebase and resuscitate https://github.com/tc39/ecma262/pull/1498 - should I try to get access to push to that branch, or start a new PR? I'm guessing you'd rather not have to fork and submit PRs to that branch from your fork? [13:36:34.0876] I could do that as well, but since the PR has become quite different by rebasing it on latest main, that might well be more complicated [13:36:43.0460] ah I didn't notice it was only one commit [13:41:41.0651] perhaps I am missing something but isn't the rebase the same regardless of whether you have write access to the repo? [13:51:47.0847] I mean, once I've rebased, would you ("you" meaning anyone with an interest in this PR) prefer that I figure out how to push the result up to the same PR, so that the previous discussions can resume uninterrupted? or is it better to open a new PR and say it supersedes the old PR? [13:56:50.0529] the extra step is just you'd be pushing to a branch on your fork and creating a PR to merge that branch to the PR branch I defer to the editors on this, as they are the ones with 1. write access to the repo and 2. can decide what they prefer re: previous discussions vs new PR [13:57:10.0205] * the extra step is just you'd be pushing to a branch on your fork and creating a PR to merge that branch to the PR branch I defer to the editors on this, as they are the ones with 1. write access to the repo and would be the ones to merge your PR and 2. can decide what they prefer re: previous discussions vs new PR [13:57:40.0327] * the extra step is just you'd be pushing to a branch on your fork and creating a PR to merge that branch to the PR branch I defer to the editors on this, as they are the folks with 1. write access to the repo and would be the folks to merge your PR and 2. can decide what they prefer re: previous discussions on existing PR vs closing in favor of new PR [13:58:03.0913] * the extra step is just you'd be pushing to a branch on your fork and creating a new PR to merge your fork branch to the existing PR branch I defer to the editors on this, as they are the folks with 1. write access to the repo and would be the folks to merge your PR and 2. can decide what they prefer re: previous discussions on existing PR vs closing in favor of new PR [14:24:58.0431] I'm fine either way. A new PR would be less noisy, but it would be a shame to not ping the current thread participants about an update/replacement PR. 2023-11-16 [00:17:16.0573] A reminder: The Interest Survey for the 100th TC39 meeting in February in San Diego is posted 🎉 - https://github.com/tc39/Reflector/issues/512 Please add yourself by Tuesday 21st November. [08:44:32.0442] For those interested, I'm putting together an incubator call for the Stable Formatting proposal. See here for an agenda and a Doodle poll for figuring out the date & time: https://github.com/tc39/Reflector/issues/513 [14:24:02.0029] from jmdyck: ``` Function( 'a = console.log("oh"', '"no")', '' )() ``` [14:25:36.0699] this is very dumb, though I don't think it's an actual problem for anyone (in particular SES implements the spec as written, i.e., join with a comma and then validate as parameters) [14:26:42.0581] isn't that disallowed as described in the note in step 18 of https://tc39.es/ecma262/#sec-createdynamicfunction? [14:27:24.0731] oh, I guess the parameters as a whole are validated, not each parameter individually [14:27:44.0831] "oh no" indeed [14:28:00.0957] yup [14:28:26.0114] and people do rely on the ability to do `Function('a, b', 'body')` - combining multiple parameters into one argument, rather than putting each into their own argument 2023-11-17 [13:28:56.0963] upcoming plenary on the calendar was mistakenly extended for 2 hours per day. it has been corrected 2023-11-18 [07:55:56.0293] hello, is there any syntax pro? I'm stuck on designing cover grammar [07:58:07.0854] Grammar: ``` MatchStatement: `match` [nLTh] `(` Expression `) [nLTh] `{ MatchStatementClauses `;` `}` ``` This is ambiguous with ExpressionStatement, therefore I need a CoverExpressionStatementAndMatchStatement grammar [07:58:32.0718] * Grammar: ``` MatchStatement: `match` [nLTh] `(` Expression `) [nLTh] `{ MatchStatementClauses `;` `}` ``` This is ambiguous with ExpressionStatement (cannot decide `match (expr)` until see `{` or any other token), therefore I need a CoverExpressionStatementAndMatchStatement grammar [07:58:40.0540] * Grammar: ``` MatchStatement: `match` [nLTh] `(` Expression `) [nLTh] `{ MatchStatementClauses `;` `}` ``` This is ambiguous with ExpressionStatement (cannot decide production for `match (expr)` until see `{` or any other token), therefore I need a CoverExpressionStatementAndMatchStatement grammar [08:00:48.0809] Now I have this cover grammar: ``` CoverExpressionStatementAndMatchStatement : match [no LineTerminator here] Arguments ``` This can cover the match head `match (a, b, c)` (where `,` is comma operator) and a call expression `match (a, b, c)` (where `,` is parameter separator). But I don't know how to use it in ExpressionStatement [08:01:50.0684] ``` MatchStatement : CoverExpressionStatementAndMatchStatement [no LineTerminator here] `{ ` MatchStatementClauses `;` `}` ``` This looks good to me for now [08:03:39.0384] ``` ExpressionStatement[Yield, Await] : CoverExpressionStatementAndMatchStatement (current definition) ``` This one does not. It does not cover everything that can follow a CallExpression, like `match (expr) + 1` or `match(expr).prop`. [08:05:05.0982] It looks like I need to add all expressions to this cover grammar (e.g. it can follow a `++` or `.x` or `[prop]` or `(...args`)) which is unrealistic. [08:05:55.0873] * Now I have this cover grammar: ``` CoverExpressionStatementAndMatchStatement : `match` [no LineTerminator here] Arguments ``` This can cover the match head `match (a, b, c)` (where `,` is comma operator) and a call expression `match (a, b, c)` (where `,` is parameter separator). But I don't know how to use it in ExpressionStatement [08:06:08.0019] * ``` ExpressionStatement : CoverExpressionStatementAndMatchStatement (current definition) ``` This one does not. It does not cover everything that can follow a CallExpression, like `match (expr) + 1` or `match(expr).prop`. [08:06:56.0624] * Now I have this cover grammar: ``` CoverExpressionStatementAndMatchStatement : `match` [no LineTerminator here] Arguments // Refined to this in MatchStatement MatchHead : `match` `(` Expression `)` ``` This can cover the match head `match (a, b, c)` (where `,` is comma operator) and a call expression `match (a, b, c)` (where `,` is parameter separator). But I don't know how to use it in ExpressionStatement [08:07:05.0208] * Now I have this cover grammar: ``` CoverExpressionStatementAndMatchStatement : `match` [no LineTerminator here] Arguments ``` This can cover the match head `match (a, b, c)` (where `,` is comma operator) and a call expression `match (a, b, c)` (where `,` is parameter separator). But I don't know how to use it in ExpressionStatement [08:07:38.0314] * ``` MatchStatement : CoverExpressionStatementAndMatchStatement [no LineTerminator here] `{ ` MatchStatementClauses `;` `}` // Refined to this in MatchStatement MatchHead : `match` [no LineTerminator here] `(` Expression `)` [no LineTerminator here] `{ ` MatchStatementClauses `;` `}` ``` This looks good to me for now [08:07:53.0205] * ``` MatchStatement : CoverExpressionStatementAndMatchStatement [no LineTerminator here] `{ ` MatchStatementClauses `;` `}` // Refined to MatchHead : `match` [no LineTerminator here] `(` Expression `)` [no LineTerminator here] `{ ` MatchStatementClauses `;` `}` ``` This looks good to me for now [12:15:29.0445] Jack Works: for that approach, I think you'll want to use and rename (and probably generalize) [|CoverCallExpressionAndAsyncArrowHead|](https://tc39.es/ecma262/multipage/ecmascript-language-functions-and-classes.html#prod-CoverCallExpressionAndAsyncArrowHead), e.g. ``` MatchStatement : CoverCallExpressionAndAsyncArrowHeadAndMatchHead [no LineTerminator here] `{` MatchStatementClauses `;` `}`

Supplemental Syntax

When processing an instance of the production
MatchStatement : CoverCallExpressionAndAsyncArrowHeadAndMatchHead [no LineTerminator here] `{` MatchStatementClauses `;` `}`
the interpretation of |CoverCallExpressionAndAsyncArrowHeadAndMatchHead| is refined using the following grammar:

MatchHead : `match` [no LineTerminator here] `(` Expression `) ``` [12:17:42.0165] * Jack Works: for that approach, I think you'll want to use and rename (and probably generalize) [|CoverCallExpressionAndAsyncArrowHead|](https://tc39.es/ecma262/multipage/ecmascript-language-functions-and-classes.html#prod-CoverCallExpressionAndAsyncArrowHead), e.g. ``` MatchStatement : CoverCallExpressionAndAsyncArrowHeadAndMatchHead [no LineTerminator here] `{` MatchStatementClauses `;` `}`

Supplemental Syntax

When processing an instance of the production
MatchStatement : CoverCallExpressionAndAsyncArrowHeadAndMatchHead [no LineTerminator here] `{` MatchStatementClauses `;` `}`
the interpretation of |CoverCallExpressionAndAsyncArrowHeadAndMatchHead| is refined using the following grammar:

MatchHead : `match` [no LineTerminator here] `(` Expression `) ``` (following the pattern in [Async Arrow Function Definitions](https://tc39.es/ecma262/multipage/ecmascript-language-functions-and-classes.html#sec-async-arrow-function-definitions)) 2023-11-19 [18:15:42.0813] Yes, I'm already doing that, just unsure if I'm doing it correctly 2023-11-20 [07:57:56.0727] A final reminder: The Interest Survey for the 100th TC39 meeting in February in San Diego is posted 🎉 - https://github.com/tc39/Reflector/issues/512 Please add yourself by Tuesday 21st November. 2023-11-25 [22:20:18.0487] bugfix in set methods, for anyone who is implementing; cc shu https://github.com/tc39/proposal-set-methods/pull/102 2023-11-26 [12:01:05.0309] Is there a draft schedule for tomorrow? [15:29:28.0910] > <@nicolo-ribaudo:matrix.org> Is there a draft schedule for tomorrow? yes -- please see the reflector issue for the meeting, 3rd line 2023-11-27 [01:23:03.0680] Hey Jesse I took a look at how other programming languages handle decimal normalization since both those things are subjects of your slide deck. I may have a conflict during the scheduled time for that discussion; I'll try to call in, but you already know my position on the issue of normalization. https://github.com/tc39/proposal-decimal/issues/89 [01:29:50.0364] thanks, that's a great contribution! Right, many other languages do support trailing zeros. I appreciate the suggestion to see how the "middle ground" suggestion. I'll continue the discussion in the GitHub issue. [01:30:04.0166] Do we have a draft schedule yet? [07:01:41.0966] we have a packed agenda, so please be mindful (as well as forgiving if the chairs seem pushy as we approach or exceed timeboxes 🙂) [07:04:41.0783] Ben and Michael Ficarra have topics that are currently in overflow, but we hope to be able to slot those in where possible, so please be on the lookout for messages from chairs as usual, similar goes for everyone presenting, as we will try to move things forward if time allows, while still respecting constraints [07:05:05.0950] amazing how the agenda always fills up despite looking empty shortly before the deadline [08:03:51.0773] > <@softwarechris:matrix.org> Ben and Michael Ficarra have topics that are currently in overflow, but we hope to be able to slot those in where possible, so please be on the lookout for messages from chairs > > as usual, similar goes for everyone presenting, as we will try to move things forward if time allows, while still respecting constraints Ben: due to a timebox change, your topic is out of overflow and is now scheduled on Day 4 [08:04:04.0864] Thanks for letting me know! [08:54:08.0952] both overflow topics are now on the schedule on Day 4 [09:31:47.0576] Thanks chairs for adding "END DAY X" and "LUNCH" to TCQ :) [10:01:27.0279] Hmm. I may also be unavailable in April for the same reason, though I believe we have a hotel so I may be able to dial in. [10:09:39.0616] Note: Ashley and Ben volunteer for notes all the time; it'd be great to have additional note-takers to relieve them [10:11:52.0349] also the Meet apps don't have an "incognito mode" [10:20:59.0783] > <@littledan:matrix.org> Note: Ashley and Ben volunteer for notes all the time; it'd be great to have additional note-takers to relieve them I'll also have to step out for ~20 minutes after the 402 editor's update [10:22:47.0313] chairs, can we ask Samina to add a link to these slides to the agenda? [10:23:00.0136] yes, that will happen [10:24:06.0381] Note, "New Proposal?" is, WinterCG is looking for a place to publish standards, and I'm proposing Ecma. https://github.com/wintercg/admin/issues/58 [10:24:43.0314] This could be a good way to enable TC39 collaboration with efforts on server-side JS runtimes [10:26:45.0637] (please don't use AI for any image designs for legal reasons) [10:26:57.0087] and aesthetic reasons [10:28:05.0756] Here's the other cap design we've used [10:28:23.0924] there's a beanie too [10:29:04.0983] rbuckton: both look good. [10:29:33.0143] What would be good to recognize 100th [10:30:31.0664] i grab more socks at conference booths than hats or shirts these days :-) but also a windbreaker/jacket would be awesome [10:31:44.0812] > <@ljharb:matrix.org> (please don't use AI for any image designs for legal reasons) wait why? i used AI for the old hat logos [10:33:09.0419] are we going more in the baseball hat direction, or rather trucker-style? [10:33:13.0163] > <@shuyuguo:matrix.org> wait why? i used AI for the old hat logos the old hats were created long before LLMs were commonplace, so i'm not sure what you mean - unless you think i meant adobe illustrator? [10:33:23.0176] yes, i have AI at home, Adobe Illustrator [10:33:42.0699] this isn't TDZ :-p [10:33:42.0905] > <@jesse:igalia.com> are we going more in the baseball hat direction, or rather trucker-style? trucker please for us big headed folk [10:34:04.0607] > <@jesse:igalia.com> are we going more in the baseball hat direction, or rather trucker-style? the last run we had 3 styles: trucker, "dad cap", and beanie [10:34:16.0078] > <@jesse:igalia.com> are we going more in the baseball hat direction, or rather trucker-style? Hopefully a choice? I have a strong preference for the baseball cap style from a comfort perspective [10:34:59.0805] should probably make a channel for hats [10:35:12.0924] or a reflector thread? [10:35:16.0560] Jack Works: just installed it, this is awesome thanks [10:35:19.0078] I think 3 styles would be fine. Should I plan for these threetrucker, "dad cap", and beanie [10:35:39.0036] Yes, please a channel for hats would be great. [10:35:40.0172] is this a LSP, can i run it in my vim [10:35:51.0252] oooh this will be super handy [10:36:29.0814] #tc39-swag:matrix.org [10:36:44.0436] This is what I wanted my extension to do, but I haven't had the time to work on it in a long while. This looks great. [10:36:46.0930] new channel? this is a full-service channel [10:36:54.0304] * new channel? this is a full-service channel! [10:36:56.0452] > <@devsnek:matrix.org> is this a LSP, can i run it in my vim apparently yes! [10:37:12.0979] > <@softwarechris:matrix.org> #tc39-swag:matrix.org room isn't in the category [10:37:16.0171] oh wait now it is [10:37:24.0118] so impatient [10:37:48.0729] https://marketplace.visualstudio.com/items?itemName=MagicWorks.ecmarkup [10:40:21.0877] > <@devsnek:matrix.org> is this a LSP, can i run it in my vim the VSCode extension is made of TMLanguage (syntax highlight JSON), snippets (JSON), language definition (JSON) and a language server (provides hover information and completion) [10:40:46.0538] I believe you can take the tmlanguage, that will highly improve the editing experience [10:41:03.0331] * I believe you can take the tmlanguage (https://github.com/Jack-Works/ecmarkup-language-service/tree/main/extension-vscode/syntaxes), that will highly improve the editing experience [10:44:00.0477] Now all LSP features are based on @tc39/ecma262-biblio and simple string analysis, no real analyze (using ecmarkup/grammarkdown in the backend) support, but I plan to add them. For example I want to make goto definition work for local-defined grammar/AOs [10:46:48.0515] I tried to do real analyze last year, but having some problem with bundling those two libs, and they are not built in an incremental way so the performance is not good. I hope I can have time to improve or reimplement part of them to provide better experience [10:52:38.0340] https://github.com/tc39/faq/pull/2 [10:52:45.0969] ^ PR documenting how to resolve disagreements [10:55:56.0159] > <@jackworks:matrix.org> Now all LSP features are based on @tc39/ecma262-biblio and simple string analysis, no real analyze (using ecmarkup/grammarkdown in the backend) support, but I plan to add them. For example I want to make goto definition work for local-defined grammar/AOs Grammarkdown has ways to reference other grammars, but doesn't itself parse a full ecmarkup file. I'd love for ecmarkup to generate a grammarkdown `.grammar` file that is included in ecma262-biblio to make that process easier. [10:56:51.0636] even if the disclaimer is read and understood, it might not be believed as credible [10:57:11.0250] wonder if it might be better to attribute answers to specific delegates? maybe that would be believed? [10:58:45.0024] rbuckton: I have an issue for putting the grammar in the biblio https://github.com/tc39/ecmarkup/issues/431 but I either did not know or forgot that grammarkdown had a specific format it used [10:59:05.0594] > <@bakkot:matrix.org> wonder if it might be better to attribute answers to specific delegates? maybe that would be believed? I don't think so either? The community might view each of us (or, worse, just some of us) as authoritative. [10:59:05.0626] anyway definitely agreed it would be nice for the biblio to hold the grammar [10:59:31.0083] > <@littledan:matrix.org> I don't think so either? The community might view each of us (or, worse, just some of us) as authoritative. that's fair but if people attribute quotes to "a TC39 delegate" instead of "TC39" that would at least be an improvement [10:59:46.0502] I don't know if they would, though [11:00:10.0295] I dunno, it feels like some alleged weasel wording that people at each level would just filter out unless they feel forced to repeat it [11:00:25.0687] fair [11:00:39.0464] by the way can you bakkot add a `.d.ts` for the biblio package? https://github.com/Jack-Works/ecmarkup-language-service/blob/main/language-server/src/biblio.d.ts It should be something like index.d.json.ts as I know how TS NodeNext should work [11:00:56.0168] to be clear I like the idea of having a disclaimer--we don't want to let people lawyer their way through to something by citing the FAQ [11:00:58.0725] * by the way, can you bakkot add a `.d.ts` for the Biblio package? https://github.com/Jack-Works/ecmarkup-language-service/blob/main/language-server/src/biblio.d.ts It should be something like `index.d.json.ts` as I know how TS NodeNext should work [11:01:28.0414] Jack Works: can do; open an issue? (or a PR) [11:05:26.0349] https://github.com/tc39/proposal-array-grouping/issues/60 [11:11:54.0148] Great work from @legendecas on the V8 implementation [11:13:58.0742] What is the current plan for which globals will be included [11:14:12.0445] (Sorry I cannot access the queue right now) [11:15:23.0498] added to tcq queue [11:18:25.0558] Great to see this moving forward [11:18:29.0012] Thanks Leo! [11:23:26.0514] [Slides](https://docs.google.com/presentation/d/17esbBbAlKe1nZzWx47ItpVP1XovIupxKEAL1PgUDFrk/edit#slide=id.g26255f6e788_0_0) added to the TC39 Agenda (I just opened the PR: https://github.com/tc39/agendas/pull/1506 [11:24:39.0008] > <@littledan:matrix.org> What is the current plan for which globals will be included Thanks for the feedback (cc syg ). I'll focus on that in the next plenary. [11:28:51.0498] If someone wants to pick up Array.isTemplateTag, it would be a great complement to this proposal, together with trusted types [11:30:08.0521] Please keep going ptomato [11:30:13.0448] We heard you well [11:30:48.0292] nicolo-ribaudo: that's a case for Function tho, not necessarily `eval` [11:31:14.0117] if you can't hear, reload [11:31:23.0690] I have run into this bug with google meet before [11:31:32.0064] where it drops the audio feed from a specific person [11:31:43.0976] If somebody can ask Philip to screen share yb himself I'll reload and fix my audio [11:32:04.0613] > <@nicolo-ribaudo:matrix.org> If somebody can ask Philip to screen share yb himself I'll reload and fix my audio Robert Pamely: [11:39:40.0588] I don’t think what Jordan is saying is aligned with the goals around CSP [11:40:06.0812] i don't think "only direct eval is a problem" is a widely shared web security opinion afaik [11:40:16.0200] it very much might not be aligned with CSP's goals, i'm not sure what those are [11:40:24.0237] It would probably be good to say that for the notes [11:40:26.0892] jordan i don't quite understand like [11:40:36.0647] i mean i understand your want of Function() [11:40:49.0611] but i don't understand how you can distinguish it from eval in any meaningful way [11:40:57.0063] i just mean i'm personally concerned when i see use of `eval()` but not `Function()` [11:41:07.0423] i mean, they're different code paths [11:41:15.0556] and `eval` even has special stuff for direct vs indirect [11:42:23.0474] Maybe in the future you could be more clear about your goals and that you aren’t talking about the goals of CSP itself [11:43:13.0572] I agree that direct eval is a terrible extra level of bad but I also like the guarantees of unsafe-eval [11:43:41.0360] Note that csp also disallows things like inline event handlers, which also don’t see local scope [11:43:50.0513] i'm not sure why it's on me to clarify that my goals aren't the goals of others when i'm not claiming to be speaking for the goals of others. [11:43:52.0892] I am definitely concerned when I see `Function`, and you should be too [11:44:00.0857] CSP blocks lots of things [11:44:08.0736] > <@bakkot:matrix.org> I am definitely concerned when I see `Function`, and you should be too i'd love to understand more about those concerns [11:45:36.0562] you have to be really careful to audit that either a) no user-control code ends up in the call to `Function()` or b) the result is never invoked, and that is very hard to do in a large web application [11:46:06.0845] of course if the argument is static it's fine, which is the point of this proposal [11:46:13.0272] fair enough [11:46:18.0186] * you have to be really careful to audit that either a) no user-controled code ends up in the call to `Function()` or b) the result is never invoked, and that is very hard to do in a large web application [11:46:36.0553] i still wouldn't want `eval()` in my codebase even with a static string tho, and i'd be fine with having that with Function [11:47:12.0306] fine not to want `eval` with a static string, but that's not a security issue, I would think? more of a linter concern, not something that needs to be banned in the browser [11:48:21.0656] fair enough [11:48:23.0745] * fair enough as well [11:56:13.0362] CSP also fails at composition [12:05:31.0521] > <@michaelficarra:matrix.org> CSP also fails at composition What do you mean by this? [12:13:22.0919] littledan: there are some cases where policy A enables one behavior, and policy B enables a second, but no combination of policies can enable both behaviors (other than not using CSP at all) [12:13:59.0543] Do you have an example? [12:14:18.0559] IIRC `unsafe-inline` plus nonces [12:14:42.0569] Wow weird, how is that prohibited? [12:14:59.0278] mm, maybe I am thinking of `unsafe-inline` plus `strict-dynamic` actually? [12:15:19.0118] ah, no, both of those [12:15:23.0229] here: https://www.w3.org/TR/CSP3/#allow-all-inline [12:15:29.0128] see step 2.1 [12:15:52.0464] it just explicitly checks for nonce sources when determining whether `unsafe-inline` can be used [12:16:22.0606] So that might be fixable? [12:16:25.0731] nonce sources, hash sources, and strict-dynamic [12:16:41.0019] yeah, presumably; on the other hand it was presumably done on purpose [12:58:25.0104] (also changing it without introducing a new directive would potentially weaken the security posture of existing pages, which would maybe be bad.) [13:24:49.0111] I'm still generally a fan of an API like: ```js let bytesRead = Uint8Array.encodeBase64(input, inputPos, output, outputPos, count); ``` and you use `count - bytesRead` to determine how much data is yet to be encoded [13:26:24.0388] rbuckton: that doesn't give you streaming, unfortunately [13:26:26.0882] it gives the developer more control over buffer sizes for memory-constrained environments, avoids excess allocations, and is consistent with a lot of similar C++ APIs [13:26:32.0614] That specifically gives you streaming. [13:26:43.0117] even accounting for the fact that you need to skip over whitespace? [13:26:53.0244] whitespace is the thing that has tripped me up here [13:31:56.0199] > <@bakkot:matrix.org> even accounting for the fact that you need to skip over whitespace? Fair point, I suppose. In .NET, the streaming API requires state so it has its own class like `TextEncoder` (https://learn.microsoft.com/en-us/dotnet/api/system.security.cryptography.tobase64transform?view=net-8.0) [13:38:25.0086] Possibly feasible by splitting the API into two methods, one that normalizes base64 input (removes whitespace, etc.), and one that does the decoding, but it's certainly not as convenient. [13:38:52.0525] I think engines should work on just not making the allocation when it's immediately destructured [13:38:54.0087] The whole point of all this discussion is to avoid two passes [13:39:32.0499] * The reason for this discussion is to avoid two passes [13:39:40.0728] Since that's what the proposal was blocked on [13:42:45.0171] it's unclear if that pays off in the general case [13:42:59.0768] whereas the # of web APIs that have *that* level of performance requirements is very small [13:43:04.0591] and we can probably just design those specially [13:43:43.0529] It would be nice to be able to have multiple return values without depending on destructuring. That's one of the things my as-yet-not-presented `ref` proposal would provide: ``` let bytesRead; let bytesWritten = Uint8Array.encodeBase64(input, inputPos, inputLen, output, outputPos. ref bytesRead); ``` [13:44:02.0448] * It would be nice to be able to have multiple return values without depending on destructuring. That's one of the things my as-yet-not-presented `ref` proposal would provide: ``` let bytesRead; let bytesWritten = Uint8Array.encodeBase64(input, inputPos, inputLen, output, outputPos, ref bytesRead); ``` [13:44:51.0852] * It would be nice to be able to have multiple return/output values without depending on destructuring. That's one of the things my as-yet-not-presented `ref` proposal would provide: ``` let bytesRead; let bytesWritten = Uint8Array.encodeBase64(input, inputPos, inputLen, output, outputPos, ref bytesRead); ``` [13:49:58.0435] Thanks for seeing this one through bakkot [13:51:16.0600] don't jinx it! [13:56:23.0768] okay `toFixed` exists though [14:06:57.0856] Objective C/Swift also has its own ad-hoc kind of decimal that no one seems to mind [14:19:39.0889] Sorry for jumping in; will stop [14:22:04.0038] But, I would kinda appreciate it if Waldemar could just make his point rather than quizzing the presenter [14:22:06.0198] IEEE is normalising though, right? [14:22:29.0054] No, IEEE explicitly does represent trailing zeroes [14:22:59.0181] So, normalizing would be sort of subsetting IEEE, just like we are also sort of subsetting by not including a bunch of signaling modes [14:23:26.0128] I'm not sure this Q&A approach is constructive [14:34:28.0234] i am losing the thread of discussion here wrt decimal [14:37:16.0631] i am not hearing an argument for why this should be part of the data model, just that having it in the data model gives you extra bits of info...? [14:41:51.0646] Yes there are three libraries by MikeMcl, and the design here is better [14:42:36.0485] But they aren’t adopted broadly enough, and people try to avoid using them with strings or fixed point number usage [14:43:19.0276] those usages would still apply with a non-primitive builtin tho, no? [14:43:24.0682] * those usages (that people want to avoid) would still apply with a non-primitive builtin tho, no? [14:43:43.0535] Sorry what is the connection to primitiveness? [14:44:03.0945] i guess it's less about it being a primitive and more about operator overloading - syntax support [14:44:25.0946] if i can't write `1.23m` or the equivalent, then i wouldn't think anything we could add would be ergonomic enough to warrant using it [14:44:33.0526] * if i can't write `1.23m * 3m` or the equivalent, then i wouldn't think anything we could add would be ergonomic enough to warrant using it [14:44:49.0329] I guess people avoid using them because they don't want introduce a heavy lib? [14:44:58.0867] iow the java-style API on the slide isn't something i'd want to see us add, nor would i want to see used in a codebase i had to maintain [14:45:26.0193] * iow the java-style API on the slide isn't something i'd want to see us add, nor would i want to see used in a codebase i had to maintain. numbers are too fundamental for a `.add()` to be reasonable imo [14:45:56.0913] * iow the java-style API on the slide isn't something i'd want to see us add, nor would i want to see used in a codebase i had to maintain. numbers are too fundamental for a `.add()` to be reasonable or elegant enough to use, imo [14:47:09.0221] the argument does apply that it's a coordination point, but we had a single dominant userland library already for temporal to replace Date, and we had a decade or more of usage to validate the need, and the variety of use cases it supports [14:47:21.0853] sidebar: i want to resist coming to some black and white conclusions here like "batteries included is always a bad rationale" or "tc39 shouldn't try to solve any coordination problems" [14:47:37.0284] these all end up being case-by-case in the end [14:47:45.0070] I also hope we can have decimal literal and op overloading but it could be a separate problem. People could use transpilers if they really want. [14:48:18.0270] Ashley Claymore: You mentioned a YAML library that came with its own "decimal" type. Was that a real-world example? [14:49:05.0276] why doesn't bloomberg make a library? [14:49:28.0680] it could put its engineering weight behind something that's fast and maintainable and evangelize that [14:49:29.0946] > <@eemeli:mozilla.org> Ashley Claymore: You mentioned a YAML library that came with its own "decimal" type. Was that a real-world example? which yaml lib? [14:49:52.0737] > <@shuyuguo:matrix.org> it could put its engineering weight behind something that's fast and maintainable and evangelize that imo that would build a much stronger case for a builtin decimal that lacks syntactic support [14:50:24.0072] One of the best reasons to have a built-in decimal, IMO, was to be able to implement it as a primitive value with operators. The worst part of Decimal in Java is that it's method based. [14:55:41.0123] shu: IIRC, you said in a previous plenary that the effort to add bigint outweighed its benefits for the language, given that the predominant use of bigint so far is cryptocurrency mining. Would that be an accurate characterization? Would higher-precision calculates in Sheets not be enough of a motivator for V8 to consider implementing this as a primitive? Are there runtime optimizations/performance benefits of syntactic decimal math vs method-based math that are worth considering? [14:56:25.0926] bad ROI on BigInts is an accurate characterization [14:56:35.0734] * shu: IIRC, you said in a previous plenary that the effort to add bigint outweighed its benefits for the language, given that the predominant use of bigint so far is cryptocurrency mining. Would that be an accurate characterization? Would higher-precision calculations in Sheets not be enough of a motivator for V8 to consider implementing this as a primitive? Are there runtime optimizations/performance benefits of syntactic decimal math vs method-based math that are worth considering? [14:56:48.0235] higher-precision calculations in Sheets may be a motivator for me if it's Sheets making the feature request, but it's not? [14:56:52.0570] like, look at Excel [14:57:12.0375] Excel also uses IEEE floating point, and it truncates [14:57:44.0618] we use bigints in discord a lot :) [14:57:55.0143] i'm saying, if you want this to be motivated by a product, the product needs to speak up [14:58:06.0687] gesturing at possible adoption is not compelling in itself [14:58:10.0177] Do you use them for actual math, or as a standin for a numeric string. [14:58:24.0092] * Do you use them for actual math, or as a standin for a numeric string? [14:58:24.0412] we do bitwise math on them [14:58:49.0149] I have used a bigint as a bitset once I think [14:58:58.0868] that says we should've added Bitset :) [14:59:04.0544] more than that BigInt was the right call [14:59:35.0620] > <@eemeli:mozilla.org> Ashley Claymore: You mentioned a YAML library that came with its own "decimal" type. Was that a real-world example? nope sorry, I was trying to turn internal Bloomberg things into more generic terms on the fly. YAML here stands for internal xml based APIs coming from other systems [14:59:39.0692] the only non-bitset operation we do on them can also be done on f64 [14:59:53.0272] > <@devsnek:matrix.org> we do bitwise math on them IMO, the two main use cases for bigint that *aren't* crypto are nanosecond precision and 64-bit integer flags/bitmasks, neither of which needed an arbitrarily-sized integer value. [14:59:55.0497] * the only non-bitset operation we do on them can also be done on f64 (shifting right 22 bits) [15:00:34.0836] (my bitset was > 64 bits fwiw) [15:01:05.0115] > <@aclaymore:matrix.org> nope sorry, I was trying to turn internal Bloomberg things into more generic terms on the fly. YAML here stands for internal xml based APIs coming from other systems Ah, got it. That's what I thought, but wanted to check. For context, I maintain the `yaml` package on npm and was not aware of such a JS YAML library. [15:01:51.0898] Note that Jesse has been working on a good library here, having a full JS implementation of the proposal [15:02:01.0054] FYI all i will not be able to attend for the next 3 days, Rezvan will be attending on V8's behalf [15:02:27.0267] who else was taking notes? I have a question for other note takers. Ashley Claymore ? [15:03:21.0474] My last question still stands: Could native, syntactic decimal math outperform any given userland library? And if so, by how much? [15:03:43.0848] * My last question still stands: Could native, syntactic decimal math outperform any given userland library? And if so, by how much (approximately)? [15:05:05.0159] I think moving towards engaging products is a good direction for TC39. It isn’t something we have done in the past—product discussions have often been treated as out of scope and implicitly discouraged. Ashley described a real product need that we have at Bloomberg, and we can work with survey respondents to more fully develop more of them. [15:08:46.0337] > <@littledan:matrix.org> I think moving towards engaging products is a good direction for TC39. It isn’t something we have done in the past—product discussions have often been treated as out of scope and implicitly discouraged. Ashley described a real product need that we have at Bloomberg, and we can work with survey respondents to more fully develop more of them. I've never heard of such a practice being discouraged, and if it is that seems unfortunate. IIRC, a number of proposals are driven by the needs of large projects. ShadowRealm, WeakRef, Shared Structs, Async Context, etc. are all driven by such a need, I think. [15:09:30.0986] > <@rbuckton:matrix.org> IMO, the two main use cases for bigint that *aren't* crypto are nanosecond precision and 64-bit integer flags/bitmasks, neither of which needed an arbitrarily-sized integer value. We did discuss BigInt vs Int64 at some length while developing things. Int64 introduces quite some additional unfortunate complexity/arbitrary design decisions. And from an implementation standpoint, my understanding was that the difficult part was adding a primitive, not the contents of whether it was big or not [15:09:57.0474] I have seen cases where feedback from these projects has been discounted and ignored, however. [15:10:31.0922] > <@rbuckton:matrix.org> I've never heard of such a practice being discouraged, and if it is that seems unfortunate. IIRC, a number of proposals are driven by the needs of large projects. ShadowRealm, WeakRef, Shared Structs, Async Context, etc. are all driven by such a need, I think. No one is explicitly discouraging it, but we also aren’t seeing lots of examples of product-driven presentations. This is why I said it was *implicitly* discouraged. [15:14:05.0666] > <@littledan:matrix.org> We did discuss BigInt vs Int64 at some length while developing things. Int64 introduces quite some additional unfortunate complexity/arbitrary design decisions. And from an implementation standpoint, my understanding was that the difficult part was adding a primitive, not the contents of whether it was big or not It's unfortunate that the introduction of bigint didn't pave the way for implementations to become more flexible in terms of adding new primitives. IIRC, BigNumber/Decimal/etc. was being discussed at the same time as BigInt, so the potential was already present. [15:15:09.0416] And BigInt followed on the heels of Symbol [15:16:13.0709] IMO, both Decimal and Temporal should be primitive, as they both involve operations that could be better expressed syntactically (`+`, `/`, `>`, `<`, etc.) [15:17:26.0685] * IMO, both Decimal and Temporal should be primitive, as they both involve operations that could be better expressed syntactically (`+`, `-`, `>`, `<`, etc.) [15:20:46.0097] also Records and Tuples [15:20:51.0314] Though, I have to admit I'm biased, having many years of using .NET, where `Decimal` and `DateTimeOffset`/`TimeSpan` have syntactic operators (`DateTimeOffset.Now + TimeSpan.FromMinutes(5)`) [15:20:57.0056] * also Records and Tuples and shared structs [15:24:10.0627] Or rather: ``` // C# DateTimeOffset.Now <= start + TimeSpan.FromMinutes(5) // vs // JS/Temporal Temporal.Instant.compare(Temporal.Now.instant(), start.add(Temporal.Duration.from({ minutes: 5 })) <= 0 ``` [15:24:34.0833] * Or rather: ``` // C# DateTimeOffset.Now <= start + TimeSpan.FromMinutes(5) // vs // JS/Temporal Temporal.Instant.compare(Temporal.Now.instant(), start.add({ minutes: 5 }) <= 0 ``` [15:25:04.0690] > <@bakkot:matrix.org> who else was taking notes? I have a question for other note takers. Ashley Claymore ? yes [15:25:08.0034] * Or rather: ``` // C# DateTimeOffset.Now > start + TimeSpan.FromMinutes(5) // vs // JS/Temporal Temporal.Instant.compare(Temporal.Now.instant(), start.add({ minutes: 5 }) > 0 ``` [15:26:15.0798] * Or rather: ```js // C# DateTimeOffset.Now > start + TimeSpan.FromMinutes(5) // vs // JS/Temporal Temporal.Instant.compare(Temporal.Now.instant(), start.add({ minutes: 5 })) > 0 ``` [15:31:23.0000] > <@rbuckton:matrix.org> IMO, both Decimal and Temporal should be primitive, as they both involve operations that could be better expressed syntactically (`+`, `-`, `>`, `<`, etc.) If this is the ideal, why are we accepting of the non-primitive compromise for Temporal? [15:32:34.0946] because... browsers would not ship the primitive version, like with Decimal? [15:33:25.0819] Ok, so we are being pragmatic in order to make progress. Fine by me. [15:36:26.0640] > <@shuyuguo:matrix.org> because... browsers would not ship the primitive version, like with Decimal? Can you clarify, do you mean "would not support" or "would not ship even if standardized"? [15:37:17.0074] what is the difference between those two statements? [15:37:25.0062] as in, how did it get standardized, if the browsers do not support it? [15:37:27.0482] That statement seems more definitive than "would not support unless convinced the motivation is sufficient" [15:37:57.0791] "would not ship" has multiple connotations [15:38:06.0366] the general statement is "would not support unless convinced" [15:38:14.0638] Thank you for the clarification [15:38:24.0491] in the specific cases of temporal and decimal, since we have discussed those at length, the answer is "not convinced" [15:38:38.0259] that is, the bar is high [15:40:35.0618] > <@rbuckton:matrix.org> "would not ship" has multiple connotations okay, right, i'm not supposing a hypothetical where the current TC39 working mode has broken down, and that the browsers continue to do things they've agreed to via the staging process [15:42:42.0934] > <@shuyuguo:matrix.org> okay, right, i'm not supposing a hypothetical where the current TC39 working mode has broken down, and that the browsers continue to do things they've agreed to via the staging process It still bears clarification. Despite being specified, there are parts of the spec that aren't implemented in all runtimes, like TCO, and things that are normative optional. [15:43:25.0547] ah, i see. well, TCO remains a special case as it predates the current staging process. [15:43:45.0131] but normative optional is interesting [15:45:04.0843] my personal take is i don't think normative optionality is a good idea except in very broad strokes, like "browsers have this for legacy reasons", as we use it today [15:47:34.0560] As well as browsers unshipping SAB and disallowing `Atomics.wait` on the main thread [15:48:20.0784] (both of which are understandable concerns, but are specific to browsers) [15:49:14.0372] yeah i think it's probably actually fine to have some implicit notion of "profiles" [15:49:29.0695] but full-on pick-and-choose normative optionality is harmful imoi [15:49:34.0052] * but full-on pick-and-choose normative optionality is harmful imo 2023-11-28 [16:00:59.0330] 🚨 📢 some things have moved around on the schedule. please have a look, especially if you are presenting as some items have moved to a different day. no constraints were impacted [16:26:00.0457] I can't believe im missing one of the hats [16:29:10.0012] Getting a new phone and forgetting to install matrix for a month means a lot of catching up to do. [10:03:25.0859] IIRC, it runs on a VM in Azure [10:11:18.0767] I would love to implement some TCQ feature improvements once it's in a developable state [10:18:29.0949] why do we put our names in the notes doc? I find it easier to keep delegates.txt open in a different tab where I can c-f for names [10:20:15.0731] > <@bakkot:matrix.org> why do we put our names in the notes doc? I find it easier to keep delegates.txt open in a different tab where I can c-f for names for helping note-takers is one use case. we also use it to record attendance -- something Ecma cares about. it also can be helpful to know who was present at the meeting when reviewing notes, as not everyone speaks at every meeting [10:20:38.0285] gotcha [10:23:35.0378] Heh, is TCQ stuck again? [10:23:55.0882] TCQ advanced [10:24:08.0839] * Heh, is TCQ stuck again? (apparently not) [10:24:12.0226] > <@softwarechris:matrix.org> for helping note-takers is one use case. we also use it to record attendance -- something Ecma cares about. it also can be helpful to know who was present at the meeting when reviewing notes, as not everyone speaks at every meeting It never seems better than 50% accurate tho [10:44:03.0414] 42 people on the call. 18 names on the notes. Not sure how many of those missing 24 are observers. [10:51:11.0554] > <@aclaymore:matrix.org> It never seems better than 50% accurate tho true. I don't know if this has ever _not_ been the case, and if so, how long ago. IME it has been voluntary; folks only add themselves and not others for Ecma's attendance-keeping it is not the only system of record. the secretary monitors the online meeting participants (and in-person folks), as well as the sign-in form people complete to get the link for the online meeting I think it's useful to have the complete attendees in the doc itself for the notes/history but it may be that some people don't want to be listed for some reason [10:52:35.0533] maybe some of the two-letter folks can provide further context [10:57:24.0628] Prior to remote meetings attendance was kept by having a physical sheet of paper passed around, and I think we used that to populate the list in the published notes [10:57:37.0015] I think "no data-driven exceptions" is a confusing way to phrase this principle [10:58:00.0024] the principle appears to be "don't reject anything which could in principle be valid", which seems like a totally fine principle [10:59:56.0141] 📝 we will need someone to volunteer to help with notes after this item. please consider helping out 🙏 [11:00:31.0736] 29-02 _is_ valid though, it's the combination that isn't valid [11:00:36.0498] * `29-02` _is_ valid though, it's the combination that isn't valid [11:01:02.0653] I think I'm a bit confused by how asking for 2030-02-29 could return 2030-02-28 rather than 2030-03-01. [11:01:23.0683] what about `04-31`? [11:02:10.0729] > <@ljharb:matrix.org> what about `04-31`? `31-04` should be invalid because it never occurs in the ISO calendar [11:02:36.0400] right but april, and the 31st, are both valid in the same way that february, and the 29th, are both valid [11:02:46.0868] or are you saying 2/29 is special because of leap days [11:02:55.0224] > <@ljharb:matrix.org> or are you saying 2/29 is special because of leap days precisely [11:03:10.0887] because it is valid but when added to a year it might not be [11:03:16.0260] philip's answer of "the shape", tho, would mean that a month 01 - 12 and a day 01 - 31 are all "valid" in that sense [11:03:26.0720] (The one person I know with a February 29 birthday celebrates on March 1.) [11:03:34.0976] thus april 31st, while obv a day that doesn't exist, each part is still valid [11:03:44.0215] * thus april 31st, while obv a day that doesn't exist, each part is still the right "shape" [11:03:51.0917] just like february 29th depending on the year [11:04:45.0142] Seems to me the reasonable behaviors are `throw`, `truncate` (to 02-28), and `carry` (to 03-01). [11:06:13.0231] ``` new Date(2030, 1, 29) → Date Fri Mar 01 2030 00:00:00 ``` [11:06:19.0983] > <@kriskowal:matrix.org> Seems to me the reasonable behaviors are `throw`, `truncate` (to 02-28), and `carry` (to 03-01). at the moment we support `constrain` and `reject` [11:06:43.0743] carrying over is not generally applicable but it could be useful in certain cases as you mentioned [11:09:56.0807] I think either `throw` or `carry` can make sense, but `truncate` is _weird_. [11:14:41.0325] They cases are well documented in the Temporal docs [11:14:47.0747] * The cases are well documented in the Temporal docs [11:15:53.0718] We should have a notion of "consensus pending one person's offline stamp" [11:16:30.0061] so that this can get consensus when waldemar has a chance to review this behavior offline and approves of it, assuming that he does [11:19:17.0544] > <@eemeli:mozilla.org> I think either `throw` or `carry` can make sense, but `truncate` is _weird_. we used to have "carry" (it was called `{overflow: 'balance'}`) but removed it during stage 2, based on experience from the Moment maintainers that people only wanted it because it was what `new Date()` does. [11:19:36.0907] > <@bakkot:matrix.org> We should have a notion of "consensus pending one person's offline stamp" provisional advancement is fairly common, no? [11:19:56.0519] yes but usually it's like "editor's review" or something, rarely "someone approving the normative behavior" [11:20:07.0865] > <@pchimento:igalia.com> we used to have "carry" (it was called `{overflow: 'balance'}`) but removed it during stage 2, based on experience from the Moment maintainers that people only wanted it because it was what `new Date()` does. Anecdotally, at least one person uses it for her birthday math. [11:21:09.0474] (And I do not have an iron in this fire, just this anecdote.) [11:21:53.0746] I'm not withholding consensus. I (and others) just found the information to be too poorly presented to understand. [11:26:49.0089] > <@waldemarh:matrix.org> I'm not withholding consensus. I (and others) just found the information to be too poorly presented to understand. If it helps, this is what I understood happens by default based on the type of methods/conversions - String->Temporal validates the strings and throws - Plain object->Temporal validates that each parameter is _individually_ in its potential domain (e.g. days are positive integers, month names specific strings, ...) and then "rounds towards zero" to get a valid date - Temporal->Temporal rounds towards zero to get a valid date There is an exception to that Temporal->Temporal class, which is the method today the champions were proposing to change to not throw anymore [11:27:18.0919] * In reply to @waldemarh:matrix.org I'm not withholding consensus. I (and others) just found the information to be too poorly presented to understand. If it helps, this is what I understood happens by default based on the type of methods/conversions String->Temporal validates the strings and throws - Plain object->Temporal validates that each parameter is individually in its potential domain (e.g. days are positive integers, month names specific strings, ...) and then "rounds towards zero" to get a valid date - Temporal->Temporal rounds towards zero to get a valid date There is an exception to that Temporal->Temporal class, which is the method today the champions were proposing to change to not throw anymore [11:27:43.0071] > <@waldemarh:matrix.org> I'm not withholding consensus. I (and others) just found the information to be too poorly presented to understand. * In reply to @waldemarh:matrix.org I'm not withholding consensus. I (and others) just found the information to be too poorly presented to understand. If it helps, this is what I understood happens by default based on the type of methods/conversions - String->Temporal validates the strings and throws - Plain object->Temporal validates that each parameter is individually in its potential domain (e.g. days are positive integers, month names specific strings, ...) and then "rounds towards zero" to get a valid date - Temporal->Temporal rounds towards zero to get a valid date There is an exception to that Temporal->Temporal class, which is the method today the champions were proposing to change to not throw anymore [11:27:53.0373] * If it helps, this is what I understood happens by default based on the type of methods/conversions - String->Temporal validates the strings and throws - Plain object->Temporal validates that each parameter is individually in its potential domain (e.g. days are positive integers, month names specific strings, ...) and then "rounds towards zero" to get a valid date - Temporal->Temporal rounds towards zero to get a valid date There is an exception to that Temporal->Temporal class, which is the method today the champions were proposing to change to not throw anymore [11:28:08.0446] * If it helps, this is what I understood happens by default based on the type of methods/conversions - String->Temporal validates the strings and throws - Plain object->Temporal validates that each parameter is individually in its potential domain (e.g. days are positive integers, month names some strings, ...) and then "rounds towards zero" to get a valid date - Temporal->Temporal rounds towards zero to get a valid date There is an exception to that Temporal->Temporal class, which is the method today the champions were proposing to change to not throw anymore [11:28:34.0363] * If it helps, this is what I understood happens by default based on the type of methods/conversions - String->Temporal validates the strings and throws - Plain object->Temporal validates that each parameter is individually in its potential domain (e.g. days are positive integers, which is all we know about days without looking at other parameters) and then "rounds towards zero" to get a valid date - Temporal->Temporal rounds towards zero to get a valid date There is an exception to that Temporal->Temporal class, which is the method today the champions were proposing to change to not throw anymore [11:32:42.0110] Or maybe "rounds down" and not "rounds towards zero" [11:33:26.0885] nicolo-ribaudo: from reading the spec I think the "plain object -> temporal" and "temporal -> temporal" cases were handled the same? [11:33:38.0683] could be wrong though, haven't traced through the whole thing [11:34:36.0078] Oh probably yes, given that if the input is a temporal object all the properties are already in the valid domain [11:36:14.0726] yes, what nicolo-ribaudo said is mostly accurate. for String->Temporal conversions, ISO 8601 is clear on what is and isn't a valid ISO string [11:36:41.0399] Plain object->Temporal is indeed basically the same as Temporal->Temporal, but Temporal objects are already valid in the domain [11:38:42.0051] Plain object->Temporal and Temporal->Temporal methods - the `overflow: 'constrain'` algorithm is a bit more complicated than rounding down: https://tc39.es/proposal-temporal/#sec-temporal-calendardatetoiso [11:39:05.0806] but in the ISO and Gregorian calendars, the only place where this is relevant is February 29 [11:39:56.0373] * but in the ISO and Gregorian calendars, the only place where this is relevant is February 29 (if you assume valid data) [11:40:08.0170] * but in the ISO and Gregorian calendars, the only place where this is relevant is February 29 (if you assume valid data, as you would for a Temporal→Temporal conversion) [11:44:29.0028] We have experience with Intl in checking in tests amid imprecise specifications, using a specific tag to note that case. We could do this for sum (and transcendental fns) if needed [11:45:13.0537] users will rely on whatever algorithm browsers select and they won't be able to change it in the future anyways [11:46:22.0549] a PDF of what waldemar linked in TCQ: https://people.eecs.berkeley.edu/~jrs/papers/robustr.pdf [11:47:45.0908] I think “batteries included” is a decent reason for this, alongside precision—as Kevin said, this just comes up frequently [11:49:41.0876] Historically, users have come to depend on answers even if the spec doesn’t say so. Eg see transcendental fns [11:50:17.0737] well we did manage to make sorting stable, even though it made lots of people angry [11:51:42.0016] snek: it being not guaranteed to be stable also made lots of people angry [11:51:55.0291] it made me angry [12:00:36.0963] the meeting in san diego is confirmed to be happening right? [12:02:31.0386] yes [12:04:33.0647] Yes, we can’t wait to have everyone on campus snek [12:05:05.0869] is there a recommended hotel or anything? i recall the building was a little bit far from most stuff [12:09:10.0076] apparently Python's full-precision floating point sum is about 10x slower than a naive summation, and probably about 7x slower than Neumaier [12:10:11.0373] but in JS using `.reduce` is probably at least 10x slower than a native Math.sum anyway, so maybe this is fine? [12:12:23.0980] http://blog.zachbjornson.com/2019/08/11/fast-float-summation.html [12:13:06.0474] it seems like with avx512 its *faster* to do the neumaier [12:13:47.0727] if only intel would properly support avx512 [12:15:45.0740] > <@devsnek:matrix.org> is there a recommended hotel or anything? i recall the building was a little bit far from most stuff we are waiting on this information; will share once available [12:22:40.0674] @snek I don’t speak officially on this, but we typically stay at a nice Embassy Suites that’s roughly a 10 minute walk from campus. It across from a large shopping center [12:23:12.0995] I’d be surprised if a different recommendation was made, but it is possible [12:29:30.0053] I figured out how to add n IEEE doubles in linear O(n) time and get the correctly rounded exact result in all cases, including avoiding overflow. In practice the running time is similar to Neumaier's but you always get exact results. [12:31:21.0937] sounds like that's the algorithm we should specify then? [12:33:03.0427] There are many algorithms that can do this. We should not specify one any more than we should specify JS language parsing by describing what data structures the parser uses and what how the parser updates them when it receives the next character of program text. [12:33:39.0044] * There are many algorithms that can do this. We should not specify one any more than we should specify JS language parsing by describing what data structures the parser uses and how the parser updates them when it receives the next character of program text. [12:34:37.0808] horwat's last theorem [12:34:50.0286] can you post the algorithms you're aware of on the repo? [12:35:00.0962] The important thing is that the results are completely deterministic. [12:35:14.0854] the reality tho is that if we don't pick an algorithm, browsers will, and it won't ever be changeable [12:35:33.0462] certainly if we have an algorithm that can unobservably be replaced then they can do so [12:36:23.0370] > <@ljharb:matrix.org> the reality tho is that if we don't pick an algorithm, browsers will, and it won't ever be changeable Is this claim provable? [12:37:16.0176] waldemar: people have started to depend on the precise results of Math.tan and friends, which historically vary across browsers, such that the minority browsers have been updating to match the semantics of the majority ones [12:37:27.0947] This may or may not mean that it is not changeable in practice [12:37:30.0837] > <@waldemarh:matrix.org> Is this claim provable? of course not, but it doesn't have to be, because that's already been browsers' experience and feedback [12:37:32.0114] The choice of algorithm is unobservable except by side channels like timing [12:37:57.0042] of course, if the result is deterministic, then yes the precise choice of algorithm doesn't matter. though Mark Miller wanted us to write down a precise algorithm. [12:37:57.0891] the exact results is what's observable [12:38:21.0975] Which I don't really want to do because writing down Shewchuk's will be somewhat lengthy. [12:38:43.0876] here's Python's, for refernece https://github.com/python/cpython/blob/48dfd74a9db9d4aa9c6f23b4a67b461e5d977173/Modules/mathmodule.c#L1359-L1474 [12:39:07.0868] The whole point of what I want to do here is to ensure that the result is deterministic by being the exact, correctly rounded answer. [12:39:16.0284] Anyway if Mark is OK with not specifying an algorithm I'm quite happy with that. [12:40:14.0976] waldemar: Are you OK with nondeterminism in the case of overflow/underflow? Because specifying those exactly will be hard, I think, without specifying a full algorithm. [12:40:54.0148] Or overflow at least; not sure about underflow. [12:42:23.0765] if the result is deterministic, then what's the problem with specifying an algorithm? it wouldn't be observable to follow it or not as long as you produced the right results [12:43:41.0852] it means that implementations probably won't innovate, for one thing [12:46:02.0726] Python's fsum throws if the intermediate sum overflows, looks like; e.g. `math.fsum([1.6e308, 1.6e308, -1.6e308, -1.6e308])`. I would not want to throw in this case though I'm not sure what a better option would be. [12:46:06.0558] The algorithm I'm thinking of gives the exact, correctly rounded result in all cases. If that final rounding is ±∞ or NaN, then that's what you get. If the rounding produces a finite double, then that's what you get. No nondeterminism in cases of ±∞ or NaN. [12:46:59.0436] Python's fsum is buggy when it gets intermediate overflows. But there is a simple way to avoid that. [12:47:16.0385] > <@bakkot:matrix.org> it means that implementations probably won't innovate, for one thing the alternative is that they’ll all probably copy the first shipper, no? [12:47:47.0602] waldemar: That sounds like a great option, then, though the paper you linked does not handle intermediate overflow from what I can tell [12:48:25.0998] It doesn't, but the way to solve that is so obvious they probably didn't bother with it. [12:48:32.0025] can you produce the algorithm you are thinking of [12:48:38.0231] just to sate my curiosity [12:51:48.0569] 1. If you have 0, 1, or 2 inputs, the result is trivial. [12:52:04.0332] 2. If you have 3 or more inputs, use the approach in the paper to compute an exact sum, represented as (p0+p1+…), where each p_i is a double and their exponents differ by at least 53 binary powers — in practice you'll likely end up with just one or two such p_i. Then round the sum as in fsum, taking care of the round-to-nearest-breaking-ties-to-even case in fsum. [12:52:54.0043] 3. If you get ±∞ or NaN as any of the inputs, the result is always ±∞ or NaN and you can figure it out directly without doing arithmetic. [12:55:01.0992] 4. Getting ±∞ as an intermediate result is only an issue if you have later cancellation coming that can bring the result back into a finite range. To take care of that case, always try to add in arguments with the opposite sign from your running total first. [12:58:29.0331] presumably -∞ yields -∞, but what does `∞ + -∞` yield? [12:58:50.0677] NaN [12:58:51.0394] NaN [12:58:53.0185] same as normal [13:09:21.0312] The claim is that people won’t use instanceof or toString? [13:09:56.0848] It seems like accessing these properties and getting the “wrong” value is a risk [13:09:59.0392] that they won't likely depend on the exact string output of toString, for one - that's been the case in the past when we've added toStringTag to things [13:10:13.0094] and for the constructor, the constructor isn't a global, so i think the likelihood someone will use it is low [13:10:36.0365] ... yes it is? [13:10:38.0183] * and for the constructor, the constructor isn't a global, so i think the likelihood someone will use it *for iterator helpers* is low [13:10:45.0240] `Iterator` is a global [13:10:48.0483] in this proposal [13:10:49.0679] oh right sorry this is Iterator not IteratorHelpers [13:11:07.0927] so I think the likelihood of someone using it is in fact pretty high [13:11:19.0271] ok so scratch that part, i still don't think people are likely to do `instanceof Iterator` tho [13:11:27.0616] I defnitely expect people to do that [13:11:33.0597] people use instanceof a lot [13:11:38.0054] you don't, I don't, but other people do [13:11:39.0832] rather than just throwing it through `Iterator.from`? [13:11:50.0161] ... uh, definitely yes? [13:11:57.0031] > <@littledan:matrix.org> The claim is that people won’t use instanceof or toString? If there's no constructor, wouldn't `x instanceof Iterator` still be fine? You just wouldn't be able to rely on `x instanceof someOtherIter.constructor` [13:12:03.0818] ok [13:12:19.0440] `instanceof` doesn't depend on `prototype.constructor` [13:12:27.0234] then i think the best thing is to hold off on the proposal until the remaining couple sites are migrated [13:12:51.0678] noooooooo [13:12:53.0858] ron, can you say that on the queue then? [13:12:54.0830] +1 to Kevin [13:13:01.0763] `instanceof` depends on `Constructor.prototype` [13:13:05.0327] Sorry I wasn’t able to use the queue for a minute [13:13:38.0096] what's two more months compared to "possibly gross forever" [13:14:19.0972] > <@littledan:matrix.org> Sorry I wasn’t able to use the queue for a minute no big deal 🙂 [13:14:59.0086] Apologies for throwing the conversation off by misremembering instanceof semantics [13:15:12.0706] `x.constructor === whatever` is almost never a good idea since it's so fragile [13:15:37.0970] I agree but still expect people to write it [13:15:51.0858] > <@ljharb:matrix.org> what's two more months compared to "possibly gross forever" The answer to this question depends on how gross we are talking about and how many iterations on “two more months” will happen [13:15:56.0967] If we had the constraint that we only had to worry about breaking _good_ code, the world would be much nicer [13:16:27.0907] > <@littledan:matrix.org> The answer to this question depends on how gross we are talking about and how many iterations on “two more months” will happen that's true. but "forever" is longer than a high number of iterations, and a little grossness accumulates over time [13:16:50.0235] Not adding `.constructor` doesn't *break* anything, since `%IteratorPrototype%` never had a constructor prior to this proposal [13:17:12.0795] It might break an expectation when writing new code, but it wouldn't break existing code. [13:17:46.0986] At least, no existing code that isn't relying on a proposed feature that hasn't yet reached Stage 4 [13:17:47.0646] To be clear I think having .constructor and Object.protototype.toString being “wrong” is grossness and the proposed alternative is “less gross” than omitting things [13:18:08.0311] rbuckton: right, but the concern is that people would come to depend on its absence once `Iterator` becomes a global, which I think is reasonably likely [13:18:36.0070] whereas I think there is much less chance of people coming to depend on these properties being accessors, as long as the people in this room agree not to do that [13:18:50.0265] wouldn't they depend on it by writing `iterator instanceof Iterator` tho, which wouldn't stop working later? [13:19:01.0208] if someone would write `iterator.constructor === Iterator`, i mean [13:19:04.0668] * if someone would otherwise write `iterator.constructor === Iterator`, i mean [13:19:48.0242] someone could write `if (val.constructor !== Iterator) val = Iterator.from(val)`, and that would start going down a different code path when `Iterator.constructor` was added, and that could easily break something [13:20:02.0121] I agree that people _shouldn't_ write that code but I think it's reasonably likely someone _will_ [13:20:35.0420] i'm skeptical it's likely they would think about that optimization [13:20:49.0595] people don't do that with `Promise.resolve` now [13:21:00.0563] uhhh lots of people do that [13:21:08.0620] or `if (!Array.isArray(x)) x = Array.from(x)` or whatever [13:21:11.0577] that is very common [13:21:17.0651] for arrays yes [13:21:24.0500] but for anything else? arrays are a bit unique imo [13:21:32.0045] iterators are more like arrays than promises [13:25:04.0697] waldemar: can you elaborate on "always try to add in arguments with the opposite sign from your running total first"? at what point during the algorithm do you mean? there's a basic Python implementation given at https://code.activestate.com/recipes/393090/ ; can you suggest the change you're proposing as a diff to this algorithm? (This algorithm is bugged, on the last line, but otherwise correct I believe) ```py def msum(iterable): "Full precision summation using multiple floats for intermediate values" # Rounded x+y stored in hi with the round-off stored in lo. Together # hi+lo are exactly equal to x+y. The inner loop applies hi/lo summation # to each partial so that the list of partial sums remains exact. # Depends on IEEE-754 arithmetic guarantees. See proof of correctness at: # www-2.cs.cmu.edu/afs/cs/project/quake/public/papers/robust-arithmetic.ps partials = [] # sorted, non-overlapping partial sums for x in iterable: i = 0 for y in partials: if abs(x) < abs(y): x, y = y, x hi = x + y lo = y - (hi - x) if lo: partials[i] = lo i += 1 x = hi partials[i:] = [x] return sum(partials, 0.0) ``` [13:27:39.0819] retvrn to associative arrays [13:36:54.0974] Whenever you add the next addend to the running total, prefer to pick an addend with the opposite sign from the running total if one exists. The sign of the running total is the sign of the first partial. [13:37:56.0555] do you get to pick any addend except the next one and still call it O(n)? [13:37:56.0829] How do you find the next addend? Sort the whole list? That's pretty expensive. [13:38:06.0895] * How do you find such an addend? Sort the whole list? That's pretty expensive. [13:38:26.0454] Addition of IEEE doubles with opposite signs can never produce ±∞. This way you can only get ±∞ if you've run out of addends of the opposite signs to your running total, in which case you've correctly overflowed to ±∞. [13:38:26.0586] Dividing it up by sign is sufficient, I guess, and cheaper. [13:38:47.0231] Though it does require keeping the whole list in memory, which previously was not required. Keeping the whole list in memory is potentially expensive also. [13:40:04.0904] If you want to do one pass, you can also do the lazy approach and worry about it only if you get ±∞ as an intermediate result, in which case you'd back up by one addend and look for addends of the opposite sign. [13:41:13.0274] Not having thought about this deeply, I like the idea of variadic Iterator.from [13:41:42.0627] That's similar to the approach of dealing with NaN's or ±∞ as inputs. If you see one of those, you want to *ignore* all finite inputs and only add the ±∞ and NaN's using IEEE double arithmetic. You can either scan for them in a pre-pass or just switch to the mode of ignoring finite values the first time you see a non-finite addend. [13:42:20.0854] I'm writing all of this as an issue on the proposal. [13:43:22.0728] can we have Iterator.from(...) and Iterator#concat [13:43:28.0257] and flat [13:43:32.0637] lets just do everything [13:45:11.0632] * Addition of finite IEEE doubles with opposite signs can never produce ±∞. This way you can only get ±∞ if you've run out of addends of the opposite signs to your running total, in which case you've correctly overflowed to ±∞. [13:45:12.0716] waldemar: when you encounter a NaN or ±∞ you can _skip_ intermediate results, whereas when searching for something of the other sign you have to keep all those values. That's fine if you're using summing values from an Array, but not when summing values from an iterable, since those are one-shot. [13:45:49.0982] I'm not saying that's a fatal problem, just that it's more overhead, and might be infeasible with extremely large iterables. [13:50:13.0448] I might be wrong, but you could keep two pointers, one with the next positive value, and one with the next negative, and that would still be O(N) with no extra memory, you'd just do at most two whole iterations over the array [13:50:35.0794] That's quite annoying. Picking operands with the opposite sign is the simplest approach to deal with this. If you *really* want to do this in one pass, you can also scale down the exponent of the most significant partial if you get an overflow by, say, 50 powers of 2. This will work as long as you have no more than 2^50 addends. [13:51:22.0778] Andreu Botella: the concern I have applies when you're summing a one-shot source, not when you're summing an array [14:01:10.0964] waldemar: To confirm my understanding, you're suggesting that when you would otherwise overflow, you instead introduce an additional partial which is specially marked as being scaled? and then if that partial still exists at the end you've actually overflowed in the final sum? I'll have to think about how to handle that partial but I think that makes sense. [14:01:57.0693] I'm fine saying that you get a rangeerror if you have more than 2**50 (or whatever) addends, so that this can be precise. I doubt that rangeerror would come up in practice anyway. [14:02:17.0831] I'll have to try implementing this before bringing it back. [14:07:47.0767] The link to the slides: this is the per [14:07:52.0147] * The link to the slides: https://notes.igalia.com/p/nxMdcUtbb#/ [14:55:43.0184] > <@bakkot:matrix.org> waldemar: To confirm my understanding, you're suggesting that when you would otherwise overflow, you instead introduce an additional partial which is specially marked as being scaled? and then if that partial still exists at the end you've actually overflowed in the final sum? I'll have to think about how to handle that partial but I think that makes sense. Yes. you'd scale p_0 by dividing it and anything you add to it by 2^50 (or whatever), and multiplying back by 2^50 when you start working on p_1. It's a bit tedious but can be done precisely and efficiently. [14:56:38.0155] Of course you'd only do this if you're close to overflowing. [14:57:41.0530] Filed https://github.com/bakkot/proposal-math-sum/issues/1 on this. [15:04:13.0850] waldemar: OK, great. Thanks for the writeup. I'm going to have to try implementing this before I am confident proposing it (and maybe I'll submit a bugfix to cpython while I'm at it), but I think I understand the how to do it in a single pass. [15:04:15.0729] I'm hoping the performance is good enough for engines to be comfortable shipping it as Math.sum. If they're not, I may suggest naming this `Math.fsum` or something, to make it clear that this is special i.e. potentially much slower than naive summation. [15:31:51.0134] ljharb: here's the relevant notes from the last meeting and why I thought that this was not possible > NRO: If you don’t want to wait too long to ship this, could we ship it without the constructor property until when we know it’s safe to do so? Because, like, I know that that’s burden of polyfill containers and people that care about compat matters, but, like, in practice, would this be an okay way to, like, avoid this hack, if we cannot solve the problem quick enough? > > JWK: I think it’s not possible because the iterator prototype is already reachable via Array#values. The iterator prototype is already existed and this proposal just exposes it on the global. You cannot really move a thing from it. > > CDA: Okay, last on the queue is Jordan. Plus one to drop constructor and toStringTag temporarily in the meantime. End of message. > > JHD: I did just want to add to Jack’s comment, the hidden iterator intrinsic does not have a iterator property. It tries to add it. It will fall back to object.prototype. > > JWK: Oh, I don’t know that, if that’s the case, maybe we can do it. [15:32:21.0665] but after reading this conversation and thinking about it more, I still prefer the weird accessors over omitting the properties [15:32:30.0722] I'm not sure how to resolve this since they both solve the immediate issue [15:32:49.0192] `Reflect.ownKeys([].keys().__proto__.__proto__)` has only Symbol.iterator on it [15:32:55.0557] so it'd be omission, not removal [15:33:18.0596] yes, that was clarified [15:33:24.0363] it seems very likely that *eventually* those websites will get updated, and whatever workaround we use will be something that we want to undo [15:33:31.0354] omission is a much easier mistake to unmake than the accessors [15:33:55.0562] I don't see why anyone would ever go out of their way to observe that they are accessos [15:34:02.0185] * I don't see why anyone would ever go out of their way to observe that they are accessors [15:34:44.0170] https://npmjs.com/get-intrinsic does, because it's using getOwnPropertyDescriptor [15:35:18.0437] it's not that i think someone will actually care which it is; it's that i know that code written to assume one kind of descriptor will break if that kind changes. and SES lockdown *does* change them, and it *does* break code [15:35:36.0067] * it's not that i think someone will actually care which it is; it's that i know that code written to assume one kind of descriptor will break if that kind changes. and SES lockdown _does_ change them, and it _does_ break code, so i have actual evidence that this breakage is a problem [15:36:46.0882] > <@ljharb:matrix.org> it seems very likely that *eventually* those websites will get updated, and whatever workaround we use will be something that we want to undo I don't think we can count on websites eventually getting updated in this way. We've made other decisions to work around old libraries before. [15:37:10.0381] If there was a way to do a Get without traversing the prototype chain then I’d use that, and it’d be immune to this breakage. [15:37:49.0452] > <@ljharb:matrix.org> https://npmjs.com/get-intrinsic does, because it's using getOwnPropertyDescriptor I kinda feel like expert polyfill authors will have an easier time working through these issues than ordinary JS developers who are doing `x.constructor === Y` [15:37:59.0143] > <@littledan:matrix.org> I don't think we can count on websites eventually getting updated in this way. We've made other decisions to work around old libraries before. in this case it’s a concrete list of known customers so i think we can count on it more than usual. [15:38:17.0287] > <@littledan:matrix.org> I kinda feel like expert polyfill authors will have an easier time working through these issues than ordinary JS developers who are doing `x.constructor === Y` if we never ship constructor then they just won’t do that [15:39:51.0109] leaving them as accessors is also a perfectly fine state [15:40:22.0932] i don’t agree, unless that’s the pattern we’re going to consistently follow elsewhere, at least in new things [15:40:53.0441] when this exact kind of breakage happens, yeah, that's probably the plan [15:41:45.0390] Ultimately I think either option is OK and am just unconvinced by the strong arguments on both sides [15:42:13.0457] I don’t know how we should make decisions in these cases. “First one to back down” seems like not completely optimal.. [15:43:30.0369] there are no strong arguments in either direction here [15:43:33.0527] We can also wait. [15:44:51.0823] Chrome was not willing to hold off on shipping this proposal while we wait for more of those customers to upgrade, if that's what you're suggesting [15:45:18.0525] what would chrome do if we didn’t suggest a change? [15:45:34.0997] presumably they’d pick one of the three options, or “break them anyways” [15:45:55.0533] they would not break these websites [15:46:06.0184] they would probably move forward with one of these two options [15:46:11.0505] I don't speak for Chrome though [15:46:14.0379] > <@ljharb:matrix.org> presumably they’d pick one of the three options, or “break them anyways” I think the hope is that TC39 will make a recommendation [15:46:19.0829] This is sort of our job… [15:46:41.0240] It is not clear to me what we should be waiting for [15:47:30.0874] If it works, I would rather choose Jordan’s preferred option than wait for something more beautiful to come along. This just isn’t a big or complex design space; we already understand it, I think [15:47:33.0445] i agree that’s our job, but if we can’t agree on the recommendation then isn’t the recommendation to either wait or break? [15:48:23.0793] > <@ljharb:matrix.org> i agree that’s our job, but if we can’t agree on the recommendation then isn’t the recommendation to either wait or break? I don’t think we should be complacent about this state of not agreeing; we should figure out how to agree, rather than calling ourselves virtuous for being thoughtful [15:48:43.0173] this isn’t like mootools or something where there’s thousands of sites with no good way to contact them. I think we won’t have to wait very long. [15:49:47.0528] > <@ljharb:matrix.org> this isn’t like mootools or something where there’s thousands of sites with no good way to contact them. I think we won’t have to wait very long. Sorry but this is where we have heard explicit disagreement from Chrome. I think we should focus on choosing between your option and Michael’s [15:49:56.0617] yeah I'm glad you can have such confidence, but Chrome can't make calls based on how confident Jordan is [15:50:19.0399] (By your option I mean omitting the properties) [15:50:23.0389] the call they made is that they're not willing to wait any longer [15:50:33.0094] i mean they could :-) they just didn’t/wont [15:51:23.0325] OK, so, can we just go with the flow of that and try to make a decision between omitting them and using getters? I don’t see what it would serve to push back on Chrome here [15:53:15.0548] honestly, I think the web compat issue (at least this particular one) will be resolved in another 3-6 months [15:53:37.0928] but if we omit them, we have to come back to this later and see if it's web-compatible to add data properties [15:53:48.0237] and if it's not, we'll have to add the accessors anyway [15:54:03.0983] whereas, if we add accessors now, we don't ever have to revisit this if we don't want to [15:55:26.0819] crucially, *I* don't have to be the one to revisit this and *Chrome* doesn't have to be the one to risk web breakage again for basically no benefit to anyone 2023-11-29 [16:44:02.0846] I will be happy to revisit it and add the omitted data properties as a proposal once the websites are fixed. I can’t speak to chromes opinion on that tho. [16:47:27.0336] assuming it's web-compat to do so, which it may not be [16:47:48.0283] whereas it would almost certainly be web-compat to change the accessors to data properties as long as the people in this room agreed not to rely on them being accessors [17:35:12.0606] Do we just need to spec a special data property flag that allows assignment of the property on an instance even if the prototype is non-writable/non-configurable? It seems to me this isn't the last time this will come up. [18:13:34.0964] I think that would be worse than just having a bunch of accessors. [09:14:28.0936] FYI I will miss the first 90 minutes today [09:22:13.0088] Rezvan: Does Chrome have a position here? If these properties are omitted for now, would you consider attempting to add data properties again in the future, or are accessors the only option? [10:02:18.0467] #jsx:matrix.org [10:04:40.0900] I wonder if a generalized `canParse` solution for JS would be viable as an alternative to using `eval` or `Function` for syntactic feature testing [10:09:13.0237] > <@rbuckton:matrix.org> I wonder if a generalized `canParse` solution for JS would be viable as an alternative to using `eval` or `Function` for syntactic feature testing definitely, and similar to [CSS.supports](https://developer.mozilla.org/en-US/docs/Web/API/CSS/supports_static) [10:13:43.0010] how do people feel about ``` Function.prototype.try = function(...args) { try { return { success: true, value: this.apply(null, args) }; } catch { return { success: false, value: undefined }; } } ``` as in ``` let { success, value } = JSON.parse.try(string); ``` [10:14:28.0078] only works for functions not methods, I guess [10:15:06.0922] guess there could be a `tryWithThis` which would let you do `JSON.parse.try(JSON, string)` [10:15:15.0663] i like that, it has the side benefit that it encourages use of standalone functions [10:15:28.0935] * i like that (the non-method one), it has the side benefit that it encourages use of standalone functions [10:17:09.0563] `let { success, value } = tryApply(target, thisArgument, argumentsList)` would be language-consistent but less ergonomic [10:17:20.0259] * `let { success, value } = tryApply(fn, thisArgument, argumentsList)` would be language-consistent but less ergonomic [10:17:36.0205] `fn.tryApply` is at least as consistent, surely [10:17:46.0874] * `fn.tryApply(thisArgument, argumentsList)` is at least as consistent, surely [10:18:09.0714] i'd swap those two but sure [10:18:22.0094] * i'd swap those two but sure (`thisArg` goes last, just like all the array methods) [10:18:29.0437] or I guess `fn.tryCall(thisArgument, ...args)` [10:18:30.0863] * i'd swap those two but sure (`thisArg` goes last, just like all the array methods, since it's more optional than args) [10:18:49.0703] > <@ljharb:matrix.org> i'd swap those two but sure (`thisArg` goes last, just like all the array methods, since it's more optional than args) I disagree, `thisArg` should come first, like `call` and `apply` [10:19:02.0501] oh hm, i guess i see that argument too [10:19:02.0593] but also I would want a version that doesn't take `this` at all [10:19:23.0310] i get this feeling that like [10:19:23.0831] so specifically I think I like best `.try`, which is only useful for non-methods, and `.tryCall`, which adds an initial `this` parameter [10:19:26.0264] yeah if the thisArg has to come first in a call/apply variant then i'd def want yet another one that omitted the receiver entirely [10:19:31.0304] async modules are some sort of fundamental failure [10:19:32.0369] yeah, that's the friction point [10:19:36.0815] because everyone keeps trying to build ways to disable them [10:19:51.0444] but i don't want them to be some sort of fundamental failure [10:19:53.0299] i really like them [10:20:13.0915] agreed on both points [10:23:11.0894] another place where async modules were no longer used https://github.com/WebAssembly/esm-integration/pull/76 [10:24:44.0348] lol if we end up doing a directive, there's going to be a deluge of pragma/directive proposals once "no more modes" isn't a law anymore [10:25:12.0042] eh, I think directives which either evaluate normally or cause errors aren't really new modes [10:25:15.0737] > <@ljharb:matrix.org> lol if we end up doing a directive, there's going to be a deluge of pragma/directive proposals once "no more modes" isn't a law anymore This directive wouldn't be a new mode [10:25:21.0742] > <@ljharb:matrix.org> lol if we end up doing a directive, there's going to be a deluge of pragma/directive proposals once "no more modes" isn't a law anymore * This directive wouldn't be a new mode like strict vs sloppy [10:25:36.0642] It doesn't introduce a new "language version" [10:25:48.0341] No more than doing the same through any other syntax [10:25:50.0896] lol yeah i understand the nuance, but i don't think it will come across [10:29:23.0021] `export with { sync: true }`? Not a huge fan of how it reads though. [10:29:34.0787] ps here's a relevant snippet from the notes from 2018 related to this exact problem: https://github.com/tc39/notes/blob/df1449925841bc77574e8e127611234670275575/meetings/2019-03/mar-28.md?plain=1#L507-L519 [10:36:06.0499] oh man i would hate if nodejs was another reason for people to not use async modules [10:36:08.0367] that would kill me [10:40:14.0062] what about a function or bit of syntax that {tells you whether/asserts !} you've hit the event loop? i feel like that's always what you really care about in these worker listener cases [10:48:47.0959] If you have multiple script tags the event loop will start spinning before that the module even starts running, so it would always say "yes" [10:50:04.0270] Example: you load an analytics script and your main entry point module, and the analytics script already spins the event loop [10:56:11.0098] then that would be the correct result right? [10:56:54.0370] if you are a worker and you need to register listeners to handle messages then you absolutely must register them before you hit the event loop [10:58:02.0312] I see a barrel library [11:00:21.0037] deferred imports make me very nervous; a keyword on `export` that's a lazily evaluated thing on the first import seems pretty nice. [11:01:51.0697] * deferred imports make me very nervous; a keyword on `export` that's a lazily evaluated thing on the first import seems pretty nice - it might turn treeshaking from a half-assed hack into a reliable mechanism [11:02:30.0637] It's like runtime treeshaking. You only get the bits of the barrel you need. [11:03:02.0276] ... treeshaking seems like a pretty reliable mechanism in the current world in fact? [11:03:04.0286] And it can progressively load more of the barrel just-in-time [11:03:47.0304] > <@bakkot:matrix.org> ... treeshaking seems like a pretty reliable mechanism in the current world in fact? not in every codebase i've worked in; changing to deep imports and prohibiting barrel files has consistently produced MASSIVE savings [11:03:55.0956] coinbase's react native app size dropped by 71% with that change. [11:04:16.0672] it should really make defer become default back when tc39 design ES module in ES6 [11:04:50.0956] * coinbase's react native app size dropped by 71% (seventy-one, not a typo) with that change [11:04:56.0220] Tree-shaking only works when the compiler can see the full-scope of the program. That's not always possible in dynamically linked systems. [11:05:31.0342] The perf issues of barrel files are well-documented https://marvinh.dev/blog/speeding-up-javascript-ecosystem-part-7/ [11:05:38.0490] even then, my statement holds. coinbase's RN app had no dynamic linking. [11:05:52.0930] and requires `"sideEffects: false"` in your package.json which is not everyone remembers to add [11:06:33.0564] and which isn't granular enough to support packages with one side-effecting code path and many non-side-effecting code paths [11:06:50.0247] * and which isn't granular enough to support packages with one side-effecting code path and many non-side-effecting code paths, eg [11:07:55.0023] i can confirm, importing fewer things is faster [11:09:33.0665] > <@ljharb:matrix.org> and which isn't granular enough to support packages with one side-effecting code path and many non-side-effecting code paths, eg actually it supports, you can write `"sideEffects": ["./src/init/**"]` [11:10:35.0554] ooh, TIL, thanks [11:12:20.0595] > <@ljharb:matrix.org> coinbase's react native app size dropped by 71% (seventy-one, not a typo) with that change that is wild to me. they just... had a bunch of side effects? for some reason? [11:13:01.0698] no, it's that treeshaking simply isn't capable of safely judging that, and so the necessary heuristics leave behind way more code than is actually used [11:13:34.0393] in the past, rollup's heuristics (when rollup was the only treeshaker) were too aggressive, and it broke airbnb.com in IE for months [11:13:42.0964] * in the past, rollup's heuristics (when rollup was the only treeshaker) were too aggressive, and it broke airbnb.com in IE for months, so it's a really hard line to walk [11:13:45.0588] that has not been my experience at all; do you have an example where the heuristics fail? [11:14:08.0381] tbf i haven't dived into treeshaking tools to know exactly what it is; that's just the sense i have seeing the empirical results [11:15:10.0783] Statically judging whether JS code has side-effects is hard - probably impossible - so compilers take a safety-first approach and bail out unless they are really sure dead code is safe to remote. This is why treeshaking is not always effective. [11:15:20.0468] the lesson here should be just don't use side effects [11:15:32.0070] i wonder if this js code halts [11:15:33.0543] * Statically judging whether JS code has side-effects is hard - probably impossible - so compilers take a safety-first approach and bail out unless they are really sure dead code is safe to remove. This is why treeshaking is not always effective. [11:15:43.0625] the lesson most of us have taken is, don't use barrel files :-) [11:16:20.0719] i wish prepack was still a thing [11:18:57.0909] > <@ljharb:matrix.org> the lesson most of us have taken is, don't use barrel files :-) and with this proposal, barrel files suddenly becomes a performance benefit [11:19:03.0026] thankfully 0% of my code has side-effects, it's all overhead [11:19:20.0511] > <@robpalme:matrix.org> Statically judging whether JS code has side-effects is hard - probably impossible - so compilers take a safety-first approach and bail out unless they are really sure dead code is safe to remove. This is why treeshaking is not always effective. Right but only if you're writing code in such a way that it's hard to analyze; my experience has been, dependencies which I consider of adequate quality to add to my projects are, in general, written in such a way that this is trivial to analyze [11:19:27.0799] I am surprised to learn this is not everyone's experience [11:20:18.0248] tbh i'm surprised it's anyone's. the above article got quite a lot of +1s on twitter and virtually no pushback [11:20:23.0397] * tbh i'm surprised it's anyone's. the above article got quite a lot of +1s on twitter and virtually no pushback that i saw [11:20:24.0355] after reading the article on what these are, I feel like this should have been obvious from the beginning [11:20:27.0549] people be crazy [11:21:04.0575] the article above was only talking runtime, not treeshaking [11:21:11.0837] in fact it specifically says "treeshaking solves this" [11:21:24.0299] > you then run the bundled file to repeat the experiment and voilá, it finishes in a blink of an eye. Out of curiosity, you measure the time it takes to run esbuild and run the bundled file together and notice that both of them combined are still quicker than running the original source code. Huh? What is going on? [11:21:56.0213] "waah, I want one import line instead of five, I'm going to *blindly merge others' namespaces*, that seems like an okay trade-off" [11:22:09.0885] 🤮 [11:24:48.0622] ah fair, i was remembering some twitter discussion then i guess, not the article [11:26:45.0389] multiple exports was a mistake [11:36:31.0476] ugh we have a bug in PerformEval: it doesn't ever ToString its argument https://tc39.es/ecma262/#sec-performeval [11:37:34.0078] oh wait, never mind, it just can't reach that point without being a String [11:37:34.0962] I got it [11:41:20.0802] the thing where `eval` is the identity function on non-string arguments is... very strange [11:45:26.0006] I prefer option 2 because it will extend to TT better [11:48:34.0734] ``` function unsafeMaybeNotAString(v) { return Object.is(v, eval(v)); } ``` [11:48:38.0918] ljharb: we need to figure out what we're going to do with iterator helpers ASAP [11:49:03.0456] the accessors approach seems safest to me, even if it makes us feel a little bit gross [11:49:17.0746] i'd love to hear v8's position on the two options, but i still don't feel that accessors are safer [11:49:19.0993] I won't die on that hill though; either solution works for now [11:50:07.0365] if we go with "omit" i will be happy to immediately make a new proposal to reintroduce them, and will coordinate with the person from the issue to track upgrading those sites, fwiw [11:50:30.0227] that doesn't mean you'll have engine support to experiment with shipping them though [11:50:40.0586] right, which is why i want to hear v8's position first [11:50:54.0232] Rezvan is the V8 rep at this meeting [11:51:43.0709] `unsafeMaybeNotAString("v")` [11:53:03.0683] ``` function unsafeMaybeNotAString(v) { return Object.is(v, (0, eval(v))); } ``` [11:53:35.0135] Level 2 [11:54:03.0682] I'm generally partial to "omit" as well. While I understand bakkot's concerns around `x.constructor === whatever`, I think there is a fairly low likelihood of that becoming a problem if there is a short turnaround on a follow-on proposal and the outstanding sites being fixed. [11:54:04.0045] can strings be quines [11:56:05.0873] ``` unsafeMaybeNotAString(`(function _(){return'('+_+')()'})()`) ``` [11:56:20.0733] also the `toString` of an Iterator will change [11:56:24.0686] Though I still think there's potential for a general solution to the "override mistake", such as adding a new PropertyDescriptor flag to opt-in to a behavior that allows setting on an instance even if the property is frozen on the prototype. [11:56:52.0670] > <@michaelficarra:matrix.org> also the `toString` of an Iterator will change From what it is in the spec, or do you mean from what it is on `%IteratorPrototype%` currently? [11:57:05.0909] > <@michaelficarra:matrix.org> also the `toString` of an Iterator will change * From what it is in the proposal spec, or do you mean from what it is on `%IteratorPrototype%` currently? [11:57:16.0290] from what's in the draft spec as of now [11:57:49.0605] it is proposed as "[object Iterator]" and will be "[object Object]" temporarily [11:58:01.0287] like... why do that? [11:58:22.0462] this is just unnecessary risk and I really don't see the upside other than warm fuzzies [12:01:46.0234] I don't have a preference regarding toString/toStringTag, tbh. I generally wouldn't recommend relying it for anything other than a debugging aid, so its presence or absence isn't that concerning to me. [12:02:00.0390] * I don't have a preference regarding toString/toStringTag, tbh. I generally wouldn't recommend relying on it for anything other than a debugging aid, so its presence or absence isn't that concerning to me. [12:32:25.0762] > <@ljharb:matrix.org> right, which is why i want to hear v8's position first V8 is supporting the PR (https://github.com/tc39/proposal-iterator-helpers/pull/287) Michael talked about yesterday. This incompatibility blocked us for shipping iterator helpers. The solution provided in the PR seems to be the best way to resolve the issue. [12:32:53.0779] > <@rmahdav:matrix.org> V8 is supporting the PR (https://github.com/tc39/proposal-iterator-helpers/pull/287) Michael talked about yesterday. This incompatibility blocked us for shipping iterator helpers. The solution provided in the PR seems to be the best way to resolve the issue. thanks; and does v8 have an opinion about, instead of the PR, just not implementing the constructor and Symbol.toStringTag properties for the time being? [12:33:31.0713] and additionally, with either approach, is Chrome willing to try to ship them as normal data properties in the future once the incompatible websites have finished upgrading? [12:51:38.0430] > <@ljharb:matrix.org> thanks; and does v8 have an opinion about, instead of the PR, just not implementing the constructor and Symbol.toStringTag properties for the time being? I am not sure about this. I do not remember anything related to this in our discussions with Shu. [12:52:22.0117] > <@ljharb:matrix.org> and additionally, with either approach, is Chrome willing to try to ship them as normal data properties in the future once the incompatible websites have finished upgrading? About this one, I think the answer is yes. Michael Ficarra Since you had discussions with Shu, what do you think about it? [12:59:35.0923] slide link of next topic: https://johnhax.net/2023/slice/slide [13:00:25.0600] Rezvan ljharb we didn't talk about that [13:02:53.0552] So, my answer was my opinion. Not sure if Shu thinks the same. [13:13:04.0580] I've never met anyone who knows the parameter meaning and order for both slice and splice off the top of their head [13:13:31.0096] other than `slice(n)`, I look them up every time [13:13:39.0877] mdn. every time [13:14:04.0343] > <@softwarechris:matrix.org> mdn. every time Quick-info in VS Code :) [13:14:35.0351] my vscode-fu need polishing for sure [13:14:54.0186] i know slice but only because i've trained myself to see the "p" so hard, at which point i immediately have to look it up every time [13:15:16.0844] > <@softwarechris:matrix.org> my vscode-fu need polishing for sure Usually just `array.slice(` is enough assuming the language service knows `array` is an array type [13:15:22.0865] I can never remember which of the string methods support negative indices. [13:16:28.0965] > <@rbuckton:matrix.org> Usually just `array.slice(` is enough assuming the language service knows `array` is an array type oh true.. I guess I start thinking about it before I start writing the code.. like I don't get to slice( and then start wondering [13:16:35.0917] this vscode example doesn't look like a bug to me [13:16:43.0425] Yeah, not a bug. [13:17:26.0254] The line assumes `subcommand` exists as an element, because that's the only way you can get to that line to begin with. [13:18:32.0201] that's what I figured [13:29:56.0347] :-( my queue reply was skipped [13:29:58.0894] apologies Michael Ficarra didn't see your reply in time [13:30:26.0404] this is why we need https://github.com/bterlson/tcq/issues/65 [13:31:49.0015] by "reified" do we mean like, a noun that represents a kind of "view" on an array/string? [13:31:49.0891] anyway, I was trying to point Ron to the https://github.com/tc39/proposal-iterator.range proposal where we have discussed having a reified range [13:32:01.0921] I personally support it, but most others seemed to reject it [13:32:35.0366] ljharb: basically a data structure that holds bounds and can be passed between the `[]` to do the slice [13:33:14.0825] yeah that sounds super unjavascripty to me [13:34:38.0571] My suggestion for reification is the introduction of "inverted" get/set/has/delete via symbols that could be looked up on an Object in lieu of ToPrimitive: ```js class Index { offset; fromEnd; [Symbol.geti](value) { return this.fromEnd ? value[value.length - this.offset] : value[value.length]; } } const x = new Index(1, /*fromEnd*/ true); ar[x] // -> x[Symbol.geti](ar) ``` Which has a general utility for custom indexes, such as turning a `WeakMap` into a scoped pseudo-private name: ```js WeakMap.prototype[Symbol.geti] = function (key) { return this.get(key); } WeakMap.prototype[Symbol.seti] = function (key, value) { this.set(key, value); } const key = new WeakMap(); const obj = {}; obj[key] = 1; // key[Symbol.geti](obj); ``` [13:34:54.0466] making an actual thing vs just typing `x => x[a, b](y)` doesn't seem worth adding [13:36:02.0968] I would definitely not want that to work with normal `obj[key]` access, but could see using the `obj[^key]` syntax or something [13:36:05.0827] That can't be unwrapped though [13:36:09.0448] and while i see ron's point that making a special kind of value and a special protocol to go with it would be a logical generalization, that's a ton of complexity that it'd be a hard sell to justify [13:36:37.0366] though I don't see why you want to do it in this inverted way - it seems like usually containers know how to use an index, rather than an index knowing how to use a container? [13:36:46.0154] i.e., `x => x[a, b]` doesn't let you extract `a` and `b` as there's no associated data model. [13:37:08.0569] so would we also have a PropertyKey that represents a property, takes an object, and does an inverted lookup? [13:37:22.0708] > <@rbuckton:matrix.org> i.e., `x => x[a, b]` doesn't let you extract `a` and `b` as there's no associated data model. oh lol yeah sorry `x.slice(a, b)` in this case, i mistyped [13:37:44.0112] > <@rbuckton:matrix.org> i.e., `x => x[a, b]` doesn't let you extract `a` and `b` as there's no associated data model. * oh lol yeah sorry `x.slice(a, b)` in this case, i mistyped. but yes it doesn't let you get at the a and b, which seems like a benefit? (to make it an opaque lens) [13:38:46.0854] I think my preference here would be to leave `obj[x]` alone, and to add a new `obj[^x]` which invokes a symbol-named method on `obj` passing it `x` (uncoerced). there could then be a `slice(a, b)` function which returns a reified Slice, and the symbol-named method on Array could know how to deal with that [13:39:00.0937] also you could have the symbol-named method on Map be an alias for `get`, and that sort of thing [13:39:09.0154] > <@bakkot:matrix.org> though I don't see why you want to do it in this inverted way - it seems like usually containers know how to use an index, rather than an index knowing how to use a container? Except `[]` is only useful for strings and symbols (i.e., via toPrimitive). You can't put anything else meaningful in there that isn't either. [13:39:13.0110] and of course have a similarly named method to be invoked when doing `obj[^x] = y` [13:39:20.0172] yeah I would also not want `a[b]` delegating to a protocol [13:40:07.0722] I'm surprised the `WeakMap` example isn't a stronger motivator? [13:40:37.0299] weak things are used so rarely i don't think it'd motivate any ergonomic changes? [13:42:53.0807] the WeakMap example seems actively bad to me? if I see `obj[key] = 1` I am really expecting to set a property on `obj`. if it does something other than that this is bad. [13:43:06.0123] Could someone clarify if we're talking about just the slice `1:2` proposal now, or also the `^` one? [13:43:17.0136] whereas `map[^key] = value` seems nice [13:43:29.0840] * whereas `map[^key] = value` seems nice (altho i'm not sure how it'd work with set) [13:44:26.0920] > <@bakkot:matrix.org> the WeakMap example seems actively bad to me? if I see `obj[key] = 1` I am really expecting to set a property on `obj`. if it does something other than that this is bad. The WeakMap thing was a way to implement the "Private Symbol" mechanism championed by Alex Russel (I think?) without the need to introduce new syntax. [13:44:38.0995] ljharb: I am imagining that `map[^key] = value` is sugar for `map[Symbol.set](key, value)` [13:44:50.0712] i would agree [13:44:55.0339] > <@eemeli:mozilla.org> Could someone clarify if we're talking about just the slice `1:2` proposal now, or also the `^` one? It's ambiguous. [13:45:14.0160] > <@bakkot:matrix.org> ljharb: I am imagining that `map[^key] = value` is sugar for `map[Symbol.set](key, value)` That is at odds with the proposal for `[^x]` to mean index-from-end. [13:45:33.0854] right, we've been talking about a new imagined proposal for `[^x]` to not necessarily mean from end [13:45:46.0095] however `arr[^-1]` could map to `.slice`, solving that problem [13:45:51.0327] rbuckton: not if `Array.prototype[Symbol.set] = function(key, value) { this[-key] = value }`! [13:45:55.0916] > <@bakkot:matrix.org> the WeakMap example seems actively bad to me? if I see `obj[key] = 1` I am really expecting to set a property on `obj`. if it does something other than that this is bad. I disagree. We *already* special case objects for indexed access. We just special case them via `Symbol.toPrimitive` [13:45:56.0764] * however `arr[^-1]` could map to `.slice` or `.at`, solving that problem [13:46:20.0026] * rbuckton: not if `Array.prototype[Symbol.set] = function(key, value) { key < 0 ? this[this.length + key] = value : this[key] = value }`! [13:46:21.0001] And an explicit `Symbol.geti` seems directly in line with "stop coercing things". [13:47:18.0820] "stop coercing things" is mainly intended to apply to new APIs, not to change the meaning of existing things [13:47:25.0574] I don't want to change the meaning of existing things as a rule [13:49:20.0214] but also, even in a world where I thought changing the meaning of `obj[key]` was a good idea, I would still think that it would invoke a method on `obj`, not a method on `key` [13:49:38.0175] Honestly, I'd love to be able to hook `a[x]` directly to better support custom collections. Indexing with things other than string/number is fairly common in many languages, and is extremely limiting in JS. `Symbol.geti` avoids hooking all of `a[x]` for a specific class of key-like things. [13:50:19.0670] My suggestion is to add a new syntax for such cases. [13:50:23.0516] rbuckton: `a[b]` needs to have simple semantics [13:50:38.0270] > <@michaelficarra:matrix.org> rbuckton: `a[b]` needs to have simple semantics I don't agree. [13:50:41.0947] I don't think we should change `a[x]`, but I think we could reasonably introduce `a[^x]`, which would allow `a` to define how it should be indexed by arbitrary `x` [13:50:49.0295] > <@bakkot:matrix.org> My suggestion is to add a new syntax for such cases. This feels extremely wasteful, imo. [13:51:05.0475] sorry, a better thing to say would be "there needs to be property access with simple semantics; `a[b]` serves that purpose already" [13:51:31.0728] put more strongly, changing `a[x]` would likely break a lot of assumptions in existing code and in the minds of existing devs, and i doubt there would ever be consensus for that, such that i think it's a waste of time to pursue it. [13:51:57.0820] yeah, changing that is almost certainly dead in the water [13:52:03.0087] > <@bakkot:matrix.org> I don't think we should change `a[x]`, but I think we could reasonably introduce `a[^x]`, which would allow `a` to define how it should be indexed by arbitrary `x` If we introduced a new syntax for indexing, I'd be opposed to `a[^x]` specifically as I'd really like it to not mean different things in different places (negative index on Arrays, something else somewhere else, etc) [13:52:05.0727] if that were possible then i would assume we'd have added objects as object keys and not symbols [13:52:24.0586] > <@rbuckton:matrix.org> If we introduced a new syntax for indexing, I'd be opposed to `a[^x]` specifically as I'd really like it to not mean different things in different places (negative index on Arrays, something else somewhere else, etc) if it's a protocol, then that's inherently unavoidable. no? [13:52:30.0363] Especially given the prior art for the `^x` syntax in C#. [13:52:34.0247] I was hoping that we could save prefix ^ for something more interesting, e.g., shorthand for zero-parameter arrow functions [13:52:42.0946] > <@rbuckton:matrix.org> If we introduced a new syntax for indexing, I'd be opposed to `a[^x]` specifically as I'd really like it to not mean different things in different places (negative index on Arrays, something else somewhere else, etc) sure, `[^x]` was just an idea. `[@x]` or something also fine. [13:53:17.0656] hax (HE Shi-Jun): I will definitely help, but I don't think I can sign up for co-championing [13:53:25.0336] or `obj@[x]`, we could be creative [13:53:33.0973] there's only so much time I have to dedicate to TC39 stuff and I need to prioritise things [13:53:43.0250] (like protocols) [13:54:01.0721] For partial application I'd considered an infix `~` as an indicator, i.e. `a~()`. I could see `a~[x]` as an option for custom syntax, but I still don't think custom syntax is merited if we could easily hook `a[x]` for a very specific set of things. [13:54:22.0527] lol tell me about it [13:54:33.0602] it's very very important that that syntax not be more hookable than it already is, getters are bad enough [13:54:38.0413] if iterator helpers and follow-ons weren't so damn useful and popular... [13:54:45.0602] > <@michaelficarra:matrix.org> there's only so much time I have to dedicate to TC39 stuff and I need to prioritise things Thank you ! I just try to advance it it the simple form which I believe is the best solution on these problems. [13:54:49.0077] You could imagine `Symbol` as being implemented this way, and the addition of `Symbol` to `x[a]` was a change to an existing thing back in 2015 [13:54:49.0473] or if someone else was working on them [13:55:11.0993] in the next half year i may have time to help with some of those, fwiw [13:55:15.0153] I'm ok with other syntax, but to be honest I don't see how diff with `a[^i]`. [13:55:46.0218] > <@haxjs:matrix.org> Thank you ! I just try to advance it it the simple form which I believe is the best solution on these problems. I agree. I think simple slicing can be added on its own, with consideration for how it might fit into the generalisation in the future. [13:56:25.0856] So it seems I have nothing could do... [13:56:26.0245] No more `('b' + 'a' + + 'a' + 'a').toLowerCase()`? [13:56:32.0862] As a counterpoint to `a[@x]` or whatever. if `x` is a reified slice, I would want a way to _explicitly_ throw when it is used via `a[x]`, since that would be a mistake. [13:57:03.0440] reified properties/indexes/object operations don't sound like a great direction to me personally, we have functions for that. [13:57:14.0984] If the things we want to use with `a[@x]` shouldn't be used with `a[x]`, then we have two mutually exclusive syntaxes that arguably do the same thing depending on their inputs. [13:57:43.0472] And that doesn't seem like a valuable use of our syntactic budget if we could merge them into just `a[x]`/ [13:57:45.0643] * And that doesn't seem like a valuable use of our syntactic budget if we could merge them into just `a[x]`. [13:58:01.0518] robustness of existing syntax > > > preserving syntax budget [13:58:08.0427] * imo robustness of existing syntax > > > preserving syntax budget [13:58:16.0871] rbuckton: `a[b]` delegating to a symbol is just *not* going to happen [13:58:28.0925] `a[x]` isn't robust, its wasteful [13:58:40.0551] lol what's wasteful about it as-is? [13:58:45.0844] (other than that getters exist) [13:58:55.0662] engines will not let that *highly-optimised*, *extremely common* operation become slow [13:59:15.0427] That you can't use non-string, non-symbol values as keys withing them being stringified. [13:59:55.0295] > <@michaelficarra:matrix.org> engines will not let that *highly-optimised*, *extremely common* operation become slow They would be deoptimized in the same way for `a[{}]` today, since they already have to patch in a call to `Symbol.toPrimitive`. [13:59:57.0070] they may all be done by then 💪 [14:00:26.0819] So I don't imagine it would affect performance at all in the common case. [14:00:38.0013] only if anyone anywhere has ever touched `Symbol.toPrimitive`, which they usually haven't [14:01:03.0334] > <@michaelficarra:matrix.org> only if anyone anywhere has ever touched `Symbol.toPrimitive`, which they usually haven't There is plenty of code in the wild that is just depending on `.toString()` for the same thing [14:01:39.0216] I'm using `Symbol.toPrimitive` as a general placeholder for all the things `ToPropertyKey` does for Object values [14:01:44.0122] 🤷‍♂️ well it'll be up to you to convince engines of that then [14:11:27.0249] To be clear, I haven't proposed `geti` because I think there are better solutions, though I do think `geti` has some interesting value on its own (i.e., using a `WeakMap` into a reified pseudo-private name). In general I'd love to be able to hook `a[x]` for custom collections, even if that were limited to only numeric string indexes as they are interpreted by Array and _TypedArray_, though that limitation wouldn't solve the same case as `geti`. In lieu of `geti`/`seti`/etc., I'd be happy with a reified `Slice` and `Index` object that had specific, explicit handling by property evaluation to call a `Symbol.slice`/`Symbol.splice` or `Symbol.indexGet`/`Symbol.indexSet` on the object, such that `x:y` could produce a `new Slice(x, y)` and `^x` could produce a `new Index(x, /*fromEnd*/ true)`. Having reified slices and indexes is extremely convenient as they have a data model that can be interrogated and can thus be composed and reused in user code. [14:15:13.0739] rbuckton: I encourage you to participate in the Iterator.range issue tracker [14:18:30.0481] > <@michaelficarra:matrix.org> rbuckton: I encourage you to participate in the Iterator.range issue tracker How does this apply to `Iterator.range`? Do you have a particular issue this applies to? Ranges and slices are subtly different. I think I did bring up reified slices when `Iterator.range` was proposed, but I haven't had much time to follow the range proposal since then. [14:18:48.0901] reified ranges seem just as unjavascripty to me as reified slices [14:19:06.0714] rbuckton: I don't see how they are different [14:19:11.0375] It's very pythony, and python and JS share many similarities. [14:19:23.0388] string enums are nice until a change results in garbage like step 24 in https://tc39.es/ecma402/#sec-initializenumberformat [14:21:09.0574] > <@michaelficarra:matrix.org> rbuckton: I don't see how they are different Ranges produce values, slices represent ordinal positions from which to read and write chunks. There is a lot of similarity, but a Range that produces values can't really have a meaningful notion of "3 elements from the end" [14:21:26.0278] Hence why I said they are subtly different [14:21:55.0831] I hadn't considered that a reified slice would try to represent relative indexing [14:22:06.0916] That was in the slides. [14:22:12.0704] `x:^y` [14:22:26.0745] lol sure, there was a lot of things in the slides [14:23:21.0012] The slice syntax is essentially `expr:expr`, so `0:1` or `x:y`. If you want to represent `.slice(0, -1)`, you use `x:^y` [14:24:06.0188] Mostly to avoid the disparity with `a[-1]`, and to align with `a[^1]`. It also keeps them visually similar: [14:24:34.0719] * Mostly to avoid the disparity with `a[-1]`, and to align with `a[^1]`. It also keeps them visually similar: ``` a[0:^1] a[0] a[^1] ``` [14:25:33.0681] Thus, a `Slice(x, y)` is actually a pair of Index objects. `x:^y` would be reified as `new Slice(new Index(x, false), new Index(y, true))`. At least, that's how it works in C#. [14:26:34.0164] Refication of index/range are good I believe, the problem is we never have such things in js, all js current methods are just calculate eaglely, for example, this is how resizeable typedarray deal with negative index. [14:27:30.0839] That also ensures the types are consistent and the object model is more user friendly if you want to do something like: ``` const x = foo ? 0 : ^1; const s = x:^y; s.start; // an Index, no need to do a typeof test s.end; // also an Index ``` [14:27:57.0802] Another problem, if there will be index/range I will really hope they are new primitive types. But it seems very impossible as current status. [14:28:15.0686] > <@haxjs:matrix.org> Refication of index/range are good I believe, the problem is we never have such things in js, all js current methods are just calculate eaglely, for example, this is how resizeable typedarray deal with negative index. I could see a reified slice of `x:y`, and a reified range like `x..y` as two distinct things. [14:28:43.0994] > <@haxjs:matrix.org> Another problem, if there will be index/range I will really hope they are new primitive types. But it seems very impossible as current status. Primitives aren't really necessary for this. Regular expression literals produce Objects [14:29:19.0228] Though `==` and `!==` might be nice, most other operators don't apply to slices and indexes. [14:29:57.0777] You can't really compare `^0` and `^1` using `<` or `>` as they may point to the same element if the array only has a single element. [14:30:58.0518] > <@rbuckton:matrix.org> Primitives aren't really necessary for this. Regular expression literals produce Objects yeah. of coz we can always use object. [14:31:30.0906] Also, `range` might accept floats, while a slice should only accept `number/bigint/Index` (and not coerce) [14:32:10.0560] Also, a slice of `x:y` could theoretically hold a non-primitive, so it can't be a primitive. [14:32:59.0340] does this not fall under the "don't coerce objects to primitives"? [14:33:53.0542] > <@michaelficarra:matrix.org> does this not fall under the "don't coerce objects to primitives"? Are you asking me, regarding Slice/Index, or something else? [14:34:12.0822] no, I'm talking about the coercion slides [14:34:24.0013] null -> some primitive [14:35:44.0000] * Also, `range` might accept floats, while a slice should only accept `number/bigint` integral values and `Index` and not coerce [14:36:05.0244] * Also, `range` might accept floats, while a slice should only accept integral `number` values, `bigint`, and `Index`, and not coerce [14:36:10.0009] these tables are soooooo helpful [14:53:27.0429] "you haveundefined notifications to review" [14:53:32.0604] (or NaN) [14:55:47.0745] IIRC, the value for Numbers and BigInts taking strings makes sense given the DOM return value rationale [14:56:06.0230] * IMO, the value for Numbers and BigInts taking strings makes sense given the DOM return value rationale [14:58:53.0132] yeah numeric strings are all over the place in the DOM, and JS kinda has to work nicely with the DOM or people will get mad [14:59:36.0816] > <@rbuckton:matrix.org> "you haveundefined notifications to review" Hopefully in an Intl.MessageFormat world, that message would read: ``` you have {$count} notifications to review ``` [15:00:24.0080] > <@eemeli:mozilla.org> Hopefully in an Intl.MessageFormat world, that message would read: > ``` > you have {$count} notifications to review > ``` In an ideal world, yeah maybe. In the current world, messages like that are so commonplace they're a meme [15:09:12.0236] > <@rbuckton:matrix.org> As a counterpoint to `a[@x]` or whatever. if `x` is a reified slice, I would want a way to _explicitly_ throw when it is used via `a[x]`, since that would be a mistake. just make the Symbol.toPrimitive method on the Slice class throw? [15:09:20.0725] that seems fairly straightforward to me, not really a counterpoint [15:09:41.0576] but, I also don't see why it would be a mistake? [15:09:55.0738] like if the class knows how to handle slices, like Array, then it would just give you the slice [15:10:10.0738] from its `Symbol.get` method [15:11:02.0484] > <@bakkot:matrix.org> but, I also don't see why it would be a mistake? If `Slice` needs to be used with `a[@x]`, then using it with `a[x]` is 100% a bug. [15:13:05.0977] oh, sorry, I misread [15:13:18.0312] yes, using with `a[x]` is a bug, and would be covered by having slice's `Symbol.toPrimitive` throw [15:13:24.0002] > <@bakkot:matrix.org> just make the Symbol.toPrimitive method on the Slice class throw? Yes, that's what I'm getting at. This message leads into the point I was trying to make in the subsequent message. What you use in `a[x]` and what you would use in `a[@x]` would be mutually exclusive to avoid bugs. If they are mutually exclusive, then just having `a[x]` do both would avoid the concern about trying to pick the right one to avoid a bug. [15:13:49.0079] ah, well, they would not be totally mutually exclusive [15:13:59.0532] because Array could have `a[^-1]` do negative indexing [15:14:04.0259] > <@bakkot:matrix.org> ah, well, they would not be totally mutually exclusive They should be. [15:14:07.0558] they would be mutually exclusive for object types though, yes [15:14:19.0323] * because Array could have `a[@-1]` do negative indexing [15:14:35.0789] why? if I do `map[@"string"]`, that can do a map lookup [15:14:37.0751] > <@bakkot:matrix.org> because Array could have `a[@-1]` do negative indexing And `a[-1]` would not, thus its still a potential bug [15:14:59.0234] Well, yes, `a[-1]` would be a bug but in general passing things to the wrong place is a bug [15:15:23.0196] > <@bakkot:matrix.org> why? if I do `map[@"string"]`, that can do a map lookup Because its too easy to write `map["string"]` and it mean something different. [15:15:46.0180] If that's true it applies to any special syntax for indexing a map. I don't agree. [15:16:01.0454] I'm not advocating for indexing a map using `[]`. [15:16:07.0949] Right, but I am [15:16:37.0017] and above you were advocating for a way to index collection types by non-string values; Map seems like the obvious collection type you'd most want to index by non-string values [15:17:10.0585] I'm advocating for doing something meaningful with objects in `a[x]` aside from just ToString(). [15:18:13.0919] What problems does that solve? [15:20:08.0801] My suggestion is, introduce a new `obj[@x]` syntax which invokes a symbol-named method on `obj` with `x`, and also `obj[@x] = y` which invokes a symbol-named method on `obj` with `x` and `y`, which solves - you can do negative indexing on arrays - you can _assign_ at negative indexes on arrays - if we have a `slice` type, you can slice arrays with syntax - you can do Map read/writes with syntax - other collection types can defining indexing behavior for non-string values so it gives you a lot of stuff! [15:20:20.0973] It solves reified `Slice`, reified `Index`, `WeakMap` as a scoped private name, plus a number of other approaches such as a "pick" object, i.e.: ```js const obj = { x: 1, y: 2, z: 3, w: 4 }; const obj2 = obj[new Pick("x", "y", "z")]; obj2; // { x: 1, y: 2, z: 3 } ``` [15:21:22.0787] Your suggestion only solves reified `Index` if either there is also an "indexing" protocol collection types can opt into, or the `Index` type knows about every single kind of collection [15:21:26.0726] I was also considering `geti` as an approach to handling concurrent reads/writes in multithreaded javascript with Worker and shared structs, though I'm also looking into `.{` notation as a solution [15:21:51.0205] Ditto `pick`, etc [15:21:54.0820] Yes, I expected there would also be an indexing protocol, just like slice notation added a slice protocol. [15:21:55.0923] and `slice` [15:22:02.0568] Pick, not so much. [15:22:12.0813] Slice depends on knowing something about the size of a collection. Pick does not. [15:22:45.0125] OK, so, my proposal does not require having an indexing protocol, or a slice protocol. If there is a `slice` type, and a `pick` type, then collections can define for themselves what to do when asked to "slice" or "pick" something. That seems better. [15:22:57.0172] * OK, so, my proposal does not require having an indexing protocol, or a slice protocol. If there is a `slice` type, and a `pick` type, then collections can define for themselves what to do when asked to "slice" or "pick" something, without needing a protocol. That seems better. [15:23:13.0997] I don't agree that it's better. [15:23:46.0007] Slice and index-from-end have a well-defined protocol that multiple different objects could implement. [15:24:30.0182] The way I am suggesting they implement that is, they define a `Symbol.get` method which has specific behavior for the reified `slice` values. [15:24:42.0056] If I have a `Slice` and use it on an array via `a[@x]`, I get a slice. If I used it on a Map via `a[@x]`, it might just act as a key, thus it's not interpreted as a slice. That means that `a[@x:y]` would do something strange on a Map. [15:25:37.0892] Yes, if you use a key with a type of collection which does not know how to interpret that key, you're going to have a bad time. But this is also true in your inverted world if you use a key with a type of collection where the key does not know how to interpret that type of collection. [15:26:26.0918] Ignoring the `@` for a second, `a[x:y]` and `a[^x]` should always be interpreted as "take a slice from `a`" and "get the element from `a` relative from its end". [15:27:24.0000] > <@bakkot:matrix.org> Yes, if you use a key with a type of collection which does not know how to interpret that key, you're going to have a bad time. But this is also true in your inverted world if you use a key with a type of collection where the key does not know how to interpret that type of collection. That's why I'm not proposing a general indexing hook. I'm proposing a very specific indexing hook. [15:28:12.0494] > <@rbuckton:matrix.org> Ignoring the `@` for a second, `a[x:y]` and `a[^x]` should always be interpreted as "take a slice from `a`" and "get the element from `a` relative from its end". I am proposing not to have either `a[x:y]` or negative-indexing `a[^x]`. I think that having only a general `a[@x]` hook would solve the use cases for both `a[x:y]` and `a[^x]`. [15:28:52.0957] With `geti`, `Slice` has a very specific and well-defined interaction with something like `Array`: ```js Slice.prototype[Symbol.geti] = function (value) { return value[Symbol.slice](this.start.getIndex(value), this.end.getIndex(value)); } Array.prototype[Symbol.slice] = function (start, end) { return this.slice(start, end); } ``` [15:30:56.0313] The same goes for `Index`: ```js Index.prototype[Symbol.geti] = function (value) { return value[Symbol.indexGet](this.getIndex(value)); } Array.prototype[Symbol.indexGet] = function (index) { return this[index]; } ``` [15:31:03.0179] (or something to that effect) [15:31:36.0107] With my proposal also: `Array.prototype[Symbol.get] = function(v) { if (Slice.isSlice(v)) return this.slice(v.start, v.end); /*...*/ }` [15:31:50.0065] And it only requires a single protocol, not two. [15:33:01.0310] But a `WeakMap` could do: ```js WeakMap.prototype[Symbol.geti] = function (value) { return this.get(value); } ``` and a `Pick` might look like: ```js class Pick { keys; constructor(...keys) { this.keys = keys; } [Symbol.geti](value) { var obj = {}; for (var p of Reflect.ownKeys(value)) { if (this.keys.includes(p)) obj[p] = value; } return obj; } } ``` [15:34:18.0294] (I really do not think it makes sense for keys to define how they interact with collections, rather than collections defining how they interact with keys.) [15:34:25.0394] > <@bakkot:matrix.org> With my proposal also: `Array.prototype[Symbol.get] = function(v) { if (Slice.isSlice(v)) return this.slice(v.start, v.end); /*...*/ }` That doesn't solve `a[@x:y]` potentially not returning a Slice and maybe doing something else instead of erroring in the case of a `Map`. [15:35:49.0776] I am specifically not proposing to have `a[@x:y]` syntax [15:35:51.0712] > <@bakkot:matrix.org> (I really do not think it makes sense for keys to define how they interact with collections, rather than collections defining how they interact with keys.) I would much rather be able to hook indexing, but not at the cost of the cognitive overhead of picking the correct indexing operator or introducing subtle bugs. [15:36:30.0823] But yes, if you have a reified slice type, and you try to index a map by that, the appropriate behavior is to look up the slice instance in the map. That's how maps work. [15:37:11.0790] And as I said, I'd be happy to have `Slice` and `Index` have special handling in indexers even without the symbols. That's what C# does. I just feel that `geti` adds a bit more flexibility. [15:37:43.0288] But I don't think leveraging a general indexing hook to handle `Slice` and `Index` is a good idea. [15:38:33.0922] > <@bakkot:matrix.org> But yes, if you have a reified slice type, and you try to index a map by that, the appropriate behavior is to look up the slice instance in the map. That's how maps work. No. The appropriate behavior for `a[x:y]` (or `a[@x:y]`) on a Map that doesn't undertand how to handle a slice should be to throw. Not silently do the wrong thing. [15:42:15.0477] Or if you expect `a[@x:y]` to just be a generalized map, then I'd still strongly prefer we have specific handling for `a[x:y]` and `a[^x]`, such that slicing with the correct syntax is _always_ slicing, and that `a[@x]` just doesn't care at all what you put into it. Documentation that describes slicing with syntax should always refer to `a[x:y]`, and it should never be recommended that you abuse something like `Symbol.get`/`a[@x]` to handle slicing. It's just a bug farm and a source of confusion. [15:42:26.0648] * Or if you expect `a[@x:y]` to just be a generalized map indexer, then I'd still strongly prefer we have specific handling for `a[x:y]` and `a[^x]`, such that slicing with the correct syntax is _always_ slicing, and that `a[@x]` just doesn't care at all what you put into it. Documentation that describes slicing with syntax should always refer to `a[x:y]`, and it should never be recommended that you abuse something like `Symbol.get`/`a[@x]` to handle slicing. It's just a bug farm and a source of confusion. [15:47:31.0606] C# lets you write `map[0..1]` as a key, but C# is typed and thus you know that the input/output is the key type. JS isn't typed, so its far easier to do the wrong thing. [15:47:50.0157] * C# lets you write `map[0..1]` as a key, but C# is typed and thus you know that the input/output is for the key type. JS isn't typed, so its far easier to do the wrong thing. [15:48:03.0277] * C# lets you write `map[0..1]` as a key, but C# is typed and thus you know that the input/output is when indexing using the key type. JS isn't typed, so its far easier to do the wrong thing. [15:56:37.0764] As an aside, I'm not sure what symbol you would want to use for `a[@b]`? Uou can't use `@` because of decorators, and I'd prefer to keep `^x` for reified relative index if possible, so it either has to be an infix operator, or a prefix operator that comes before the `[`. I'd like to avoid using `&` and `*` due to both their precedence as use for pointers in other C-like languages, and that I'd really like to use `&` for the ref proposal if a `ref` keyword ends up not being feasible (since `ref` has a close enough similarity to pointers that the semantic meaning seems reasonable). [15:56:47.0134] * As an aside, I'm not sure what symbol you would want to use for `a[@b]`? You can't use `@` because of decorators, and I'd prefer to keep `^x` for reified relative index if possible, so it either has to be an infix operator, or a prefix operator that comes before the `[`. I'd like to avoid using `&` and `*` due to both their precedence as use for pointers in other C-like languages, and that I'd really like to use `&` for the ref proposal if a `ref` keyword ends up not being feasible (since `ref` has a close enough similarity to pointers that the semantic meaning seems reasonable). [15:57:07.0243] * As an aside, I'm not sure what symbol you would want to use for `a[@b]`? You can't use `@` because of decorators, and I'd prefer to keep `^x` for reified relative index if possible, so it either has to be an infix operator, or a prefix operator that comes before the `[`. I'd like to avoid using `&` and `*` due to both their precedence for use with pointers in other C-like languages, and that I'd really like to use `&` for the ref proposal if a `ref` keyword ends up not being feasible (since `ref` has a close enough similarity to pointers that the semantic meaning seems reasonable). [15:58:53.0567] `%` may be out as well. We'd considered it for pipeline, but IIRC `%` is hard to type on a number of international keyboard layouts. 2023-11-30 [16:01:10.0763] I've considered using an infix `~` as an indicator for partial application, i.e. `obj.method~(a, ?)`, so `obj~[key]` might be reasonable. Thin-arrow is possible as well (i.e., `obj->[key]`), though that sequence of tokens get's in to "`obj.get` is easier to write" territory [16:07:20.0754] * I've considered using an infix `~` as an indicator for partial application, i.e. `obj.method~(a, ?)`, so `obj~[key]` might be reasonable. Thin-arrow is possible as well (i.e., `obj->[key]`), though that sequence of tokens get's into "`obj.get` is easier to write" territory [16:07:39.0533] * `%` may be out as well. We'd considered it for the topic variable in pipeline, but IIRC `%` is hard to type on a number of international keyboard layouts. [16:08:45.0357] We at Agoric are also hoping to use `remote~.method()` for async method invocation on a promise/placeholder for a remote object, `remoteFunction~()` for async function application, and `promise~.propertyName` for async get. [16:09:41.0304] (On the mnemonic that `~` resembles a stream and each of these would be used to stream operations to remote objects.) [16:10:06.0103] If `f~()` gets used for that, then I don't think there's any syntax that would ever work for partial application. [16:11:03.0440] If you used`f~.()` it would be consistent with `f?.()` at least, though I imagine `f~.~()` would end up being a bridge too far. [16:13:22.0033] I still hold out hope for partial application, which is why I haven't withdrawn it, but where I left it one of the things it needed was a prefix token for the argument list. For a number of reasons I've discussed on the issue tracker, the token can't come *before* the method/function name since it has the wrong precedence for binding, and for partial application to be practically useful it can't have an arduous syntax. [16:14:48.0936] One of the things that the original `f(?)` syntax for partial app lacked was the ability to indicate a partial 0-arity invocation, i.e. `obj.method()` isn't partial, and there's no way to defer its invocation, while `object.method~()` allows for 0-arity partial application. [16:16:47.0945] The other upshot of using `~.` for async invocation, is that you're not limited to `~` as there are a number of other symbols that are currently illegal before `.` in that position. [16:21:14.0634] This is also why I'm not a fan of using up our syntax budget on `a[@x]` when we primarily want to support a narrow case for a small set of objects (`Slice`, `Index`, maybe `WeakMap` or a set of user-defined objects like `Pick`, etc.) that could easily be accomplished with `a[x]`. [16:23:40.0002] Whatever we used for that would impact what's available for future proposals. i.e., any symbol in the place of `@` in `a[@x]` means that symbol can never be used in a prefix position of an AssignmentExpression. A symbol before `[` doesn't have that issue, but we have an even smaller number of symbols we can legally put before `[` and still have it be somewhat ergonomic to type. [16:27:04.0244] I'd love to be able to hook `a[x]` for _numeric_ indexes, since that also gives us a way to make things like Array and TypedArray into regular objects instead of exotic objects. It also opens the door for user-defined numeric-indexed collection classes that work like `Array`, which can only be implemented via a `Proxy` today. [20:23:13.0880] > <@rbuckton:matrix.org> And that doesn't seem like a valuable use of our syntactic budget if we could merge them into just `a[x]`. but by merging it into `a[x]`, now all `a[x]` require 2 Get call instead of 1, that will be a huge performance cliff [20:28:48.0755] > <@haxjs:matrix.org> Another problem, if there will be index/range I will really hope they are new primitive types. But it seems very impossible as current status. I don't know if you can take the Decimal way here. preserving the possibility of adding new primitive types and add them as an object for now [03:52:45.0175] > <@kriskowal:matrix.org> We at Agoric are also hoping to use `remote~.method()` for async method invocation on a promise/placeholder for a remote object, `remoteFunction~()` for async function application, and `promise~.propertyName` for async get. I'd like to update Extension proposal in recent future meetings, one use case in the original proposal is to support eventual send with Extension syntax, in the original draft, it is `promise::Eventual:method()` and `promise::Eventual:propertyName`. I think the old eventual send proposal do not have `remoteFunction()` feature, is it ok to use `remoteFunction::Eventual:call()` for that? (note, I plan to change `::` and `:` delimiters, but I assume it should not the big issue for this case) [08:54:41.0151] i feel like some things should remain as DSLs [09:06:28.0060] or, in a versatile enough language, just libraries [10:12:00.0524] I agree with Chris. It's much harder to validate tests without also writing an implementation. I'm wondering if it makes more sense to split the "implementation" part into two parts: the development/validation of the feature internally or flagged, and _shipping_ the implementation unflagged. [10:12:26.0427] Or I think I agree. I agree with the topic text at least, heh. [10:17:48.0325] I like the names [10:18:17.0227] (but keeping the numbers too sgtm) [10:19:05.0916] i def like re-adding names. but numbers should remain the primary thing [10:19:13.0160] the reason for adding names is because they help explain what we're talking about. The new names are much much better than the old names, hence the change vs previously [10:19:41.0133] (I have no opinion on what should be "primary"; maybe we should just start with not primary) [10:19:51.0080] * (I have no opinion on what should be "primary"; maybe we should just start with not changing) [10:20:07.0914] well, i just mean, the numbers should never be absent from our communication about the stages; i don't care if the names are present also or not [10:20:15.0866] * well, i just mean, the numbers should never be absent from our communication about the stages; i don't care if the names are present also or not in every such communication [10:20:23.0159] Stages: 1, 2, 2-3 transitional validation, 3, 4 [10:20:31.0243] (we also don't need to renumber; there's infinite numbers between 2 and 3) [10:20:55.0754] I hope we can avoid this bike shedding debate blocking us from making the more meaningful process change that Michael proposed [10:21:10.0357] Stage numbers don't need to be integral or floating-point [10:21:10.0520] your optimism is refreshing [10:21:36.0555] +<3 for whimsy [10:21:49.0697] I am anti-whimsey [10:22:10.0466] introducing the new stage with `2.5` is: - the path of least resistance - avoids bikeshedding - is unambiguous - does not prevent iterating on this more in the future (names, different schemes) [10:22:35.0863] I prefer 2 3/4 or 2.75 because it expresses that it's closer to 3 [10:22:42.0391] whimsy is great for audiences in the know, usually falls flat and ends up being a barrier in external communication [10:22:42.0879] I really like having the "External Communication" definition in the document, even if we don't use them as names or vocally. It's the best way of concisely explaining things to a wide audience. [10:24:46.0800] Moving from Stage e to 3 should require consensus *on the question of whether the tests are sufficiently done*; it'd be sort of inappropriate to reject Stage 3 because you didn't like the design in the first place [10:25:24.0438] oh sure if there's implementation experience at that point, then that'd be a good reason to hold back Stage 3 [10:25:32.0668] * oh sure if there's implementation experience at that point, requiring changes, then that'd be a good reason to hold back Stage 3 [10:30:18.0960] One way to keep the integer numbers would be to shift the lower end down, so random ideas are at stage -1, they're first accepted at stage 0, need spec text for stage 1, and this new stage would be stage 2. [10:31:03.0247] that'll cause a lot of confusion for existing data all over the internet [10:31:46.0758] But less than shifting the other end up a step. [10:32:57.0611] i think that disruption isn't worth keeping integers, personally [10:33:01.0752] * i think that any disruption isn't worth keeping integers, personally [10:33:10.0723] * i think that any such disruption isn't worth keeping integers, personally [10:34:01.0220] i feel like we have several questions happening at once here [10:34:08.0047] the first is "what stages do we want to have" [10:34:15.0099] and only once we answer that can we talk about how to label them [10:35:07.0021] it seems like the stages as described are already what we want, we're just confirming the wording [10:35:13.0946] imo, a clean break switching away from numbers to names is far preferrable to shifting stage numbers around. [10:36:13.0550] and a clean break is problematic for reasons i've described, so picking a noninteger number is what's left [10:37:00.0792] Chris de Almeida: numbers and names landed together with the post-ES6 process iirc, and i think we moved away from the names a few years back because nobody, internally or externally, was using them anyways [10:39:00.0350] yes, thanks for the correction -- I misremembered partially; trying to dig up the reasoning, but there was i18n aspect IIRC [10:39:43.0407] 10,20,30, with 10.20, 30.20, etc. is no different thatn 1,1.2,3.2, etc [10:40:01.0542] but I guess they have thing's like .93 in there [10:40:06.0344] * but I guess they have things like .93 in there [10:40:13.0872] Again, we don't need to use integral or real numbers at all. The new stage could just be something like `2-3-validation` or something, or rename stages like: 0, 1, 2.approved, 2.validated, 3, 4 [10:40:45.0600] Stages 2.a, 2.v (or 2.b) [10:41:10.0436] since a/b/v/etc. don't imply a closeness or distance from 2 or 3 [10:42:09.0439] Or just do stages 0, 1, 2, 2+tests, 3, 4, or something. [10:42:28.0160] or "pre-3" [10:42:30.0621] I guess the whole question of "can we migrate community understanding" was answered once by turning ESx -> ESxxxx digits eight years ago. I'd estimate that took two years to achieve widespread understanding. So Stage x -> Stage xx would probably be accepted in a similar timeframe. [10:43:37.0724] Actually, "pre-3" doesn't seem too bad to me? [10:43:54.0649] having "3" in it seems very bad to me [10:44:04.0369] * having "3" in it seems very bad to me, as we discussed last plenary [10:44:15.0512] if it has "3" in it people will treat it as safe to use [10:44:24.0834] Except it's "pre-", its even semver-ish. [10:44:50.0798] > <@robpalme:matrix.org> I guess the whole question of "can we migrate community understanding" was answered once by turning ESx -> ESxxxx digits eight years ago. I'd estimate that took two years to achieve widespread understanding. So Stage x -> Stage xx would probably be accepted in a similar timeframe. that took longer than 2 years, and also was because we were making yearly editions which was a huge change. and, people *still* refer to things by edition number [10:45:00.0557] stage "almost-3-but-do-not-use-or-you-will-be-fired" /s [10:45:20.0101] > <@rbuckton:matrix.org> Except it's "pre-", its even semver-ish. that's what michael was advocating too, but i don't think that's enough. i think if "3" is in the name, no qualifier will be sufficient to remove the implication that it's stage 3 [10:45:38.0045] > <@robpalme:matrix.org> I guess the whole question of "can we migrate community understanding" was answered once by turning ESx -> ESxxxx digits eight years ago. I'd estimate that took two years to achieve widespread understanding. So Stage x -> Stage xx would probably be accepted in a similar timeframe. * that took longer than 2 years, and also was because we were making yearly editions which was a huge change. and, people _still_ refer to things by edition number (eslint still supports edition numbers in its config for ecmaVersion, even) [10:45:42.0492] https://github.com/tc39/notes/blob/df1449925841bc77574e8e127611234670275575/meetings/2021-07/july-14.md#renaming-strawperson-to-concept-or-something-better [10:46:15.0284] this is the discussion that led to the removal of stage names [10:46:38.0281] This new stage has the same entrance criteria that 3 did, so "pre-3" makes sense to me. "post-2" feels a bit odd to me, though. [10:46:55.0370] notably, the discussion actually began with trying to name a stage -- and that led to removal of the names entirely [10:49:06.0080] 0,1,2,name,3,4 works too, it'll just inevitably become referred to as "2.5" or similar, and then that's what it'll be called. [10:49:15.0297] * 0,1,2,name,3,4 works too, it'll just inevitably become referred to as "2.5" or similar, and then that's what it'll be called. if we don't pick a number, a number will be picked for us. [10:49:29.0465] `unproposed` (old 0), `exploring` (old 1), `draft` (old 2), `validation` (new), `candidate` (old 3), `adopted` [10:50:23.0633] Stage 2e1 [10:50:30.0235] (that's a literal number) [10:50:33.0849] didn't we talk about `e` last time? [10:51:08.0188] > <@ljharb:matrix.org> 0,1,2,name,3,4 works too, it'll just inevitably become referred to as "2.5" or similar, and then that's what it'll be called. if we don't pick a number, a number will be picked for us. Well that's a way to solve the consensus problem [10:51:47.0319] I don't know that people will pay enough attention for that to actually come up [10:52:10.0336] like if it's "2" and "test development" and "3", not a lot of people are going to get that excited about moving to phase "test development", even though it is in reality a big milestone [10:52:12.0558] there are a lot of podcasters and blog posters and twitter tech influencers that pay attention to it [10:52:34.0956] * there are a lot of podcasters and blog posters and twitter tech influencers that pay attention to stage progression (whether it's actually valuable for them to care or not) [10:52:44.0493] I guess I don't care that much about what name those people use [10:53:43.0715] we could also do `2.9` so that "just before 3" is strongly implied [10:53:49.0982] * we could also do `2.9` so that "just before 3" is strongly implied, and then there's no confusion with "e" [10:53:58.0693] `2.testing` (why not both?) [10:54:16.0071] I love the bingo call-out lol [10:54:25.0282] 2-bis [10:54:36.0381] "2" and "2v" sgtm [10:54:50.0919] 2+ [10:55:11.0138] Christian Ulbrich: in new tcq can you make sure there's a way to rewind, so previous queue items aren't deleted? :-) [10:55:15.0899] * Christian Ulbrich: in new tcq can you make sure there's a way to rewind, so previous queue items aren't lost? :-) [10:55:26.0812] * Christian Ulbrich: in new tcq can you make sure there's a way to rewind, so previous/accidentally advanced queue items aren't lost? :-) [10:57:26.0675] What we want is to move the testing portion into stage 2, but allow the champion to have consensus on the specification text without rehashing old discussions when getting approval for tests. 2a/2b makes sense for me since as far as the community is concerned, they both still imply 2 [10:57:57.0891] msaboff: you think users can handle renumbering existing stages, but not a non-integer number? [10:58:16.0596] > <@rbuckton:matrix.org> What we want is to move the testing portion into stage 2, but allow the champion to have consensus on the specification text without rehashing old discussions when getting approval for tests. 2a/2b makes sense for me since as far as the community is concerned, they both still imply 2 the difference is that design can change radically in stage 2, but can NOT change radically in the new stage [10:58:17.0812] TCQ really just needs polling instead of abusing temperature checks [10:58:49.0699] > <@ljharb:matrix.org> the difference is that design can change radically in stage 2, but can NOT change radically in the new stage Yes, but if test acceptance is mostly pro-forma, a proposal shouldn't be in 2b for very long. [10:59:03.0484] 2 hours free today to talk about consensus :) [10:59:20.0016] > <@rbuckton:matrix.org> Yes, but if test acceptance is mostly pro-forma, a proposal shouldn't be in 2b for very long. if we'd had it years ago, temporal would have stayed in it for 3-4 years now [10:59:41.0482] but certainly most proposals shouldn't stay in the new stage very long [10:59:46.0915] * but certainly most proposals shouldn't stay in the new stage very long. some will tho. [10:59:48.0795] > <@rbuckton:matrix.org> TCQ really just needs polling instead of abusing temperature checks specifically approval voting, it needs approval voting [11:01:32.0523] nicolo-ribaudo: you are right, and we don't even need avote: the chairs can just dictate this [11:01:55.0808] ehhh i think things that involve external communication outside the committee do require consensus [11:02:44.0252] In general, I'd be fine with just needing tests to advance to Stage 3, if that's the crux of what we want, but I'm uncomfortable with demoting proposals that advanced prior to this change. [11:03:21.0810] it's important to have a step between "design is mostly final" and "tests are required", that's the whole point of this effort [11:03:30.0361] Informally, a champion could get consensus on the specification text without advancement, write the tests at the end, then ask for advancement in the following meeting. [11:04:16.0108] Or ask for conditional advancement pending the addition of tests, with a pro-forma ratification of advancement when tests are complete. [11:04:33.0879] * Or ask for conditional advancement pending the addition of tests, with a (mostly) pro-forma ratification of advancement when tests are complete. [11:06:46.0581] yeah ordinary members vote at GA, all members vote at TCs [11:06:58.0030] > Voting on any matter shall be by simple majority of Ecma TC members. Each Ecma member has only one vote. [11:07:01.0123] per https://ecma-international.org/policies/rules/ [11:07:11.0078] Istvan clarifies in Meet that it would be 50% majority though [11:07:26.0321] yeah it's per member and simple majority [11:08:17.0357] fwiw I would be fine with _literally any process by which we can reach a decision_, even if the decision reached is one I don't like [11:08:42.0760] If we added polling, we could just indicate it is non-binding. What I was suggesting was just a better way to do what we've been abusing temp checks for. it's still essentially a temperature check [11:08:51.0676] RCV would be nice too :-) [11:09:12.0716] RCV is dangerously broken, approval all the way [11:09:52.0755] O.o i'd love to hear more about that; RCV seems like the best approach to me by a large margin for any voting [11:10:05.0628] * O.o i'd love to hear more about that; RCV seems like the best approach to me by a large margin for any voting (like, hear about it in general, not just as it applies to tc39) [11:11:15.0450] yes I prefer to go with a temperature check [11:11:33.0560] Temp check on whether to do a temp check? [11:11:52.0070] i've never heard a strong argument against RCV so i am also interested [11:12:24.0068] my topic was skipped? [11:12:30.0877] I don't think there are any Ecma rules about how we do a temperature check, right? [11:12:36.0900] * my reply was skipped? [11:14:06.0357] +1 to rbuckton 's point [11:14:32.0526] the temperature check was designed this way deliberately, because some people were extremely opposed to non-binding polling. It sounds like that opposition has fallen away [11:16:21.0112] reminder that we only have 15min left [11:16:29.0723] Temperature check scale is asymmetric, so it matters how whatever the question is, is phrased. [11:16:48.0521] "Temperature Check" is designed to ask the committee's impression about a single topic. i.e., if we were to do this via temperature check, it would be a series of questions: - Preference for E: - Preference for 2.7 - Preference for 2.a: etc. Saying "smiley means E" is just an abuse of the temperature check to do polling. [11:16:54.0476] * "Temperature Check" is designed to ask the committee's impression about a single topic. i.e., if we were to do this via temperature check, it would be a series of questions: - Preference for E: \ - Preference for 2.7 \ - Preference for 2.a: \ etc. Saying "smiley means E" is just an abuse of the temperature check to do polling. [11:17:19.0414] > <@rbuckton:matrix.org> "Temperature Check" is designed to ask the committee's impression about a single topic. i.e., if we were to do this via temperature check, it would be a series of questions: > > - Preference for E: \ > - Preference for 2.7 \ > - Preference for 2.a: \ > etc. > > Saying "smiley means E" is just an abuse of the temperature check to do polling. Yeah true, I want to be able to say what I do not like other than what I like [11:17:38.0511] If we're going to have polling/voting/etc., it makes sense to add that to TCQ [11:18:30.0948] > <@nicolo-ribaudo:matrix.org> Yeah true, I want to be able to say what I do not like other than what I like There's no reason we couldn't have a multi-topic temperature check as a form of polling. It would give participants an overview of the full scope of what's being considered. [11:18:49.0833] i guess some people like STAR [11:18:56.0312] we've used what is basically non-binding RCV in Temporal champions meetings as a way to get a quick picture of the position of the group [11:19:09.0177] I think temp check on what we don't like would be useful [11:19:14.0853] +1 to "general consensus" (definition tbd) [11:19:29.0592] this is the typical Ecma/standard best practice [11:23:30.0468] oh jeeze this is a large topic but the big obvious one is that it fails monotonicity, which means you can make someone lose off by ranking them higher [11:23:36.0382] * oh jeeze this is a large topic but the big obvious one is that it fails monotonicity, which means you can make someone lose by ranking them higher [11:25:04.0814] wait what are we voting on? [11:25:12.0349] https://electionscience.org/voting-methods/runoff-election-the-limits-of-ranked-choice-voting/ [11:25:14.0770] E [11:25:57.0435] 2.e? [11:26:01.0613] I thought it was just E [11:26:04.0768] lowercase e, yes [11:26:11.0792] like the math constant, 2.718 whatever [11:26:15.0213] Then we need an option 2.a [11:26:17.0738] * Then we need an option 2.a/2.b [11:26:29.0119] Because that is none of the three options [11:26:29.0252] ryzokuken 🇮🇹: ^ [11:26:34.0691] * ryzokuken 🇮🇹: ^ for option 4 [11:26:50.0018] * Rob Palmer : ^ for option 4 [11:27:40.0681] * Rob Palmer ryzokuken 🇮🇹 : ^ for option 4 [11:28:03.0572] ^ that is for Option 1, `Stage e` [11:30:00.0083] ^ that is for Option 2, `Stage 2.x` (ie, 2.5, 2.7, 2.9, etc) [11:30:49.0862] ^ that is for Option 3, `Stage 10/20/25/30/40` [11:31:13.0228] FYI, I do have a 5th option as a topic in the queue that we haven't discussed yet [11:31:35.0000] we already have consensus from last plenary of making a new stage, so i assume that suggestion wouldn't do well [11:31:46.0055] > <@rbuckton:matrix.org> FYI, I do have a 5th option as a topic in the queue that we haven't discussed yet That's not really related to the naming poll, it's about something we already discusses (whether we want a new stage or not) [11:32:06.0150] > <@rbuckton:matrix.org> FYI, I do have a 5th option as a topic in the queue that we haven't discussed yet * That's not really related to the naming poll, it's about something we already discussed (whether we want a new stage or not) [11:32:08.0774] ^ that is for Option 4, `Stage 2.a/2.b` [11:32:25.0646] Yes, but I don't believe we specifically discussed this option in prior discussions. [11:32:48.0917] option 2 clear winner [11:33:15.0190] now do we vote on which digit goes after the decimal place? [11:33:43.0304] 😭 Jordan no [11:33:43.0339] lol [11:33:48.0543] > <@ljharb:matrix.org> now do we vote on which digit goes after the decimal place? Everybody gets a slider [11:34:04.0896] everyone post a number and we'll take the average [11:34:23.0587] average rounded to 1 decimal place! [11:34:46.0742] `.toFixed(1)` [11:35:06.0461] also it doesn't actually prevent third-party spoilers except when the third party is very unpopular. which is especially dumb because "ending the entrenched two-party system" the whole reason most people like RCV https://electionscience.org/library/the-spoiler-effect/ [11:35:13.0277] `2.6̅6̅6̅` [11:35:52.0261] littledan: Missing 2.718. :) [11:36:05.0526] chris you need only one 6 and a bar [11:36:09.0839] aww, i can't vote for more than one? [11:36:22.0779] if we take every number between 2 and 3 and put them in a big table, and then add up each subsequent decimal place, we will have a new number which does not appear in the table and that will be our phase number [11:36:29.0436] > <@jesse:igalia.com> chris you need only one 6 and a bar sir, please. this is my emotional support number of the beast [11:36:40.0633] This is why I liked 2.b, it didn't need a numeric representation [11:36:58.0716] b is 2 [11:37:12.0553] it just requires renaming 2 to "2, but part 1" [11:37:18.0758] I need a 9 and 3/4 option please /s [11:37:19.0770] * it just requires renaming 2 to "2, but part 1", ie, 2.a [11:37:47.0798] Are all delegates in attendance in matrix as well? [11:37:51.0693] is there a better system? [11:38:18.0387] * is there a better system than RCV you'd suggest? [11:38:24.0689] approval [11:38:31.0805] Go with 2 and 3/4 :) [11:38:34.0482] Otherwise the poll above isn't useful since it excludes folks not in the chat [11:38:36.0180] I would also accept STAR or range [11:38:40.0417] https://en.wikipedia.org/wiki/Condorcet_method in general, approval as a practical special case [11:38:41.0517] what is "approval"? [11:38:52.0895] I don't think matrix polls count but heh I would also be ok with just reading the answer in a cup or tea or in the lines on my hand at this point [11:38:55.0760] vote for as many candidates as you like, candidate with the most votes wins [11:39:10.0347] don't even have to issue new ballots [11:39:39.0804] If test acceptance is mostly pro-forma, 2.5 seems like the wrong answer since its not halfway between 2 and 3 [11:39:58.0470] * If test acceptance is mostly pro-forma, 2.5 seems like the wrong answer since that stage is not halfway between 2 and 3 [11:43:11.0846] I don't see how a stage number with more significant digits than the other stage numbers should convey something besides being in that stage. [11:43:14.0857] haha good luck making that process change eemeli [11:44:03.0358] can't we split the diff with 2.7 ? [11:44:23.0351] > <@msaboff:matrix.org> I don't see how a stage number with more significant digits than the other stage numbers should convey something besides being in that stage. Numbers have weight and often imply a semantic meaning. 2.5 seems half-way to stage 3. It seems to me this gives lower confidence in the stability of the specification text. [11:44:56.0821] sorry not sorry [11:45:17.0447] It is a separate stage. [11:46:19.0656] That doesn't change the implication of 2.5. That's why I suggested 2.b as it has absolutely no bearing on the distance between 2 and 3 [11:46:36.0023] ^ this is for Option A, `2.5` [11:47:09.0835] One benefit of 2.7 is that if needed there is space between 2.7 and 3 without one day having also 2.95 [11:47:17.0293] * One benefit of 2.7 over 2.9 is that if needed there is space between 2.7 and 3 without one day having also 2.95 [11:47:29.0166] `2.10` [11:47:34.0117] Love it [11:47:40.0146] blasphemy [11:47:41.0687] Nobody ever said that we use base 10 anyway [11:47:44.0591] > <@nicolo-ribaudo:matrix.org> One benefit of 2.7 over 2.9 is that if needed there is space between 2.7 and 3 without one day having also 2.95 IMO, if we need another new stage we should just switch to names [11:47:52.0030] that would be 2.a [11:47:56.0112] we're coming full circle [11:47:58.0788] ^ this is for Option B, `2.9` [11:48:09.0186] No, that would be 3.14159 [11:48:17.0113] spoiler alert: 2.7 wins [11:49:25.0056] ^ this is for Option C, `2.7` [11:49:40.0130] and the crowd goes mild [11:50:16.0671] yay, now we can all be unhappy! [11:50:30.0084] i was already unhappy [11:50:48.0538] Can we merge the PR with numbers and talk about names next time? [11:50:55.0582] I'm tired [11:50:55.0810] yes please we can just not name things [11:51:56.0849] I hope we can avoid naming the stages [11:51:59.0437] yes, I thought this meant we don't have to name [11:52:12.0407] TC39 Anonymous [11:52:16.0419] or at the very least, unblocks the stage itself / process change [11:52:34.0820] I think Ron's point that the names can be misleading or overly simplified is a good reason to not try to choose a single name. [11:52:36.0629] (I like re-introducing names) [11:55:30.0312] msaboff: Not a fan of 2.7 either, but the objective implication of moving from integral stage numbers to real stage numbers is that the value after the dot is interpreted as a fractional value. 2.b would have avoided that implication. Following your logic, 2.5 doesn't make sense as a stage name either. [11:56:19.0974] * msaboff: Not a fan of 2.7 either, but the subjective implication of moving from integral stage numbers to real stage numbers is that the value after the dot is interpreted as a fractional value. 2.b would have avoided that implication. Following your logic, 2.5 doesn't make sense as a stage name either. [11:57:00.0550] to be clear, I don't oppose regressing decorator metadata to 2.7; it just needs to be on the agenda [11:57:01.0590] * msaboff: Not a fan of 2.7 either, but a subjective implication of moving from integral stage numbers to real stage numbers is that the value after the dot is interpreted as a fractional value. 2.b would have avoided that implication. Following your logic, 2.5 doesn't make sense as a stage name either. [11:58:05.0109] notes are a little bad this section; I suspect I was not the only note taker who was having difficulty with actively following along this topic [11:58:13.0712] to be fair, it was a wild ride [12:00:06.0789] Can someone clarify a part of the process for me? When I had to come off mute to get clarification for the voting we were doing, should I have instead use tcq "Clarifying Question" button? Is TCQ the like main controller for who speaks when? Is it sorta like raising your hand on a zoom meeting where it sticks you in a queue? [12:00:41.0342] probably 'point of order' on that one actually [12:00:47.0633] (and apologies again if this is common knowledge. this is my first plenary so I'm learning a ton about the actual process of everything) [12:01:13.0789] ethanarrowood: [12:01:14.0585] https://github.com/tc39/how-we-work/blob/main/how-to-participate-in-meetings.md [12:01:42.0555] the guidance there should help; there's a section on what the options mean [12:02:18.0055] excellent thank you! [12:03:41.0436] * I am anti-whimsy [12:05:00.0523] we picked the least disliked option.. so that's gotta be good for something [12:05:22.0691] in any case, big thanks to Michael Ficarra for proposing and landing this. 📈 [12:37:37.0663] does anyone have access to apple's secret internal workings and would be able to tell me whether there is a radar bug tracking dns prefetch with csp default-src? [13:02:28.0699] snek: Do you have more details to help me search? [13:03:39.0636] > <@msaboff:matrix.org> snek: Do you have more details to help me search? `prefetch-src` may also be a good search term [13:03:53.0706] also this [13:05:40.0484] https://yourcalendricalfallacyis.com/ [13:06:38.0359] ok, from what i've read so far, i'm convinced, thanks [13:14:12.0428] > <@devsnek:matrix.org> `prefetch-src` may also be a good search term I found a radar that points to [this](https://bugs.webkit.org/show_bug.cgi?id=185070) bugzilla bug. [13:15:08.0659] > <@msaboff:matrix.org> I found a radar that points to [this](https://bugs.webkit.org/show_bug.cgi?id=185070) bugzilla bug. hmm ok. prefetch-src was deprecated and replaced with the thing at that spec link though [13:15:15.0889] so i'm wondering where webkit is on getting to that reality [13:18:42.0793] it's way too late to change temporal's design in this was, but the more i hear these presentations the more i think it should all have thrown by default [13:18:50.0518] * it's way too late to change temporal's design in this way, but the more i hear these presentations the more i think it should all have thrown by default [13:20:02.0187] generally I am going to defer to the datetime people about appropriate defaults for datetime things [13:20:54.0062] i would agree, which is why we're here :-) but if a day or time doesn't exist that's a bug and the potential problems caused by it throwing are much more easily fixable than the potential problems caused by it silently changing the value i provided. [13:20:58.0775] * i would agree, which is why we're here :-) but if a day or time doesn't exist, that's a bug and the potential problems caused by it throwing are much more easily fixable than the potential problems caused by it silently changing the value i provided. [13:21:03.0427] * i would agree, which is why we're here :-) but if a day or time doesn't exist, that's a bug, and the potential problems caused by it throwing are much more easily fixable than the potential problems caused by it silently changing the value i provided. [13:21:34.0237] iow "stop coercing things" doesn't feel philosophically aligned with "silently change input values" [13:21:41.0932] * iow "stop coercing things" doesn't feel philosophically aligned with "silently change input values by default" [13:21:48.0292] also think about Adar 2! [13:21:49.0376] * iow "stop coercing things" doesn't feel philosophically aligned with "silently change input values by default" to me [13:22:06.0954] indeed, i could be a whole month off without knowing it [13:22:25.0519] > <@ljharb:matrix.org> i would agree, which is why we're here :-) but if a day or time doesn't exist, that's a bug, and the potential problems caused by it throwing are much more easily fixable than the potential problems caused by it silently changing the value i provided. when the happens the first time you run your program, agreed; when the error happens much later, with user data, disagree [13:22:45.0782] that's always going to be the case tho, when users enter something outside the data model [13:22:48.0982] "stop coercing things" refers to _types_, which is to say bugs that you will hit instantly unless you're mixing types (which is on you) [13:23:02.0553] so since you always have to have some kind of "hey user, this is wrong, double check", why wouldn't you do the same here? [13:23:22.0143] you're not always at the point where user data is being entered [13:23:28.0073] like they ask for something to happen at 2:30AM every day [13:23:29.0328] that's fine [13:23:44.0754] sure. the semantics vary, and in that case clamping is fine [13:23:48.0272] and then Mar 12 comes along, and your program needs to run [13:23:55.0609] erroring in that case is bad [13:24:09.0054] that seems like the thing guiding this design, and that seems good to me [13:24:13.0664] but since in nonzero cases it's not fine, the *default* should probably have been to error. and then me, the author of this cron program, can pass the option to clamp [13:24:40.0358] you would not have been exposed to the error until 3am on March 12 [13:24:42.0539] I think the normal semantics would be, if I'm in Adar 2 and I am supposed to identify "today a year from now", it would go to Adar 1 if next year isn't a leap year [13:24:43.0433] exceptions in production are much easier to fix ime than silent bugs, but ymmv [13:24:44.0557] which is much too late [13:25:42.0024] * exceptions in production are much easier to find and fix ime than silent bugs, but ymmv [13:25:46.0331] * exceptions in production are much easier to find and fix ime than silent bugs, but ymmv i suppose [13:26:18.0343] > <@ljharb:matrix.org> exceptions in production are much easier to find and fix ime than silent bugs, but ymmv i suppose I guess I don't think of "what day will it be a year from February 29 2024" as being the sort of exception which should trigger a bug [13:26:30.0546] there is a sensible answer to that question and the default should be to return the sensible answer to that question [13:26:32.0777] it depends on the use case. in some it isn't. in some it is. [13:26:47.0667] so there isn't a universal sensible answer, and in those scenarios i prefer to throw and let the user explicitly disambiguate. [13:27:19.0137] there is a 99% answer; it is better to default to that, and then if you want something else to opt in to that. [13:27:30.0087] i'd love some citations for "99%" [13:27:30.0136] this is not good always but seems clearly good here [13:28:31.0339] > <@ljharb:matrix.org> i'd love some citations for "99%" I am very happy to take the word of the people who work with datetimes on this question; if you are not I think that ought to be on you, not on me. [13:28:52.0196] sure. it just doesn't match my experience. [13:29:01.0038] * sure. it just doesn't match my experience. nor my intuition overall. [13:29:41.0879] > <@ljharb:matrix.org> so there isn't a universal sensible answer, and in those scenarios i prefer to throw and let the user explicitly disambiguate. but also, again, most of the time you're not going to be in a position to raise this error to the user [13:29:51.0424] it's going to happen deep in the system, and surface to the user as a 500 at best [13:30:01.0476] or a missed appointment or similar at worst [13:30:11.0151] * it's going to happen deep in the system, at some point in the future, and surface to the user as a 500 at best [13:30:12.0440] also you'd almost never be able to account for all the weird edge cases [13:30:28.0478] or you'd give up altogether and this would be bad for internationalization [13:33:51.0938] https://github.com/search?q=lang%3Ajs+%22.constructor+%3D%3D%3D%22&type=code [13:34:07.0634] many many people write `x.constructor === Thing` [13:34:31.0635] then get yourself on the queue bakkot [13:35:05.0178] sure. but if they write it with `.constructor` omitted, they'll immediately get the wrong result, so they won't come to rely on it [13:35:29.0314] not if they do `if (x.constructor !== Iterator) x = Iterator.from(x)`, like I said the other day [13:35:48.0645] it is very easy to write code which will appear to work and then break later if we add `.constructor` [13:36:08.0790] that specific code wouldn't suddenly break if we added .constructor [13:36:18.0420] since Iterator.from(x) would be a conceptual noop in that case, i believe? [13:37:00.0489] honestly I'm 50/50 and could go either way on this question, at this point. [13:37:08.0949] nicolo-ribaudo: that contradicts what mark said [13:37:25.0793] if we get stick with the *value*, we can't move to either the accessor or that data property [13:37:35.0875] * if we get stick with the _value_, we can't move to either the accessor or the data property [13:37:46.0132] * if we get stuck with the _value_, we can't move to either the accessor or the data property [13:38:00.0111] > <@michaelficarra:matrix.org> if we get stuck with the _value_, we can't move to either the accessor or the data property Wasn't mark saying that he doesn't want to get stuck with omission? [13:38:08.0577] yes [13:39:11.0576] Right, and I was saying that while it's true that going from omission to data property might still not be possible, going in the future from omission to accessor is still less risky than omission to data property [13:39:30.0330] (assuming that omission is a better temporary solution, and accessor is a better permanent solution) [13:40:41.0988] is it worth a quick temp check on omission vs accessors? [13:40:49.0487] * is it worth a quick temp check on omission vs accessors? (two checks, one for each) [13:41:58.0986] nicolo-ribaudo: I don't see why, they both change the observed value [13:42:30.0780] > <@michaelficarra:matrix.org> nicolo-ribaudo: I don't see why, they both change the observed value I was assuming that the "we risk being stuck" problem is that the websites blocking us might never upgrade their code [13:42:46.0432] And so we would want to be stuck in an ok situation [13:46:58.0291] https://github.com/tc39/Reflector/issues/513 [13:49:08.0847] > <@ljharb:matrix.org> i'd love some citations for "99%" it's actually higher than 99% in this example; the problematic cases are only 1 day out of (365 * 4 + 1) ≈ 0.068% 😈 [13:50:00.0645] for this one case sure, but it's a month every 7 years for adar 2, it's once a year for daylight savings dropping an hour, it's every time someone mistypes 31 for a 30 day month, etc [13:54:59.0717] I was being facetious, but applying the same arithmetic gives 98.82% for non-leap Hebrew calendar months and 99.98% for hours of the year unaffected by DST transitions. All of these edge cases really are below or just about at a 1% threshold [14:11:57.0783] ok, but reducing human use cases to percentages seems not very kind, either way :-)