2023-03-12 [19:00:52.0741] ah [19:01:01.0146] when can we have field declaration in constructor parameter [19:01:51.0206] ```js constructor(#srv) {} ``` rather than ```js #srv constructor(srv) { this.#srv = srv } ``` [20:02:28.0439] what about if you want `this.srv = srv;`? [21:08:27.0330] I don't know 🤣 [01:29:29.0645] https://es.discourse.group/t/class-property-parameters/543/12 (Note: this was before I had joined Bloomberg, not a BB proposal) [07:13:04.0786] some discussion around `take` being confusing in this thread, with a proposed fix of renaming to `limit`; thoughts? https://github.com/tc39/proposal-iterator-helpers/issues/71#issuecomment-1461841551 [07:13:46.0856] specifically the confusion is, the subiterator form `take` closes the underlying thing when the subiterator is exhausted, which might confuse people who are wanting to repeatedly take a few items [07:14:34.0173] this is a disanalogy with other languages because most things you can call `take` on don't have a notion of "being closed", even iterators [07:14:37.0750] cc Michael Ficarra 2023-03-13 [01:06:56.0495] ljharb: we have some extra time on the agenda this meeting; if markm's around, do you think we could talk about next steps for making regex escape happen? [01:07:49.0063] that is, assuming the next step for that proposal is "talk to the rest of the committee and settle on a design", rather than anything in particular which would need to be done in advance of the meeting [01:19:48.0498] (or if anyone has other proposals blocked on similar "we just need to discuss and/or argue about it for a while" issues, this seems like a good time) [04:41:25.0041] > <@bakkot:matrix.org> (or if anyone has other proposals blocked on similar "we just need to discuss and/or argue about it for a while" issues, this seems like a good time) Could be fun also to chat about the fundamentals of equality and immutability and what the committee wants there. [04:43:07.0101] Also, if we are going totally crazy, we could talk about reactivity and signals and observables [04:43:47.0587] > <@bakkot:matrix.org> (or if anyone has other proposals blocked on similar "we just need to discuss and/or argue about it for a while" issues, this seems like a good time) * Could be fun also to chat about the fundamentals of equality and immutability and rekey/compound keys. [05:08:32.0406] > <@bakkot:matrix.org> (or if anyone has other proposals blocked on similar "we just need to discuss and/or argue about it for a while" issues, this seems like a good time) I'm happy to chat about decimal numbers! [05:13:18.0378] > <@bakkot:matrix.org> (or if anyone has other proposals blocked on similar "we just need to discuss and/or argue about it for a while" issues, this seems like a good time) * I'm happy to chat about numbers (decimal or otherwise)! [12:36:24.0560] ℚ? [12:44:06.0761] ℝ? [12:50:22.0461] hopefully not ℂ [15:03:17.0694] went ahead and added a topic for it 2023-03-14 [01:23:24.0698] AFAIK there is not current proposal to add ℂ to JS 🤣 [01:23:32.0933] * AFAIK there is no current proposal to add ℂ to JS 🤣 [01:46:42.0155] https://github.com/tc39/proposal-extended-numeric-literals "Other numeric types which may be added: [...] Complex numbers" 😛 [01:48:33.0658] Next up, quaternions [01:51:12.0995] see, there's all sorts of stuff to talk about! [09:26:19.0632] okay, serious question: what advantage do decimals have over rationals? [09:26:24.0956] it seems like rationals would be strictly better [09:27:20.0136] and a rational library is really simple to implement on top of bigints today [09:36:00.0613] one concern that comes to mind with rationals would be the normal form representation (unless one wants to expose numerically equal values with different representations). There might be quite a lot of integer division and modulo checks to reduce the numerators and denominators [09:38:02.0944] there was a discussion about rationals in proposal-decimal: https://github.com/tc39/proposal-decimal/issues/6 [09:45:27.0832] Rationals and decimals are just different data types. A very common and important operation on decimals is rounding in an inherently base-10 way; this operation doesn't really make sense on rationals. [09:46:03.0526] pervasive rounding is also important to control size blowup (which, as Waldemar, remains a problem anyway for BigDecimal, but is worse for rationals) [09:55:21.0264] I dunno, that thread seems to support rational pretty well IMO [09:55:51.0000] a smart implementation can amortise the GCDs as appropriate for the platform [09:56:49.0713] anyway, we can talk more about it at the meeting next week [12:15:53.0207] > <@michaelficarra:matrix.org> I dunno, that thread seems to support rational pretty well IMO Heh my leading comment there is pretty weak. I'd say that the main factor for me is this round operation. Looking forward to discussing more. 2023-03-15 [12:33:42.0916] Reminder for anyone attending the meeting next week: prepare for rain. March is Seattle's rainiest month. It will rain every day. [12:39:42.0961] ljharb: Just curious, was the ordering there deliberate? [12:41:17.0821] ordering? [12:59:44.0974] Extra please I choose the nearest hotel [12:59:50.0213] * Extra pleased I choose the nearest hotel [13:04:03.0989] yes, the Lotte literally has a covered walkway between its entrance and the F5 Tower entrance [13:41:49.0134] the RegExp topic comes amid Stage 3 proposals, even though it's Stage 1 [13:41:56.0048] in the agenda [14:15:35.0948] sorting is by timebox first, then stage [14:15:50.0170] or did i mess that up, and it’s the reverse? I’ll check [14:16:07.0950] ah you’re right, my bad, will fix [14:33:06.0955] no need, I fixed it for you already [14:36:12.0639] i saw; there were a few others that needed fixing so i rebased and pushed [15:25:10.0928] anyone got any recommendations for where to buy a prepaid SIM card nearby the venue? [15:33:11.0833] ptomato: Will you be arriving via the airport? Usually there are kiosks in the airport. [15:35:01.0903] I'm coming by train from north of the border 😄 [15:37:42.0944] Does your carrier not cover US/Canada? Most US carriers cover Canada at least. [15:39:45.0772] I have a very cheap carrier which does not cover the US - I rarely use talk/text unless I'm travelling, in which case I buy a SIM card [15:45:52.0233] I would probably try this 7-Eleven around the corner: https://goo.gl/maps/Qg11dSu9Fcz2LmRy8 [15:46:24.0313] thanks! [15:46:28.0818] also if you're picking up masks/tests at the local Bartell Drugs, they may carry prepaid SIM cards [15:47:02.0001] those I was going to bring, but that's nonetheless a good tip for others maybe! [15:48:51.0675] it also might not be too late to order a prepaid US SIM online and get it delivered before you leave [15:49:22.0904] that might be better if you're worried about being without talk/text/data on your way from the train to F5 Tower [15:51:20.0763] anyway, if none of those suggestions work, just ping one of us and we can help figure something out [15:52:09.0715] I'm not too worried about that, I'd probably be using it more for coordination with other attendees [15:52:12.0270] thanks! [15:53:17.0830] https://pagersdirect.net/ 2023-03-16 [17:34:50.0862] ptomato: if your phone has eSim, I've used the ones you can buy online, and worked well [17:35:00.0061] * ptomato: if your phone has eSIM, I've used the ones you can buy online, and worked well [17:36:40.0344] well - I only used the data-only one that Orange sells and used in Europe, but presumably can get the same for US from them or another carrier [17:38:45.0960] I avoided the resellers like airalo, etc that route all your stuff through middleperson servers 2023-03-20 [07:55:35.0823] The draft schedule for this week's TC39 plenary has been posted on [the Reflector](https://github.com/tc39/Reflector/issues/461). Please do not share the link here because this is a public channel with logs. [09:03:21.0027] For those folk in Seattle, we have a dedicated Matrix room for logistics of getting around or meeting for dinner. Please say if you need an invite. 2023-03-21 [08:14:25.0580] Hello all. Plenary meeting begins in just under two hours. For those attending in person in Seattle, please arrive from 09:20 where you will be met in the F5 lobby. Breakfast will be served on the same floor as the meeting room from 09:30. [08:33:28.0750] i still don't see a zoom link [08:43:09.0339] The entry-form containing the zoom link will be posted in the next 30 mins and I will notify here. [09:20:52.0868] why we're always changing the meeting software 🤔 [09:21:19.0509] The entry form is now available on the Reflector: https://github.com/tc39/Reflector/issues/461 [09:22:41.0770] Jack Works: This is due to host room setup. The room has been built to work with Zoom, e.g. the AV is connected to an inaccessible Zoom server. We did try to get Google Meet running with no success. [09:55:26.0947] We begin in 5 minutes! [09:56:12.0048] This is our room for the week. [09:59:43.0211] looks great! [10:02:21.0178] Customer Engagement Center [10:04:41.0900] looks really fancy [10:04:50.0899] (im not present in any form today) [10:09:55.0474] Wish I was there [10:14:55.0648] @bakkot You should probably advertise somehow that you are recording for the late arrivals. [10:25:41.0212] msaboff: I'll say it again in my editor update [11:09:14.0210] dminor: not sure i understand that point. that sounds like mozilla-internal meeting wrangling [11:09:44.0985] I think the point they tried to make was that what Shane's mentioning now [11:09:50.0817] TG2 is run very differently [11:10:03.0712] for one, the agenda isn't set up clearly ahead of time [11:10:40.0706] we don't use TCQ but do use a simpler Google Meet queue [11:10:42.0196] ah i misunderstood then, it was about how TG2 is run, not mozilla? [11:11:07.0994] well, a bit of both I thought [11:11:32.0299] because of how TG2 is run, Mozilla cannot have structured internal discussions about the agenda a week ahead [11:11:42.0907] (IIUC, dminor will probably correct me) [11:11:43.0303] Basically, it would be difficult for us to review proposals properly in advance given the way that TG2 is currently run, so we'd prefer to continue to do advancement in the main committee meetings [11:12:08.0307] dminor: okay, thanks [11:15:28.0133] Async: Please share the link to the slides on test262 funding so we can reference them from the notes. [11:25:23.0256] https://ptomato.name/talks/tc39-2023-03/ [11:25:27.0795] agenda and notes updated [11:28:54.0614] To meet Justin Grant's schedule constraint, we are suggesting Temporal will be at 13:00 (first thing after lunch) [11:31:33.0736] wow jordan sounds great [11:31:37.0004] kudos to these room mics [11:31:43.0224] Do any other Ecma TCs have shared costs between member companies that attend? Curious if something like specific TC "dues" could work if rolled up into the yearly fee. [11:32:20.0825] A lot of pain in companies contracting out work if they can't do it themselves is the burden of that internal process... [11:35:36.0486] it definitely seems like the primary purpose of member dues is so Ecma, not individual members, can fund shared needs. [11:59:02.0634] not sure how renaming to limit/skip solve the problem ... [12:00:10.0701] do all of the iterator helpers currently close the underlying iterator? [12:00:36.0477] > <@haxjs:matrix.org> not sure how renaming to limit/skip solve the problem ... I don't think it does, especially given the rather common meaning of `take` across the ecosystem as well as other languages. [12:01:13.0781] > <@apaprocki:matrix.org> Do any other Ecma TCs have shared costs between member companies that attend? Curious if something like specific TC "dues" could work if rolled up into the yearly fee. Ecma folks have told me that there have been shared costs historically, and that members handle their own financial things when it comes up [12:01:15.0674] It's rather trivial to write a wrapper for an iterator that doesn't forward `return` [12:01:21.0874] (and they consider this best practice in general) [12:01:35.0695] We will return in one hour. If any of the remote attendees have feedback on AV etc please say it here. [12:01:57.0028] I find "limit" less understandable than "take". If it helps avoid misunderstanding, I would expect that's only because one has to read the docs to understand what it does at all. [12:10:06.0956] imo "limit" conveys very clearly that the iterator is closed, i guess because it sounds like SQL limit, and obviously SQL queries are not stateful; whereas "take" is much more ambiguous. but i guess this is a minority view! [12:56:40.0878] Are there actually any iterator helpers in the proposal that do *not* close the underlying iterator? [12:58:20.0647] They all either iterate everything (thus closing the underlying), or close when they early exit [12:58:26.0161] `take` is special in that `take` ends _before_ exhausting the underlying iterator [12:58:33.0685] My general expectation is that if I pass an iterator off to any other code, I should assume it is exhausted and not touch it again myself. [12:59:20.0898] whereas if you `map` or something the expectation is that it either you are exhausting it, which will naturally close the underlying iterator, or closing the `map` helper explicitly [13:00:03.0787] > <@bakkot:matrix.org> `take` is special in that `take` ends _before_ exhausting the underlying iterator So does `some`, `every`, and `find` [13:00:33.0166] Justin Ridgewell: those don't produce new iterators though [13:00:37.0297] Caveat being that `some`, `every`, and `find` return scalar results [13:00:42.0904] they are as it were "consumers" rather than "transfomers" [13:01:58.0247] Though `take` ending before exhausting the iterator is a misconception. The fact it calls `return` is more of an optimization than a meaningful difference when it comes to sequence operators. [13:02:56.0562] by "an optimization", do you mean relative to the option of manually exhausting the underlying by calling `.next` repeatedly, or something else? [13:03:09.0091] Yes. [13:03:41.0995] If JS had no `.return` and the only way to close an iterator were to exhaust it, I would expect `take` to exhaust the iterator. [13:04:14.0735] So its good that `return` exists, as it allows us to short-circuit such an expensive operation. [13:05:10.0505] But I'm pretty sure that in every example of prior art in the ecosystem, where `take` is used it means "take X items and exhaust/close the underlying iterator" [13:05:35.0432] If the iterator were a database, I would expect `take` to close the connection when completed. [13:05:42.0070] * If the iterator were backed by a database, I would expect `take` to close the connection when completed. [13:05:55.0389] The alternative is resource starvation, which is a bad failure state. [13:06:41.0972] If you want "consume X and not close", that operation is normally named something like `read` (at least, where IO is concerned) [13:10:50.0479] erights: i finished the iterator helpers "close the underlying iterator" change before lunch, and it passes all the proposed test262 tests as well as my own [13:13:24.0852] We are bringing forward Async Explicit Resource Management to happen this afternoon. TCQ and draft schedule are updated accordinlgly. [13:15:38.0745] rbuckton: isn't your claim about taking more uncommon directly contradicting by the issue that prompted this discussion? [13:15:47.0087] * rbuckton: isn't your claim about taking more being uncommon directly contradicting by the issue that prompted this discussion? [13:15:54.0997] * rbuckton: isn't your claim about taking more being uncommon directly contradicted by the issue that prompted this discussion? [13:16:54.0435] My impression is that the use case in that issue was a misuse of the API. Perhaps `take` may seem confusing in a vacuum, but not with adequate context [13:19:18.0829] Why is it "Speaker's summary of key points" rather than "summary of key points" in the notes? [13:19:25.0606] Didn't get to it due to time, but there is precedence for a `preventClose`/`preventReturn` option on the web: `preventClose` on `ReadableStream.prototype.pipeTo` and `ReadableStream.prototype.pipeThrough`. I am not necessarily in favour of adding that - but if we did, people may already be familiar with the opt out behaviour. [13:19:32.0976] > <@littledan:matrix.org> Why is it "Speaker's summary of key points" rather than "summary of key points" in the notes? I haven't really been seeing speakers fill this in; I think note-takers and the committee could fill it in as well [13:21:25.0270] It can be written by anyone so please change the title if you like. The key is that the presenter ought to be at least approving the summary so that we have some kind of responsibility when distributing the load of writing these summaries. [13:21:49.0589] The confusion is a consequence of choosing to build an API that is dependent on `Iterator` vs the notion of an iterable. As I understood it as the proposal was advancing, basing this on `iterator` meant we were in the realm of "one shot" or "single use" iterators, and that any kind of reusable iteration would rely on arrow functions. IIRC, all of the helper methods are exhaustive, either through repeated calls to `.next` or through the use of `.return`. I don't believe `.take` should be substantially different in this regard. I would much rather have an "opt-out" mechanism to avoid closing an iterator than breaking from the norm here. [13:24:19.0903] Definitely agreed that `take` not exhausting is not an option [13:24:32.0268] the question was just whether a different name could lead people to correctly intuit the semantics [13:25:11.0716] my intuition is no, unless the name is literally, like `takeAndThenClose` [13:32:43.0097] The alternative, `.limit`, only really makes sense for numeric arguments. It becomes much less clear if you later adopt something like `.limitWhile` (vs. `.takeWhile`). [13:33:56.0964] fun fact, Java has both `limit` and `takeWhile` [13:34:01.0171] (and no `take`) [13:36:27.0529] 64+32 Abseil: https://github.com/abseil/abseil-cpp/blob/master/absl/time/duration.cc#L15-L50 [13:37:43.0324] > <@lucacasonato:matrix.org> Didn't get to it due to time, but there is precedence for a `preventClose`/`preventReturn` option on the web: `preventClose` on `ReadableStream.prototype.pipeTo` and `ReadableStream.prototype.pipeThrough`. I am not necessarily in favour of adding that - but if we did, people may already be familiar with the opt out behaviour. I know that NodeJS has that concept, i.e.`stream.pipeline(streams, { end: true })` https://nodejs.org/dist/latest-v19.x/docs/api/stream.html#streampipelinestreams-options [13:38:29.0202] and `readable.pipe(dest, { end: true })`. I'm not sure about the DOM APIs offhand [13:39:17.0292] for DOM it'd be `readable.pipeTo(writable, { preventClose: true })` [13:39:47.0175] Yeah, I misread your comment as a question, sorry. [13:49:37.0810] waldemar: the core confusion from me is why do you trust multiple implementations to be correct and interoperable here, if you don't trust the spec to be correct (because it's so tricky to get correct)? [13:49:51.0898] like my goal isn't _just_ a correct document, it's correct interopable implementations [13:52:12.0744] shu: It sounds like you're trying to fit the spec around one possible (and pretty problematic) implementation. The spec should be implementation-agnostic about internal details. [13:53:05.0309] in this case my understanding is that the bounds the champions are working to put in place are precisely so that it _is_ implementable with that technique [13:53:07.0106] I'm also more interested in the ns vs µs question. [13:53:15.0568] (also why is the 64+32 impl problematic?) [13:54:26.0790] > <@waldemarh:matrix.org> I'm also more interested in the ns vs µs question. I know that ptomato framed this as "for future discussion" but I don't see any arguments to switch to microseconds at this point. [13:54:37.0744] Elementary math: 64+32 can implement integral counts of subseconds. This is obvious. [13:55:20.0924] well, V8's position is still pro microseconds, but we won't block the proposal on it if implementation complexities and bad performance cliffs are addressed [13:55:27.0356] Not obvious: spec that explicitly manages two integers implements integral counts of subseconds. It's easy to get carries and overflows wrong, and you can't tell without examining the entire spec. [13:55:55.0814] i agree with you [13:56:13.0093] what i don't get is, why do you think that trickiness is best left for implementations to all figure out via implication? [13:56:24.0591] If you just want µs, then you can store durations in flat 64-bit integers and get a much more efficient implementation with a range of >500,000 years. [13:56:46.0855] indeed! *i* just want us [13:56:56.0920] but v8 has not been able to convince the champion group [13:57:38.0077] > <@waldemarh:matrix.org> If you just want µs, then you can store durations in flat 64-bit integers and get a much more efficient implementation with a range of >500,000 years. Do we have any information that this difference in performance will be signficant? there's so much other stuff going on anyway [13:58:05.0253] it's a nuanced conversation that's hard to tease apart [13:58:26.0047] it's not just absolute performance, it's the complexity around supporting optimized paths also [13:58:29.0671] it's philosophical objection [13:58:51.0766] Whether a difference in performance is significant depends on who is writing the benchmark ☺ [13:59:09.0649] apaprocki has given examples of other systems that support ns that temporal might want to interface with, which i don't really get at all [13:59:21.0573] ns are common enough nowadays that it seems it would be limiting use cases unnecessarily by limiting to µs, e.g. node embeds v8 and would hopefully like to represent filesystem times without losing precision [13:59:25.0919] those other systems don't have ns as part of a date-time arithmetic library, they're raw ns counts [13:59:31.0145] they're int64s [13:59:57.0154] what i'm saying is it doesn't follow "ns are common enough -> ns need ot be supported in a fully featured date-time arithmetic library" [14:00:08.0297] you still can just put the raw ns count into a BigInt [14:02:34.0445] V8 position is: - ideal: us precision, simple bounded arithmetic + storage follows straightforwardly - can live with: ns precision, with 64+32 being a tried-and-proven implementation technique from e.g. abseil that we can use - cannot live with: ns precision, bigint math required [14:02:47.0123] > <@shuyuguo:matrix.org> what i'm saying is it doesn't follow "ns are common enough -> ns need ot be supported in a fully featured date-time arithmetic library" well, take filesystem times.. certainly those are displayed on screens as formatted date times and not counts [14:02:59.0803] great, it's fine to format them [14:03:12.0989] you need to do full arithmetic to ns precision? [14:03:18.0717] how is that useful? [14:06:25.0107] > <@shuyuguo:matrix.org> you need to do full arithmetic to ns precision? I haven't found this as a hard requirement for us when I talked to the relevant groups (except for certain algorithms like PTP which we probably wouldn't end up porting to JS) [14:06:35.0169] > <@shuyuguo:matrix.org> you need to do full arithmetic to ns precision? * I haven't found this as a hard requirement for us when I talked to the relevant groups inside of Bloomberg (except for certain algorithms like PTP which we probably wouldn't end up porting to JS) [14:08:51.0733] there are certain feeds of information where the individual events are represented in ns precision and series of events could be displayed as offsets from an initial event (in essence, durations from an arbitrary epoch rather than UTC epoch) [14:10:00.0699] > <@shuyuguo:matrix.org> what i'm saying is it doesn't follow "ns are common enough -> ns need ot be supported in a fully featured date-time arithmetic library" I think using ns would create somewhat of a risk, that Temporal might become obsolete (which is a surprising choice given how much else we decided to be super future-proof for). It's sort of clear that we don't really need to go more precise than ns. [14:10:54.0630] (and a later evolution here would be really bad, given compat/interop risks) [14:12:25.0663] > <@shuyuguo:matrix.org> what i'm saying is it doesn't follow "ns are common enough -> ns need ot be supported in a fully featured date-time arithmetic library" * I think using us would create somewhat of a risk, that Temporal might become obsolete (which is a surprising choice given how much else we decided to be super future-proof for). It's sort of clear that we don't really need to go more precise than ns. [14:12:29.0713] yes (edited) [14:15:43.0565] Good news everyone: The transcriptionist might be available for tomorrow! [14:15:52.0285] (they got back to me by email) [14:28:00.0963] this isn't worth bringing up, but `await` is not reserved in strict mode, only in module code and async functions [14:28:42.0649] very very few people are aware of syntax being dependent on the start symbol [14:29:36.0312] bakkot: perhaps we should have `Set.prototype.sort` if the sort order is important? [14:30:06.0717] if you're going to explicitly manage the sort order, put it in an explicitly ordered container [14:30:08.0011] the problem is that when I care about the order it's because I care about insertion order specifically [14:30:15.0760] and you can't sort it into "insertion order" [14:32:31.0826] ah true, hm [14:35:05.0259] I know we don't have much else to go on, but I feel like we're taking these poll results way too seriously [14:35:24.0998] right now we're just hearing what they are [14:35:38.0876] no one has expressed anything about what to do with them [14:41:29.0362] for await has always felt like an awkward piece of syntax to me, though [14:41:55.0097] like I don't know if we should be using it to guide future syntax choices [14:44:04.0128] tbf if we're just picking something because we have to pick something, "difficulty of parsing" is a fine reason to choose - I just wouldn't want "difficulty of parsing" to prevent us from picking a thing we do all think is best [14:44:46.0829] > <@michaelficarra:matrix.org> for await has always felt like an awkward piece of syntax to me, though huh? it seems intuitive to me [14:46:48.0421] as a code reader, I kind of want a syntactic note on the block that it may await at the end, not just on individual statements in the block [14:46:57.0596] like `async` on a function [14:48:33.0530] justin, is this just syntax shock? I fully have the same initial reaction as you. I just recall many times when my initial reaction is later overcome once it goes into the language and you get used to it [14:49:10.0295] that's not much of an argument though, because you can make that about literally syntax we choose? [14:49:10.0331] could be? [14:49:14.0119] "you'll get used to it" [14:49:22.0426] * that's not much of an argument though, because you can make that about literally any syntax we choose? [14:49:26.0480] That could be the JS motto. [14:50:12.0880] justinfagnani: yeah the original design was more like python's `with` or java's `try-with-resources`, which has that [14:50:21.0966] but we ultimately decided not that [14:50:29.0099] Would something like: ``` async { await using x = y; foo(); } ``` make it more clear that the block may yield at the end? [14:50:33.0891] bakkot: ok [14:50:37.0837] FYI, Mark is not active on Matrix [14:50:46.0510] > <@justinfagnani:matrix.org> Would something like: > ``` > async { > await using x = y; > foo(); > } > ``` > make it more clear that the block may yield at the end? This was something we discussed in depth and resolved in the last meeting [14:50:55.0721] ok, thanks [15:05:19.0405] so... what just happened? [15:05:25.0268] sorry all didn't mean to make the decision space so complicated [15:05:31.0549] no this was good [15:05:45.0358] please read the summary at the bottom of the notes page and edit it or make comments as needed [15:05:48.0069] the only signal i got from the past 10 minutes is, the consensus was not just "we can all live with await using" but in fact "we are now convinced `await using` is the ideal, if achieveable" [15:05:53.0298] which is a good signal [15:05:57.0943] and backs up coming back next meeting [15:06:00.0607] Having a block-level indicator was the issue blocking the async version `using` for the past few years. [15:06:06.0814] > <@littledan:matrix.org> please read the summary at the bottom of the notes page and edit it or make comments as needed yes -- maybe we should ask for consensus on that summary.. I'm concerned we are not all on the same page [15:06:14.0876] > <@littledan:matrix.org> please read the summary at the bottom of the notes page and edit it or make comments as needed * yes -- maybe we should ask for consensus on that summary conclusion.. I'm concerned we are not all on the same page [15:06:21.0656] > <@shuyuguo:matrix.org> the only signal i got from the past 10 minutes is, the consensus was not just "we can all live with await using" but in fact "we are now convinced `await using` is the ideal, if achieveable" Yes, I think `await using` has broad support (and this is why I wanted to do a temperature check) [15:06:29.0154] > <@softwarechris:matrix.org> yes -- maybe we should ask for consensus on that summary conclusion.. I'm concerned we are not all on the same page could you elaborate? [15:06:58.0726] (I did ask everyone to review it, but we can come back and project it to force everyone to review it when we come back from the break) [15:07:33.0412] littledan: heh, i still don't like it! but i'm fine with it [15:08:13.0686] what's there atm makes sense to me -- just want to confirm expectations as it seemed we might have been going a different direction for a bit there [15:21:25.0730] i have lost my apartment internet due to what i assume is high winds in SF currently [15:21:43.0247] i don't have good enough cell service to do zoom, so looks like i am out for the remainder of today :/ [15:26:09.0968] wait maybe i have enough phone tether to do zoom [15:26:13.0137] it's like 90% packet loss [15:27:07.0752] do you live in a dirigible? [15:27:45.0497] it's called san francisco, thank you [15:28:38.0743] Frank Tang also said he's been in and out of power/internet [15:32:32.0318] BTW here are my conclusion notes for the await using topic, please edit in the notes if you want to make changes: ### Summary Various grammars for async resource disposal were considered, including results from polls. The champion's preference became `await using`, and several delegates were swayed to prefer this option based on the data and arguments presented. There are concerns about the parse-ability of `await using`, both based on practical implementations and the fit into the ES spec's cover grammars; it's unclear if certain edge cases will be easy to manage. If `await using` isn't viable, it's likely that `async using` isn't viable, and the committee may come back to the conclusion of `using await`, but this will need to come back to plenary for future discussion. ### Conclusion The committee resolves to attempt the syntax `await using`. The grammar will need to be worked out in a PR, which will need to be presented in a future plenary for review and consensus. [15:44:10.0244] i am triggered about static private semantics [15:44:39.0478] same [15:44:54.0817] static private semantics are actually fine [15:45:12.0691] the problem is that `class extends` implies inheritance not just of instances but of _the constructors themselves_, which is wack [15:46:15.0692] > <@bakkot:matrix.org> the problem is that `class extends` implies inheritance not just of instances but of _the constructors themselves_, which is wack I'm like 80% sure I agree. Constructor inheritance is definitely used. [15:46:57.0635] yeah I use it myself [15:47:37.0798] but it should never have existed, it gives us the wild things like `Promise.resolve` not working unless bound (whereas `Array.from` does, for... reasons) [15:54:51.0113] we *really* need to figure out a more appropriate organisational scheme for well-known symbols than putting them all on Symbol [15:55:34.0964] I don't blame this proposal author for this choice, since we don't have committee guidance on the topic [15:56:31.0438] > <@michaelficarra:matrix.org> we *really* need to figure out a more appropriate organisational scheme for well-known symbols than putting them all on Symbol I don't really see the same issue; it's just a single namespace for these things, just like if we had called it `__metadata__` [15:58:08.0598] littledan: yes, a single global namespace for everything is bad, whether that is globalThis or Symbol [15:58:34.0798] Hey all, Ron (rbuckton ) and I will be requesting a new agenda item this Thursday which will propose the preferred `await using` syntax for the [Async Explicit Resource Management proposal](https://github.com/tc39/proposal-async-explicit-resource-management). We're currently working on the grammar, but will let everyone know when the slides and changes are ready to review. [15:58:35.0874] ironically, that opinion is also on-topic for this topic [15:59:23.0557] i don't think a single global namespace is bad [16:00:01.0605] i think it's only ex ante bad but is mostly ok [16:01:07.0925] `var doNotPolluteTheGlobalNamespace = {};` [16:02:35.0315] Option 3 feels the most bizarre to me, since the intended usage of it needs to go back to the single namespace anyway [16:02:46.0538] shu: surely with time, we will have more than 1 built-in protocol that want to use the same simple name for one of their provided/required fields [16:03:30.0038] that's why i said ex ante bad [16:03:41.0897] none of these well-known symbols have particularly unique simple names [16:03:44.0980] my point is that when we come to that bridge it's usually not a big deal to work around [16:04:25.0565] shu: fair, though it would be nice to set a precedent for userland protocols, especially if we ever have a world with first-class protocols [16:06:23.0343] which class does the metadata get added to? If there was a class decorator which returns a new class, does that get it, or should it have to make sure it 'forwards' on `Symbol.metadata' ? [16:06:59.0574] The final class [16:07:22.0430] (I think) [16:07:45.0685] so might not work if the decorator freezes the class [16:07:47.0189] * so might not work if the decorator freezes the class? [16:07:54.0096] A _good_ class decorator that performs replacement should either subclass with `extends`, unless it is doing something very complex. [16:09:06.0150] either, or what? [16:09:42.0764] * A _good_ class decorator that performs replacement should either subclass with `extends`, or use `.setPrototypeOf` to emulate that approach, unless it is doing something very complex. [16:10:34.0688] so `Symbol.metadata` would already be there on the class that is being decorated? Rather than added to the final class? [16:11:04.0438] I'd have to recheck the spec [16:13:52.0835] i'm confused about kevin's use case [16:14:29.0049] two libraries which both want to use the key `type` [16:14:38.0539] including possibly two major versions of the same library [16:14:46.0128] you fundamentally cannot use these things at the same time [16:15:01.0597] because it's a shared global namespace [16:15:07.0828] is he saying programs will want multiple versions of the same decorator library in the same running app...? [16:15:34.0624] multiple versions of a library in the same app is a thing which happens constantly [16:16:32.0796] rbuckton: if you want a shared global namespace in scripts, use `globalThis`? why do we need to add a second global namespace? if you really want a global namespace, there already is one already [16:17:04.0918] > <@bakkot:matrix.org> multiple versions of a library in the same app is a thing which happens constantly right, I guess the question is: are we more likely to want them to share or partition the namespace? I think share is more pragmatic, given the cases we've heard about. What's more likely to work in practice? [16:17:20.0627] but... why is the app use two major versions of the same library in the same app? that happens? [16:17:28.0176] that happens constantly [16:17:32.0622] littledan: they can't share [16:17:38.0673] > <@lucacasonato:matrix.org> rbuckton: if you want a shared global namespace in scripts, use `globalThis`? why do we need to add a second global namespace? if you really want a global namespace, there already is one already That is essentially what `reflect-metadata` does, and one of the things we have sorely wanted to address with this proposal. [16:17:39.0422] like, that's the problem [16:17:41.0650] they ause the same key [16:17:44.0692] * they use the same key [16:17:47.0678] it happens constantly? [16:17:51.0130] We cannot mutate `globalThis` in a locked down environment like SES [16:17:51.0819] and coordinating it becomes the consumer's problem [16:17:53.0381] the various layers of dependency hell [16:18:27.0879] > <@bakkot:matrix.org> littledan: they can't share I don't see why this is such an absolute, rather than pragmatic, thing [16:18:32.0126] okay i think i'm getting the picture. currently the builders do some kind of deduplication / versioning at the build step for regular import/exports [16:18:36.0226] Also, `[Symbol.metadata]` isn't necessarily a "global namespace" any more than a static property on the class is a global namespace. Because the `[Symbol.metadata]` property _is_ a static property on a class. [16:19:06.0979] rbuckton: right, class fields are also a shared namespace, which is why string-named mixins was not a viable proposal [16:19:51.0818] > <@bakkot:matrix.org> rbuckton: right, class fields are also a shared namespace, which is why string-named mixins was not a viable proposal Symbol-named protocols are also not beyond Stage 1; I still like string-named mixing. [16:20:01.0209] There's a difference between "shared namespace" and "global namespace" though. The 2nd term has more implications [16:20:02.0006] > <@bakkot:matrix.org> rbuckton: right, class fields are also a shared namespace, which is why string-named mixins was not a viable proposal * Symbol-named protocols are also not beyond Stage 1; I still like string-named mixing. [16:20:08.0593] * Symbol-named protocols are also not beyond Stage 1; I still like string-named mixins. [16:20:25.0140] the names of all fields used in all decorators anywhere must be unique [16:20:26.0501] that's global [16:20:37.0160] I want a mutable object _because_ I don't want a shared _global_ namespace. [16:21:03.0959] The alternative to use `globalThis` mandates I do the worse thing [16:21:13.0143] rbuckton: but only you [16:21:14.0723] "be careful" assumes that all parties are coordinating, but in reality, pages and applications are often composed of many non-coordinating scripts [16:21:20.0904] I am OK with only typescript having to do the worse thing [16:21:29.0099] as long as everyone else falls into the happy path of the right thing [16:21:41.0951] Its not only typescript, its every typescript user. [16:22:10.0865] TS users presumably would only use an interface TS provides [16:22:12.0729] * TS users presumably would only use an interface TS provides? [16:22:14.0185] > <@michaelficarra:matrix.org> "be careful" assumes that all parties are coordinating, but in reality, pages and applications are often composed of many non-coordinating scripts You only have to worry about the set of decorators that a particular class uses. [16:22:42.0743] * TS users presumably would only use an interface TS provides, regardless of which option was chosen? [16:23:12.0423] littledan: and are those decorators always created by a single party or by coordinating parties? I doubt it [16:23:36.0238] > <@littledan:matrix.org> You only have to worry about the set of decorators that a particular class uses. Decorators from different libraries can usually be mixed, so the decorator author doesn't really know what this set is [16:24:06.0689] > <@nicolo-ribaudo:matrix.org> Decorators from different libraries can usually be mixed, so the decorator author doesn't really know what this set is I don't think this is really true with framework decorators [16:24:27.0156] littledan: "not true for some cases" is not the bar we're trying to meet here [16:24:42.0984] ljharb: re: your queue item, the only reason I suggested a frozen object instead of a symbol is that a frozen object lets you get to the parent metadata [16:25:53.0459] makes sense, thanks [16:27:23.0920] `Symbol.for("foo")` isn't much better than `"foo"` [16:27:32.0974] I didn't mention this, but the other downside of option 1 is that it is public-by-default, which is... very bad [16:27:47.0005] you can remember to be disciplined about it but people will not remember [16:27:50.0497] > <@bakkot:matrix.org> I didn't mention this, but the other downside of option 1 is that it is public-by-default, which is... very bad It's not anything by default; it's just as easy to use the WeakMap with it [16:27:55.0515] no it isn't [16:27:56.0570] > <@bakkot:matrix.org> I didn't mention this, but the other downside of option 1 is that it is public-by-default, which is... very bad There is no default. Its purely based on usage. [16:28:08.0037] it is not as a easy to use a weakmap as it is to use a string-named property [16:28:29.0434] But option 2 has the same level of difficulty with weakmaps [16:28:54.0704] yes but that's the only way to use it, so that's fine [16:29:05.0551] like, as a practical matter, people are going to use public string-named properties with option 1, even when they don't intend to make a public API [16:29:08.0483] that is what is going to happen [16:29:18.0673] that is what "public-by-default" means [16:31:01.0734] That is more about documentation and learning than it is about capability. If you tell folks, use `WeakMap` or `Symbol`, if you're concerned about collisions, but strings or `Symbol.for` if you're not. Library authors will almost certainly avoid collisions, end user applications often won't need to. [16:31:19.0821] * That is more about documentation and learning than it is about capability. If you tell folks, use `WeakMap` or `Symbol` if you're concerned about collisions, but strings or `Symbol.for` if you're not. Library authors will almost certainly avoid collisions, end user applications often won't need to. [16:31:49.0277] You have a lot more faith in the power of documentation to shape what happens than I do [16:31:55.0554] for that matter you also have more faith in the power to shape documentation [16:31:56.0810] Assignments to `context.metadata` will never be so symbol as `context.metadata["a"] = b` anyways [16:32:08.0603] I really appreciate you being flexible here, bakkot ljharb Michael Ficarra . It's great that we're able to move forward and not have a big gap of metadata-less decorators [16:32:10.0699] * Assignments to `context.metadata` will never be so simple as `context.metadata["a"] = b` anyways [16:32:42.0373] `context.metadata` is just an object. If you need to differentiate between a class, or a method, or a field you still have more work to do to avoid collisions, even in the `WeakMap` case. [16:32:49.0981] Is the `context` object (not the `context.metadata` obj) consistent between all decorator invocations on a particular class? [16:32:57.0366] Or is it a new object for every invocation? [16:33:09.0032] Same object for every decorator on a single class [16:33:21.0683] including the methods and fields. [16:34:03.0250] If we had chosen Option 2 here, would there even have been a need for `context.metadataKey` at all? [16:34:15.0750] We could have just keyed the `WeakMap` on `context` [16:34:18.0484] ```js @((_, ctx) => { ctx.metadata["a"] = 1; }) class C { @((_, ctx) => { ctx.metadata["b"] = 2; }) method() {} } ``` produces a single object with `{ a: 1, b: 2 }` [16:34:23.0439] yeah you need it to be available after decoration time [16:34:29.0746] and you don't want to share the `context` object [16:34:36.0275] which has a bunch of decorator-time-only stuff on it [16:34:42.0972] Ah, ok [16:34:45.0017] sorry, I misread. [16:34:51.0692] `context` is not shared, only metadata is. [16:35:10.0461] * sorry, I misread (despite your clarification). 2023-03-22 [08:58:27.0741] Good morning, all. Plenary begins in one hour. [09:27:16.0857] For those interested, I have two draft PRs up that illustrate the potential cover grammars for `await using` and `async using`: - `await using`: https://github.com/tc39/proposal-async-explicit-resource-management/pull/15 - `async using`: https://github.com/tc39/proposal-async-explicit-resource-management/pull/16 [10:18:36.0107] slides for the awkwardly done election (sorry about that y'all) https://docs.google.com/presentation/d/1xQ7huTJQsbcfFM6nhN7Tk3uBUf3h7FHkroM1m56ueZE/edit#slide=id.g6e7d7a6a09_0_98 [10:20:15.0551] I thought it was fine, I had no problem with the process, personally [10:21:45.0300] ah nice, i like source as a keyword [10:22:10.0487] I already love this presentation [10:34:05.0592] Wait, he said "next slide" right? [10:34:14.0416] I'm still seeing "Import phase syntax" slide [10:34:37.0723] we're on spec: ordering of fetches slide [10:34:50.0522] now on spec: idempotence is unchanged [10:35:05.0291] https://docs.google.com/presentation/d/1F62Jia5erIm6m6nqkm_2pFIlNLOVF0E4ewrVRytSJEs/edit [10:48:31.0390] this seems like a thing that we, as language designers, would notice and/or care about, but users of the language don't want to care about this distinction or have to pass around an awkward intermediate opaque value because of it [10:49:30.0448] feature request: import/export queue as YAML [10:49:57.0964] some though: ```js import source wasm from './x.wasm' // and import wasm from './x.wasm' ``` both give us reference to undeniable host objects. [10:50:37.0451] I mean that depends on the embedder, right? [10:51:21.0377] the embedder could add hooks for denying that, surely [10:51:22.0347] yes. since it already happens today, IMO we no need to care about deniability in this syntax. [11:08:42.0875] Wait, so `import x from "test"` and `import x from "test" with {}` would have different cache keys? [11:08:53.0542] in that case, no [11:09:22.0937] keep in mind, it's not that all attributes result in a differing cache key at the host level, they might be normalized just like relative paths [11:10:10.0803] slide https://docs.google.com/presentation/d/1Abdr54Iflz_4sah2_yX2qS3K09qDJGV84qIZ6pHAqIk/edit#slide=id.g216c73c7b74_0_35 seems to suggest the cache key for the former would be `#["test", null]` and the latter would be `#["test", #{}]` [11:12:56.0482] erm, ok. i have maybe a solution to what mark is asking [11:12:59.0212] i have a slide deck [11:13:06.0254] but it wasn't totally ready [11:13:57.0576] I will probably do it as a blog post after i've had a chance to talk to the other modules folks [11:13:57.0590] oh, I just checked the spec and it is actually the same cache key, my bad [11:14:06.0152] * oh, I just checked the proposed spec text and it is actually the same cache key, my bad [11:14:19.0782] here is the deck: https://docs.google.com/presentation/d/1YDFyEj8SxbWXhtPBVjyoSOVnaeydnZ_lexmd-LLgO4U/edit#slide=id.p [11:14:42.0867] its out of date, please don't take it as anything concrete [11:15:45.0636] I took it off the agenda because it wasn't concrete but i can talk about it briefly [11:15:59.0682] I'd encourage you to add this to the agenda as well as the queue [11:16:25.0802] I think Mark was probably just unaware of the coordination already happening between the module proposal authors [11:16:28.0384] I've been impressed with how much coordination and participation has gone into the various modules proposals [11:18:37.0220] OT yulia presented some stuff about this module work (including layering/process improcements) at BOBKonf 2023 just last week (great talk!) https://bobkonf.de/2023/startsev.html [11:18:56.0513] its very out of date already [11:19:12.0637] in one week? JS moves faster than I thought! [11:19:29.0874] yes, i have the wrong names already, probably because i was writing the talk a couple of months ago [11:19:33.0823] I think it'd be much better to discuss this internally in TC39, even if very very unfinished, before you leave (and maybe this will feed into the blog post, even) [11:19:58.0920]