2026-10-01 [17:23:06.0402] From my [July slides](https://docs.google.com/presentation/d/1vTRHdRzIZQF69Q5Nx_VDkCkm2mn1rJK-CTtDiSqA9x0/edit?slide=id.g3f503113f27_0_21#slide=id.g3f503113f27_0_21), the benefit of caching unsurprisingly increases with the number of keys. Microbenchmark of a perfect sort cache (cache always hit, ~no lookup overhead) based on the shape showed: 3 properties: 0.53 µs → 0.46 µs (12% faster) 16 properties: 0.91 µs → 0.65 µs per composite (29% faster) 250 properties: 10.34 µs → 4.72 µs per composite (54% faster) [17:23:57.0707] A real cache wouldn't be so perfect, so I wouldn't expect there to actually be a win for the smaller sets of properties [17:25:58.0400] Talking with keith_miller yesterday, it's a fun one. I suspect people will by far only create smaller keys as those are the core use cases so the caching won't be critical. And if engines don't cache then that may also discourage large keys as they are slow. But if large keys did become common for some reason, then engines would be pressured into optimizing for that case. [17:26:27.0069] * Talking with keith_miller yesterday, it's a fun one. I suspect people will by far only create smaller keys as those are the core use cases so the caching won't be critical. And if engines don't cache then that may also discourage large keys as would be relatively slow. But if large keys did become common for some reason, then engines would be pressured into optimizing for that case. [17:33:47.0942] Even if large numbers of keys did become common I think the obvious ways for that to happen all start out sorted anyway (e.g. this is what happens if you pass an array), so just handling that specific case probably gets you most of the value [17:52:34.0695] I've opened https://github.com/tc39/proposal-composites/issues/42 as a place to discuss potential API changes. cc: keith_miller [17:58:11.0460] good morning, all [17:58:38.0767] we're starting in 1 min [18:49:23.0956] https://github.com/michaelficarra/michael-tcq/pull/66 [19:12:22.0240] in all seriousness can we please not use teams again? it is consistently the worst available option [19:13:02.0629] lgtm ship it [19:18:24.0168] I'm sympathetic to this. In general it is the host that selects the AV system because they must take responsibility for providing the overall end-to-end service, handling in-room amplification and dealing with feedback and linking to sufficient mics. Maybe we could update host.md in how-we-work to express our preferences to influence hosts more explicitly, e.g. "Zoom and Google Meet are normally preferred over Microsoft Teams". [19:20:35.0751] True, but we ask our hosts to do all sorts of things they may not typically do, including not doing NDAs, and this seems like something we can ask for. I’d also phrase it stronger than “preferred”, more like “Teams is strongly discouraged in favor of Zoom or Google Meet” [19:26:08.0786] This seems a good start for the PR. Please go ahead and see what review feedback we get. [19:27:50.0248] Michael Ficarra: could you write your alternative problem framing here [19:31:54.0597] is "∉" not considered negative? [19:32:49.0163] the new formalism is more powerful, the mapping can only go one way [19:39:12.0163] Is our current usage of cover grammars causing readability/writability/implementability difficulties worth investigation and potential churn? In particular, consider the lack of explicit disambiguators (shown to be needed by all implementers), the non-locality of the grammar, and its interdependence with early error prose rather than being self-contained. [19:46:43.0429] > in all seriousness can we please not use teams again? it is consistently the worst available option > we ask our hosts to do all sorts of things they may not typically do, including not doing NDAs, and this seems like something we can ask for. The hosts completely understand the frustration, and we agree that Teams is far from ideal 🥲 In response to the point about asking hosts to accommodate TC39’s needs: Unfortunately in this case it’s not really a policy we can make an exception to, but a limitation of the meeting room hardware itself. Sony meeting rooms are specifically wired to support Teams (and Webex in some locations), and we’re unable to configure them for Google Meet, Zoom, etc. We’ve asked about this ourselves, but have been flat out rejected 💔 We’re genuinely sorry about the inconvenience. If there were a way for us to accommodate this request, we absolutely would!! 😭 [19:47:14.0681] * > in all seriousness can we please not use teams again? it is consistently the worst available option > we ask our hosts to do all sorts of things they may not typically do, including not doing NDAs, and this seems like something we can ask for. The hosts completely understand the frustration, and we agree that Teams is far from ideal 🥲 In response to the point about asking hosts to accommodate TC39’s needs: Unfortunately in this case it’s not really a policy we can make an exception to, but a physical limitation of the meeting room hardware itself. Sony meeting rooms are specifically wired to support Teams (and Webex in some locations), and we’re unable to configure them for Google Meet, Zoom, etc. We’ve asked about this ourselves, but have been flat out rejected 💔 We’re genuinely sorry about the inconvenience. If there were a way for us to accommodate this request, we absolutely would!! 😭 [19:47:25.0079] * > in all seriousness can we please not use teams again? it is consistently the worst available option > we ask our hosts to do all sorts of things they may not typically do, including not doing NDAs, and this seems like something we can ask for. The hosts completely understand the frustration, and we agree that Teams is far from ideal 🥲 In response to the point about asking hosts to accommodate TC39’s needs: Unfortunately in this case it’s not really a policy we can make an exception to, but a physical limitation of the meeting room hardware. Sony meeting rooms are specifically wired to support Teams (and Webex in some locations), and we’re unable to configure them for Google Meet, Zoom, etc. We’ve asked about this ourselves, but have been flat out rejected 💔 We’re genuinely sorry about the inconvenience. If there were a way for us to accommodate this request, we absolutely would!! 😭 [19:53:15.0010] oof, good to know. [20:01:33.0484] "we" being Americans here [20:02:09.0467] also, I don't see how anyone would be willing to make a legal opinion on the spot [20:02:14.0713] * also, I don't see how anyone would be willing to make a legal opinion on the spot on this topic [20:17:49.0292] Chris de Almeida: Unfortunately, I think I'll probably be asleep by the time we get to your agenda deadline topic, but fwiw, I'd like to express my support for both making the deadline fall on a consistent day, and for having that deadline not be after working hours on Friday or on the weekend for anybody. [20:19:07.0831] Thank you for bringing the topic. [21:04:27.0042] though of course it'd be great to have all the other iterator helpers on AsyncIterator.prototype in the future! [21:05:42.0007] if we want to avoid Friday evening, I might propose Wednesday AoE [21:06:54.0662] (Thursday AoE might be Friday evening SoE) [21:08:01.0055] (if only there were a datetime library for computing this kind of thing) [21:28:09.0136] @christianulbrich:matrix.org I believe that's the method you were asking me for at the community event [21:30:44.0376] (https://docs.google.com/presentation/d/19xEFe4rHPDxpX_ai7dXrYY3wNtgwcsaKV25PwZiml54/edit?slide=id.g3fa9bcbfd42_1_85#slide=id.g3fa9bcbfd42_1_85) [21:41:39.0890] Michael Ficarra: I think it is not. I want something, that completes, once from a list of promises any promise resolves to a certain value. [21:43:20.0931] meaning you have a list of promises, and as soon as any of them resolve to a certain value, you want something else to happen? [21:44:43.0600] Yes. [21:45:22.0886] yeah then that's what you want [21:54:06.0536] Michael Ficarra: No `.asCompleted()` returns all Promises in settling order, if I understand the code directly. But I am with you, that the idea is similar, it is a perpetual race with a filter. So I want `Promise.raceWithFilter()` [21:55:43.0462] I think this can be solved with `AsyncIterator.filter()`. [21:57:03.0475] can someone explain to me why `some` has to wait until all the `map`s are done? like why can't it check each value as it settles? [21:57:44.0622] in sync iterators, i thought `.map().filter()` maps and then filters each value, rather than maps each value and then filters each value [21:58:23.0245] (i can ask this on the queue if it's useful but i assume i'm just missing something) [21:59:54.0736] yes exactly, `await asCompleted(...).filter(x => !x).take(1)` [22:01:22.0628] Yes. Or `Promise.all()` with the _golden_ Promise being a rejection :) [22:04:57.0130] we are over an hour in and we still haven't gotten to the first open question... [22:05:02.0384] not resolved, *gotten to* [22:07:10.0633] It's OK we'll handled the open questions concurrently [22:07:15.0977] * It's OK we'll handle the open questions concurrently [22:11:17.0099] @erights:matrix.org you can just press enter after pressing the new topic button if you don't want to (or have time to) type out a topic [22:11:50.0818] I don't think `MM` is active here [22:23:49.0918] I would like to reaffirm my appreciation for TCQ 2000 XP Millennium Edition [22:27:15.0646] 🤷‍♂️ I had a lot of time to wait on the queue [22:28:20.0597] just open the inspector and do `Promise.all()` while selecting everyone else's questions [22:59:44.0100] the support was for distinguishing based on thenableness [22:59:54.0673] great [23:00:15.0013] how do you feel about caching whether the first result was thenable vs checking for every call to .next()? [23:03:40.0815] `asCompleted().find(pred)` surely [23:03:59.0731] this actually came up on the discourse https://es.discourse.group/t/promise-pick-predicate-based-promise-selection/2496 [23:21:06.0100] don't we have to check for every call? Or we're assuming that promises only come from `async` functions and therefore consistent [23:21:54.0485] we would be assuming that it is either an async iterator or a sync iterator and that async iterators always have `next()` return a Promise [23:22:10.0835] this is admittedly not a totally valid assumption [23:25:38.0858] my gut is that it's a step too far to avoid the overhead of checking everytime, as the overhead feels very low. But have no data to back that up. [23:27:50.0680] What's the argument against having a deadline on a weekend? [23:28:09.0401] i'm curious about that too [23:34:27.0836] people have done a terrible job of putting their acronyms on the notes [23:34:34.0665] this is very hard [23:35:02.0782] @rkirsling:matrix.org https://github.com/tc39/notes/blob/main/delegates.txt [23:35:16.0597] yeah lemme juggle that on top of everything else [23:36:55.0595] Ctrl-tab and Ctrl-shift-tab is *so* much easier than scroll-up-to-top and scroll-back-down-to-bottom [23:38:22.0333] * Ctrl-PgDn and Ctrl-PgUp is *so* much easier than scroll-up-to-top and scroll-back-down-to-bottom [23:38:27.0904] that is true but I just feel overwhelmed the entire time when doing this [23:39:10.0625] I think we can get acronyms added to TCQ and will help a lot [23:40:22.0663] It's the equivalent of "must be postmarked by MM/DD" [23:42:33.0668] If you do take notes often, you know the acronyms by heart. [23:42:38.0908] I am *shocked* that people do not know what AoE means [23:42:57.0621] and a lot of people think they know what it means and also do not [23:42:59.0358] Area of Effect! [23:43:21.0579] Age of Empires! [23:43:24.0941] Always favor AoE spells over targeted ones. [23:43:47.0756] 🚨👮 #temporaldeadzone:matrix.org [23:44:15.0305] This is one of the strangest discussions I've been to in a while… [23:44:40.0922] I am about to lose it [23:46:52.0319] @ljharb:matrix.org your TCQ isn't working? [23:49:25.0413] sorry, i decided to reply too quick. will use it next time 2026-10-02 [16:40:16.0230] > <@dminor:mozilla.org> Chris de Almeida: Unfortunately, I think I'll probably be asleep by the time we get to your agenda deadline topic, but fwiw, I'd like to express my support for both making the deadline fall on a consistent day, and for having that deadline not be after working hours on Friday or on the weekend for anybody. I'm nearly certain I forgot to read this out, so apologies. I was attempting to blaze through the topic in hope that we might get to an unrelated continuation or two. Alas, the fates refused to conspire thusly. Nevertheless, I appreciate your comment. 🧡