2024-02-01 [16:12:34.0857] I don't hate it [16:12:58.0808] lgtm [16:14:49.0619] pattern? [16:18:07.0854] my personal preference is no pattern. what's the pattern for? [16:45:12.0453] lol for looking dopey [16:45:17.0752] I don't like the pattern [18:32:17.0670] flagged css and no pattern seem good, fwiw [18:39:53.0232] we should get this merged before the 2024 cut: https://github.com/tc39/ecma262/pull/3103 2024-02-02 [14:03:36.0193] hey folks -- who will be handing the editors' report at plenary and how much time do you need? [14:06:54.0135] Chris de Almeida: me, about 5 minutes, same as always [14:07:40.0402] excellent, thank you 2024-02-04 [23:51:29.0328] shu: DetachArrayBuffer only allows an AB, not a SAB - is there no need for the web to detach SABs? if so, how do they do it in the spec? should DetachArrayBuffer allow SABs also, just like IsDetachedBuffer does? [23:53:37.0624] * shu: DetachArrayBuffer only allows an AB, not a SAB - is there no need/way for the web to detach SABs? if so, how do they do it in the spec? should DetachArrayBuffer allow SABs also, just like IsDetachedBuffer does? [23:55:27.0753] * shu: DetachArrayBuffer only allows an AB, not a SAB - is there no need/way for the web to detach SABs? if so, how do they do it in the spec? should DetachArrayBuffer allow SABs also, just like IsDetachedBuffer does? i do see that structuredClone/MessageChannel in node doesn't allow transferring SABs [11:08:36.0464] SABs cannot be detached [11:08:46.0043] transferirng a SAB doesn't detach it [11:08:50.0671] that is in fact the point of SABs 2024-02-05 [22:04:17.0943] ok, then why does IsDetachedBuffer bother to allow an SAB? [22:04:32.0565] just to simplify callers? [23:11:38.0838] I assume so [23:11:47.0799] it's a reasonable question to ask of a SAB [23:11:54.0979] it's just that the answer is always "no" [23:36:50.0823] gotcha, thanks 2024-02-08 [13:05:47.0266] (i've spoken to shu about it) at the end of the meeting i'll be asking for plenary approval of ES2024, including nicolo's normative PR and the transfer PR, so we can start the clock in time. [13:06:06.0433] what's the hard deadline to merge the PRs by? [13:08:34.0386] February 14th is 70 days ahead of GA which i'm told is on April 24th [13:08:44.0379] * February 14th is 70 days ahead of GA which i'm told is on April 24th (which confused me because GA is usually in june) [13:08:58.0598] but basically, if we get them landed and i cut the spec within a week, and we get approval today, we're fine [13:09:14.0908] (transfer's freshly rebased if anyone wants to stamp it and slap the label on, fwiw) [13:12:00.0141] ljharb: also https://github.com/tc39/ecma262/pull/3222#issuecomment-1931050968 [13:12:14.0365] ah yes thanks, i'll mention that too [15:12:42.0506] who was it that did a publish-on-demand print of the spec and what service did you use? [15:16:58.0332] vaguely recalling twas `bakkot` (?) [15:23:00.0962] nope [15:23:10.0509] I have used lulu.com for other things, but not of the spec [15:55:06.0804] > <@bakkot:matrix.org> I know this because literally yesterday I had a printed book show up at my door which I made with paged.js which was missing lines of text at the bottom of a couple pages and it turned out to be because those lines were present in paged.js's preview but not in the PDF generated by doing print-to-pdf from that page ah, it wasn't the spec but this is what I was thinking of [15:58:38.0040] I've been using lulu for more than a decade for random projects and am generally happy with it. don't expect a heritage-quality book but it's only a little lower quality than a typical mass-market book from a bookstore [15:58:52.0493] and it's like $10 2024-02-12 [13:23:36.0075] (heads up the CI deploy preview stuff on begin.com is broken rn; i've got someone working on updating the SSL certs and getting it fixed - after which i'll merge whatever's waiting) 2024-02-15 [18:56:43.0229] is https://github.com/tc39/ecma262/pull/3175 ready for the merge label? [21:35:58.0645] should be, just stamped [09:13:53.0356] thanks! should https://github.com/tc39/ecma262/pull/2814 have the es2024 label, or should i cut without it? [09:20:50.0670] umm it would be nice to get that in [09:21:03.0196] only thing it's waiting for is shu to respond about the note position [09:21:06.0549] otherwise it LGTM [09:21:25.0475] I also won't die on this hill if someone prefers the note where he put it [09:21:33.0935] k, labeled it. https://github.com/tc39/ecma262/pull/3279 is a nice cleanup that could land right after that, if desired :-) [12:04:06.0037] Michael Ficarra: i like it after? [12:04:18.0687] bakkot can be tie-breaker [12:06:55.0760] I don't care, and we appear to be wildly inconsistent, and therefore cast my vote for the thing which does not require us to push up any changes i.e. leave it as is [12:07:19.0911] (compare e.g. the note in the first case in https://tc39.es/ecma262/multipage/ecmascript-language-expressions.html#sec-runtime-semantics-arrayaccumulation) [12:07:51.0178] wfm [12:58:00.0448] k, i'll cut the spec this evening. feel free to stamp and label https://github.com/tc39/ecma262/pull/3279 before then if desired, but obv no rush [14:41:05.0897] oh also, we need another PR just like https://github.com/tc39/ecma262/pull/2709 and https://github.com/tc39/ecma262/pull/3032, for ES2024. i can write one, but it's probably better if one of yall does [14:42:27.0477] oh crap always forget about the foreword [14:50:31.0574] maybe we just delay until next editor call then? [14:50:35.0286] we have time [14:51:25.0136] we did these in late March last 2 times [14:51:40.0516] true, altho we said in plenary that the spec would be cut this week [14:51:49.0490] it'd be really nice to get it done today or tomorrow [14:52:11.0024] I can write something up tonight or tomorrow [14:52:18.0603] since it's largely just going to be summaries of a selection of the last few editor slides, it shouldn't take too long [14:52:22.0240] * since it's largely just going to be summaries of a selection of the last 6 editor slides, it shouldn't take too long [14:57:15.0569] yeah if Kevin wants to make a PR I can review 2024-02-16 [11:25:37.0268] shu Michael Ficarra https://github.com/tc39/ecma262/pull/3282 2024-02-17 [16:12:38.0170] any update on the merge label for PR 3282?, or anything else to wait for? [16:12:40.0707] * any update on the merge label for PR 3282, or anything else to wait for? [16:13:13.0510] should wait for stamp from michael [16:42:41.0943] sure, but any other PRs besides that one? [16:44:35.0202] ah i misinterpreted "anything else to wait for" as "on that pr" [17:05:44.0262] michael approved, should be good to go [17:05:55.0237] nothing else I can think of [17:06:08.0746] think it's time to cut once that lands [21:16:47.0959] sounds good [21:17:11.0750] (unless someone shu or kevin wants to stamp and label https://github.com/tc39/ecma262/pull/3279 - def not urgent tho) [21:32:12.0862] done [21:33:40.0704] thanks [21:33:47.0378] will have the candidate cut in the next 10-15 [21:45:47.0791] https://github.com/tc39/Reflector/issues/519#issuecomment-1949682730 [21:48:38.0994] woooo [09:27:22.0335] btw confirmed that zhangenming's commit email indeed isn't attached to the github account; the presence of the avatar isn't an indicator. when there's no account, the avatar shown is automatically the PR author's. if you look at the commit that i've pushed, which should have *two* avatars, it only has mine. [09:27:29.0299] * btw confirmed that zhangenming's commit email indeed isn't attached to the github account; the presence of the avatar isn't an indicator. when there's no account, the avatar shown is automatically the PR author's. if you look at the commit that i've pushed (on the old PR and the new one), which should have _two_ avatars, it only has mine. 2024-02-18 [10:18:06.0808] PR #3279 un-defined sec-createmethodproperty (i.e., didn't make it an oldid) [14:09:26.0338] oh oops, thanks, i'll put up a PR to fix it [14:11:36.0982] https://github.com/tc39/ecma262/pull/3283 2024-02-20 [08:55:07.0903] do we want to allow rest parameters in abstract closures? https://github.com/tc39/ecmarkup/issues/572 [08:55:18.0935] I guess I don't see any reason not to? [09:18:58.0866] ...i see no reason not to [10:05:03.0507] I'd say we already do [10:18:16.0324] abstract closures specifically, not AOs [10:48:12.0042] do we have any use cases in 262 rn that could take advantage of that? if not, i'd assume the only reason not to so far was "it hasn't come up" [10:49:42.0153] not that i'm aware of [10:50:00.0365] and yes i also assume only reason not to so far is because it hasn't come up [10:50:22.0258] i mean it's just implicit list creation, could always do it at the callsite [10:53:59.0441] that paragraph makes no distinction between parameter lists of AOs and parameter lists of ACs [10:54:13.0038] so to me it sounds like we're just missing tooling support [10:54:48.0104] Seems like unnecessary complication to me. [10:55:21.0035] as in you'd prefer to do the manual List creation at the callsites, jmdyck? [10:55:46.0552] yup. [10:59:52.0247] I'd say it's not motivated enough to add if we didn't already have it, but since we already have it, I'm fine using it in ACs [11:05:49.0052] In what sense do we already have it? [11:09:05.0068] Currently, `...` is only used in the definition of built-in functions. [11:10:18.0819] see my screenshot above [11:10:35.0352] I read that as parameter lists, anywhere, support the ellipsis notation [11:11:03.0101] and, as a reader, if I saw it used somewhere, and I found the above explanation, I would consider it to apply [11:21:49.0991] so we have it in the sense of a sentence that appears to license the use in any parameter list, but we don't have it in the sense of actual use in AOs/SDOs/ACs. We know that ecmarkup doesn't support it in ACs, does it support it in AOs/SDOs? [11:22:49.0206] The same para also licences optional params in all param lists, and we do use those in AOs, but I seem to recall some sentiment that we'd be better off avoiding them in AOs. [11:25:00.0936] And if you create an AC with a rest param and then pass it to CreateBuiltinFunction, that isn't handled by the phrase "using the provided arguments as the values of the corresponding parameters". [13:00:27.0469] the sentence "using the provided arguments as the values of the corresponding parameters" doesn't need to be generic, it just has to be coherent for all existing uses in the spec [13:00:44.0147] so if we want to pass such an AC to CreateBuiltinFunction, we'd need to update that sentence, but not before then [13:16:04.0036] Yup, but passing such an AC to CBF is exactly what legendecas wants to do, so it's not like it's a hypothetical future problem. [13:23:58.0871] ah, fair [13:57:12.0077] On second thought, I think that rest params are unnecessary complication for AOs/ACs that are explicitly invoked in the spec. But if you want to algorithmically ('dynamically') create a builtin function that accepts (and uses) an arbitrary number of args, then I think you kind of have to pass an AO/AC with a rest param to CBF. (You could maybe fudge it some other way, but I think it would be messy.) [13:59:17.0732] (Currently, the spec's varargs builtins are all created elliptically in CreateIntrinsics, so it doesn't come up.) 2024-02-21 [17:10:21.0635] "note that this phrasing ['is present'] is used both for positional AO parameter lists and optional terms in SDO grammar productions" It's also used in algs for builtin functions. [17:13:39.0278] Long ago, I tried to settle on a different phrase for "parameter X was not passed an argument", to distinguish it from "child node X is omitted from this Parse Node", but met opposition. [17:32:32.0978] I think it's fine to use it in both places [17:32:50.0962] the same word/phrase can mean different things in unambiguously different contexts [19:53:54.0509] There's a potential ambiguity if you have an optional parameter that's typed as a Parse Node. [19:54:48.0656] (which doesn't occur in the current spec) [12:16:11.0309] for discussion in today's call: https://github.com/tc39/proposal-async-context/pull/68#discussion_r1498240523 [15:34:02.0171] I love the low number of fresh issues/PRs allowing us to finally get to some of these reviews during the call [15:34:14.0675] only like 2 or 3 more of these slow weeks and we can get down to a reasonable number of PRs 2024-02-24 [17:47:39.0962] FYI: PR 3074 un-defined ids 'table-31' and 'table-format-control-code-point-usage' [19:21:50.0812] this has happened enough times that it might be worth trying to get CI to warn us about that [19:22:06.0492] it's so hard to catch under manual review