2023-07-05 [02:04:16.0414] [The September Tokyo plenary invite](https://github.com/tc39/Reflector/issues/499) is now posted on the Reflector. If anyone needs support on visas (e.g. generating an invite letter from the host), please let me know. It is just under 12 weeks away. [04:56:12.0750] Note that we are working on a community event the evening before, on the 25th. [07:20:55.0627] oops i didn't see this before, thanks for this! i actually didn't mean to include that slide, ha! [12:13:57.0838] https://github.com/tc39/agendas/pull/1423 ☝️ this is a low-stakes change, but would be nice to get some more blessings on it 2023-07-06 [01:59:18.0773] https://docs.google.com/presentation/d/1m5R5J98W6adegghgkAlbSuFgAYJDT52yyFVdAqLjm00/edit#slide=id.geaea8d83af_0_4 [01:59:27.0695] https://github.com/tc39/proposal-iterator.range/issues/60 https://tc39.es/proposal-iterator.range/#sec-create-numeric-range-iterator [01:59:35.0049] also in Iterator.range [10:01:29.0622] https://github.com/tc39/proposal-integer-and-modulus-math appears to have Issues turned off so I can't comment on it. littledan ? [10:20:05.0849] they're on afaict [10:20:12.0632] * they're on afaict - https://github.com/tc39/proposal-integer-and-modulus-math/issues [10:20:26.0139] * TabAtkins: they're on afaict - https://github.com/tc39/proposal-integer-and-modulus-math/issues [10:21:04.0036] Wth, nothing was there on my desktop 2023-07-09 [05:06:20.0083] Do we already have a matrix room for the in-person participants to the meeting? [05:09:04.0578] I don't think so [05:15:50.0048] Please create one, Nicolo! [10:43:59.0133] nicolo-ribaudo: can you link the room here or send me an invite? [10:55:31.0958] You already joined it some hours ago 😅 [11:09:18.0673] I am so confused [11:09:52.0993] I have been in transit for far too long [11:11:37.0939] I literally thought I imagined that lmao 2023-07-10 [00:47:17.0133] wait 10am in Oslo is 5pm in Tokyo? [00:47:19.0423] wild [03:50:50.0254] Sorry if this is a basic element/matrix question, but how do I join the TC39 space, like the thing that organizes all of the TC39 rooms into one view? [03:51:45.0811] https://matrix.to/#/#tc39-space:matrix.org try this [03:51:55.0289] https://matrix.to/#/#tc39-space:matrix.org [04:30:05.0188] Well, it looks like that should work, but my element client just spins on `loading` for 30 minutes :/ I'll try again later. [05:51:59.0214] Is anyone available to dial into zoom to help confirm AV in 20 mins time? [06:00:12.0717] I'll try the zoom from the hotel Wi-fi [06:08:35.0032] Thanks, Ashley [06:10:14.0035] ping me a link when you're ready [06:54:05.0941] Works now, thanks for the help :) [15:42:13.0216] Chairs: Any concern if I extend the timebox for the Explicit Resource Management update by 15 minutes to cover a suggestion that came up last week? The schedule currently calls for a 15 minute underflow on the day/time I'm currently scheduled to present. If that's not feasible, I'll see what I can squeeze in in the time I have available and offer to discuss further with interested parties after the plenary. 2023-07-11 [18:25:52.0330] rbuckton: you got it [00:31:33.0476] The sign-in form is now posted if you wish to dial into the Zoom for today's plenary: https://github.com/tc39/Reflector/issues/473 [00:49:58.0332] Please could someone attempt dial in so we can confirm AV is working [01:01:52.0052] it's working [01:02:02.0596] * it's working (zoom web) [01:18:25.0714] huh, "OramaSearch" is new to me; any delegates from them here today? [01:18:36.0784] Michele Riva is the delegate, I think? [01:18:45.0192] yeah [01:18:52.0250] it's a new org [01:20:03.0996] i found the voice quality is bad... i need more effort to heard what are the meetings talking about [01:28:58.0433] Jack Works: is it one person's voice quality? [01:31:46.0692] > <@robpalme:matrix.org> Jack Works: is it one person's voice quality? it's the in-person one [01:32:59.0612] The whole room is "hot". Meaning all mics on the whole time. So we need everyone to avoid noise unless they are speaking, e.g. placing cups down gently. [01:34:37.0740] Rob Palmer: Although it would be possible to mute each mic directly, because they have a direct mute button. [01:35:40.0179] That is a good point - lets try using that [01:41:53.0253] Yeah, this does look nicer! Thanks editors [01:44:57.0772] tcq does indeed appear to be down [01:45:04.0842] chaos :( [01:46:45.0808] I don't even know what to do without TCQ anymore [01:47:12.0593] we are now 100% dependent [01:47:13.0374] A google doc with someone manually sorting the items by priority? [01:47:54.0823] current discussion is not audible remotely [01:48:30.0154] Sorry! We forgot to unmute; it was about missing conclusions. [01:49:42.0120] Just give us a nod and we will signal, unmute. [01:52:40.0196] is TCQ still just running off of some Azure account Brian is expensing? [01:54:16.0507] bakkot: Looks so -> https://github.com/bterlson/tcq/blob/b5be1287a6843f24dc570c1d951d1c26ac566d66/src/server/db.ts#L1C14-L1C18 [01:55:49.0783] why is #783 being done as a needs-consensus PR and not a staged proposal? [02:00:32.0459] I don't think it's that useful to make things like this optional? [02:00:41.0029] at least not optional for web browsers [02:00:50.0660] as a programmer I am going to want to rely on their existence [02:00:55.0438] +1 [02:01:11.0604] and as a user I'm going to be annoyed if the page behaves differently in my browser than the one the developer was using [02:01:57.0939] but when it comes to internationalization, that's bound to happen, right? [02:02:05.0159] I mean, I totally agree with the general sentiment [02:02:54.0023] ... is it? [02:03:01.0769] bakkot: ligatures and opentype features are optional; that doesn't make a font not useful [02:03:25.0043] > <@usharma:igalia.com> but when it comes to internationalization, that's bound to happen, right? well, we still try to limit the scope of this [02:03:36.0561] > <@bakkot:matrix.org> ... is it? it is because different browsers make different tailorings of the data [02:05:32.0991] sffc: Can you link to that PR for number format for the notes? [02:05:45.0188] oops it's in TCQ [02:05:46.0250] https://github.com/tc39/proposal-intl-numberformat-v3/pull/130 [02:09:01.0571] > <@michaelficarra:matrix.org> I don't even know what to do without TCQ anymore There is a defined backup plan involving a spreadsheet. [02:09:27.0488] good to hear! [02:10:25.0322] someone is typing surprisingly loudly? [02:10:29.0927] does import attr support boolean values? [02:10:55.0269] I think it may be ryzokuken 🇳🇴 aggressively typing. [02:11:16.0168] > <@haxjs:matrix.org> does import attr support boolean values? no [02:11:25.0796] I think it is littledan just surprisingly close to the mic [02:11:52.0528] Is someone typing on an open mic? [02:12:20.0835] sorry that may be me. Is it fixed now? [02:12:25.0935] (I moved off of the table) [02:12:38.0389] there are not currently typing noises [02:13:34.0084] > <@jackworks:matrix.org> no If support boolean I would like it also support `null` :) [02:14:16.0015] HE Shi-Jun: Jack Works: I would oppose that because I want to keep a future open where we do not ToString these value [02:15:17.0439] yeah I like keeping the restrictions tight until there are concrete things we want to loosen them for [02:15:52.0249] definitely I can imagine features where we'd want `true`, `false`, `null` etc but I think we can come back when that's relevant? [02:15:55.0320] we do ToString for attribute values now? [02:16:05.0743] otoh I guess this is partially for bundlers to build out there own things so maybe that doesn't make sense [02:34:23.0743] I support auto deferral in this case, but I don't want this or iterators to be considered precedent to justify auto deferring in future proposals [02:43:02.0107] could someone remind me what "hint" means in this context? [02:43:15.0233] it's an alias in the spec [02:43:15.0834] it means "flag" in practice [02:43:19.0440] it's a silly name [02:43:35.0402] it's used in places where we provide an AO with context about its use [02:44:18.0802] so it's not something specific to the syntax for Explicit Resource Management, then. Thanks [02:44:33.0013] yeah, I always assumed that it was a contextual hints from the caller, as in toPrimitive [02:44:34.0259] correct, entirely spec internal [02:44:45.0428] * yeah, I always assumed that it was a contextual hint from the caller, as in toPrimitive [02:44:46.0996] > <@bradfordcsmith:matrix.org> so it's not something specific to the syntax for Explicit Resource Management, then. Thanks Well, in this specific case the hint is whether we are using `using` or `await using` [02:45:18.0103] hmm, I would've said the word "context" is better but at this point it's so overloaded that it's probably not [02:45:50.0132] same with "flag" [02:48:39.0885] ptomato (at TC39, limited availability): It is not possible unless we want all the `const` and `let` declaration to perform property access [02:52:05.0891] or if we change the semantics of `using`, like suggested here [02:52:16.0159] > <@nicolo-ribaudo:matrix.org> ptomato (at TC39, limited availability): It is not possible unless we want all the `const` and `let` declaration to perform property access Oh well, the resource could throw if it's used before accessing its `[Symbol.dispose]` property [02:52:49.0591] that's kinda cute actually [02:53:04.0025] And also, it is totally reasonable to move around disposables using `let` or `const`, before passing it to a `using` [02:53:08.0261] but probably confusing [02:53:25.0187] if we want to seriously consider Symbol.enter, we should demote this proposal to Stage 2 [02:55:58.0663] > <@lucacasonato:matrix.org> And also, it is totally reasonable to move around disposables using `let` or `const`, before passing it to a `using` I don't quite understand how you envision this [02:56:18.0885] littledan: I think it works fine as a follow-on [02:58:48.0537] this is not the kind of thing that will be good to have a compatibility matrix around. It's also not some complicated uncertain technology--we know the design space already. [03:00:11.0620] littledan: Are you concerned about avoiding a future where some disposables are wrapper objects that pseudo-enforce use of `using` and some are not? [03:00:45.0616] it will be annoying to have to reason about different possible ways that this protocol could be implemented, in general. Possible, but annoying [03:01:33.0965] Queue: Reply: Concern with disposers that throw exception in GC for embeddings Philip Chimento 2 New Topic: I am not in favour of recommending GC based cleanup. Should -> may? Luca Casonato (@denoland) 3 New Topic: Is it possible to enforce use of `using` in the language, rather than in tooling Philip Chimento 4 New Topic: Test sanitizers can be used to help with this Luca Casonato (@denoland) 5 New Topic: I support looking into the @@enter/@@asyncEnter, possibly part of this proposal. Michael Saboff [03:02:16.0960] thanks, could we perhaps also put this in the notes so we have a copy stored? [03:03:53.0942] is tcq.app down for anyone else? The console says ``` WebSocket connection to '' failed: WebSocket is closed before the connection is established. wKFO:1 Unchecked runtime.lastError: The message port closed before a response was received. ``` [03:04:03.0581] yeah, it's down again [03:09:53.0928] To clarify, I am fine with not providing a recommendation to ensure cleanup if a disposable is dropped on the floor, regardless as to the practice in other languages. It was brought up in #159 as one of the concerns about dropping a disposable is that native handles that are usually just tracked by a `number` value can leak and are not visible in a heap dump. [03:11:23.0275] That said, it is feasible to implement a "cleanup on GC" behavior using `FinalizationRegistry` in user code if needed, given that's one of `FinalizationRegistry`'s use cases, and such behavior already exists in NodeJS for many native handles. [03:24:49.0138] Regarding the `Symbol.enter` suggestion, I have been considering the following as a follow-on proposal: `Symbol.enter` (or `Symbol.enterContext`?) - indicates a method that, when invoked, enters a context and returns a value associated with that context. This method is optional, and if missing is implicitly handled as if the definition was: ``` [Symbol.enter]() { return this; } ``` `Symbol.exit` (or `Symbol.exitContext`?) - indicates a method that is invoked when the context is exited at the end of the block. Receives two arguments, `hasError` and `error`, that indicate whether an exception occurred prior to context exit. The method may return `true` to inform the caller not to throw `error` (swallowing the exception). Any other return value is ignored, indicating the caller should throw `error`. The method may also choose to throw its own error, but should not throw `error` itself. This method is also optional, and if missing is implicitly handled as if the definition was: ``` [Symbol.exit](hasError, error) { try { this[Symbol.dispose](); } catch (e) { if (hasError) { throw new SuppressedError(e, error); } else { throw e; } } return undefined; } ``` Thus, `[Symbol.dispose]()` on its own would constitute a lightweight context manager. [03:28:48.0847] Things do become more complex for async context managers, however, given that they must `await` the result of `[Symbol.asyncEnter]()` if we were to adhere to the Python design. `await using x = y` would potentially Await twice: once at the declaration site in the presence of a `[Symbol.asyncEnter]()` method, and once at the end of the block for the `[Symbol.asyncExit]()` or `[Symbol.asyncDispose]()` call. [03:31:45.0193] Finally, `AsyncDisposableStack.prototype.use` becomes *slightly* more complicated as it may return a `Promise` if the resource that is passed to `use` is an async context manager. `use` itself doesn't necessarily need to become async, however, since all it needs to do is return the result of calling `[Symbol.asyncEnter]()`. If you were to pass in a sync context or a disposable, it would not need to return a `Promise`. [03:32:56.0584] Context managers are extremely powerful, but also extremely complex, which is why I have been reticent to consider them for this proposal. [03:36:08.0463] I also didn't want the general purpose `[Symbol.dispose]` behavior to be complicated by the error handling and error suppression semantics of `__exit__`, as the majority of cases related to resource management have no need of that complexity. [04:08:10.0949] you may come back ljharb Chris de Almeida [04:08:13.0713] Please return to the Zoom [04:10:08.0221] > <@usharma:igalia.com> I don't quite understand how you envision this ```js const resource = createResource() promises.push(doSomethingWithResource(resource)); async function doSomethingWithResource(resource) { using r = resource; ... } `` [04:10:15.0808] > <@usharma:igalia.com> I don't quite understand how you envision this * ```js const resource = createResource() promises.push(doSomethingWithResource(resource)); async function doSomethingWithResource(resource) { using r = resource; ... } ``` [04:19:44.0993] littledan: My preferred source-maps scope change would be to expand the two "including ECMAScript code" mentions to be something like "including CSS and ECMAScript code". [04:21:49.0741] -> https://notlaura.com/is-css-turing-complete/ [04:28:06.0197] Thank you for ensuring that the CoC Committee member list is accurate [04:28:08.0901] with the pruning [04:28:12.0080] and thanks to new volunteers [04:34:55.0982] The delegate's organization is not listed in https://github.com/tc39/notes/blob/main/delegates.txt. Is that information available somewhere? [04:35:37.0309] We are divided in teams in the tc39 GH org based on our org [04:35:41.0292] * We are divided in teams in the tc39 GH org based on our organization [04:35:43.0747] * We are divided in teams in the tc39 GH org based on our organizations [04:36:25.0754] Example: https://github.com/orgs/tc39/teams/member-igalia [04:36:49.0356] Thanks for that reminder. I still don't really know how to "look up" the information that way. I mean go from name/abbreviation -> organization [04:37:01.0761] so, the public calendar email address to invite will be shared with the committee to make events public? [04:37:37.0280] Bradford Smith: type their name here: https://github.com/orgs/tc39/teams/eligible-meeting-participants?query=membership%3Achild-team [04:44:09.0800] yes [04:45:02.0712] I'm confused, don't only the chairs have edit access? [04:45:22.0193] the public calendar is managed by way of the private calendar [04:45:43.0664] yes, I mean edit access to the private calendar [04:45:52.0817] no, we can all edit the private calendar [04:46:01.0136] not everyone can edit it [04:46:07.0997] several people have permission though [04:46:18.0736] https://github.com/tc39/how-we-work/issues/94#issuecomment-1518375862 [04:46:38.0625] calendar id there is the address to invite the public calendar to a private calendar meeting [04:47:01.0032] as discussed, we will place this information in a more accessible place rather than buried in a GH issue [04:48:22.0110] we should document some points of contact who have edit access so it's not ambiguous who to contact when needing to make calendar updates [04:48:55.0502] at the very least the chairs, but other folks with edit access may be willing to make themselves available for this purpose [04:49:06.0971] i've been fielding calendar update requests for awhile [04:49:31.0461] I think the admin role is perfect for this tbh [04:49:33.0674] * i've been fielding calendar update requests for awhile fwiw [04:49:52.0354] so it makes sense for you to be among the listed contacts ljharb [04:49:54.0835] maybe we should give edit access somewhat more broadly? [04:50:16.0756] I don't really see why I should have more access than others [04:50:32.0879] I think we have a high enough degree of trust within the committee to share edit access to the calendar more broadly, yes [04:50:48.0997] like the calendar edit permission is not really that critical now that I think about it [04:50:50.0081] that said, calendar management can be tricky and it's really easy to accidentally fire off dozens of email notifications [04:51:01.0635] true [04:51:02.0722] * that said, calendar management can be tricky and it's really easy to accidentally fire off dozens of email notifications, and there's no audit log to restore deleted events [04:51:36.0474] > <@ljharb:matrix.org> that said, calendar management can be tricky and it's really easy to accidentally fire off dozens of email notifications, and there's no audit log to restore deleted events In fact it looks like the source map meetings might've been randomly deleted or something [04:52:07.0727] oof, ping me with the deets you want and i'll be happy to set it back up [04:52:32.0144] > <@ljharb:matrix.org> that said, calendar management can be tricky and it's really easy to accidentally fire off dozens of email notifications, and there's no audit log to restore deleted events I guess that makes sense given that those operations are not actually part of the calendar protocol [04:52:49.0996] yeah I'm fine with delegating the calendar management as long as the people are decently responsive [04:52:52.0625] the calendar protocol is weird actually, but maybe you have some degree of a backlog in your emails [04:53:07.0891] or CalDAV [04:54:08.0837] source maps still on my calendar, but not on the tc39 calendar [04:54:33.0292] it's 2023 and calendaring is still in the dark ages [04:54:46.0907] TG5: Calendar Spec [04:55:29.0626] Chris de Almeida: 100% seriously I've been thinking about it a lot lately [04:55:34.0242] and trying to fix that somewhat [04:56:05.0939] I'd support you [04:57:42.0176] littledan: so actually for the loop bound recomputation bugs there are already tests AFAICT [04:58:09.0969] (marja implemented and wrote the tests for them, but i didn't correctly fix the spec draft) [04:58:14.0402] syg: I wonder if throwing if there was a concurrent too-large grow makes sense, since if the concurrent grow happens just after this thread's grow returns, you'd still have a too-large buffer when you try to use it [04:58:18.0684] the only one missing is the detach timing [04:58:46.0734] * shu: I wonder if throwing if there was a concurrent too-large grow makes sense, since if the concurrent grow happens just after this thread's grow returns, you'd still have a too-large buffer when you try to use it [04:58:47.0436] Andreu Botella: you mean throwing if there is _any_ race? [04:59:18.0103] i don't think so, because racing for too-large cannot be reliably detected [04:59:37.0176] no, I mean you'd still have a race in user code if the concurrent grow happens just a bit too late [04:59:46.0784] right, you can't detect that [04:59:57.0035] so why try to detect it inside the loop? [05:00:15.0695] well, I guess you'd have to detect it anyway, but why throw [05:00:24.0443] the race inside the loop is for the opposite case, where grow(10) races with grow(20) [05:00:32.0321] https://github.com/tc39/proposal-array-grouping/issues/57 [05:00:35.0443] and grow(20) happens first, and grow(10) is now a shrink [05:00:38.0615] and is disallowed [05:00:49.0337] it's throwing not because of a race per se, it's throwing because shrinks already throw [05:01:07.0247] you could have it silently do nothing, that's a possibility [05:01:09.0094] After a grow, you know the SAB is *at least* the size you've grown it too [05:01:15.0527] so I'm not thinking of the grow(10) as a shrink [05:01:21.0051] maybe a user might [05:01:32.0322] * maybe a user might though [05:02:05.0767] that's fair, this could be relaxed, but it's shipped with these semantics already and i don't feel particularly compelled to change it [05:02:13.0487] oh, right, a slightly-too-late grow(10) would indeed throw [05:02:21.0297] that makes sense then [05:02:22.0007] the actual answer is just... don't race your grows [05:02:23.0926] synchronize another way [05:03:16.0858] I understand that but given the level of abstraction we work on, couldn't we do a bit of hand holding here? [05:03:36.0345] make it a bit harder to run into this issue to begin with to whatever extent we can [05:04:07.0424] > <@shuyuguo:matrix.org> that's fair, this could be relaxed, but it's shipped with these semantics already and i don't feel particularly compelled to change it oh, this is quite compelling, nvm [05:04:27.0025] > <@usharma:igalia.com> I understand that but given the level of abstraction we work on, couldn't we do a bit of hand holding here? yeah I think this is generally not the right kind of thing to do with low-level concurrency primitives [05:05:11.0115] So, should we have a brief overflow topic to get through the conditionality? [05:05:20.0725] if msaboff expects to review it tonight [05:05:59.0809] it has not really been helpful to replace what we were calling "conclusion" with "summary". The idea was to be more detailed. [05:06:17.0467] agreed with littledan, i think hand-holding lock-free concurrency stuff is just not a good idea [05:06:18.0216] we've had a conclusion for a long time [05:07:01.0905] the request from this morning is just that we don't forget to add a conclusion [05:07:56.0271] this is false. The request from Ecma has been to add summaries. We had been adding conclusions previously. [05:08:23.0330] I'm really confused by the resistance from the committee to summaries. I really think they would make the notes more accessible. [05:08:42.0882] the idea is to cover the main points in the presentation and discussion, not only the things we got consensus on [05:09:08.0246] if a delegate doesn't want to write a summary, that's OK, but I don't understand why they should oppose others writing summaries... [05:10:49.0452] i don't recall any opposition to someone just going in and adding a summary - i thought the opposition was just to pausing the meeting and/or asking champions to write a summary [05:11:07.0858] * i don't recall any opposition to someone just going in and adding a summary - i thought the opposition was just to pausing the meeting and/or asking champions to write a summary, but maybe i'm not remembering right [05:21:34.0330] the summaries (with or without a conclusion) are very helpful. it takes only a moment for the speaker to dictate a summary. I don't think there's a lot of controversy with this, but in the past IIRC it was only because it was perceived to take up too much committee time. but I think that was also when we were sitting there waiting for the speaker (or someone else) to type up the summary, whereas it should just be dictated, which should only take a moment, and can be cleaned up async as needed [05:22:45.0343] so yes, Jordan is right that it was in opposition to pausing the meeting. it's such a small sacrifice though and is a lot easier to do when it's timely [05:24:23.0552] but 100% almost every time in recent memory where I needed to refer to meeting notes, it was so helpful to have those summaries rather than having to scour the entire dialog [05:24:31.0004] * 100% almost every time in recent memory where I needed to refer to meeting notes, it was so helpful to have those summaries rather than having to scour the entire dialog [05:38:44.0161] syg: The profile ^^ [05:43:01.0547] ljharb: if you don't use namespace imports, you will have effects triggered on reading a local [05:43:11.0229] reading a local shouldn't have an effect [05:44:48.0092] i agree with that [05:45:08.0092] that doesn't mean `import *` is any more palatable tho [05:45:23.0883] > <@ljharb:matrix.org> that doesn't mean `import *` is any more palatable tho Do you have any other suggestions? [05:45:44.0068] > <@michaelficarra:matrix.org> reading a local shouldn't have an effect `with` would like a word /s [05:46:05.0684] "why not `with` but *everywhere*?" [05:46:47.0664] I don't understand current page... [05:47:16.0716] > <@littledan:matrix.org> Do you have any other suggestions? no, the design goals of ESM didn't really leave many options here i can see :-/ [05:47:38.0436] > <@michaelficarra:matrix.org> reading a local shouldn't have an effect but imported variable isn't a local. [05:47:47.0719] sure it is [05:47:58.0622] like it could be `import with` instead of `import defer`? [05:48:01.0096] personally i think some magic like `with` is acceptable in this specific case :) [05:48:03.0070] altho it's slightly different in that its value can change out from under you [05:48:15.0287] * altho it's slightly different in that its value can change out from under you if the export is a `let` that's reassigned [05:48:30.0539] > <@ljharb:matrix.org> no, the design goals of ESM didn't really leave many options here i can see :-/ I don't really understand why the namespace restriction is fatal, but I guess you'll explain in your queue item? [05:48:46.0419] i didn't say it was fatal. but yes, i will [05:48:58.0855] * i didn't say it was fatal. but yes, i will elaborate on my queue item [05:49:09.0148] * like it could be `import with` instead of `import defer`? (joking) [05:49:31.0238] * i didn't say it was fatal. but yes, i will elaborate on my queue item (i just combined my two into one) [05:49:38.0708] I support allowing `import defer { ... }`, we have already using it by the webpack implementation and we found enforcing a namespace is somewhat a bad DX . [05:50:25.0662] in our use at Bloomberg, we've found that the restriction to a namespace is a little annoying but not really that bad [05:50:58.0852] bakkot: adding TLA to a module is already a breaking change i think [05:51:07.0360] the more significant thing is the decision about whether to include deferred * re-exports (coming later in the slides, proposed to discuss during stage 2) [05:51:10.0177] > <@lucacasonato:matrix.org> sent an image. is the second column milliseconds? [05:51:18.0316] > <@ljharb:matrix.org> bakkot: adding TLA to a module is already a breaking change i think well. ot [05:51:33.0009] > <@ljharb:matrix.org> bakkot: adding TLA to a module is already a breaking change i think * well. it's observable but it's intended to not be quite breaking [05:52:02.0676] > <@danielrosenwasser:matrix.org> is the second column milliseconds? i think either function call count or sample count - but I don't know for sure [05:52:17.0953] i believe there's nonzero use cases where if a module starts using TLA, things will break - i forget which off the top of my head tho [05:52:31.0102] > <@littledan:matrix.org> in our use at Bloomberg, we've found that the restriction to a namespace is a little annoying but not really that bad I wonder if we could employ a heuristic where named imports that are only used in functions are deferred until the first function call? [05:53:55.0166] > <@ljharb:matrix.org> i believe there's nonzero use cases where if a module starts using TLA, things will break - i forget which off the top of my head tho If it has side effects and a module that does not list it as a dependency relies on its side effects [05:55:02.0965] hm, that's not what i was thinking of, but since i can't recall specifics rn, ¯\_(ツ)_/¯ [05:55:05.0042] i.e.: ```js // a.js import defer * as ns from "foo"; // defer until `ns` property accessed. // b.js import defer { a, b } from "foo"; export function f() { console.log(a, b); } // defer until `f` is called // c.js import defer { a, b } from "foo"; console.log(a, b); // not actually deferred ``` [05:55:08.0139] * hm, that's not what i was thinking of, but since i can't recall specifics rn, ¯\\\_(ツ)\_/¯ [05:55:23.0649] > <@ljharb:matrix.org> i believe there's nonzero use cases where if a module starts using TLA, things will break - i forget which off the top of my head tho for well-behaved graphs I don't think it's ever breaking; it's only if there's weird side-effect ordering problems that it breaks [05:56:27.0366] > <@rbuckton:matrix.org> I wonder if we could employ a heuristic where named imports that are only used in functions are deferred until the first function call? fwiw that seems like too much magic to me [05:56:47.0885] > <@bakkot:matrix.org> for well-behaved graphs I don't think it's ever breaking; it's only if there's weird side-effect ordering problems that it breaks we've hit that. we have code `onAppInstall.addListener(...)` which the callback is _only_ called if the callback is registered in 1st event loop. [05:57:37.0460] > <@bakkot:matrix.org> fwiw that seems like too much magic to me `defer` itself is too much like magic [05:58:08.0841] the thing where the namespace object implicitly has side-effecting accessors is, just barely, not too magic for me [05:58:19.0640] the previous suggestion of having local access be side-effecting was too magic [05:58:24.0891] but property access can already be side-effecting [05:58:28.0838] bakkot: Most places I have seen TLA in is leaf modules (for example Wasm loading), or the top level entrypoint (for example data fetching in a CLI). In my experience TLA anywhere between entrypoint and leaf is very rare. [05:58:30.0912] you can explain this feature in terms of existing ones [05:58:37.0248] * you can (mostly) explain this feature in terms of existing ones [05:58:38.0417] it still feels too magic to me tbh [05:58:40.0307] so it is, just barely, ok with me [05:58:56.0073] > <@lucacasonato:matrix.org> bakkot: Most places I have seen TLA in is leaf modules (for example Wasm loading), or the top level entrypoint (for example data fetching in a CLI). In my experience TLA anywhere between entrypoint and leaf is very rare. why would wasm loading be a leaf? [05:59:00.0824] wasm is just like... code [05:59:08.0479] > <@rbuckton:matrix.org> `defer` itself is too much like magic but also, determining whether named imports are lexically scoped to functions is statically analyzable, with the exception of direct-`eval` (which could just block deferred evaluation anyways). [05:59:24.0022] +1 I don't think it's magical for the `ns` case. Direct import binding is a little bit magic but also good to me. [06:00:17.0505] > <@bakkot:matrix.org> why would wasm loading be a leaf? ... because it needs to be passed an imports object? how can it not be a leaf? [06:01:51.0372] I guess I mean a difference sense of "loading" [06:02:00.0740] yes, loading the bytecode is a leaf, of cousre [06:02:03.0623] * yes, loading the bytecode is a leaf, of course [06:03:02.0537] but if you have a library which has a wasm component, it seems like "TLA to async-compile the wasm" is a pretty normal use case [06:03:56.0303] which means your library's entry point would have a TLA, not just the leafs of the library [06:05:57.0951] i don't think i'm confused [06:06:08.0207] i'm saying in JS, compilation can be transparently deferred and folded into evaluation [06:06:19.0838] in wasm because timing is of a bigger concern, it cannot be generally transparently deferred [06:06:54.0635] I also want to notice the deferred is not only the compilation happened in the engine, but also the _execution_ of the JS code [06:06:55.0388] and the motivating number of "half the time spent in evaluation" as shown by the profiler output suggests that that includes main-thread deferred compilation [06:07:07.0677] well yes, obviously the execution is the main thing to be deferred [06:07:16.0402] i'm questioning the "half the time" measure and what it includes [06:07:18.0551] https://developer.mozilla.org/en-US/docs/WebAssembly/JavaScript_interface/Instance/Instance#syntax says in a big red box, "Warning: Since instantiation for large modules can be expensive, developers should only use the Instance() constructor when synchronous instantiation is absolutely required; the asynchronous WebAssembly.instantiateStreaming() method should be used at all other times." [06:07:58.0049] ^ This is about the sync constructor after you already have an async compiled Module [06:08:01.0853] for example https://github.com/alexcorvi/anchorme.js/pull/127 this library cost 30ms to init (this PR is reverted by the author). We now using `defer` to save this 30ms [06:08:11.0708] > <@shuyuguo:matrix.org> i'm questioning the "half the time" measure and what it includes right, the thing is, we have a whole bunch of data about the benefit of this, and the champions were conservative about what they included on slides. I think it's reasonable that you ask how much benefit this will get on the web. [06:08:28.0228] I would point out, though, that when it's a cache hit, the fetching and compiling part might be pretty quick [06:08:30.0139] i'm convinced it's a win for JS for sure [06:08:57.0427] the wasm questions got me doubting about how well the performance story composes [06:08:58.0946] Synchronous lazy loading in CommonJS is sometime known as "inline requires". Jest managed to [half their startup time](https://jestjs.io/blog/2016/03/11/javascript-unit-testing-performance#inline-requires-and-lazy-mocking) by incorporating this technique. [06:09:03.0020] or are we also introducing performance footguns [06:09:17.0379] I guess I don't understand the performance breakdown case [06:10:35.0663] you're all right that we should investigate this better for Wasm. I think this should block Stage 3. [06:10:52.0626] I should've realized that earlier, so thanks for raising it [06:11:06.0324] Chris de Almeida: have you considered just implementing https://github.com/bterlson/tcq/issues/14? [06:11:26.0430] there's so many good things on the TCQ issue tracker [06:11:28.0100] I wonder if a module could say e.g. `"defer load"` to communicate that if it's loaded via `import defer`, all of its imported dependencies could be completely deferred until its evaluation. [06:11:50.0878] well i think the wasm case is generalizable to a certain kind of module with a certain weight profile of time spent in which phases [06:12:04.0521] the high-order bit for me is "does the performance story compose" [06:12:16.0381] concretely, I have published exactly one wasm-based library (z3-solver). It's CJS-based so it has an async `init` function, but if it was ESM-based it would totally have a top-level `await` in its entrypoint, not at a leaf. and it's doing a nontrivial amount of computation on load, of exactly the sort I'd hope to be deferring by the use of `defer`. [06:12:20.0177] can someone who doesn't need sync evaluation can just always insert `defer` and get some loading wins [06:12:37.0123] Michael Ficarra: yeah.. I think we need a DX workflow presentation from BT first [06:13:50.0703] > <@shuyuguo:matrix.org> the high-order bit for me is "does the performance story compose" right, I think this comes down to some details of the algorithm for exactly what is made eager. It's a good action item for the champions to articulate some more cases to investigate this. My intuition is that it should work out as long as you do `import defer` for the imports from within the module that uses TLA--then you get the deferred-ness back [06:13:56.0556] > <@shuyuguo:matrix.org> the high-order bit for me is "does the performance story compose" Given our experience deploying an ESM system, we've found the ESM performance composition story is not viable without this feature. [06:14:16.0435] let me rejoin [06:14:22.0337] > <@robpalme:matrix.org> Given our experience deploying an ESM system, we've found the ESM performance composition story is not viable without this feature. this matches what Yulia shared for Firefox DevTools at the outset of this project [06:14:34.0731] that's not what i mean by composition, i don't think [06:14:40.0681] It also matches what I've said at every plenary where this item is brought up ;-) [06:14:54.0305] i understand Yulia's original claim to be "ESM performance story is not viable without this feature" [06:15:01.0274] ok sorry if I misinterpreted the point [06:15:01.0834] maybe that's the overriding thing [06:15:45.0646] > <@littledan:matrix.org> right, I think this comes down to some details of the algorithm for exactly what is made eager. It's a good action item for the champions to articulate some more cases to investigate this. My intuition is that it should work out as long as you do `import defer` for the imports from within the module that uses TLA--then you get the deferred-ness back does this match what you're asking about, shu ? [06:17:11.0507] let me try to articulate what i'm asking for plenary littledan [06:18:12.0048] webpack might be the TLA breaking change i was thinking of [06:19:08.0400] I know bakkot mentioned something like this - but it does feel like `import defer` is going to ring the wrong bells for a lot of people who expect this won't even do script parsing. Not that I am necessarily advocating for that behavior. [06:19:13.0871] this proposal is good enough for sync usage. I have no idea about TLA and WASM and we haven't try that yet. [06:19:59.0506] so it did get stage 2? [06:20:07.0380] yeah [06:20:14.0369] k [06:20:14.0875] fwiw, at Bloomberg we still encourge use of fully-async dynamic import when that is viable. This proposal has been great for the places where it has not been viable to go fully async [06:20:32.0170] Ashley Claymore: see that smells really off to me [06:21:54.0675] the current situation when it is not viable is that code is written to be fully eager. [06:22:41.0030] hm my internet is not down but zoom disappeared for me [06:23:01.0080] just me? [06:23:07.0938] no, I can see zoom [06:25:16.0660] okay, took a while to come back [06:25:25.0899] Ashley Claymore: right, agreed on that premise [06:26:02.0853] > <@shuyuguo:matrix.org> Ashley Claymore: see that smells really off to me it's pretty common that you're writing code that's not in an async function... I don't think that's going to go away. [06:26:03.0505] Ashley Claymore: but it doesn't smell right to me (yet) that we've been saying "asyncify" and now saying "well, if you did asyncify if you wanna take advantage of this new deferral thing you might not be able to" [06:27:14.0899] shu: Using dynamic import would only neuter the deferred import if the dynamic import were awaited at top-level. The general advice is to never do that. Instead, dynamic import is best used just-in-time inside async functions that require it. [06:27:51.0339] i mean top-level await is a thing? [06:28:08.0535] i don't know how to reconcile that we added it with "actually the general advice is to never do that"? [06:28:10.0047] > <@shuyuguo:matrix.org> Ashley Claymore: but it doesn't smell right to me (yet) that we've been saying "asyncify" and now saying "well, if you did asyncify if you wanna take advantage of this new deferral thing you might not be able to" In some way, this is a key part of providing a well-scoped amount of feature parity from CJS into, since CJS has always supported this pattern (differently, just by having sync require, which is more general than this feature) [06:28:20.0975] > <@shuyuguo:matrix.org> Ashley Claymore: but it doesn't smell right to me (yet) that we've been saying "asyncify" and now saying "well, if you did asyncify if you wanna take advantage of this new deferral thing you might not be able to" * In some way, this is a key part of providing a well-scoped amount of feature parity from CJS into ESM, since CJS has always supported this pattern (differently, just by having sync require, which is more general than this feature) [06:28:25.0857] interesting framing [06:28:29.0606] i don't know enough about CJS to say [06:28:35.0316] "never do that" -> "avoid if possible" (I was too strong) [06:28:38.0618] * i don't know enough about CJS to say if i find that compelling [06:28:53.0915] 😮 I had no idea they didn't have an FPU! [06:29:21.0317] > <@shuyuguo:matrix.org> i don't know how to reconcile that we added it with "actually the general advice is to never do that"? I think this isn't actually the advice--it's more like, if you want the deferral to happen, you also need to defer the imports within the TLA-containing module, and not put the only `defer` things higher up in the module graph [06:31:46.0607] someone is spamming the notes with the letter t [06:32:04.0571] did someone fall asleep at their keyboard? /j [06:32:44.0720] why would we want `irandom` to take bounds if `random` doesn't? I don't like it [06:32:53.0419] 🐈️ ⌨️ [06:37:02.0388] Because it's very common? `Math.random()` actually have bounds implicitly [06:37:15.0742] Note that our internal membership lists don't exactly match what Ecma has recorded. We should work to reconcile these. cc saminahusain [06:37:35.0058] > <@michaelficarra:matrix.org> why would we want `irandom` to take bounds if `random` doesn't? I don't like it don't think if it as "like random, but gives an int" [06:37:49.0311] think of it as "like randInt, the extremely useful function in every other standard library" [06:38:12.0854] (probably it should also not be spelled `irandom`) [06:39:19.0127] sffc: is divrem considered an alternative to divmod or is it still useful even when you have divmod? [06:40:50.0226] why not operator `a /% b` instead of `divrem`? 😁 [06:40:52.0511] littledan: doesn't Ecma only keep one point of contact per member? [06:41:14.0822] sffc: ... because we don't have 64-bit integers? [06:42:04.0082] yeah i think... that's just that [06:42:10.0274] also i don't want to allocate BigInts? [06:43:43.0332] yeah I guess if we wanted to support 64-bit integers we'd need stuff for, like, adding two bigints and then rounding to the right 64-bit int (possible to define in multiple ways for signed vs unsigned). I'm not convinced we need that--my hope was that BigInt.asUintN would be a suitable replacement (to call after the bigint arithmetic op) [06:44:29.0045] > <@shuyuguo:matrix.org> also i don't want to allocate BigInts? I guess the hope is that the compiler would do representation analysis and avoid allocating BigInts [06:44:39.0229] lol, lmao [06:45:06.0065] why lol? [06:45:26.0341] I mean, it's fine that you don't do it now, but I don't know what the blocker would be if it were used commonly enough [06:46:07.0858] like, this is a totally classical optimization in the Scheme world [06:46:18.0426] i don't think that will ever happen outside of the optimizing tier [06:46:37.0947] oh yeah definitely [06:46:50.0885] and i don't consider optimizing tier hope to be very compelling for proposal motivations, or alleviating proposal performance concerns [06:47:50.0884] I mean, this logic went into the decision to not add int64 and instead go for bigint, in the first place [06:48:38.0121] yes, and in retrospect i think it was wrong [06:49:08.0722] for Promise.withResolvers: i have another meeting at 7am (didn't realize this went until 7:15) [06:49:35.0151] shu: Are you OK with the presentation going on? we can return to it later if you want to give more comments [06:49:41.0503] but you might have time for yours [06:49:52.0338] yes of course [06:59:43.0716] > <@michaelficarra:matrix.org> sffc: is divrem considered an alternative to divmod or is it still useful even when you have divmod? I was referring to the Euclid divrem, which always returns positive numbers for the remainder and rounds the quotient toward negative Infinity instead of zero. At least this is what Rust calls the operation (added a link to the notes) [07:02:20.0756] > <@sffc:mozilla.org> I was referring to the Euclid divrem, which always returns positive numbers for the remainder and rounds the quotient toward negative Infinity instead of zero. At least this is what Rust calls the operation (added a link to the notes) thanks for clarifying in the notes [07:03:11.0061] I maintain that `defer` and `deferred` are awful names for anyone who doesn't know the history, which is 95%+ of users [07:03:14.0771] it doesn't defer anything [07:03:22.0572] and `deferred` is not a noun [07:07:17.0236] > <@bakkot:matrix.org> I maintain that `defer` and `deferred` are awful names for anyone who doesn't know the history, which is 95%+ of users Yeah, bikeshedding names is sort of the rare case where it is reasonable to make decisions based on the knowledge of percentages of JS developers [07:07:41.0385] Rob Palmer: We'd gladly host you in Dresden :) [07:08:18.0983] than we can name it `import duck` until stage 3 😇 [07:09:45.0193] ok I'm assuming nothing else important is happening so I am going to go sleep [07:27:01.0679] ``` // wasm.js const mod = await WASM.instantiateStreaming(fetch(…)); export const foo = mod.exports.foo; ``` [07:27:15.0750] This is a leaf. No imports [08:02:56.0556] bakkot: looks like we're missing the logs for today? https://matrixlogs.bakkot.com/TC39_Delegates/2023-07-11 [08:19:27.0865] > <@mhofman:matrix.org> bakkot: looks like we're missing the logs for today? https://matrixlogs.bakkot.com/TC39_Delegates/2023-07-11 I think it's a cron job that runs, not realtime (?) [08:32:40.0089] I forgot who asked, but I added the TG3 slides to the agenda (`07.md`) [08:37:28.0392] https://www.ecma-international.org/news/ecma-tc39-ecmascript-has-formed-a-new-task-group-tg3-dedicated-to-the-security-of-the-ecmascript-javascript-language/ do we want/need to work with Ecma on drafting something like this for TG4? littledan jkup [09:08:51.0792] > <@softwarechris:matrix.org> https://www.ecma-international.org/news/ecma-tc39-ecmascript-has-formed-a-new-task-group-tg3-dedicated-to-the-security-of-the-ecmascript-javascript-language/ > > do we want/need to work with Ecma on drafting something like this for TG4? littledan jkup I think that would be great! [09:14:00.0568] Array Grouping has now met its stage 3 condition [09:48:18.0682] peetk: i am fine with Promise.withResolvers advancing to Stage 3 given the explanations [09:48:30.0602] sorry for having to drop out early [09:48:56.0598] (though for the future i'd still prefer to not have meetings end on :15 which is kinda weird) [10:02:32.0506] i think it's good and healthy to revisit, and overturn, previous design decisions based on new evidence [10:03:52.0542] but still in this particular case and future ones i don't want to conflate "good" defaults and developer signal [10:07:10.0173] the end goal for me is users, not developers, and good defaults for me should be chosen to nudge developers to the result (responsiveness, correctness, fast loading, whatever) we want on products they build for the user. if _all_ developers ignore a default constantly, then we obviously failed and nobody benefits. Google-internally, i did not get this sense when talking with practitioners [10:08:48.0957]