2025-09-01 [05:19:53.0600] Curious what folks may think about this: https://es.discourse.group/t/text-modules/1031/8 [05:20:39.0493] * Curious what folks may think about this: https://es.discourse.group/t/text-modules/1031/8 (`import with { type: 'text' }`) [05:21:04.0628] * Curious what folks may think about `import ... with { type: 'text' }` (context: https://es.discourse.group/t/text-modules/1031/8 ) [06:22:36.0742] With https://github.com/tc39/proposal-import-bytes, it can be done like `import ... with { type: 'bytes' }` + `textDecoder.decode(buffer)` [06:27:26.0271] There was some appetite for it in the last meeting, strongly pushed for by eemeli [10:16:14.0066] yeah I think if someone champions it people are in favor [11:15:21.0081] I don't think I've the bandwidth for putting together an import-text proposal for the next plenary, but in case no-one else does, I can try to do so for Tokyo. [13:07:15.0493] @leaverou:matrix.org you can see the notes from the related discussion here: https://github.com/tc39/notes/pull/379/files#diff-16e44c4f2f7e8f811605c9425be9e53906830267d08666efe463e866801d96f7R355-R501 [13:50:21.0141] Here's a slightly easier and more targeted link for the above: https://github.com/tc39/notes/blob/bcdb104c5783f2d2eca39b31a1d9ab42a3aa3df0/meetings/2025-07/july-30.md#import-buffer-for-stage-1 2025-09-02 [02:17:11.0812] Back in 2021, when `Object.hasOwn()` raced all the way to Stage 4 in four months, was something like `Object.getOwn()` considered at all? I can't find any reference to such in the notes or the proposal repo. I'm currently needing to write this repeatedly in a project, and it feels a bit repetitive: ``` let x = Object.hasOwn(obj, name) ? obj[name] : undefined; ``` [02:55:52.0752] When is the Tokyo plenary? There's TPAC in Japan this year so if they're close I may be able to join too! [03:00:17.0278] It's the week after TPAC. The meeting schedule is available here: https://github.com/tc39/agendas [05:39:07.0556] Lea Verou: https://github.com/tc39/Reflector/issues/567 [08:26:42.0289] https://github.com/tc39/agendas it seems like the Sept agenda page is not created yet.. 2025-09-03 [10:02:38.0156] sorry about that, i'll make it today [15:41:34.0595] I created the agenda earlier today and was going to highlight here, but alas Matrix had an outage so could not. [15:42:02.0326] Anyway, the agenda is naturally fresh and light, so please add content! 2025-09-09 [12:40:37.0569] so I don't think it's anyone's specific job to merge the notes PRs to https://github.com/tc39/notes/pulls that Aki opens [12:40:42.0910] but it would be good to get those merged [12:40:56.0126] can we just auto-merge those after a couple of weeks? [12:40:57.0581] Chairs [12:41:09.0286] ok cc chairs 2025-09-10 [08:58:07.0517] So uh, is there a policy of cancelling a plenary if the agenda is empty? (Or empty by some point?) [08:59:47.0254] People always put stuff on last minute so I don't think it has (or is likely to) come up [09:00:12.0758] But for remote plenary we definitely skip the last day or two if possible [09:11:27.0204] I'm sure there will be more added (I intend to add something myself), but this is by far the lightest agenda we've ever had this close to the deadline. [09:27:24.0333] Please don't wait to add things to the schedule. It's better for everyone to see what's coming earlier - even if your materials are not ready yet. [09:59:54.0278] Going forward, I think we could drop one of the online plenaries from our annual cycle, and have 3 in-person/hybrid + 2 online. [10:11:42.0332] please add your input to the plenary survey if you have not already done so: https://github.com/tc39/Reflector/issues/560 [10:11:43.0886] There's an opportunity cost associated with reserving four days for something that ends up only taking one or two. This time around, there was a conference I would have liked to attend, but couldn't, because it would have overlapped with the Wednesday and Thursday plenary days. [10:15:52.0922] is said conference something that could be a conflict for other delegates? want to make sure it's on the constraints survey if so. (https://github.com/tc39/Reflector/issues/559) [10:17:40.0756] I don't think so, so I haven't included it in the constraints in the past or for the coming year. It's https://nerdear.la/, I'd be happily surprised if someone else was interested :) [11:32:05.0625] > <@softwarechris:matrix.org> please add your input to the plenary survey if you have not already done so: > > https://github.com/tc39/Reflector/issues/560 Everyone is equally welcome to update their own answers if opinions have changed over time. (Perhaps also write a note to say why in this case.) [12:24:51.0614] > <@dminor:mozilla.org> I don't think so, so I haven't included it in the constraints in the past or for the coming year. It's https://nerdear.la/, I'd be happily surprised if someone else was interested :) Knuth and Tanenbaum as speakers! [13:56:24.0121] Does anyone have further comments on https://github.com/tc39/how-we-work/pull/164? Can we land it? Who needs to press the button? [14:09:43.0861] there appear to be unresolved comments [15:07:01.0126] Chris de Almeida: Responded to the two editorial ones; the other two are basically disagreeing with the policy which we got consensus on. [15:07:15.0502] I personally think it's good to go now and people can add further refinements in follow-ups. 2025-09-11 [21:50:20.0188] Are PR previews broken ? Looks like the upload job has been broken for a few months [21:50:38.0546] * Are PR previews broken ? Looks like the upload job has been failing for a few months [21:50:47.0035] yes [21:51:00.0350] I have a PR fixing it which is ready to go https://github.com/tc39/ecma262/pull/3679 [21:51:06.0696] cc ljharb [21:52:41.0559] I might rebase my PR on that :p [21:53:10.0703] won't work [21:53:43.0239] ah yeah it's using `pull_reqest_target`, oh well [21:53:49.0871] * ah yeah it's using `pull_request_target`, oh well 2025-09-12 [00:04:31.0295] Hello all, The stage advancement deadline for the September plenary is eight hours away. There is now a decent amount of agenda content. https://github.com/tc39/agendas/blob/main/2025/09.md [11:43:35.0772] The agenda looks to be about 8h in total. Could we already now cancel the last day of the plenary? Or alternatively, cancel all/some of the "afternoon sessions"? I have some personal interest here, as in my timezone that would mean we'd finish at 8pm rather than 11pm. [11:43:53.0225] * The agenda looks to be about 8h in total. Could we already now cancel the last day of the plenary? Or alternatively, cancel all/some of the "afternoon" sessions? I have some personal interest here, as in my timezone that would mean we'd finish at 8pm rather than 11pm. [12:15:43.0763] We are not going to signal any cancellation of sessions until and unless we are absolutely certain that we won't need the time. There are several days remaining for folks to add topics and constraints, but you're right -- as of now the agenda is looking relatively light. In the recent past when we have signaled that we MIGHT be ending early, some folks interpreted that as a strong signal and made their plans accordingly. This resulted in the absence of some folks during part of plenary -- a situation we are keen to avoid in the future. 2025-09-15 [08:55:24.0218] I am concerned about some proposals going for Stage 1 at the upcoming meeting with a particular API name as the proposal name. *Please* don't do this. Proposals should be named after the problem they're solving, not the champion's assumed or preferred solution at the time of presenting for Stage 1. [14:19:22.0709] As the "upsert" champion, I strongly second this :) [14:36:40.0412] Documenting that strings-as-enums are kebab-case: https://github.com/tc39/how-we-work/pull/165 2025-09-16 [23:46:37.0410] And then Intl comes, using both "camelCase" and "with spaces" in the options bag of a single function 😅 [00:20:59.0308] Where's the "with spaces" style used? I thought Intl was pretty consistently camelCase. [00:21:40.0047] For localeMatcher [00:22:33.0798] Ah, true. And then of course we also have "2-digit" in a few places as well. [00:23:45.0010] Thankfully "best fit" is the localeMatcher default, so it ~never shows up in real code. 2025-09-17 [17:29:21.0745] I don't think anyone will ever be able to top `XMLHttpRequest`. It has uppercase and pascal case. Not to mention its not related to XML at all. 😂 [20:19:39.0607] Ah, so you have not heard of SpOnGebObcAsE. [20:20:13.0254] Ah, well, an argument can be made that XMLHttpRequest is worse. [00:28:17.0287] > <@michaelficarra:matrix.org> I am concerned about some proposals going for Stage 1 at the upcoming meeting with a particular API name as the proposal name. *Please* don't do this. Proposals should be named after the problem they're solving, not the champion's assumed or preferred solution at the time of presenting for Stage 1. I have one of those, but I really can't imagine another name given the isError and isArray precedent. [00:29:01.0335] I guess promise predicate would be another option. [00:30:15.0663] * I guess promise predicate would be an option for the proposal name [05:32:10.0308] > <@mhofman:matrix.org> I have one of those, but I really can't imagine another name given the isError and isArray precedent. I suggested some names in the issue I opened https://github.com/mhofman/proposal-is-promise/issues/4 [07:02:14.0450] I also opened an issue about how I think isPromise isn't actually the best name for the API, which reinforces my point about the proposal name https://github.com/mhofman/proposal-is-promise/issues/3 [09:09:49.0490] I mean, I'm not sure how much more generic one would have been able to make a proposal that was initially about whether or not something was a promise. If the proposal ends up significantly genericizing, that's just something unpredictable. [09:18:21.0407] Read the motivation for the proposal in the README. It's about detecting whether the value is treated specially by `await`. `isPromise` is clearly an assumption about how we would do that. [09:18:53.0502] I mean, sure, but also I think it's a *very* reasonable assumption that "`await` cares about promises" [09:18:57.0407] (in some way) [09:19:10.0641] I'm also not trying to pick on @mhofman:matrix.org or this proposal in particular. At the time of writing my original complaint, I hadn't even read the proposal. 2025-09-18 [00:14:34.0886] I did consider picking another name for the proposal (which I've now updated) but originally chose proposal-is-promise since I believe any solution is basically gonna be a variation of this. Anyway, I guess we'll be debating this next week. [13:26:54.0097] draft schedule link is up on the Reflector: https://github.com/tc39/Reflector/issues/568 [13:27:08.0754] * 📢 draft schedule link is up on the Reflector: https://github.com/tc39/Reflector/issues/568 2025-09-20 [17:56:19.0381] Something is confusing me about AsyncGeneratorStart / AsyncGeneratorCompleteStep. Is the return value of an async generator not awaited? Does that mean the final iterator result may have a promise as its `value` ? From my testing that doesn't seem to be the case, but I don't see how that's happening in the spec. ``` (async function * () { return Promise.resolve(42); })().next().then(x => console.log(x)); // { value: 42, done: true } ``` [18:21:55.0198] awaiting of `return` values actually happens as part of the evaluation of the `return` itself [18:22:02.0510] https://tc39.es/ecma262/multipage/ecmascript-language-statements-and-declarations.html#sec-return-statement-runtime-semantics-evaluation [18:24:48.0381] Oh that is wild! [18:32:01.0010] This way it triggers finally statements [18:32:05.0803] Which, also kinda weird [19:59:07.0594] I'm not sure I understand, `finally` always executes if a `return` is in a `try`. Internally awaiting the return expression shouldn't change that. And if there was a `catch` it shouldn't trigger it, in the same way `yield`ing a rejected promise only triggers a `catch` if the consumer of the iterator called `throw`. (I might have gotten myself confused again with generator behaviors and afk so can't easily double check) [21:08:16.0729] sorry, I meant `catch` not `finally` [21:08:21.0429] and it doe trigger a `catch` [21:08:37.0974] ``` (async function*(){ try { return Promise.reject('hi'); } catch (e) { console.log('caught', e); } })().next() // caught hi ``` [21:09:13.0006] this is in contrast to async functions ``` (async function(){ try { return Promise.reject('hi'); } catch (e) { console.log('caught', e); } })().catch(e => console.log('did not catch', e)) // did not catch hi ``` [21:09:53.0187] yielding a rejected promise does also trigger a `catch` incidentally [21:10:18.0504] which I am pretty sure is why `return` works that way in async generators [00:20:21.0718] Well at least it's consistent. And now that you mention it, I think I knew that and just forgot about that oddity.