2024-01-01 [14:24:50.0753] > The IndexedDB API provides a built-in method for comparing two ArrayBuffers or ArrayBuffer views in a bytewise fashion. This is because IndexedDB has a concept of "key order", where a subset of JavaScript values that can be used as "keys" in IndexedDB have a defined sorting order. The important part is that one such kind of key is a binary key, which is defined in the spec as "ArrayBuffer objects (or views on buffers such as Uint8Array)." 2024-01-11 [11:00:40.0291] Happy New Year, all 👋 The 100th TC39 meeting in San Diego is now only 3.5 weeks away! So far we have 17 folk registered on [the sign-up sheet.](https://forms.gle/PSAjQCQQTCP8cDfG8) The advertised deadline for registrations is Friday 18th January 2024 - so if you plan on coming please sign up soon so our hosts can plan accordingly! - https://github.com/tc39/Reflector/issues/516 [11:28:59.0982] I'm unable to attend in person, unfortunately. If there are to be TC39 hats, will there be a way to get one for remote attendees? [11:58:17.0779] I don't think we've explicitly said what the swag will be yet? Taking notes and writing summaries will definitely increase the chances of getting some. [12:01:49.0589] Well, swag in general. I have the last two hats, can't let the collection be incomplete. [12:13:49.0565] It seems likely there will be enough to bring to future plenaries. [13:33:06.0925] ah, but do you have the beanie? 2024-01-12 [16:11:05.0539] Alas, no. I do have the ball caps though [16:12:34.0830] Unfortunately, the next two are outside the US and are outside of my travel budget. Iay have to wait for the next east coast plenary. [16:12:53.0995] * Unfortunately, the next two are outside the US and are outside of my travel budget. I may have to wait for the next east coast plenary. 2024-01-13 [16:43:43.0372] We are now at 21 registered attendees for the Feb meeting in San Diego. The advertised deadline for registrations is Friday 18th January 2024 - so if you plan on coming please sign up soon! - https://github.com/tc39/Reflector/issues/516 [17:57:58.0099] 18th January is a Thursday [02:05:24.0251] * We are now at 21 registered attendees for the Feb meeting in San Diego. The advertised deadline for registrations is Friday 19th January 2024 - so if you plan on coming please sign up soon! https://github.com/tc39/Reflector/issues/516 [02:05:40.0969] * Happy New Year, all 👋 The 100th TC39 meeting in San Diego is now only 3.5 weeks away! So far we have 17 folk registered on the sign-up sheet. The advertised deadline for registrations is Friday 19th January 2024 - so if you plan on coming please sign up soon so our hosts can plan accordingly! https://github.com/tc39/Reflector/issues/516 2024-01-15 [02:51:36.0250] As of Monday we have 22 registered attendees for the Feb meeting in San Diego. Please join us! [15:50:18.0159] Whooops my company is out so i am out. Y'all I live in San Diego, lets' get a cocktail or tea or something. 2024-01-16 [17:14:55.0390] > <@akirose:matrix.org> Whooops my company is out so i am out. Y'all I live in San Diego, lets' get a cocktail or tea or something. count me in! [17:16:15.0289] oh wait, she won't be able to see that, will she [17:19:35.0814] the channel is still public, you just can't post when below the delegate power level [17:21:29.0634] oh! cool, thanks for the clarification [08:31:38.0125] On Thursday 8th Feb we will have a Community Event in San Diego. If you wish to present or would like to help judge proposals (in an entertaining and education way) please volunteer on [the Reflector. post.](https://github.com/tc39/Reflector/issues/516) [12:13:00.0791] * On Thursday 8th Feb we will have a Community Event in San Diego. If you wish to present or would like to help judge proposals (in an entertaining and education way) please volunteer on [the Reflector post](https://github.com/tc39/Reflector/issues/518) 2024-01-17 [11:13:28.0972] dminor: Is there a tracking bug for https://github.com/tc39/proposal-regexp-modifiers, which is at Stage 3? I cannot find one on https://bugzilla.mozilla.org/. [11:47:43.0459] msaboff: Do you know if JSC has a tracking bug for RegExp Modifiers yet, I also cannot find one on https://bugs.webkit.org/ [11:47:51.0409] * msaboff: Do you know if JSC has a tracking bug for RegExp Modifiers yet? I also cannot find one on https://bugs.webkit.org/ [14:21:09.0301] We now have 26 folk signed up for February San Diego meeting. So it's on track to be the biggest meeting since 2019. The advertised deadline for registrations is Friday 19th January 2024 - so if you plan on coming please sign up soon! https://github.com/tc39/Reflector/issues/516 [14:29:31.0041] should be 27 now--see you all there! 2024-01-20 [18:02:23.0903] Last meeting, which proposals did we agree are at 2.7? [19:09:34.0306] > <@ljharb:matrix.org> Last meeting, which proposals did we agree are at 2.7? none [19:16:14.0171] the only proposal that could have been regressed was decorator metadata and it was objected to on the grounds that proposals stage changes need to be on the agenda. in any case, it's moot now because the 2.7 -> 3 criteria was quickly resolved for that proposal, so it remains at stage 3 [19:17:36.0770] https://github.com/tc39/test262/pull/3971 [19:48:35.0234] ah ok, gotcha 2024-01-22 [16:11:32.0347] to be pedantic, many proposals "qualified" for demotion to stage 2.7, in that their tests may not be deemed sufficient by committee [16:12:05.0129] but I only proposed demotion for proposals that had no tests at all [16:12:45.0464] if somebody wanted to do the work, they could probably make a pretty good case for demotion of a few more stage 3 proposals [20:43:24.0235] anyone want to volunteer to review the base64 proposal so I can go for stage 3? https://github.com/tc39/proposal-arraybuffer-base64 [20:44:13.0335] the actual decoding is a little annoying, but mostly quite mechanical, and otherwise there's not much to it [20:44:26.0270] (also there's a polyfill which works pretty much exactly like the spec text) [07:17:40.0644] sure, i can do that [14:36:48.0608] FYI we have an in-person Matrix room for those attending San Diego in Feb. Please shout if you need a invite to the room. So far we have 29 in-person attendees so it will be the highest attendance since Hawaii which coincidentally also featured whales. [14:56:31.0994] ✋ 2024-01-23 [11:49:31.0319] does anyone have strong opinions about `Uint8Array.fromHexInto` being on the prototype vs static? It sets bytes in an existing `Uint8Array`. Currently it's static to match TextEncoder's `encodeInto`, which is a very similar method, but it could be prototype instead [11:49:42.0819] * does anyone have strong opinions about `Uint8Array.fromHexInto` being on the prototype vs static? It sets bytes in an existing `Uint8Array` and returns a `{ read, written }` pair. Currently it's static to match TextEncoder's `encodeInto`, which is a very similar method, but it could be prototype instead [11:50:06.0009] * does anyone have strong opinions about `Uint8Array.fromBase64Into` being on the prototype vs static? It sets bytes in an existing `Uint8Array` and returns a `{ read, written }` pair. Currently it's static to match TextEncoder's `encodeInto` and the `Uint8Array.fromBase64` method, but it could be prototype instead 2024-01-24 [08:31:19.0903] I do not have a strong opinion. My weak opinion teeters. Just facts: TextEncoder had to be static because the byte array could not be the receiver. The “into” term indicates that writer array is an argument, not a return or the receiver. By contrast “copyWithin” implies both the reader and writer are the receiver. I don’t know a modifier word precedent for indicating the operation writes to the receiver and reads from an argument. [08:35:42.0481] So nothing prevents the method from being on the prototype but it is easier to name on the constructor. [09:05:26.0043] `write`? [09:06:45.0213] > I don’t know a modifier word precedent for indicating the operation writes to the receiver and reads from an argument. Plausibly [`fill`](https://tc39.es/ecma262/multipage/indexed-collections.html#sec-%typedarray%.prototype.fill), which I guess for this proposal would suggest something like `Uint8Array.prototype.fillFromBase64` [09:07:08.0521] `fill` sounds very reasonable, imo [09:07:50.0034] Maybe `set`? `DataView.prototype.setUint32()` sets multiple bytes on the receiver from an argument. [09:08:12.0778] `fill` usually means performing a repetitive action, like "fill this array with zeroes" [09:09:44.0121] yep, `set` appears to be the other prior instance of that pattern [09:10:00.0777] This is also a somewhat new capability in the standard library, so something precedent-setting isn't necessarily uncalled for. I would generally use a term like `write` for this kind of operation elsewhere. [09:11:28.0633] Also, `decode` has *some* precedent with `decodeURI`/`decodeURIComponent`, so `decodeBase64Into` is a possibility. [09:12:40.0291] I think the overarching point is that we ought to avoid "into" in the naming of a prototype method that writes into its receiver [09:13:54.0409] The name I would normally use for such a method, were it on the prototype, would be `writeBase64Bytes()` [09:15:23.0244] `set` doesn't seem like the right precedent, because its essentially a byte-for-byte copy. There's no encoding that happens (aside from byte order) [09:15:50.0635] `setFromBase64` and `writeFromBase64` seem like solid options. `writeBase64Bytes` isn't as strong IMO, but also isn't bad. [09:16:47.0561] The term `byte` has precedent within the language, despite referring to it as `Uint8` on DataView and in the TypedArray constructor. `BYTES_PER_ELEMENT`, `byteLength`, etc. [09:19:39.0704] Also, `writeBase64Bytes` means it could theoretically be applied to any typedarray prototype with the same meaning (i.e., "write the bytes"). An `Int32Array.prototype.writeFromBase64`, for example, might be misconstrued as decoding base64 into `Int32` elements, rather that bytes. `writeFromBase64` is probably fine if its *only* on `Uint8Array` (or maybe `Int8Array`). [09:42:56.0354] I think `writeBase64` is sufficiently specific and would be equally sensible on DataView or Uint*Array. [09:43:12.0424] * I think writeBase64 is sufficiently specific and would be equally sensible on DataView or Uint8*Array. [09:43:39.0446] * I think writeBase64 is sufficiently specific and would be equally sensible on DataView or Uint8Array (and variants). [09:43:44.0622] plan is for these to only be on Uint8Array specifically, so I'm not too worried about the interpretation on other TA types [09:43:56.0837] I would find base64-decoding to non-byte types confusing [09:45:28.0042] I don’t like it but `set` has much stronger precedent than `write` [09:45:48.0416] re: `set` vs `write`, we have a bunch of methods called "set" and none called "write", and the names themselves don't seem to suggest that one of them does decoding, so I'm inclined more towards `set` [09:46:28.0898] the DataView `setUint32` etc methods are arguably doing encoding, especially given the endianness parameter [09:46:47.0846] so of the names above, `setFromBase64` is my preference [09:47:21.0223] not opposed to `write`, but `set` seems nicer [09:47:33.0148] and it sounds like people are leaning towards having this on the prototype rather than a static? [09:53:12.0301] ok maybe no one actually cares about prototype vs static? [10:25:24.0894] As I said, my biggest concern for `set` is that methods like `setInt32` imply a byte-for-byte copy, which doesn't seem consistent with this, but I'm not strongly opposed. [10:39:45.0549] I guess I slightly prefer it on the prototype [10:41:49.0102] I’m leaning toward the prototype, given we’ve found precedent-founded names for a prototype-method, like `setFromBase64`. [10:59:15.0562] `setFromBase64` seems as byte-for-byte as `setInt32` does, to me? the input is not bytes itself, but can be represented by bytes in a canonical way, so you represent it as bytes and then set those in the buffer [12:29:48.0275] I would not be offended by `setFromHex`, `setFromAscii`, or `setFromUtf8` if they were proposed. There’s some bytewise compaction and contraction, not even uniformly proportional in all these cases. [13:00:50.0028] this proposal will include `setFromHex` [13:01:01.0799] `fromUtf8` will continue to live in TextEncoder; no reason to be duplicative [14:27:52.0204] Point made only to express comfort with `set` over `write` even for “bytes of heterogenous width” [14:30:21.0617] * Point made only to express comfort with set over write even for “input of heterogenous width” [14:30:34.0534] * Point made only to express comfort with set over write even for input of heterogenous width 2024-01-25 [16:54:46.0476] PR for moving/renaming the methods: https://github.com/tc39/proposal-arraybuffer-base64/pull/45 [19:17:03.0075] bakkot: I hope you're gonna PR iterator helpers proposal and my follow-ons 🙏 [21:29:16.0537] Michael Ficarra: you mean for https://github.com/tc39/ecma262/pull/3268? yes, once the biblio is published [14:12:30.0445] I may need to split up the Function Decorators proposal into two presentations and may split the proposal itself, after plenary. The current proposal includes functions *and* object literal elements, but that's a lot to cover and I have a feeling we will spend a long time discussing function declarations. [14:22:30.0736] This is encouragement for you to come to San Diego to get extra time with other delegates to talk about Decorators and tacos. [14:50:06.0225] > <@rbuckton:matrix.org> I may need to split up the Function Decorators proposal into two presentations and may split the proposal itself, after plenary. The current proposal includes functions *and* object literal elements, but that's a lot to cover and I have a feeling we will spend a long time discussing function declarations. I am happy that you are raising these together. It isn’t always great to have lots of tiny proposals. [14:50:52.0808] I know I'm going to at least need to amend my timebox to something longer. [15:20:06.0117] > <@robpalme:matrix.org> This is encouragement for you to come to San Diego to get extra time with other delegates to talk about Decorators and tacos. Only that I could. [15:21:11.0548] I added a note to the **Normal Constraints** section indicating that the presentation can be split into two separate timeboxes of 60 and 30 minutes to focus on the two high level areas of the proposal, independently. [15:21:56.0998] I'm leaving it as a single presentation for now, as I still hope to advance them together as a single proposal. 2024-01-26 [06:36:21.0267] I think 90 minutes is too long for a Stage 1 advancement topic. I appreciate the amount of work that has gone into the presentation and the proposals, but advancement to Stage 1 is about agreement that the problem is worth investigating, and a 90 minute timebox to me sounds like we're getting into too many details about how to solve the problem. I would prefer a shorter Stage 1 advancement presentation, followed by a Stage 1 update at the next plenary. I think that splitting this way could help keep the discussion more focused, by separating the "should this be part of JavaScript" from "how should we do this" into separate discussions. [07:13:10.0428] > <@dminor:mozilla.org> I think 90 minutes is too long for a Stage 1 advancement topic. I appreciate the amount of work that has gone into the presentation and the proposals, but advancement to Stage 1 is about agreement that the problem is worth investigating, and a 90 minute timebox to me sounds like we're getting into too many details about how to solve the problem. I would prefer a shorter Stage 1 advancement presentation, followed by a Stage 1 update at the next plenary. I think that splitting this way could help keep the discussion more focused, by separating the "should this be part of JavaScript" from "how should we do this" into separate discussions. I allocated 90 minutes because function decorators have already been discussed several years ago as part of the original decorators proposal. I expect much of that timebox will be in discussion about hoisting, as that's where we last left it. The actual presentation isn't 90 minutes long. I'm also happy to couch a discussion about hoisting as something to dig into as part of stage 1, as you said, but a discussion on hoisting needs to happen at some point whether that is now or in two months. [07:14:34.0898] It's also structured so that I can split it up into two presentations, and potentially two separate proposals if necessary. [07:16:17.0651] I can also break off the hoisting discussion into a separate open-ended discussion on the agenda [07:16:52.0906] My opinion is that the hoisting conversation is more appropriate once this reaches Stage 1. I don't want to be pedantic about the process, I'm also concerned about people's capacity for attention, and I think having a Stage 1 Update specifically about hoisting might end up being more productive in terms of useful feedback for you. [07:19:12.0122] But if others on the committee would like to do it all at once, I won't stand in their way :) [07:23:30.0861] I'm somewhat doubtful that a two month delay on a general discussion about hoisting is beneficial? It's a known concern from prior discussion dating back 8-9 years from when Yehuda was the initial decorators champion. It may take multiple sessions to iron out, so I'd like to get the ball rolling as other proposals like parameter decorators (which is already stage 1) have a dependency on this. [07:24:26.0823] I'll break out the hoisting discussion to a separate topic that we can skip if this doesn't advance to Stage 1. [08:07:42.0105] I think 60 minutes is probably a good upper bound for any particular presentation, because you will just have a drop-off in attention and interest over time. (And it isn’t a good idea to work around that ceiling by breaking things into multiple agenda items, for the same reason). At the same time, I do think it would be good to introduce the hosting topic as well as Ron’s preferred conclusion—I think that part should be able to fit in under 15 minutes (just to state the problem and have a brief discussion, to make sure everyone understands; drawing a conclusion would happen in a future meeting) [08:07:51.0983] * I think 60 minutes is probably a good upper bound for any particular presentation, because you will just have a drop-off in attention and interest over time. (And it isn’t a good idea to work around that ceiling by breaking things into multiple agenda items, for the same reason). At the same time, I do think it would be good to introduce the hoisting topic as well as Ron’s preferred conclusion—I think that part should be able to fit in under 15 minutes (just to state the problem and have a brief discussion, to make sure everyone understands; drawing a conclusion would happen in a future meeting) [08:24:42.0632] * I'm somewhat doubtful that a two month delay on a general discussion about hoisting is beneficial? It's a known concern from prior discussions dating back 8-9 years from when Yehuda was the initial decorators champion. It may take multiple sessions to iron out, so I'd like to get the ball rolling as other proposals like parameter decorators (which is already stage 1) have a dependency on this. [09:23:11.0107] I've updated the timebox, though I'd still prefer to get a jump start on the discussion if the proposal advances to stage 1. We've already had a number of discussions about this in plenary since Decorators was first proposed, with no clear outcome. This isn't exactly a net new topic, though there may be new voices joining the dialogue. My hope is that the numerous prior discussions we've had are a good indicator that this proposal should at least get stage 1 to continue examining the problem, but in a more focused way. [09:24:24.0233] * I've updated the timebox, though I'd still prefer to get a jump start on the discussion if the proposal advances to stage 1. We've already had a number of discussions about this in plenary since Decorators was first proposed, with no clear outcome. This isn't exactly a net new topic, though there may be new voices joining the dialogue. My hope is that the numerous prior discussions we've already had are a good indicator that this proposal should at least get stage 1 to continue examining the problem, but in a more focused way. [13:12:12.0044] Luca Casonato, guybedford On the agenda it says _ESM Phase Imports for Stage 1_ but also has its stage already marked as 1. Is that a typo? 2024-01-27 [17:08:44.0852] seems like it is; i've fixed it. [10:10:04.0176] I feel like shorter topics are usually healthier for the process. as fun as it is, plenary is probably not the best place for designing solutions. [10:33:23.0702] That's not the goal. The goal is to acknowledge the prior discussions, present the alternatives that have been considered, describe the proposed solution, and take questions. I know that there is the potential for a outsized queue on this topic, hence the increased timebox, though I certainly hope that won't be the case. [10:34:09.0664] * That's not the goal. The goal is to acknowledge the prior discussions, present the alternatives that have been considered, describe the proposed solution, and take questions. I know that there is the potential for an outsized queue on this topic, hence the increased timebox, though I certainly hope that won't be the case. 2024-01-29 [07:52:26.0951] do we have Metamask delegates in this channel? [07:52:49.0593] reshipping iterator helpers with the weird getters broke the Metamask extension somehow [07:52:57.0164] would appreciate some help debugging [08:12:54.0258] MetaMask do are not members of ECMA at the moment, but I am in touch and can connect and also assist later today. [08:18:34.0606] Kris Kowal: would be much appreciated, thank you [08:21:31.0022] FYI the SES shim had been updated last year in anticipation of Iterator helpers to expose these in its original shape (data values), but we forgot to update the shim after the decision to switch to accessors, resulting in this breakage. This was [discovered a couple weeks](https://github.com/endojs/endo/issues/1971) ago in Chrome canary, and fixed, but I suppose the fix may not yet have been deployed. [08:22:01.0092] * FYI the SES shim had been updated last year in anticipation of Iterator helpers to expose these in its original shape (data values), but we forgot to update the shim after the decision to switch to accessors, resulting in this breakage. This was [discovered a couple weeks](https://github.com/endojs/endo/issues/1971) ago in Chrome canary, and fixed, but I suppose the fix may not yet have been deployed by Metamask [08:37:46.0534] both of the iterator helper breakages were from people writing code in anticipation of unshipped proposals :( [08:37:58.0779] time to start conducting meetings in secret, I guess [08:39:04.0617] "the feature will have to work with all existing code" is bad enough; if the constraint becomes "also has to work with code that people will write in anticipation of this feature" it will become outright impossible [08:40:07.0573] Well in the latter case it's a TC39 member (Agoric) implementing support for a proposal that stage 3, so I think that's acceptable. Also the issue is already fixed, just apparently not deployed. [08:40:27.0500] * Well in the latter case it's a TC39 member (Agoric) implementing support for a proposal that reached stage 3, so I think that's acceptable. Also the issue is already fixed, just apparently not deployed. [08:44:28.0145] * Well in the latter case it's a TC39 member (Agoric) implementing support for a proposal that reached stage 3, so I think that's acceptable. Also the issue should be already fixed, just possibly not deployed. [08:45:46.0245] would be good to confirm and then have Metamask deploy an update asap [08:46:06.0962] anyways Kris has started an email thread, will wait for Metamask folks to chime in as the PST workday gets started [08:46:11.0788] i really don't want to unship this again [11:01:00.0992] For those watching here, we believe this is an issue that MetaMask discovered on Chrome Canary two weeks ago. Agoric shipped a patched and that was rolled up for a MetaMask release that is rolling out now and has reached 1% of Chrome users. [11:14:44.0254] what is being rolled out to 1% exactly? do 1% of the extension users see an updated version of the extension on the store? (i didn't know the extension store worked that way) [11:15:10.0445] or is it that the extension loads some remote code, and the remote code has the bug, and that remote code has been updated for 1% of the users? [11:15:38.0747] chrome extensions do have partial rollout https://developer.chrome.com/docs/webstore/update#partial-rollout [11:16:00.0287] Let’s figure that out over email. [11:16:01.0139] ah i see, good to know [12:16:44.0942] leobalter: A ShadowRealms question: Where do you want to have issues opened for tests that don't seem to be running as expected when inside a shadow realm (e.g. missing dependencies, such as `setInterval`) [15:03:20.0885] the uuid proposal was never formally withdrawn despite its champions doing it in WHATWG instead; should it be moved to the inactive proposals list? https://github.com/tc39/proposal-uuid [15:07:43.0592] i still think it belongs in the language, but if Benjamin E. Coe isn't interested in pursuing that (and neither is anyone else) then yes [15:10:33.0256] I don't think engines are going to be willing to add it under a different name, so the only way it could be "in the language" is by pulling parts of the crypto spec in [15:10:41.0839] which would be fine/good, but is a different project really [15:13:14.0485] agreed, i think pulling it in at this stage would be a very different proposal, not picking up where the current one leaves off [15:13:19.0315] given that i support marking it as inactive [15:21:42.0350] i agree that's the unfortunate reality yes [15:33:38.0819] we have to accept that WinterCG provides a de facto extended stdlib for JS via the minimum common web platform API [15:54:52.0966] ha, good question. Can you link me to any example? I'd assume that would mean fixing coverage within WPT, but I don't how issue tracking is handled there. I'd kickstart reporting wpt coverage related issues within the shadowrealm proposal repo. 2024-01-30 [01:15:44.0531] The 100th TC39 meeting in San Diego is now one week away! So far we have 31 folk registered on the in-person sign-up sheet which is well above-average numbers 🎉 There is still capacity if folk want to come, so please sign-up soon. There will be tacos and mystery/unrevealed celebrations. https://github.com/tc39/Reflector/issues/51 [01:26:55.0030] * The 100th TC39 meeting in San Diego is now one week away! So far we have 32 folk registered on the in-person sign-up sheet which is well above-average numbers 🎉 There is still capacity if folk want to come, so please sign-up soon. There will be tacos and mystery/unrevealed celebrations. https://github.com/tc39/Reflector/issues/51 [08:54:23.0680] So, for example /streams/readable-streams/cancel.any.shadowrealm.html fails because it calls into RandomPushSource, defined [here](https://searchfox.org/mozilla-central/source/testing/web-platform/tests/streams/resources/rs-utils.js), which uses `setInterval`. I'm also still seeing some peculiarity in the wasm tests (mentioned previously [here](https://github.com/tc39/proposal-shadowrealm/issues/386#issuecomment-1819763999) -- I'm open to the possibility this is an implementation issue, but it would be good to have feedback that this is working in other implementations or not) [08:55:48.0713] Another one to note would be `/streams/readable-streams/owning-type-video-frame.any.shadowrealm.html` et.al can't run in a shadow realm because `VideoFrame` doesn't exist inside one. [08:56:48.0996] given Rick's comment [here](https://github.com/tc39/proposal-shadowrealm/issues/386#issuecomment-1904918045) I wasn't sure how the champions wanted feedback [09:12:18.0794] that's certainly its goal, yes [10:19:48.0840] link seems wrong :) [10:20:09.0348] * link seems wrong, missing a 6 at the end [10:20:49.0620] * The 100th TC39 meeting in San Diego is now one week away! So far we have 32 folk registered on the in-person sign-up sheet which is well above-average numbers 🎉 There is still capacity if folk want to come, so please sign-up soon. There will be tacos and mystery/unrevealed celebrations. https://github.com/tc39/Reflector/issues/516 [13:06:02.0909] Yeah let's put a topic on an agenda to ask for consensus on it being withdrawn; we should become comfortable taking things over when a champion leaves [13:09:04.0724] https://github.com/tc39/agendas/pull/1537 [13:09:41.0619] (this is to discuss Stage 1 proposals in general; withdrawal topics should come before the agenda deadline. I suspect we'll find a lot more things to withdraw here) 2024-01-31 [16:34:58.0143] I'm regularly disheartened that `AbortController` was standardized in WHATWG and not here. It's design privileges DOM APIs over user APIs in a way we very likely wouldn't have designed, and now were essentially stuck with something that only gets us about 50% of what the language actually needed out of cancellation. [16:35:17.0803] * I'm regularly disheartened that `AbortController` was standardized in WHATWG and not here. It's design privileges DOM APIs over user APIs in a way we very likely wouldn't have chosen, and now were essentially stuck with something that only gets us about 50% of what the language actually needed out of cancellation. [16:45:57.0943] yupppp. it's likely going to happen with observables too, and maybe with signals [18:38:04.0514] 👋 looks like I'll be there [18:38:20.0015] I don't see a particular chance of this happening with signals. I apologize that development has so far been in private; it's just been me and some framework people, trying to get something concrete and validated. All members of this group are happy to work with TC39. I expect to be able to share a draft by April at the latest (which is much later than I was expecting previously). [18:40:33.0669] I think we can recover the situation with AbortController. It will be a lot of work, though... I think many people recognize that the current state is not perfect. It's just very hard to do basic things with the current API, e.g., correctly subscribe to an AbortSignal today in a way that doesn't leak memory in certain cases. [18:41:02.0253] I've raised some concerns about observables on their issue tracker, and not yet seen a response from Google. I'm not sure how they're working towards conclusions on the many issues they have open. I don't understand what they plan to get out of an origin trial that they couldn't get with a polyfill (this isn't like new web platform capabilities--the polyfill will be complete). I worry that it will ship prematurely. [19:33:33.0769] > signals There's a Signals proposal? [19:35:23.0476] > <@jridgewell:matrix.org> There's a Signals proposal? Within Google, you can contact Jatin, Alex and Pawel within the core web infrastructure team--they are participating in very early development which is unfortunately happening in private at the moment. [22:06:21.0504] Reading the docs, it's building on Angular's signals impementation