2023-06-01 [18:41:10.0962] ljharb: mind rebasing https://github.com/tc39/ecma262/pull/3046? [18:41:38.0327] also ping bakkot for review on that and https://github.com/tc39/ecma262/pull/2951 [22:09:42.0580] done [23:30:00.0826] bakkot: btw i found my bug with the extra bytes; i was just an idiot and forgot typed arrays aren't concat-spreadable [08:08:36.0551] nobody remembers what is and is not concat spreadable 😞 [09:25:31.0464] i remember that arrays and nodelists are :-p but yeah i agree it's a dumb protocol, it should just have spread any non-primitive arraylike without a protocol [15:42:15.0078] we haven't been keeping up with Annex F in a while [15:42:28.0508] have we been able to get away with any breaking changes since 2019? [15:47:25.0483] that annex is a bit silly given that "add a new method to Array.prototype" is objectively much more likely to break things than dumb completion value edge cases [16:15:19.0463] true [16:15:27.0887] also, a running list isn't all that useful [16:15:43.0708] nobody cares about something that was a "breaking change" years ago and nothing came of it [16:15:55.0273] motion to remove Annex F [16:18:39.0757] it's still useful i think, as history [16:19:00.0330] if we've made any breaking changes since 2019 i think it'd be good to add them, but i don't know of any, unless you could unicode stuff [16:22:05.0051] I would not count Unicode stuff [16:22:33.0004] wan't like `\k` in RegExps technically breaking bakkot? [16:22:44.0443] nope [16:23:09.0929] `\k` only means something else if you have a `(?` somewhere, and that wasn't previously legal [16:23:20.0278] so no previously-legal regexp changed meaning [16:24:59.0293] yeah I can't think of anything [16:25:20.0717] the committee blocked all my proposals to make breaking changes 😝 [16:26:36.0316] lol [16:26:48.0375] yeah there were a few of those i wish we'd done, like get rid of regex symbols 2023-06-02 [17:51:29.0113] we could really use a better font on the spec [17:52:19.0331] I'd prefer something that dots/slashes zero, but also we could select something with better general legibility [17:53:35.0463] also, it would be better to use a web font so everyone has the same experience instead of using a font list with Windows-exclusive fonts at the highest priority (looking at you, Brian!) [18:27:47.0130] > 6. Let t be ((h * msPerHour + m * msPerMinute) + s * msPerSecond) + milli, performing the arithmetic according to IEEE 754-2019 rules (that is, as if using the ECMAScript operators * and +). uh, isn't that just how math on Numbers works in the spec? why do we say it like this? [00:44:36.0541] we don't generally do nontrivial math on Numbers [05:51:13.0076] If multiplication and division count as nontrivial, I count 7 other places: Day, TimeFromYear, HourFromTime, MinFromTime, SecFromTime, MakeDate, Date.prototype.getTimezoneOffset [05:55:23.0179] Not sure how much bother it would be to shift those to mathematical ops. [05:58:22.0392] side question: is there any interest in having those `` ops converted into proper abstract operations? [08:12:47.0637] jmdyck: Yes, I would love that! [08:13:01.0310] I was just thinking about that yesterday [08:13:40.0875] > <@bakkot:matrix.org> we don't generally do nontrivial math on Numbers that's because we typically desire precise semantics, not float semantics, like here [08:14:16.0072] I don't think that has anything to do with an editorial choice 2023-06-07 [14:32:51.0647] Is there a meeting? [14:38:51.0076] i'm going to skip it, but i assume others will join [16:33:45.0700] ljharb: https://github.com/tc39/ecma262/pull/3035 is ready to go now, can you merge as soon as you get a chance so we unblock Justin/Temporal? [16:34:02.0273] sure, will do shortly 2023-06-08 [11:13:04.0185] the latest gh-pages job failed; can someone poke and/or fix it? https://github.com/tc39/ecma262/actions/runs/5205795786 [11:32:26.0398] re-running... [11:33:46.0263] seems to have worked this time [11:45:20.0211] thanks 2023-06-11 [20:41:25.0117] trivial one could use another stamp: https://github.com/tc39/ecma262/pull/2994 [22:16:29.0606] why do we put `%TypedArray%` in percents when defining it https://tc39.es/ecma262/multipage/indexed-collections.html#sec-%typedarray%-intrinsic-object [22:17:39.0636] we're kind of inconsistent I guess [22:36:53.0450] i assume because it's not available as a global [22:38:35.0710] neither is AsyncFunction e.g. [22:39:58.0259] that should use the % also everywhere, no? [22:40:16.0319] TypedArray might be a bit special due to the way they're all defined (NativeError-esque) tho [06:55:33.0228] Yeah, I think GeneratorFunction, AsyncGeneratorFunction, and AsyncFunction should be put in percents. 2023-06-12 [19:42:41.0557] shu: https://github.com/tc39/ecma262/pull/3049 lgtm; you have any last things you want to get in for it or should we mark it ready-to-merge? [00:29:43.0302] also shu did you want to review https://github.com/tc39/ecma262/pull/2418 or is it ready to land? 2023-06-13 [10:21:30.0467] bakkot: i want to do a cursory glance at #2418; #3049 should be ready-to-merge [10:21:36.0510] sorry i've been out due to family 2023-06-15 [08:04:20.0054] https://github.com/tc39/ecma262/pull/2418 should be ready now, right? [10:19:51.0320] 2418 has a "For each X in Y" rather than "For each X of Y" if you want to fix that before merge [10:24:03.0590] (For me, it doesn't much matter, because the rest of the loop-control is so weird that i need to special-case it anyway) [10:40:04.0422] (There's also a "which" that should be "that", if that's something y'all care about.) [10:57:24.0946] never mind, I can submit a PR [14:10:01.0275] I pushed a commit to https://github.com/tc39/ecma262/pull/3066 if anyone wants to take a quick look before stamping [14:10:07.0439] * I pushed a commit to https://github.com/tc39/ecma262/pull/3066 if anyone wants to take a quick look before stamping as ready to merge [14:10:14.0826] though it's trivial enough it probably doesn't need it [15:19:10.0288] jmdyck: Yes, please submit a PR 2023-06-16 [13:43:32.0557] Done. 2023-06-21 [12:39:29.0646] I won't be at today's meeting. [13:30:36.0440] i likely won't either 2023-06-22 [08:38:34.0603] @shu: see https://es.discourse.group/t/is-support-for-subnormal-denormalized-numbers-required/1421 [08:41:39.0477] (and the linked esdiscuss thread [08:41:43.0696] * (and the linked esdiscuss thread) 2023-06-23 [07:45:26.0074] Michael Ficarra: to be clear i'm not, like, refusing to merge it, but if i merge it then we'll have to discuss it in plenary and i'm hopeful to avoid that [07:46:31.0971] i feel like we (tc39) either needs to decide the year is important - and then Annex E is critical, backporting bugfixes to the candidate is critical (which yall three haven't wanted to do much this year or in past years), and then it's fine to link to the snapshots - or, the year's just ecma bureaucracy, and we should only do the bare minimum to satisfy ecma, and we should be linking to the living standard on github everywhere we can [07:47:08.0473] but for the better part of a decade many delegates have been pushing the narrative that it's a living standard, that what's on github is what matters, etc, and linking to ecma's website undermines that [07:49:26.0719] (it'd be a fair point that these links predate the PR and the PR is just updating them, which is fine, but i hadn't realized we were linking to ecma's website in this context still) [07:50:14.0244] ljharb: we considered 2 options: link to the editors' draft and be burdened with updating the reference to the corresponding yearly release when we cut our own yearly release, or just say "the corresponding yearly release" and for the editors' draft, that kind of implies that the corresponding version is also the editors' draft (since you're not currently looking at a yearly release) [07:50:26.0999] we went with the latter because we didn't want that additional maintenance burden [07:51:49.0829] why would we have to update it [07:52:04.0228] it's good for us if the snapshot on ecma's website points people to the real spec. they can update it if they want to. [08:11:39.0271] when we cut the 2024 edition, it should point to the 2024 edition of 402 [08:11:46.0490] not to the editors' draft [08:12:27.0462] why? [08:12:37.0885] the 2024 edition of 402 is either the same as the draft, or, it's obsolete already [08:12:52.0263] we don't want anyone looking at the snapshots, ideally. we only produce those for ecma imo. [08:13:18.0607] if we could put a big red warning on the ones on ecma's site pointing people to the latest one, we would [08:13:19.0927] yes, but someone trying to conform to a yearly release should be conforming to the corresponding yearly release of 402 [08:13:32.0650] it may not even integrate properly with the editors' draft anymore [08:13:38.0521] nobody should be trying to conform to a yearly release [08:13:58.0865] but that is the person we are considering at the moment! [08:14:02.0062] but sure, i see the point. i think that's a really easy thing to automate tho, and i'm happy to do it manually once a year compared to having the wrong link the rest of the year [08:14:53.0109] I am concerned about the fragility of that process [08:15:09.0900] I'd maybe be okay with it if we had a CI process that ran on the release branches that could check it or somethign [08:15:15.0643] sure, i'm fine with adding that too [08:16:14.0852] but also, the downside of that process being skipped is that someone doing a bad thing - trying to conform to a yearly release - *might* have to do a bit of extra work to find a yearly release. and in that scenario, ecma can make manual updates (they've done so in the past) the downside of keeping the ecma links is that people will be implementing an obsolete snapshot that may contain un-backported spec bugs [08:16:25.0946] and i think the latter is far more likely than the former [08:17:10.0986] on Ecma's page about 262, it links to the editors' draft [08:17:13.0797] * but also, the downside of that process being skipped is that someone doing a bad thing - trying to conform to a yearly release - _might_ have to do a bit of extra work to find a yearly release. and in that scenario, ecma can make manual updates to fix the links (they've done so in the past for different href issues) the downside of keeping the ecma links is that people will be implementing an obsolete snapshot that may contain un-backported spec bugs [08:17:24.0112] maybe the 402 editors should ask Ecma to update their page to also link to the draft [08:17:24.0512] which is great, we had to advocate for that as i recall [08:17:30.0384] yes, they should [08:17:39.0855] then that should be sufficient [08:19:15.0189] that would still be unnecessary indirection [08:19:28.0461] but i agree at that point, then this change wouldn't be as harmful as i'm suggesting [08:20:11.0929] i can very easily update the build process to replace the tc39.es links for ecma ones before next march, if that fragility is a concern [08:20:20.0549] I will talk to bakkot about it again today and let you know what we decide [10:28:49.0728] Linking to the draft version from the annual version is definitely wrong because it is not generally going to be consistent [10:28:57.0536] I am OK with any option which does not have that property [12:10:53.0400] i agree it's wrong, and would prefer it not be wrong, but i also care the least about that particular bad outcome (and i think it's easy to avoid) [12:14:49.0382] I've opened https://github.com/tc39/ecma402/issues/795 2023-06-27 [17:00:53.0797] sorry i'll be out this week as well, on PTO [17:01:05.0401] will take stock of stage 3/4 things to review 2023-06-29 [10:39:38.0535] the spec doesn't define a "code unit" or a "code point", and there's enough ambiguity that they could either be a string or an integer (since either is easily convertible to the other). what type of thing would you expect them to be? [10:46:49.0464] Depends what you mean by "expect". Over the course of a few PRs, they've become more like an opaque type. E.g., you can't just do arithmetic on a code point, you have to ask for its numeric value and then do arithmetic on that instead. [10:49:09.0323] (I think that transition is not quite complete.) [11:00:11.0730] definitely not a string [11:00:16.0716] I would not treat them as integers either though [11:01:53.0815] what are they, then? [11:02:40.0976] What is a Boolean? What is *undefined*? [11:02:54.0156] so its its own primitive type?? [11:02:55.0141] * so its its own primitive type? [11:03:14.0166] that's a fine answer - like a spec enum - but then, would you say that "how to represent it in JS" is a judgement call? [11:04:05.0722] Isn't "how to represent it" always a judgement call? [11:09:02.0191] more specifically, I think it's a judgement call whether you represent a code point via UTF-8 or UTF-32 or something else. [11:30:31.0802] ok [11:31:59.0699] yeah I mean it's always a judgement call [11:33:36.0522] if you were writing typescript I would tell you to use a phantom brand but presumably you are not [11:34:08.0313] https://www.typescriptlang.org/play?#code/C4TwDgpgBAwg9gEwgVQHYEthQLxVQVwFsAjCAJygDIoBvKAfXuLIENUEAuKAcgGNEI+DMG5QAvgG4AUFIA2ELAA8u8JGkw4oABglQA9HqjkycMnIVQQKgeqy4tUFgGdYN4boNRC+J1lJHFMFl0XkwgA [11:35:20.0768] if you're asking for practical advice, in JS I'd either just use a number and try to be very disciplined about which things are code units and which are not, or use an explicit `{ type: 'code unit', value: number }` wrapper so that they were not interchangeable [11:35:50.0446] (of course IMO the better way to prevent that sort of confusion is TypeScript, but.) [13:36:30.0706] yooo you can do phantom types in TypeScript? [13:36:42.0993] I may have to actually check out this TypeScript thing some day [13:36:53.0821] not today though [13:42:40.0221] yeah though I guess in that example it's not exactly "phantom" [13:43:56.0118] yeah it can technically be satisfied by something without putting the phantom type on it [13:43:59.0383] it's a close-enough hack [13:44:27.0869] https://github.com/Z3Prover/z3/blob/30a2ced9aa7f97e7c896072c11a64549b4dde899/src/api/js/scripts/make-ts-wrapper.ts#L378-L383 [13:44:33.0166] is a more phantom-y example [13:45:15.0547] the type parameter is only used to tell the type system about the relationships between types, not for the actual data in any way [13:56:25.0612] ljharb: https://github.com/tc39/ecma262/releases/tag/es2023 pretty sure it was approved on the 27th, not the 29th (today) [14:10:58.0639] whoops, thanks, not sure where I got 29th 2023-06-30 [08:48:24.0062] ljharb: do you think we should delete the old candidate releases? [09:11:53.0097] no, they're historical markers [09:12:03.0803] especially in the years where there was more than one candidate