2023-04-01 [18:26:35.0385] https://github.com/tc39/how-we-work/issues/94 ☝️ 🚨 important calendar info 🚨 ☝️ [18:26:50.0945] * https://github.com/tc39/how-we-work/issues/94#issuecomment-1492775885 ☝️ 🚨 important calendar info 🚨 ☝️ 2023-04-03 [22:08:13.0803] ES2023: https://github.com/tc39/Reflector/issues/466 [16:03:42.0565] Michael Ficarra: did you intend step 5 of https://tc39.es/proposal-iterator-helpers/#sec-iteratorprototype.reduce to be "not present", as in an arguments length check? it is consistent with Array.prototype.reduce, but is generally weirder than just checking for undefined nowadays [16:06:41.0132] hmm, yeah it seems like the right call, as that's how we distinguish two pretty radically different behaviors [16:07:27.0736] reduce can either be passed the initial memo (which is perfectly reasonable to be `undefined`) or it can assume the structure is non-empty and use the first element as the initial memo [16:07:52.0971] I think a presence check is the only thing we can do short of separating `reduce` and `reduce1` [16:07:59.0791] ah good point, undefined is a good initial value, so the only choice here is an arguments length check [16:08:03.0593] thanks 2023-04-04 [17:13:30.0800] Yeah, reduce() def needs the presence check rather than undefinedness. [18:33:10.0051] shu: FYI there's another 2 iterator helper topics added to the May agenda [18:33:23.0766] they're some minor inconsistencies that I discovered while working on the tests [18:34:12.0075] the slides should be self-explanatory [18:45:19.0695] do they really need 30 minutes each [18:47:36.0715] hopefully not [18:51:29.0580] does anyone remember a discussion about whether `const [] = { [Symbol.iterator]() { return {}; } };` (a malformed iterator that never gets iterated) should throw? [18:51:39.0298] I vaguely remember Justin Ridgewell being involved I think [18:53:37.0986] bakkot found it! https://github.com/tc39/ecma262/pull/1288#issuecomment-424457388 [18:53:38.0759] We discussed whether a malformed iterator would close the underlying [18:55:46.0820] notes: https://github.com/tc39/notes/blob/main/meetings/2018-09/sept-25.md#normative-use-getmethod-instead-of-getv-to-get-iterator-next [19:25:41.0388] had not encountered this particular downside of floats [19:26:05.0540] though it's of course an instance of a the same problem as all the other things we've been discussing lately [19:26:18.0017] * though it's of course an instance of the same problem as all the other things we've been discussing lately [19:26:32.0678] (this example is from https://speleotrove.com/decimal/decifaq.html about why a Decimal type is warranted) [05:29:12.0624] I'm curious what you're trying to do. I got the feeling that the committee as a whole wasn't totally convinced that decimal was actually a general-purpose, useful thing, as opposed to something very specialized. [05:29:38.0424] * I'm curious what you're trying to do that made you run into this--was it just researching decimal, or do you have a specific application? I got the feeling that the committee as a whole wasn't totally convinced that decimal was actually a general-purpose, useful thing, as opposed to something very specialized. [07:50:12.0199] finally got around to reading the FAQ linked during the discussion, which has this example [07:50:47.0986] I didn't actually run into it in real life [08:29:51.0068] ah OK. Yeah I really enjoyed the FAQ. 2023-04-05 [10:58:49.0467] Can someone invite me to the TC39/JavaScript tools discussion? I missed the meeting today because Calendar doesn't send notifications for shared meetings, only ones I'm invited to. [11:01:07.0154] littledan manages it [11:01:36.0247] actually Romulo Cintra does these days [11:02:21.0416] Use this contact form: https://forms.gle/rSNWHknikVSpGHmD6 2023-04-06 [23:33:06.0461] updated the base64 proposal and added a playground. would love feedback on the design (and the contents of the playground, the design of which I ripped off wholesale from temporal) https://tc39.github.io/proposal-arraybuffer-base64/ [23:51:49.0914] * updated the base64 proposal and added a playground. would love feedback on the proposal API (and the contents of the playground, the design of which I ripped off wholesale from temporal) https://tc39.github.io/proposal-arraybuffer-base64/ [10:11:40.0270] Chris de Almeida: re: the declined TC39 meeting, it looks like Rob created the meeting and then invited the TC39 Events Calendar. I think the way to fix it is for someone to create a new Chairs Meeting directly on the TC39 Events Calendar and for Rob to then remove the existing one. If you share your preferred email address with me, I can give you write access to the TC39 Events Calendar. [11:12:43.0414] I would rename the "alphabet" option to something like "alphabetName" so we know it's an identifier and not the alphabet itself being passed in (without referring to docs) [11:13:12.0048] alternatively, actually pass the alphabet in and define constants for standard ones [11:22:13.0177] I was imaging you could specify either by identifier or by an entire alphabet [11:22:41.0984] as long as we don't want to support identifiers which are exactly 64 characters long we can just let the name be overloaded, and not require the user to find the constants somewhere [11:24:23.0285] well that's certainly creative [13:19:42.0192] ...huh, having an overlapping value space which is definitely disjoint in practice is very interesting. [13:21:00.0395] Might be too magic when we can just have two different options in the bag, but it does avoid us having to answer the question of what to do when the author specifies both, I guess. [13:22:00.0772] yeah [13:22:06.0957] also, I dunno it's not that magic [13:22:53.0540] no more so than `new Temporal.TimeZone('UTC');` and `new Temporal.TimeZone('+00:00');` both working [13:25:08.0369] it's not even like we couldn't have a well-known alphabet have a 64-character name, it just can't refer to some *other* alphabet, which would be a misleading name to say the least [13:26:36.0438] right, also the space is even more constrained because all 64 characters need to be unique, which... you are probably not going to run into an identifier which looks like that [13:28:51.0748] can't wait to see the TypeScript type for it [13:38:46.0134] `any` should work [13:47:04.0997] Can typescript represent strings of a particular length? [13:47:29.0756] If not, then worst case you can just type it as `String` (no need to fall all the way down to `any`) [13:48:15.0074] Of course, was joking [13:48:36.0441] man distinguishing shitposts from serious suggestions can get really hard sometimes [13:58:54.0849] the question of what typescript "can" represent is somewhat complicated because it has a very powerful type system [13:59:17.0021] I am confident there is a way to abuse it into representing "strings of length 64" but it is not something built in and you'd probably get a horrible error message [13:59:59.0676] maybe some nonsense with template literal types [14:05:41.0057] just do a disjuction of literals, with the known keywords and all, uh, 128^64 valid alphabet literals? [14:08:11.0951] unfortunately it refuses to represent unions larger than ~10k members, because it is a coward [14:18:29.0389] Sigh, guess we'll have to throw the whole idea out, then. [15:51:14.0630] RFC 4648 has like base32 and stuff, is there any way that could be added in the future? [15:53:56.0439] see https://github.com/tc39/proposal-arraybuffer-base64#what-other-encodings-should-be-included-if-any [15:54:09.0660] and specifically https://github.com/tc39/proposal-arraybuffer-base64/issues/7#issuecomment-872536851 2023-04-07 [06:07:34.0734] Has there been any discussion around "nullish coallescing destructuring", that is, making something like `function a ({ x = 10 }) { }` "just work" for the `a()` case and having x just be set to 10 instead of throwing? Perhaps using syntax like `function a({ x ?= 10 }) { }` or something? [07:25:38.0285] While not as efficient, you can already do `function a ({ x = 10 } = {}) { }` [07:35:26.0429] There were a few discussions in the Optional Chaining proposal: https://github.com/search?q=repo%3Atc39%2Fproposal-optional-chaining+destructuring&type=issues [10:09:53.0060] Yeah the `= {}` trick works for top-level, but it's more annoying if you want to destructure deeper into the object; you've got to supply more dummy objects for each path you take. [10:45:13.0336] Right, the concern is when it starts to nest pretty deep [11:51:44.0992] Oh, there was also https://github.com/tc39/agendas/pull/1122, but it was never presented [11:54:46.0602] https://twitter.com/TheJoin95/status/1644387103105482753 speaking of... [12:00:15.0413] I feel like doing very deep destructuring all in one go is generally less clear than splitting it up, so I'm not sure I would want to add syntax which is mostly useful for very deep destructuring [12:01:10.0413] well.. could simplify the example: ``` const state = { profileMenu: null } const { profileMenu: { username: ProfileMenuUsername } } = state; ``` [12:01:22.0514] * well.. could simplify the example: ``` const state = { profileMenu: null } const { profileMenu: { username: ProfileMenuUsername } } = state; ``` [12:03:35.0570] `const { username: ProfileMenuUsername } = {} = state.profileMenu;` ? [12:03:41.0543] * well.. could simplify the example: ``` const state = { profileMenu: null } const { profileMenu: { username: ProfileMenuUsername } } = state; ``` [12:03:44.0737] * `const { username: ProfileMenuUsername } = {} = state?.profileMenu;` ? [12:05:03.0582] > <@ljharb:matrix.org> `const { username: ProfileMenuUsername } = {} = state?.profileMenu;` ? `Cannot read properties of null (reading 'username')` [12:05:36.0850] `const { username: ProfileMenuUsername } = state?.profileMenu ?? {};` then :-p [12:07:01.0288] well that gives you a diff obj 🤷 [13:46:26.0487] the only thing you care about is ProfileMenuUsername, and it gives you undefined in this case [14:10:03.0070] fair. that was just a reduction of the ackchyual example in the repo. I can't speak to what they care about or not wrt the deep obj destructuring there. anyway, to my eyes, seems like it's just one tiny requirement away from needing refactoring -- seems like fragile serialization [14:21:36.0799] true. what's fragile is having deeply nested data structures that can have nulls in it. outside of graphql tho i don't think that's super common. 2023-04-11 [18:08:49.0224] FYI, waldemar has approved the PR to https://github.com/tc39/proposal-async-explicit-resource-management that adds the cover for `await using`, which satisfies the condition for Stage 3 advancement. [18:10:01.0656] I will update the Stage in the explained and spec text tomorrow, and will start the process of merging the async and sync proposals this week. [16:57:52.0705] what happened to J.S. Choi? busy with other work or did he step back? 2023-04-12 [18:17:04.0027] I'm also wondering whether someone else should take over Array.fromAsync since Mozilla is waiting on review feedback to be addressed: https://github.com/tc39/proposal-array-from-async/issues/14#issuecomment-1488876729 [22:06:16.0174] ping jschoi 2023-04-14 [09:21:00.0244] maybe I will present the normative change for Array.fromAsync at the next plenary since it's stage 3 and that makes it kind of urgent [09:21:17.0658] it should also be pretty uncontroversial 2023-04-15 [12:08:50.0284] anyone able to answer this q? https://es.discourse.group/t/is-accessing-webassembly-memory-using-typedarrays-incorrect-on-big-endian-systems/1696 [12:13:53.0844] that's a fun problem [12:13:57.0705] is it relevant though [12:14:04.0386] who is running big endian [12:14:45.0612] just MIPS? 2023-04-16 [03:51:35.0427] I think some smart TVs/STBs are MIPS 2023-04-17 [08:11:30.0877] I don't see a problem. The original question had the answer in it already. Just use a DataView if you want explicit control over endianness or you want portability of your JS to big-endian systems. The docs already mention it. 2023-04-18 [11:51:36.0368] could a 262 editor kindly give me enough permission level to post in #tc39-editors:matrix.org ? 2023-04-19 [11:20:42.0681] bakkot: Do we have ES2023 nicely typeset, or should we get someone to help with this again, like Alan did for ES2022? [11:20:56.0470] Michael Ficarra: shu ^ [11:21:48.0145] littledan: we do not and the editors do not think it is worth prioritizing that effort [11:22:01.0042] (there's some discussion in #tc39-editors:matrix.org ) [11:22:28.0174] bakkot: I'm just trying to tell Ecma, hey, the editors aren't doing this; if we as a standards body want this done, then we should find a vendor to do so [11:22:44.0394] for this to take place, it would have to be a request originating from TC39. I don't see any harm in doing that. [11:23:43.0028] so I was going to start an email thread about this--the Ecma secretariat is under the impression that the editor group will handle this themselves. [11:24:36.0462] also give that Michael had found a vendor before (which I'm trying to dig up), it'd be nice to send that reference (and ideally the others that Michael evaluated) to Ecma for their use [11:24:44.0689] indeed, the editors are not intending to produce anything nicer than the print-to-pdf option [11:24:52.0093] I can handle arguing with Ecma--I'm not asking for a lot from you here [11:27:41.0999] I'm sure Michael can dig up the old email threads yes [11:28:12.0831] if you are asking for anything beyond that I am not clear on what it is? [11:28:26.0003] just an email to Ecma saying we're not planning on doing anything more than print-to-pdf? [11:30:11.0432] Yeah, digging up the old email threads would be helpful. In the response email to the thread I'm starting, it'd be great if you said something which amounts to, "We only have bandwidth to produce the HTML version, which can be print-to-pdf'd; if Ecma wants to publish something nicer, we request that this be done by a vendor." [that last half is critical, that the request originate from TC39] [11:30:22.0011] would this be OK from your perspective? [11:30:31.0015] yup definitely [11:37:22.0058] Great, thanks. I started the thread; if you can confirm that I'm accurately representing the state of things, from the point of view of the editors, that'd be helpful. [11:38:27.0913] thanks for your help on this Dan [12:04:04.0216] also sgtm [15:37:59.0539] > Hello, I am one of the editors of ECMA-262, a formal specification published by Ecma International to standardise the programming language commonly known as JavaScript. We author our specification as a website using HTML. You can view it at https://tc39.es/ecma262/. Annually, Ecma International publishes a new version of this document (and makes a small print run). We, the editors of ECMA-262, provide Ecma International with a PDF that is produced through the web browser's print-to-PDF functionality. This has some shortcomings with layout that we believe you may be able to overcome with a more manual layout process. For example, long tables get split across pages, sometimes breaking in the middle of a row and without repeating header rows. We estimate that this document is on the order of 1000 pages. It contains technical diagrams, mathematical notation, and code. The table of contents and section cross-references are already automatically generated, but no page numbers are used within the document. We can start the process as early as March and would like it completed before June. If we are pleased with the result, we would like to establish a long-term relationship for creating this print-ready PDF annually. Would you be able to help us with our needs? [15:38:38.0874] that's the email I sent to the "interior formatting and layout" services, requesting a quote [15:38:42.0230] https://bookdesigners.com https://bookbaby.com/book-formatting https://damonza.com/other-services/formatting-and-layout https://polgarusstudio.com/format-your-book [15:38:48.0244] those were the 4 services I contacted [15:38:56.0197] I got quotes from 2 of them [15:43:52.0475] littledan: also please next time use my @f5.com email for TC39 stuff [15:47:31.0703] shu: per your comment on the async built-ins thing, I just wanted to remind you that Array.fromAsync depends on that, so we'll need to figure something out before its spec text can be finalised/approved [15:47:45.0412] it's not just async iterator helpers [15:53:12.0129] Michael Ficarra: yes, that's why i commented [15:53:16.0504] to remind myself to not forget [15:54:21.0565] > <@michaelficarra:matrix.org> littledan: also please next time use my @f5.com email for TC39 stuff Sure, what is it? [15:58:18.0356] littledan: see DMs 2023-04-20 [12:47:57.0955] any _particular_ reason squash commits are not allowed on the `agendas` repo? [13:02:37.0747] yes, i don't like them and i manage the repo :-) happy to elaborate on why i don't like them but most people don't care about the reasons i have [14:27:04.0231] I don't like them a lot of the time, but they are useful on occasion (like when there are 10 micro-commits for the same thing) [14:28:16.0494] I guess you get around that by force pushing, though that's not always possible [15:52:36.0137] when isn't it possible? [16:44:20.0905] p̶o̶s̶s̶i̶b̶l̶e̶ advisable 2023-04-21 [17:33:03.0588] when isn’t it advisable? [01:04:30.0152] Force push with lease is our friend 2023-04-25 [01:43:43.0512] I tried new decorator and very surprised that it does not have the semantics I expected (sorry I though it too naturally and didn't find the proposal made a different thing). [01:45:43.0721] since native implementation is not available in Chrome, I uses TS 5.0 transpile [01:45:59.0473] I found I cannot make an intuitive @lazy decorator [01:46:46.0009] I received the evaluated value, but I thought it will be a `() => initial_expression` function so I can defer the evaluation of the field. [01:49:03.0045] note: I know I can write `@lazy x = () => expr` but that's a non starter for me since TypeScript currently cannot change the type of the field. (which means `T.x` will have type `() => X` instead of `X`) [02:02:16.0316] I found some discussion in the decorator repo, basically `@lazy` is considered as no real use cases. I'm confused about this decision https://github.com/tc39/proposal-decorators/issues/403 > this is not possible in this proposal due to performance constraints > but there weren’t any compelling use cases in the ecosystem 2023-04-26 [17:21:19.0732] syg: super cool to see the `--harmony-structs` stuff in v8 :O [17:22:21.0459] snek: thanks! hoping for more eyes on the devtrial for folks to play with in node [15:28:48.0153] for decorator metadata - https://slides.com/pzuraq/decorator-metadata-for-stage-3#/1 - it seems like the metadata prototype chain ought to bottom out in `null` rather than `Object.prototype`, right? like module namespace objects do? [15:29:04.0975] cc pzuraq ^ [15:30:02.0456] yeah I just saw your comment, I agree that seems correct [15:30:28.0883] will update it tomorrow [15:36:26.0190] nice [15:36:56.0967] always happy to have one fewer use of `Object.prototype` around 2023-04-27 [21:44:50.0395] am I missing something or does `parseInt` not say that it should handle lowercase hex digits in base 16? https://tc39.es/ecma262/multipage/global-object.html#sec-parseint-string-radix [21:48:52.0265] oh, wait, I just can't read, never mind [21:48:56.0115] it's just a little unclear [00:24:12.0686] Could the function be passed as an argument to the decorator itself? Would need to be a `function` style one so the decorator can call it with the instance as `this` [06:14:12.0483] An earlier version of the decorators proposal had this auto thunking behavior. It was removed for regularity with normal fields and especially static “shape” goals [07:24:18.0238] The type problem is probably something TS will need to figure out. It should chain the transforms produced by decorators to infer the resulting type. [08:23:44.0436] I meant in user land `@lazy(function() { return this.x * 10 })` [08:25:16.0000] As a workaround for the TS types (personally right now I kinda like that decorators can't change the type of something, seems like a simpler starting point while we see what patterns emerge) [09:51:39.0332] I think what Jack is asking for makes sense: a nicer way to write that without functions. Some other languages have this in their notion of field decorators [09:53:03.0339] The goal of a static shape (the reason the original stage 2 decorators didn’t make the cut) means that we should always or never “thunkify” the rhs [09:53:32.0518] Because a lot of use cases don’t require this, it seems to be unfortunately punishing their performance if the answer is “always” [09:54:14.0123] Yehuda originally did include thunkifying, very much on purpose, both for this laziness feature and (more importantly) for computed reactive stuff [09:54:38.0194] In the static shape model, we would have an additional keyword to trigger thunkifying, analogous to accessor [09:54:52.0785] But at that point, you might as well write ()=> [16:26:29.0840] we gotta get https://github.com/tc39/ecma262/pull/2600 merged [16:26:32.0723] it's waiting on tests, is all [16:26:40.0111] if anyone is excited to write some tests that's a good option 2023-04-28 [07:01:41.0280] a dev in my chat group just hit this foot gun [07:01:42.0632] https://github.com/microsoft/TypeScript/pull/54056 [07:02:26.0710] the only correct way to inherit a class like this is to: ```js class T extends Parent { constructor() { super() const old = this.foo this.foo = () => old.call(this) } } ``` [07:02:52.0601] looks like we have too much footgun with class fields [08:37:59.0677] that doesn't really look like a footgun to me [08:38:10.0132] or at least not a footgun with class fields [12:28:25.0725] indeed, that looks fine to me [12:29:44.0569] i'd probably do something like ``` class T extends Parent { #oldFoo = this.foo; foo = () => this.#oldFoo.call(this); } ``` tho [12:29:55.0896] * i'd probably do something like ``` class T extends Parent { #oldFoo = this.foo; foo = () => this.#oldFoo.call(this); } ``` tho, to avoid a constructor 2023-04-29 [20:21:05.0896] it's really hard to educate people why JavaScript class works this way [20:21:34.0920] other class features don't have this problem when inheriting [20:22:26.0595] if we use the `accessor` semantics for class fields, it will also be good with inherit [22:13:22.0247] I feel like "fields are on the instance, methods are on the prototype" is pretty straightforward? [00:35:08.0436] Are the two explicit resource management proposals going to be merged back, now that they are both at stage 3? rbuckton [05:50:24.0984] > <@bakkot:matrix.org> I feel like "fields are on the instance, methods are on the prototype" is pretty straightforward? We definitely could have done accessors for fields. It would have certain advantages and disadvantages. I am also very confident that, if we did that, people would have said “this has lots of footguns, look this basic code doesn’t work as expected” [12:57:40.0821] > <@nicolo-ribaudo:matrix.org> Are the two explicit resource management proposals going to be merged back, now that they are both at stage 3? rbuckton Yes, see https://github.com/tc39/proposal-explicit-resource-management/pull/154 [12:58:36.0466] I'm just waiting for reviews from waldemar and shu [13:20:24.0528] Thank you! 2023-04-30 [18:47:39.0791] > <@bakkot:matrix.org> I feel like "fields are on the instance, methods are on the prototype" is pretty straightforward? only to language lawyers