2022-01-05 [07:36:20.0739] https://github.com/tc39/proposal-class-fields is still getting new comments despite it being Stage 4. It should get archived, right? [07:43:41.0033] maybe ljharb (our Administrator-to-be) would like to handle that [07:53:49.0672] Yup, that is the first thing on my list 2022-01-06 [10:55:24.0433] FYI, the State of JS people have reached out to TC39 at https://es.discourse.group/t/help-shape-the-contents-of-the-next-state-of-js-survey/1148 asking what sort of questions they should be asking for the upcoming community survey. This might be really useful. [10:57:36.0268] * FYI, the State of JS people have reached out to TC39 at https://es.discourse.group/t/help-shape-the-contents-of-the-next-state-of-js-survey/1148 asking what sort of questions they should be asking for the upcoming survey. This might be really useful. [10:57:42.0056] * FYI, the State of JS people have reached out to TC39 at https://es.discourse.group/t/help-shape-the-contents-of-the-next-state-of-js-survey/1148 asking what sort of questions they should be asking for the upcoming community survey. This might be really useful. [10:58:18.0850] Oh wait, I missed this already in the General chat, whoops. 2022-01-10 [22:54:10.0326] i'd love a review here: https://github.com/tc39/notes/pull/176 if someone has a sec [14:44:45.0192] Aki bterlson Rob Palmer can one of you take a look at this invited expert issue? https://github.com/tc39/Admin-and-Business/issues/190 [14:45:29.0956] yep - I will get to it Michael - thank you for the reminder [14:45:38.0394] thanks so much Rob! 2022-01-15 [17:42:13.0315] Only three proposals made today's deadline for possible advancement at this month's TC39 meeting. Looks like it's going to be a short meeting… [09:17:48.0808] i count 4 for advancement, but indeed there'll be a lot of time that could be filled with updates and discussions [12:00:22.0129] It might be worth offloading some of the chartered incubator topics into plenary, if there’s lots of room. https://github.com/tc39/incubator-agendas/issues/22 [12:00:22.0989] https://github.com/tc39/process-document/pull/33 might also be worth discussing. 2022-01-18 [10:22:10.0438] jschoi: agreed, i haven't had time to run any calls at all between last meeting and this one [10:57:00.0403] > <@ljharb:matrix.org> i count 4 for advancement, but indeed there'll be a lot of time that could be filled with updates and discussions Ah, enum for stage 1 was in the "open-ended discussion category" instead of in the proposals. [11:03:15.0680] I thought TC39 was this week… [11:03:26.0610] Anyways, TCQ's SSL cert is expired. [11:03:34.0367] We should fix that before plenary. [11:03:41.0578] bterlson: ^ [12:52:00.0986] Bterlson is on it. [14:31:39.0444] What is the "presentation from KAIST research group"? I'd like an idea of what we're planning on discussing for this item. It's hard to prepare or look at background materials without any idea what the topic is. [14:45:22.0946] Here is a link to their publications: https://plrg.kaist.ac.kr/research/publications Michael Ficarra might want to ask them if there is anything that might be relevant to look at before their presentation. Also I believe they have an "as late as possible in the day" scheduling constraint. The 2-3 PM slot probably makes sense for them? [15:01:18.0938] waldemar: the most relevant papers are https://dl.acm.org/doi/10.1145/3324884.3416632 and https://ieeexplore.ieee.org/document/9402086 2022-01-19 [17:09:03.0610] I've also asked them to post links to resources next to their agenda item once they are prepared [17:14:25.0572] from my invited expert proposal (https://github.com/tc39/Admin-and-Business/issues/187): [17:14:34.0669] > Reason for invitation: These researchers from KAIST presented their recently published works to the TC39 editor group. This work includes automatic generation of a reference implementation, automatic generation of a step-through debugger, and tools for helping editors to catch spec errors. We think this work would be useful to share more broadly with the rest of the committee in a plenary. [14:07:28.0922] jschoi: your agenda item for Array.fromAsync does not say it's going for stage 3 [14:07:45.0612] so people might not be reviewing it in enough detail [14:10:44.0277] (the rules for advancement eligibility "Proposals looking to advance to stages 2, 3, or 4 must be added (**and noted as such**)" [emphasis added], so in principle someone can object to advancement on those grounds) [14:15:27.0997] also it's currently stage 2; the "stage" column is the stage it _is_, not going for [14:34:47.0336] oops [14:36:16.0859] i pushed up a change to that, under the assumption it's meant to be for stage 3. if that's not the intention, we can remove it; if someone missed it between the deadline and now due to the mislabeling, we can deal with that as part of the normal process in plenary [14:36:59.0334] > <@bakkot:matrix.org> also it's currently stage 2; the "stage" column is the stage it _is_, not going for Oh darn - I think enum and string split might be wrong too. Should both be 0 in that column then, right? [14:37:22.0795] yes, i'll fix those too [14:37:36.0801] > <@ljharb:matrix.org> yes, i'll fix those too thx :-) [15:48:29.0268] Yeah, my intent was to go for Stage 3. I marked it as such in the pull request but I forgot to add it to the table entry itself. My apologies. 🙇 2022-01-24 [01:18:01.0927] 👀 is there drafted agenda for this meeting so I can schedule my sleeping time? thanks! [03:14:34.0838] jschoi: i have a dumb question, what if promise.all accepted async iterators and returned an array of values, instead of doing that in a separate API? re: https://github.com/tc39/proposal-array-from-async [03:17:01.0295] * jschoi: i have a dumb question, what if promise.all accepted async iterators (it already takes iterables), instead of doing that in a separate API? re: https://github.com/tc39/proposal-array-from-async [05:28:57.0100] The draft schedule for today's meeting is now posted: https://hackmd.io/s3ovtgLsTa-QAhFqYTl_YA [05:29:06.0829] * The draft schedule for today's meeting is now posted [05:29:26.0725] * The draft schedule for today's meeting is now posted: https://github.com/tc39/Reflector/issues/411 [05:31:48.0122] > <@robpalme:matrix.org> The draft schedule for today's meeting is now posted: https://github.com/tc39/Reflector/issues/411 Thanks! 🙏 [07:59:53.0759] > <@yulia:mozilla.org> jschoi: i have a dumb question, what if promise.all accepted async iterators (it already takes iterables), instead of doing that in a separate API? re: https://github.com/tc39/proposal-array-from-async `Promise.all`’s current semantics involve parallel awaiting of input values. If some `input` yields `a, b, c`, then `Promise.all(input)` would first drain `input` into its three items `a, b, c`, and then it would simultaneously await `a, b, c`. Parallel awaiting is impossible when getting values from async iterators; we must sequentially await the values. I think it would be quite confusing if `Promise.all` did parallel awaiting on sync inputs and sequential awaiting on async inputs. This is the similar to how it would be confusing if `for await` did parallel awaiting on sync inputs but sequential sequential awaiting on async inputs. Hopefully that makes sense. [08:00:30.0717] I see, thanks! [08:17:33.0102] * > <@yulia:mozilla.org> jschoi: i have a dumb question, what if promise.all accepted async iterators (it already takes iterables), instead of doing that in a separate API? re: https://github.com/tc39/proposal-array-from-async `Promise.all`’s current semantics involve parallel awaiting of input values. If some `input` yields `a, b, c`, then `Promise.all(input)` would first drain `input` into its three items `a, b, c`, and then it would simultaneously await `a, b, c`. Parallel awaiting is impossible when getting values from async iterators; we must sequentially await for the values. I think it would be quite confusing if `Promise.all` did parallel awaiting on sync inputs and sequential awaiting on async inputs. This is the similar to how it would be confusing if `for await` did parallel awaiting on sync inputs but sequential sequential awaiting on async inputs. Hopefully that makes sense. [09:48:09.0063] We will start the meeting in 12 minutes! [10:24:27.0713] I like the formal votes, but fine with it going without it. I also have no opposition to ryzokuken being on both roles (402 Editor + TC39 Co-Chair). [10:50:29.0004] we could in theory make a bot to download issues but I don't wanna do it [10:55:19.0300] bakkot: is the ecmarkup change an API change or breaking in the sense that new things in the biblio will change where links go/what links/etc.? [10:55:22.0470] just curious [10:56:29.0306] Rick Waldron: can you confirm that https://github.com/tc39/proposal-modules-pragma should become an inactive proposal? [10:57:41.0978] ljharb: That was true in 2017. I have no further information that changes that status [10:58:00.0772] ok thanks, i'll update the repo and the proposals list to mark it as such. would you call it "rejected' or "withdrawn"? [10:58:24.0198] ljharb: lemme check the notes, one sec. [10:59:57.0044] possible bot autocorrect needed: "x markup" -> "ecmarkup" [10:59:58.0341] bterlson: main change is that the biblio will not be built in, and you'll have to specify `--load-biblio=file/package` to get the biblio [11:00:08.0548] so it can be updated independently of ecmarkup [11:00:28.0513] (in particular the plan is to release a new biblio with every commit to the spec, or at least every one which affects the biblio) [11:00:37.0210] * (in particularly the plan is to release a new biblio with every commit to the spec, or at least every one which affects the biblio) [11:01:14.0011] * (in particular the plan is to release a new biblio with every commit to the spec, or at least every one which affects the biblio) [11:01:35.0707] ljharb: I cannot find discussion of record, but I would not pursue it myself in 2022, or any year... I can't even remember why I thought it was an idea to explore at the time. [11:01:49.0425] thank you for the feedback on this topic, sffc :-) [11:02:05.0559] > <@rwaldron:matrix.org> ljharb: I cannot find discussion of record, but I would not pursue it myself in 2022, or any year... I can't even remember why I thought it was an idea to explore at the time. I may have been doing a favor for a community member [11:02:16.0837] > <@rwaldron:matrix.org> ljharb: I cannot find discussion of record, but I would not pursue it myself in 2022, or any year... I can't even remember why I thought it was an idea to explore at the time. as i recall, it was around the time of the fauxtrage about `.js` and ESM in node [11:02:27.0483] i'll mark it as just being "inactive" [11:02:50.0867] @bakkot sounds great, it's super annoying for non-262 uses to have the biblio there at all :-P [11:03:05.0610] > <@ljharb:matrix.org> as i recall, it was around the time of the fauxtrage about `.js` and ESM in node Which would TOTALLY support my suspicion that I was "proxy-championing" this [11:03:14.0968] This is so amazing shu [11:03:23.0760] yulia Michael Ficarra Here is a discussion from October (https://github.com/tc39/ecma402/blob/master/meetings/notes-2021-10-07.md#normative-add-new-numbering-system-tnsa) and another from January (https://github.com/tc39/ecma402/blob/master/meetings/notes-2022-01-13.md#normative-add-new-numbering-system-tnsa) [11:03:32.0345] That is something I would've done: tell a community member to write a solution and that I would present it in good faith. [11:03:36.0564] thanks! kevin helped a lot too with the ecmarkup stuff needed [11:04:14.0248] But it looks like they never really pushed forward on it, and since I was acting in a proxy role, I wouldn't have done any extra work beyond reporting to committee. [11:09:43.0381] > <@bterlson:matrix.org> @bakkot sounds great, it's super annoying for non-262 uses to have the biblio there at all :-P there's actually already a `--no-ecma-262-biblio` which tells it not to load it [11:10:00.0862] > <@bterlson:matrix.org> @bakkot sounds great, it's super annoying for non-262 uses to have the biblio there at all :-P * there's actually already a `--no-ecma-262-biblio` which tells it not to load the built-in one [11:10:36.0748] sffc: per anba's comment here (https://github.com/tc39/ecma402/pull/614#issuecomment-938638422) i don't think we have any comments but i will clear it with our intl team [11:13:29.0358] How do you annotate that something doesn't call user code? [11:15:11.0540] waldemar: https://github.com/tc39/ecma262/pull/2548 describes guidance for spec authors, relevant part of which is > False positives can be manually suppressed with `suppressed`. [11:15:13.0208] waldemar: if you need to do it manually, like this: https://github.com/tc39/ecma262/pull/2548/files#diff-181371b08d71216599b0acccbaabd03c306da6de142ea6275c2135810999805aR18446 [11:15:31.0905] but mostly it's implied by `!` [11:16:22.0246] @waldemar: you can wrap the abstract operation / SDO call in `AbstractOp()`, but yeah as Michael Ficarra says `!` implies the suppression [11:24:28.0695] for spec authors, the tests in this file also serve as a good tutorial for how to annotate, but hopefully most spec authors require no additional work: https://github.com/tc39/ecmarkup/blob/main/test/baselines/sources/effect-user-code.html [11:25:51.0989] * for spec authors, the tests in this file also serve as a good tutorial for how to annotate, but hopefully most spec drafts require no additional work: https://github.com/tc39/ecmarkup/blob/main/test/baselines/sources/effect-user-code.html [11:39:53.0469] whatwg on polyfils: https://w3ctag.github.io/polyfills/ [11:41:28.0505] > <@yulia:mozilla.org> whatwg on polyfils: https://w3ctag.github.io/polyfills/ that document is broken for me [11:41:29.0544] did my queue item get deleted? [11:42:49.0510] Rob Palmer: ^ [11:43:48.0653] > <@michaelficarra:matrix.org> that document is broken for me took a second for me [11:44:09.0071] perhaps the CSS load is non-blocking [11:44:48.0894] sorry shu I did not see you on the queu [11:45:10.0266] put yourself back on and i shall re-order - just tell me where it should go [11:45:11.0512] hm, pretty sure i added myself, guess i'll re-add myself to the end [11:45:27.0001] i can move you up [11:45:38.0124] in that doc they have ``` * **polyfill**: Emulates a well established feature of the web platform * **speculative polyfill** (aka 'ponyfill', 'prollyfill', 'nottifill'): Emulates a proposed feature of the web platform * **library** (aka 'module'): Provides features or functionality not anticipated to be a web platform feature ``` [11:45:39.0977] Rob Palmer: after J. S. Choi is done is good [11:46:34.0026] actually you're already there! [11:46:42.0628] just refresh - tcq bug :-( [11:47:02.0162] oh weird :( [11:48:10.0060] jschoi: i didn't have time to respond, but yes feature detection is a problem [11:49:38.0506] though i wonder if it makes sense to include this in the document. Experiment should be treated as not in production code [11:50:53.0645] Here's the published version of the TAG finding, which is *not* broken: https://www.w3.org/2001/tag/doc/polyfills/ [11:51:19.0911] Also note that this is *not* WHATWG, it's the W3C TAG. [11:51:27.0885] I feel like this could be cited? [11:51:31.0816] * I feel like this could be cited? [11:51:34.0838] > <@tabatkins:matrix.org> Also note that this is *not* WHATWG, it's the W3C TAG. oh, my bad [11:51:35.0792] I just don't think anything will tangibly change, whatever recommendation we make [11:51:48.0350] clarity is helpful though [11:53:39.0092] I haven't had time to review the document we're being asked to voice our support for [11:53:53.0307] maybe we come back with a modified proposal that references the document next time? [11:54:47.0322] Yeah, that makes sense [11:55:24.0794] for the specific wording, that's fine, but i still wanted to get consensus on the conceptual change, to avoid distractions in the PR. [11:57:54.0007] we may need to change 3.5 of that document... [11:58:46.0322] 3.5? [11:59:02.0788] https://www.w3.org/2001/tag/doc/polyfills/#detect-and-defer-to-native-implementations [11:59:35.0811] yeah, that sounds like the opposite of what we would advise [12:00:30.0963] Note that that's explicitly guarded by "past the tipping point", aka things that are already well-decided and implemented in some browsers, and thus very unlikely to change. [12:01:03.0705] It explicitly warns against doing this before that point, and has examples of the "grab the native if it exists, otherwise use the polyfill" pattern as explicitly discouraged. [12:02:33.0458] hmmm, maybe we can define tipping point clearly [12:02:51.0674] but even then , it seems liable to being misinterpretted.. [12:03:27.0080] ah, thanks TabAtkins I misread it [12:24:23.0083] if we need clarifications we can post on the TAGs design issue tracker [12:25:28.0640] * I think tab is right, this aligns with our goals it looks like. if we need clarifications we can post on the TAGs design issue tracker [12:55:04.0167] is ptomato ready to go? [12:59:04.0913] I am [12:59:45.0510] great [13:18:38.0480] motion to close this discussion and move on, no one disagrees with the proposal afaict [13:19:25.0573] well, I appreciate everyone having clarity on the topics we discuss [14:15:48.0577] would this document basically be like a new TG? [14:16:03.0461] i can ask that on the queue if it wouldn't derail the ending of the item [14:17:35.0055] is 404 a tg? [14:17:38.0938] * is 404 a tg? [14:17:40.0456] i think so [14:17:48.0169] actually i dunno, maybe not [14:17:50.0269] we also have the spec suite as a document [14:17:54.0864] i see this as closer to one of those [14:18:01.0730] since there's just tc39, 402, and security [14:18:03.0194] k [14:18:17.0316] i still want it to be 405 [14:19:22.0568] ljharb: i don't see it as a TG, no [14:19:32.0345] the IP-making body is still TG1 [14:19:39.0726] it just goes into a separate document than ecma262 [14:20:09.0969] cool [14:20:27.0828] i don't know how to legally set that up but i'm not too worried about it? [14:21:21.0151] can prolly just make a repo for it when we're at that stage, which i'm now empowered to do [14:54:01.0905] When did the "structured clone" discussion start? I really thought it started before 2pm. Isn't the time box spent? [14:55:53.0569] Bradford Smith: meeting's over [14:55:59.0121] this is post-plenary me picking mark's brain [14:56:29.0831] oh, thx [15:49:06.0611] ljharb: can you use your admin powers to drop a link to https://github.com/bakkot/proposal-duplicate-named-capturing-groups on https://github.com/tc39/proposal-regexp-named-groups/issues/44 ? [15:50:41.0567] also, new (small) regex proposal I intend to put together for next meeting: allow capture group names to be re-used (when in different `|` alternatives) rather than enforcing uniqueness in the full regex https://github.com/bakkot/proposal-duplicate-named-capturing-groups 2022-01-25 [16:46:48.0084] sure, i can unarchive it if you want to comment it yourself? just lmk [16:47:25.0974] > <@bakkot:matrix.org> ljharb: can you use your admin powers to drop a link to https://github.com/bakkot/proposal-duplicate-named-capturing-groups on https://github.com/tc39/proposal-regexp-named-groups/issues/44 ? * sure, i can unarchive it if you want to comment it yourself? just lmk [16:47:50.0717] also, what happened with the "set method argument internal slot" discussion? i had to drop off [16:58:10.0293] * sure, i can unarchive it if you want to comment it yourself? just lmk, or if we can't coordinate, i can [19:32:46.0276] ljharb: if you want to unarchive tonight and ping me I'll link it, or you should feel free to do so on my behalf [19:33:11.0253] > <@ljharb:matrix.org> also, what happened with the "set method argument internal slot" discussion? i had to drop off tl;dr was, for the argument to `Set.prototype.union`, MM does not like the idea of _only_ reaching in to the [[SetData]] internal slot, but would potentially be OK with reaching in to that slot if present and otherwise falling back to the publicly exposed methods (`has`, etc), even though this would technically be a violation of proxy transparency (because for most cases it would still Just Work) [19:33:12.0903] bakkot: done now, go nuts [19:34:24.0206] bakkot: but the receiver would still have slot access only, yes? [19:34:32.0427] yeah, receiver is fine [19:34:37.0817] that's already how it works [19:34:46.0767] awesome [19:34:49.0100] that is, it is already common to access the internal slot of the receiver [19:34:55.0507] (re-archived the repo, after your comment; lmk if you need anything else) [19:35:03.0674] nope, that was all, thanks [19:35:17.0532] though in both the argument case and the receiver case we need to figure out what affordances, if any, we're going to make for subclasses [08:38:53.0172] hi I've read the meeting logs yesterday. I'm interested in reviewing structured clone algr. (cc syg ) [08:40:54.0146] Jack Works: sure, will request your review when the draft is ready [08:49:20.0372] 👀 I set an alarm on 14:00 PST and not be able to present enum before 14:00 cause I'm sleeping. [08:52:50.0339] Jack Works: we'll schedule you as late as possible today to help you sleep - so in between 14:00-15:00 PST [09:57:01.0660] This is your 4 minute warning: Plenary starts soon [10:02:18.0016] I can't do notes right away, but I can in a bit [10:03:15.0269] thanks ptomato [10:27:03.0089] Mathieu Hofman: can you confirm the conclusion we have captured in the notes is correct [10:27:10.0574] I think so but best to confirm [10:44:57.0848] never GCing is always legal, so XS's implementation would still be conformant [11:00:25.0095] +1, that was a mistake [11:00:47.0907] (but i also think registered symbols themselves are a mistake) [11:04:46.0899] what was the original use case for them anyway [11:05:01.0486] for registered symbols? [11:05:07.0532] it lets you do the same thing as well-known symbols for libraries [11:05:12.0515] so a library can interop with itself across realms [11:05:22.0245] but... what realms [11:05:24.0963] we didn't have sync realms [11:05:40.0866] iframes [11:05:48.0655] we have always had iframes [11:05:48.0791] oh, i guess sync iframes [11:05:54.0917] but also, not necessarily across realms [11:05:59.0345] i have a hard time believing that was a use case tc39 cared about back then? [11:05:59.0886] just multiple version of the library within the same realm [11:06:06.0082] * but also, not necessarily across realms [11:06:09.0908] Ashley Claymore: can you share with me the test case you used to identify SM gc behavior? [11:06:23.0620] yes, right, coordination without having the library do the heavy lifting [11:07:10.0666] > <@yulia:mozilla.org> Ashley Claymore: can you share with me the test case you used to identify SM gc behavior? will do :) [11:07:26.0284] well, also lets consumers of a library coordinate with it without having a direct reference to it [11:07:46.0826] like you can have a library which defines a protocol, and have someone else implement that protocol without reference to the library [11:09:02.0097] shu: as much as i claim that the existence of iframes means browsers can't pretend realms don't exist, i completely agree with you that it's unlikely that was the motivation [11:09:23.0522] making the symbol registry realm-specific would have supported the library use case just fine, i think [11:09:33.0217] forget I said realms; "multiple versions of a library" is the right thing to think about, whether that's cross-realm or not [11:09:43.0714] and consumers of a library which aren't including it directly [11:10:58.0030] erights: what if i had a WeakMap of a symbol to an object, and then a WeakRef of the same object, and no other refs to the object. couldn't i observe the collection of the symbol via the collection of the object? [11:19:52.0376] subclassing doesn't work anyway, because of e.g. `BaseClass[method].call(subclassInstance, …)` directly interacting with internal slots [11:20:06.0385] ljharb: fwiw I don't think "registered symbols" and "unique symbols" are actually the same kind of thing for users [11:20:15.0533] they have the same type but they really do not come up in the same cases [11:21:12.0896] Aren't registered Symbols often used for safely branding objects, in case you have more the one copy of a library (so instanceof is risky)? [11:21:44.0065] Ben Newman (Apollo, @benjamn on GH): yes, but that's not like a regular symbol [11:22:05.0123] I was responding to the question about whether anyone actually uses registered Symbols [11:22:17.0572] ah, sure [11:22:33.0692] that's the common _appropriate_ use case, yeah [11:24:31.0958] "eternal" seems to mean/imply "recoverable after all references are lost" (fair?) [11:24:32.0226] Ben Newman (Apollo, @benjamn on GH): my claim is that there is no good reason to want to put such a brand in a WeakMap [11:24:46.0148] at least not that i can think of offhand [11:25:51.0419] I'm uncomfortable with throwing "good" around like that [11:25:53.0436] hm, i just got kicked off the call [11:25:57.0150] Me too [11:25:59.0313] what did i miss? [11:26:05.0067] ah k [11:26:19.0827] did the call just die? [11:26:47.0133] same [11:26:48.0892] (it's back if you reconnect) [11:27:17.0386] * Oh again [11:30:03.0364] let me put it a different way: the reason to want a registered symbol is that you want something which lives forever, for e.g. coordination across instances/consumers of a library. the reason you want to put symbols in a weakmap is that you want to hold something weakly - you have a symbol which is ephemeral, and you want to hold something else ephemerally. (Otherwise you could just use a Map.) these uses are directly opposed. [11:31:16.0912] I'm fine with never collecting registered symbols, as are V8 and Mozilla's engine, it sounds like [11:31:32.0290] they are, quite literally, always reachable once registered, even if you've lost all references [11:32:44.0274] bakkot: But you can also intentionally craft an object that should live forever and also place it in a weakmap. If you *want* to track a symbol in a way that is "preferrably" weak, you would have to write a lot of defensive code and have both a WeakMap and a Map. [11:33:03.0821] the "optimization" of collecting registered symbols anyway and then later returning a new reference if someone asks for them again with Symbol.for is simply unsound, IMO [11:33:15.0209] it would be nice to hear about a JS engine that actually does that [11:34:31.0126] is someone from Apple on the call? msaboff ? does Safari actually collect registered symbols? [11:34:34.0296] rbuckton: my position is that the desire to weakly hold symbols which may or may not be registered is niche enough that it's sufficient for the language to _support_ it without needing to make it trivial [11:34:39.0087] * rbuckton: my position is that the desire to weakly hold symbols which may or may not be registered is niche enough that it's sufficient for the language to _support_ it without needing to make it trivial [11:34:53.0878] Robin Ricard: can you add "no preference, general support"? [11:35:16.0120] XS does not collect any symbols (just stated by Peter H on the call) [11:35:19.0642] i mean, i care, i like it [11:35:28.0731] yulia: "indifferent" [11:35:31.0423] Ben Newman (Apollo, @benjamn on GH): why is that unsound? [11:35:35.0620] changed wording [11:35:42.0844] it happens with strings all the time [11:35:56.0475] and doubles, actually, in V8 [11:36:12.0511] @shu because the reference shouldn't change in any semantically observable way, and the WeakMap question provides observability [11:36:27.0384] strings aren't stored in [weak]maps/sets by reference though [11:36:31.0822] they're stored by value [11:36:41.0236] it's only unsound if WeakMaps can hold registered symbols [11:36:42.0724] strings can't be put into weak collections at all [11:36:52.0344] * strings can't be put into weak collections at all [11:36:53.0453] (and doing so does not prevent GC of the symbol) [11:36:59.0344] correct [11:37:06.0287] I'm saying it's unsound anyway, and this is just the first gotcha we've encountered [11:37:13.0496] it's... not unsound anyway [11:37:21.0418] it's sound by accident, currently [11:37:34.0454] wasn't an accident [11:37:50.0982] that was definitely an intentional part of the design of the symbol registry [11:38:12.0146] yes, they *were* accidentally eternal before, when it was keyed by something else, like parse nodes or something? [11:38:34.0137] i have the screenshots if anyone needs them [11:38:43.0211] you're thinking of template tags [11:38:43.0548] cc Robin Ricard [11:38:53.0369] oh, i am, bakkot correct [11:41:55.0776] thanks yulia, nicolo took them as well so we are good [11:43:30.0902] catch the positive names? [11:43:36.0243] * catch the positive names? [11:50:54.0430] shu: "We should do the same as others" isn't quite the point, "everyone else is doing something useful that we aren't" is. [11:52:36.0161] TabAtkins: can i cast your own spell on you? isn't that a fully general argument for stdlib differences? [11:53:12.0783] No, it's just pointing out that the argument wasn't just "we should be following the bandwagon". [11:53:21.0438] ah [11:53:34.0342] i was responding to the narrower motivating story of "even surma got tripped up" [11:54:02.0314] The other lang's version of split() is just genuinely better, which is definitely part of why JS's version is so confusing. ^_^ [11:54:07.0150] which isn't the same as "i wish we had this other behavior but we don't", it's "i thought our behavior was X but it wasn't" [11:54:54.0605] I will try to remember to ask my dad about the history of this next time I talk to him [11:55:16.0455] Insofar as Surma would have been confused by Python (off-by-one versus the other langs), sure. But it's not clear from his particular complaint whether it was *just* familiarity or "i'm confused this works differently entirely" [11:55:46.0341] I'd like if we rename this splitn to `String.prototype.part` (or parts) [11:55:54.0537] * I'd like if we rename this splitn to `String.prototype.part` (or parts) [12:00:41.0913] Going for the `{remainder: true}` part and taking on Python's numbering semantics would defuse these complains, I think. [12:00:59.0717] I have an open issue about the possible confusion that Chip is talking about: https://github.com/lucacasonato/proposal-reversible-string-split/issues/6 [12:01:24.0638] So `.split(..., 2, ...)` always returns 2 bits between separators, you just get a *third* item with the remainder if you pass the flag. [12:02:10.0052] > taking on Python's numbering semantics would defuse these complains, I think [12:02:17.0143] say more about what that means? [12:05:22.0203] Luca Casonato: i invited you to tc39-transfer on github, so you can bounce your proposal repo there [12:06:14.0846] bakkot: Well there was an "and" there that was pretty important. [12:06:33.0611] The part after the "and" that you quoted was more of an "(and, in effect, ...)" [12:07:39.0703] > <@leobalter:matrix.org> I'd like if we rename this splitn to `String.prototype.part` (or parts) Could you add that to this issue? https://github.com/lucacasonato/proposal-reversible-string-split/issues/6 [12:08:32.0194] But basically, if we use a flag argument in .split(), I don't think we should significantly change the existing semantics/behavior of the proposal. `.split(..., 2)` should still always trigger (up to) 2 splits, with the option just controlling whether we get the remainder or not included in the array. [12:08:58.0745] That also avoids all the regex questions, since the answer remains "act exactly as normal, just include the remainder as a final item" [12:11:03.0745] (sounds like Luca Casonato got stage 1? :D) [12:11:17.0136] yes [12:12:23.0540] > <@surma:matrix.org> (sounds like Luca Casonato got stage 1? :D) indeed! :D [12:12:36.0668] > <@lucacasonato:matrix.org> Could you add that to this issue? https://github.com/lucacasonato/proposal-reversible-string-split/issues/6 Done [12:13:16.0435] > <@tabatkins:matrix.org> But basically, if we use a flag argument in .split(), I don't think we should significantly change the existing semantics/behavior of the proposal. `.split(..., 2)` should still always trigger (up to) 2 splits, with the option just controlling whether we get the remainder or not included in the array. Don't generally disagree with this, I just worry about discoverability here. If people already don't know about the second argument, how will they find a third argument? [12:13:40.0604] If people already don't know about the second argument, how will they find a completely separate method? [12:13:54.0099] > <@tabatkins:matrix.org> If people already don't know about the second argument, how will they find a completely separate method? Editor autocompletions :-) [12:14:13.0618] Editors often offer signature suggestions too ^_^ [12:16:21.0181] > <@tabatkins:matrix.org> That also avoids all the regex questions, since the answer remains "act exactly as normal, just include the remainder as a final item" This brings up the question of what our actual definition of N is - is it number of splits, or number of return values? If we continue expanding regexps capturing groups into the return values array when "remainder" is included, then we must use number of return values (non python behaviour). I'd argue that if we overload, then the overload should not support regexp separators. [12:16:55.0023] * "eternal" seems to mean/imply "recoverable after all references are lost" [12:17:49.0289] Really, I dislike this capturing group expansion into the return value array behaviour. It significantly increases complexity [12:19:01.0675] Ugggggh I didn't realize the N is *literally* "length of the returned array" even when regex capture groups are used, that's *worthless*. [12:19:27.0735] does anyone know who https://github.com/phohensee is, in relation to tc39? [12:22:49.0095] > <@tabatkins:matrix.org> Ugggggh I didn't realize the N is *literally* "length of the returned array" even when regex capture groups are used, that's *worthless*. You understand my frustration now? xD [12:23:32.0844] Yeah the currrent split behavior is just useless [12:23:39.0601] `"".split(sep, n)` === `"".split(sep).slice(0, n)` [12:24:30.0793] for n >= 0, i presume [12:24:33.0986] * for n >= 0, i presume [12:25:12.0135] I think we'd better follow rust, splitN(n, s) seems very clear and won't confused with the old one. [12:25:21.0293] > <@ljharb:matrix.org> for n >= 0, i presume ``` > "a|b|c|d|e".split("|", -1) [ "a", "b", "c", "d", "e" ] ``` [12:30:20.0807] 🎉 we just got consensus at the UTC meeting for my proposal to stabilise the spelling of property names/values/aliases! https://www.unicode.org/L2/L2022/22029-canonical-prop-spelling.pdf [12:31:50.0083] we'll be able to delete tables 67 and 68 now [12:41:17.0502] * table 69 is breathing a sigh of relief right now [12:59:00.0237] the meeting resumes in 60 seconds [13:03:12.0813] Michael Ficarra: did you ask them why they recommended loose matching in the first place? [13:03:39.0384] no, though it sounded like it's just kind of their default position [13:03:50.0575] weird [13:04:52.0957] someone was like "can't we just make it stable but not add it to our stability policy?" and I was like "uuuhhhh that's not gonna work" lol [13:05:27.0486] imo the only reason they would want that is if they planned to break it [13:07:54.0926] why do we allow this form in any position other than the target of a call? do we really want it being passed around? [13:08:13.0957] which form? [13:08:24.0188] class.hasInstance [13:08:39.0587] i assume `class.hasInstance()` would work just like `super()` and `import()`, in that it's not a real function and can't be passed around [13:08:54.0245] exactly, that's what I'm suggesting [13:09:06.0277] oh, is this proposal currently suggesting something different? [13:09:31.0859] that's how I understood the presenter, maybe not? [13:09:54.0365] I didn't look at spec text for this proposal [13:10:04.0086] for stage 2 i'd definitely insist alongside you that that's how it work ¯\\\_(ツ)\_/¯ [13:10:20.0146] oh no your arm [13:10:33.0194] * for stage 2 i'd definitely insist alongside you that that's how it work ¯\\_(ツ)_/¯ [13:10:36.0757] * for stage 2 i'd definitely insist alongside you that that's how it work ¯\\\_(ツ)\_/¯ [13:10:48.0948] lol matrix is even worse than github with the markdown escaping (－‸ლ) [13:12:46.0645] i thought it was a meta property call syntax, yeah [13:12:50.0199] how do you even pass it around [13:13:27.0371] if it were a real function you could `foo(class.hasInstance)` but obv that'd be subpar [13:13:52.0087] well right, but i didn't think it was a real function [13:15:34.0638] someone want to ask the clarifying question? I'm kinda in the middle of my lunch [13:15:44.0121] i am not so convinced by the "you might end up with a partially constructed instance" problem. you have to work pretty hard to still end up with a reference to the instance when a field initializer throws; it's not something you're going to end up passing around natuarlly [13:16:10.0826] i am not understanding what is being proposed for the synthetic brand he wants `class.hasInstance` to make [13:16:13.0422] at the start or at the end? [13:16:27.0153] oh here's the slide [13:17:20.0367] "after the constructor returns" does seem like the right answer to this question to me yeah [13:18:14.0238] oh THAT'S what he meant by function-like [13:19:09.0108] does `import()` work inside eval? [13:19:17.0202] i am guessing yes, so I would say this should also work [13:19:36.0044] "if there is a direct eval you have to do a lot more work" is not a new thing [13:20:28.0553] super does [13:20:39.0543] and super already causes extra allocation for home objects [13:20:44.0773] so eval also causes that [13:20:53.0370] it's no worse than the status quo, which remains "don't use eval" [13:21:08.0312] private fields don't tho, i think [13:21:19.0199] really? [13:21:25.0016] ~hm, let me confirm~ no nvm, they do work [13:21:42.0909] I need to draft an update on class access expressions. Assuming it will ever move forward, I think I need to move it to a meta property like `class.static` or something. [13:22:02.0474] or `class.constructor` maybe. [13:22:07.0501] * ~hm, let me confirm~ no nvm, they do work [13:22:11.0488] * ~~hm, let me confirm~~ no nvm, they do work [13:22:17.0473] * ~hm, let me confirm~ no nvm, they do work [13:22:33.0094] I think we're managing just adequately with the notes, so no need to interrupt the presentation to ask for more, but if someone wants to help out I'd nonetheless appreciate it [13:23:47.0392] rbuckton: for anonymous classes or something? [13:25:17.0679] Its original intent was to handle multiple things: anonymous classes and giving a consistent name to access statics to avoid the `this.#foo` footgun in static methods [13:26:52.0314] it's also nice to avoid repeating the class name - gives you only one thing to change if you want to rename a class declaration [13:26:54.0588] so `hasInstance()` true implies the object was fully constructed without throwing [13:26:58.0722] * it's also nice to avoid repeating the class name - gives you only one thing to change if you want to rename a class declaration [13:27:39.0742] all non-throwing cases can be, yes [13:27:42.0785] then why did we even expose an immutable binding inside the class? I'm unconvinced [13:27:53.0517] ~~~recursion~~~~~~ [13:28:00.0139] what the hell [13:28:13.0654] i typed `~~~~recursion~~~~~~` [13:28:15.0158] yulia: i do agree that `class.hasInstance` is always equivalent to a private field at the end of the class body, that's assigned to `sentinel` at the end of the constructor, and doing `#field in o && o.#field === sentinel` [13:28:28.0925] it's not equivalent to private field at the end, is it? [13:28:29.0024] to replicate this feature with ergonomic brand checks, i think the user would have to assign to the brand field at each return point in the constructor [13:28:49.0415] yeah, it's like that, but that's also why i'm kinda not super convinced [13:28:51.0891] Michael Ficarra good question. i don't find that binding immutability particularly useful, and would have preferred a class access expression [13:28:56.0804] but i'll ask during my queue item [13:29:28.0737] > <@michaelficarra:matrix.org> then why did we even expose an immutable binding inside the class? I'm unconvinced The immutable binding in the class has been a problem for decorators and is constantly surprising to some [13:29:37.0688] ljharb: I think it speaks to the intentions of the delegates who designed the class proposal [13:29:58.0317] > <@robpalme:matrix.org> to replicate this feature with ergonomic brand checks, i think the user would have to assign to the brand field at each return point in the constructor only because someone might get a hold of `this` during the constructor even if the constructor throws, right? if you assume the ctor/initializers don't throw it's equivalent? [13:29:58.0777] https://github.com/tc39/proposal-class-brand-check/issues/6#issuecomment-1015303592 [13:30:03.0891] Michael Ficarra: it might be just copying the function scope [13:30:13.0828] named function expressions also have that constant lambda scope [13:30:14.0866] Michael Ficarra: since some of them are here, it'd be nice to hear their intentions spoken instead of inferring them [13:30:19.0350] but yes, it's the same way functions work [13:30:20.0639] if so, as I said above, i am not so convinced by the "you might end up with a partially constructed instance" problem [13:30:29.0374] shu: they have their own name scope, but it's mutable [13:30:35.0417] which fwiw is also subpar, it's just that self-recursion is much rarer than accessing the constructor's statics [13:30:37.0663] what [13:30:41.0681] the lambda scope is not mutable [13:30:52.0566] uhh I thought it was, let me check [13:31:00.0304] nope [13:31:04.0085] you can assign to it but it's immutable [13:31:08.0563] yeah [13:31:11.0058] it's a unique kind of const among bindings in JS [13:31:14.0522] it's not the same semantics as const but it's immutable [13:31:15.0318] so good [13:31:22.0668] ugh weird [13:31:31.0266] * it's a unique kind of const among bindings in JS [13:31:53.0416] > <@ljharb:matrix.org> which fwiw is also subpar, it's just that self-recursion is much rarer than accessing the constructor's statics doubt [13:32:03.0568] doubt which, the rarity? [13:32:06.0782] > <@bakkot:matrix.org> only because someone might get a hold of `this` during the constructor even if the constructor throws, right? if you assume the ctor/initializers don't throw it's equivalent? yes. maybe the constructor passes `this` to a static function that contains `hasInstance` from the same class [13:32:11.0314] > <@michaelficarra:matrix.org> ugh weird sickos.jpg [13:32:12.0435] yes [13:32:21.0904] bakkot: recursion at all is rare in JS due to a lack of PTC [13:32:29.0836] it's certainly all over the place, but way rarer than it would be otherwise [13:32:30.0757] ...false? [13:32:32.0765] this has not been my experience [13:32:44.0007] perhaps we look at very different kinds of codebases [13:32:50.0188] most useful recursion i argue is in fact not tail recursion [13:33:12.0647] everything is tail recursion [13:33:15.0883] How does Contains work with respect to a class? If you're evaluating Contains on Expr which contains a class expression C, does Contains peek into C's computed property names? [13:33:37.0606] I do recursion all the time. [13:33:47.0884] waldemar: there is a special ComputedPropertyContains which, yes, descends into the computed property names, but not into method bodies or initializers [13:33:53.0465] And if you're doing Contains on C itself, does it peek into its own property names? [13:34:13.0414] That one I'm not sure of offhand [13:34:46.0227] looks like, yes, it peeks into its names but not into method bodies, same as if you called Contains on a parent of C [13:34:49.0948] It seems that both do, which is weird. Things in computed property names are both in the class and not in the class? [13:35:13.0360] This is a problem for things which are class-scoped like the proposal just presented. [13:35:36.0804] We'd need to use a different operation than Contains, yes [13:36:54.0212] Contains normally stops at function boundaries - which you can read to mean "places where `yield` might start meaning a different thing", to be precise - which is why it looks into computed property names but not method bodies [13:37:20.0583] Hax's proposal makes it pierce function boundaries [13:37:40.0626] Methinks Contains is getting too overloaded and confusing [13:37:56.0891] I would suggest introducing a different operation, yes [13:38:28.0286] we've done that before - e.g. we have ContainsArguments for looking for `arguments` in field initializers, which is like Contains but with some details different (it descends into arrows, in particular) [13:38:46.0104] adding a similar new ContainsClassHasInstance is probably the way to go [13:48:34.0883] Currently we use ContainsClassHasInstance to check whether a class scope include any class.hasInstance. Maybe we don't need modify Contains... Speccing such things is too hard for me or TianYang 😂 [13:49:20.0158] Actually we already rewrite the spec text at least three times. [13:52:28.0837] > <@waldemarh:matrix.org> It seems that both do, which is weird. Things in computed property names are both in the class and not in the class? We (three champion) haven't has meeting for that, but we chatted about it yesterday and we tend to make `class.hasInstance` in computed property syntax error. Though as current spec text, (if I really figure out all things) i believe it's allowed but always give u false, because at that time, no one have the class so no instance of it. [13:53:37.0035] > <@waldemarh:matrix.org> Hax's proposal makes it pierce function boundaries Yeah, this part make me headache... [13:54:00.0617] If you figure out exactly what the semantics you want I'm happy to help with writing the spec text before stage 3 [13:54:27.0128] at least in terms of telling what is probably the simplest way to write the thing you want [13:54:54.0565] important part is figuring out the semantics you want [13:59:47.0660] rbuckton: I just realized that I'm going to miss the Enum proposal because I have to go get my kid from school. [14:00:34.0682] waldemar: if it's a syntax error [in computed names] then it doesn't refer to either the inner or outer class, because it's unutterable [14:00:39.0167] which seems like a good approach to me [14:00:46.0081] > <@rwaldron:matrix.org> rbuckton: I just realized that I'm going to miss the Enum proposal because I have to go get my kid from school. Is there anything you need me to cover? [14:00:50.0566] * waldemar: if it's a syntax error [in computed names] then it doesn't refer to either the inner or outer class, because it's unutterable [14:01:44.0663] sorry i lose the connection [14:05:13.0261] ~Do we have a link to the slides?~ nevermind, the agenda was updated [14:05:30.0809] * ~Do we have a link to the slides?~ nevermind, the agenda was updated [14:10:56.0694] > <@bakkot:matrix.org> Mathieu Hofman: can you confirm the conclusion we have captured in the notes is correct Looks right to me. And PR has been updated. [14:11:14.0759] I wonder if we could have a more general construct for 'run this on successful return' . `catch` for errors, `finally` for all exits and something else for `completed without error` [14:11:31.0708] `` [14:11:50.0196] > <@mhofman:matrix.org> Looks right to me. And PR has been updated. (pr will need another update; see comment) [14:12:28.0246] Ashley Claymore: there's been proposals for like a `catch.error` meta-property you could use in `finally` which would tell you what the error is in that case [14:12:36.0454] Ashley Claymore: isn't that just "add a statement at the end of the `try`" tho [14:12:41.0590] which lets you just check in your `finally` if you are in the `completed without error` case [14:12:55.0018] ljharb: end of the `try` isn't necessarily reached if there's a `return` [14:13:01.0411] (to add that now we'd have to solve it both for syntactic and Promise `finally`) [14:13:03.0480] oh true [14:13:28.0709] strong disagree with the claim that any functionality available in syntactic finally must also be available in `Promise.finally` [14:13:33.0108] if that was the claim [14:13:41.0273] > <@ljharb:matrix.org> Ashley Claymore: isn't that just "add a statement at the end of the `try`" tho I set a flag in a catch [14:13:44.0003] it was, because in the past that was one of the stated blockers for three-state promises - iow, that claim has precedent. [14:13:55.0920] * it was, because in the past that was the stated blocker for three-state promises - iow, that claim has precedent. [14:14:02.0195] * it was, because in the past that was one of the stated blockers for three-state promises - iow, that claim has precedent. [14:14:17.0753] eg the whole `catchCancel` thing [14:14:26.0292] ehhhhhhhhhhhhhhhhhhhhh [14:14:40.0884] don't really agree with that on multiple levels [14:14:57.0725] none the less, that parity was a huge part of the design of Promise, and it constrained me on Promise `finally` as well [14:15:36.0543] any motivating use case for `catch.error` would exist in promise finally, so i'm not sure i understand why it'd be ok to do just one [14:15:48.0571] you can achieve the same thing with `.then` and `.catch` if you really want to [14:16:17.0859] you can achieve it with a boolean flag in .catch too. [14:16:25.0446] yeah but it's gross [14:16:34.0954] > so i'm not sure i understand why it'd be ok to do just one you can add a meta-property to solve it in syntax, and you cannot do that to add it in `Promise.finally` [14:16:46.0591] right, it'd have to be an argument to the finally callback somehow [14:16:50.0661] "there is a good way to do this in one case, and not in this other" is a fine reason to provide an affordance in one case and not the other [14:16:59.0566] > <@bakkot:matrix.org> Ashley Claymore: there's been proposals for like a `catch.error` meta-property you could use in `finally` which would tell you what the error is in that case I have on my list of wishes to add an optional error argument to the `finally` block: ``` try { // something that throws } finally (err) { if (err) { // something } else { //something else } } ``` [14:17:23.0642] what if someone throws falsey [14:17:26.0101] Mathieu Hofman: you can throw and reject with `undefined`, so it'd have to be a container [14:17:30.0057] you can implement this with private fields though, so it is a usecase that is possible with it -- is it being used for that? [14:17:32.0074] > We (three champion) haven't has meeting for that, but we chatted about it yesterday and we tend to make `class.hasInstance` in computed property syntax error. Though as current spec text, (if I really figure out all things) i believe it's allowed but always give u false, because at that time, no one have the class so no instance of it. It's not always false. You can define a function inside a computed property name expression, squirrel it away somewhere, and call it later. [14:17:52.0047] * > We (three champion) haven't has meeting for that, but we chatted about it yesterday and we tend to make `class.hasInstance` in computed property syntax error. Though as current spec text, (if I really figure out all things) i believe it's allowed but always give u false, because at that time, no one have the class so no instance of it. It's not always false. You can define a function inside a computed property name expression, squirrel it away somewhere, and call it later. [14:17:53.0628] and allow spread so you can do `finally (...errs) { if (errs.length); }` to handle the `err === undefined` case [14:18:02.0331] * > We (three champion) haven't has meeting for that, but we chatted about it yesterday and we tend to make `class.hasInstance` in computed property syntax error. Though as current spec text, (if I really figure out all things) i believe it's allowed but always give u false, because at that time, no one have the class so no instance of it. > It's not always false. You can define a function inside a computed property name expression, squirrel it away somewhere, and call it later. [14:18:13.0166] * > We (three champion) haven't has meeting for that, but we chatted about it yesterday and we tend to make `class.hasInstance` in computed property syntax error. Though as current spec text, (if I really figure out all things) i believe it's allowed but always give u false, because at that time, no one have the class so no instance of it. It's not always false. You can define a function inside a computed property name expression, squirrel it away somewhere, and call it later. [14:18:20.0964] i suppose that'd work in `.finally` with `arguments.length` [14:18:30.0380] And similar for `Promise.p.finally` [14:18:43.0299] Also there's not a way to only freeze prototype right, though I think there is a proposal for that right? [14:18:44.0533] * And similar for `Promise.p.finally` [14:18:47.0101] anyway maybe it would prove possible to add an argument to the `Promise.finally` callback, which would be fine; but if not I don't think that needs to block the syntax [14:19:10.0887] > <@aclaymore:matrix.org> Also there's not a way to only freeze prototype right, though I think there is a proposal for that right? yeah, though I haven't been working on that one lately [14:19:38.0291] need to revisit and figure out how to work with the rest of the traps, like [[IsExtensible]] [14:20:04.0545] i'd love to see that freeze proto one advance [14:20:28.0646] override mistake be damned? [14:20:56.0805] ? how does it conflict with that? [14:21:32.0619] oh, maybe i misunderstood what the freeze proto proposal does [14:21:47.0452] iiuc it'd make Object.prototype not be exotic, because it'd make "a fully mutable object with a frozen [[Prototype]]" a normally achievable thing [14:21:52.0531] * iiuc it'd make Object.prototype not be exotic [14:22:05.0394] * iiuc it'd make Object.prototype not be exotic, because it'd make "a fully mutable object with a frozen prototype" a normally achievable thing [14:22:08.0608] yeah i completely misunderstood, please ignore [14:22:10.0310] yeah, just freezes the prototype slot itself, not the prototype object [14:22:14.0548] * iiuc it'd make Object.prototype not be exotic, because it'd make "a fully mutable object with a frozen [[Prototype]]" a normally achievable thing [14:22:24.0349] > <@shuyuguo:matrix.org> override mistake be damned? still on board with this though :P [14:22:36.0352] lol [14:22:51.0748] if you can get someone else to own the breakage fallout bugs on v8, sure [14:23:44.0970] really it's more "be damned" in the sense of "damn it" [14:26:15.0159] HE Shi-Jun: posted https://github.com/tc39/proposal-class-brand-check/issues/15 [14:27:08.0277] ljharb: ok, so, syntactic `finally` is already unlike `Promise.prototype.finally`, in that syntactic `finally` can _override_ the return value, and `Promise.prototype.finally` cannot [14:27:13.0839] so how does that not already break the equivalence? [14:28:22.0040] > <@waldemarh:matrix.org> > We (three champion) haven't has meeting for that, but we chatted about it yesterday and we tend to make `class.hasInstance` in computed property syntax error. Though as current spec text, (if I really figure out all things) i believe it's allowed but always give u false, because at that time, no one have the class so no instance of it. > > It's not always false. You can define a function inside a computed property name expression, squirrel it away somewhere, and call it later. You are correct! so maybe we could keep current behavior 😅 [14:30:55.0424] I like syntax error, syntax error is good - there is no reason to want to write this code [14:31:42.0728] bakkot: you're right, that is the one way it's unlike; and given that it's impossible via the callback, we all decided to accept that difference. but that doesn't mean further avoidable deviation is a good idea [14:32:08.0987] sure. depends on how avoidable it is. [14:32:10.0675] I am so incredibly opposed to auto-increment, I cannot find the words to describe it [14:34:09.0082] so for the enum proposal - this is a ton of discussion about semantics, which are more of a stage 1+ concern. is it worth a 💩 to talk about problem space/motivation? [14:34:18.0173] sorry that's a "point of order" initialism; my autocorrect took over [14:34:24.0477] * sorry that's a "point of order" initialism; my autocorrect took over [14:34:29.0074] ljharb: agreed, was thinking the same thing [14:34:46.0724] this is cool and all, but the more important bit is to convince us that there's a problem worth solving here [14:34:52.0091] Lessons from protobuf are that anything other than explicitly id'd values are a big footgun for cross-module apps [14:34:55.0386] auto-increment gives a meaningful value for enums whose base primitive is `number`. [14:35:12.0999] > <@aclaymore:matrix.org> Also there's not a way to only freeze prototype right, though I think there is a proposal for that right? Yeah unfortunately setImmutablePrototype is tied to preventExtensions right now. I wish it was available [14:35:44.0027] https://github.com/tc39/proposal-freeze-prototype [14:36:35.0567] (very stale, as mentioned, just the place to follow along or pick up if you want to make it happen) [14:37:02.0745] If you have `enum Color of String { Red, Green, Blue }`, it can be clear that `Color.Red === "Red"`. If you have `enum Color of Symbol { Red, Green, Blue }`, it can be clear that `typeof Color.Red === "symbol"` and `Color.Red.description === "Color.Red"`. If you have `enum Color of Number { Red, Green, Blue }`, what would you expect `Color.Red` to be? [14:37:12.0052] * If you have `enum Color of String { Red, Green, Blue }`, it can be clear that `Color.Red === "Red"`. If you have `enum Color of Symbol { Red, Green, Blue }`, it can be clear that `typeof Color.Red === "symbol" and `Color.Red.description === "Color.Red"`. If you have`enum Color of Number { Red, Green, Blue }`, what would you expect `Color.Red` to be? [14:37:12.0309] > <@shuyuguo:matrix.org> if you can get someone else to own the breakage fallout bugs on v8, sure I have ideas to tame the override mistake beast, but I need to familiarize myself with previous attempts first [14:37:23.0321] * If you have `enum Color of String { Red, Green, Blue }`, it can be clear that `Color.Red === "Red"`. If you have `enum Color of Symbol { Red, Green, Blue }`, it can be clear that `typeof Color.Red === "symbol" and `Color.Red.description === "Color.Red"`. If you have`enum Color of Number { Red, Green, Blue }`, what would you expect `Color.Red` to be? [14:37:28.0780] good luck [14:37:34.0899] * If you have `enum Color of String { Red, Green, Blue }`, it can be clear that `Color.Red === "Red"`. If you have `enum Color of Symbol { Red, Green, Blue }`, it can be clear that `typeof Color.Red === "symbol"` and `Color.Red.description === "Color.Red"`. If you have`enum Color of Number { Red, Green, Blue }`, what would you expect `Color.Red` to be? [14:38:05.0244] * If you have `enum Color of String { Red, Green, Blue }`, it can be clear that `Color.Red === "Red"`. If you have `enum Color of Symbol { Red, Green, Blue }`, it can be clear that `typeof Color.Red === "symbol"` and `Color.Red.description === "Color.Red"`. If you have `enum Color of Number { Red, Green, Blue }`, what would you expect `Color.Red` to be? [14:39:37.0768] note takers? [14:40:30.0647] it's unfortunate, I think there actually is a pattern in use in the wild that we could improve by providing language support with something like this, but this proposal hasn't been motivated in that way [14:41:02.0199] > <@mhofman:matrix.org> I have ideas to tame the override mistake beast, but I need to familiarize myself with previous attempts first many have come before you; none have succeeded [14:41:17.0419] i am most interested in danielrosenwasser's agenda item [14:41:35.0714] the thing that would convince me is to get rid of a TS wart if TS is willing to do some kind of breaking change, or maybe there's a way to thread the needle, idk [14:42:04.0631] > <@ljharb:matrix.org> bakkot: you're right, that is the one way it's unlike; and given that it's impossible via the callback, we all decided to accept that difference. but that doesn't mean further avoidable deviation is a good idea At least errors thrown or a rejected promise returned in a finally is taken into consideration. I think `return` or `break` being control flow justify the difference [14:42:36.0361] do we accept that creating a set of unique values for a given type is a frequent use-case? I hope the answer is yes - it feels self-evident based on other languages and my personal usage. [14:42:51.0878] sure, but it's not an expressivity gap [14:43:26.0804] shu: but I bet there's some value in normalising how that's done [14:43:43.0793] it's not succinct enough with the current constructs imo - it becomes imperative rather than declarative [14:43:50.0380] right now people just do one of a dozen different approaches, and it makes code more accessible if everyone is using built-in support [14:43:59.0235] i agree on the "coordination" angle for what is currently "a set of strings/symbols/numbers" [14:44:12.0585] that feels very hopeful [14:44:15.0898] i am not that full of hope [14:44:24.0935] but i hope we're all on the same page about that motivation before we debate syntax, is all :-) [14:44:29.0641] Rob Palmer: not just succinct, but it would be nice if, for example, all of the value-back-to-enum-name functions had the same name [14:44:32.0000] but i'm not against it! i just want TS to convince me [14:44:39.0865] TS has the biggest lever here in pushing folks to one way [14:44:55.0917] I'm interested in formalizing a syntax for a common pattern, just as `class` formalized syntax for class behaviors previously built using `function`. This also affords a number of opportunities: - declaration on which to hang decorators for metadata/serialization/etc. - possibility of leveraging constant inlining vs a regular object. - possibility of extending to ADT enums with support for pattern matching/destructuring. - improved API for working with `enum`-like types, such as reverse mapping (value -> key) without the conflicts TS string enums currently have. [14:45:02.0265] Can we just fix TS's utterly-terrible-no-good-very-bad output for enums? [14:45:04.0611] yeah we're going to have to get past that unfortunate typescript cowpath [14:46:18.0148] Mark is now talking about string unions `type foo = "this" | "that"` [14:46:32.0586] people use string literals as enums, don't they [14:47:01.0118] sure but it's nice if they have identity, so Foo.A and Bar.A aren't accidentally interchangeable [14:47:28.0369] You won't necessarily get that for string based enums, but you would for symbol-based ones. [14:47:28.0863] i definitely do not want to solve the ADT use case in the same proposal [14:47:33.0433] that seems like a very very different problem space to me [14:47:33.0837] Yeah, identity (aka enum members are primitives or similar) is pretty important [14:47:38.0267] (i'm still bitter from realizing that scala inherits java's silly confusion of chars and ints) [14:47:42.0199] and agree that ADT should be put to the side [14:47:42.0764] shu: yes exactly, people use literally dozens of different approaches, and it would be nice if there was more consistency there [14:47:45.0271] * (i'm still bitter from realizing that scala inherits java's silly confusion of chars and ints) [14:48:11.0690] ljharb: Scala inherits *so much* of Java's crap, it really kills the language for me [14:48:19.0462] Michael Ficarra: i dislike TC39 being looked to as a lever to move the ecosystem one way [14:48:31.0709] shu: re your queue item, `class` DID actually kill off almost all of the other ways of doing inheritance (including `Object.create`, not that it was very popular before that) [14:48:37.0471] shu: how is it a lever? people are already doing this all over the place [14:48:41.0260] so i think an `enum` syntax would actually achieve that goal. [14:48:43.0354] i should qualify, where there is no expressivity gap [14:49:02.0177] * shu: re your queue item, `class` DID actually kill off almost all of the other ways of doing inheritance (including `Object.create`, not that it was very popular before that) [14:49:40.0120] ljharb: `class` is good historical evidence, yes [14:49:42.0178] thanks [14:50:20.0282] can't typescript just introduce like a `// ts-enum` annotation which means "this is an enum" [14:50:24.0586] without needing new syntax in the language [14:50:32.0507] I am confused by this whole "it helps static analysis" claim [14:50:50.0057] "eslint, for normal JS" is still a pretty important use case [14:51:02.0371] not clear how much this would help eslint? [14:51:28.0706] targeting parseable grammar (that comes with semantics) is far easier than trying to target a nonstandard commenting convention? [14:51:36.0581] * targeting parseable grammar (that comes with semantics) is far easier than trying to target a nonstandard commenting convention [14:51:47.0685] There's already a `/** @enum {T} */` in JSDoc, but it does not mean what most people want it to mean, unfortunately. [14:51:48.0454] * targeting parseable grammar (that comes with semantics) is far easier than trying to target a nonstandard commenting convention? [14:52:15.0750] > <@michaelficarra:matrix.org> shu: how is it a lever? people are already doing this all over the place people aren't doing the same thing all over the place, they're doing the same kind of thing all over the place [14:52:21.0643] ljharb: if TS wrote down a specific syntax for the comment then it would not be any harder to target [14:52:35.0767] sure but then it'd still be TS-specific, and that's not relevant to non-TS users. [14:52:40.0254] oh sorry I got offlined [14:52:45.0535] let me rejoin [14:53:35.0577] ljharb: I was responding specifically to the "it helps TS analysis" motivation [14:53:41.0153] if there is some other motivation, sure [14:53:43.0955] ah ok, gotcha [14:53:54.0240] I'm interested in whether ADT enums could help avoid megamorphic ICs in V8, where the "kind" of enum value could be inlined into the IC, so that switching/matching on the enum kind wouldn't be polymorphic. [14:54:53.0489] hmm can anyone hear me? [14:55:02.0952] looks like still not got online 🤔 [14:55:17.0094] The TS compiler has a lot of `switch (node.kind) { ... }` cases that are megamorphic. Being able to do something like `match (node) { when (Node.Identifier) -> ... }` and avoid megamorphism would (hopefully) be a perf win. [14:55:58.0226] exhaustiveness checks will be a godsend, too [14:56:05.0796] Jack Works: Are you able to hear and just can't speak? [14:57:08.0488] rbuckton: not sure why a tagged disjoint union "kind", even if built-in, would make a callsite any less megamorphic [14:57:46.0125] presumably each disjunct of the sum type still has a different layout [14:57:55.0436] if the callsite deals with those different layouts, it's as polymorphic as before [14:59:26.0679] Can anyone give a demonstration of ADT without using pattern matching? [14:59:38.0870] Justin Ridgewell: every AST [15:00:06.0932] the usefulness for ASTs means people who work with programming languages tend to think about them a lot [15:00:10.0321] what's the point of adt without pattern matching [15:00:11.0905] * the usefulness for ASTs means people who work with programming languages tend to think about them a lot [15:00:30.0697] (i say, as one of the pattern-matching champions) [15:00:53.0792] my hot take is i think PL and compiler people definitely overindex on pattern matching and ADTs [15:01:03.0217] like ML is a great language for writing ML compilers [15:01:17.0610] A code example. I don't understand how I get fields out of a `Square(int int)` [15:01:22.0446] Yes, but I'm curious if it would be possible to inline a consistent shared field such as a "kind" that *all* ADT enum values would be expected to have, so that the `switch` isn't megamorphic when branching on that "kind". Each branch could then be monomorphic. [15:01:34.0507] The only thing that demonstrates is pattern matching, and I hate pattern matching. [15:02:10.0663] hate? wow [15:02:13.0827] Justin Ridgewell: normally you name the fields I think [15:02:21.0264] Justin Ridgewell: You mean like, `square[0]`? [15:02:31.0696] Is it an object? [15:02:59.0755] An ADT enum would likely be a record or tuple value, if not a regular object. That's still TBD. [15:03:05.0904] Flow Enums: https://flow.org/en/docs/enums/ Comparison with TS and Flow Enums: https://medium.com/flow-type/typescript-enums-vs-flow-enums-83da2ca4a9b4 [15:03:19.0624] gkz: your mic is still hot I think [15:03:24.0324] oh fixed nvm [15:03:32.0471] there's a common pattern in Haskell libraries, considered a good practice, to actually not expose your ADT constructors so that consumers *can't* pattern match on them [15:03:56.0736] the idea is you're supposed to do every kind of pattern matching that makes sense as functions and expose those [15:04:01.0501] also allows for "smart constructors" [15:04:39.0709] lol I just did exactly the same thing as PH: https://github.com/Z3Prover/z3/blob/c6539deb6169afde2b569fba89a828f2f726691f/src/api/js/scripts/parse-api.js#L141-L204 [15:04:42.0403] converts C enums to TS [15:06:50.0445] Justin Ridgewell: i don't think you can get fields out of an ADT without pattern matching. the point of ADTs is that you have N type constructors to create the data, and on the other side you have "eliminators" to unwrap the type constructors and get the field out. usually, the eliminator is pattern matching [15:07:20.0630] on the flipside, you have classes, which sometimes get described as co-data, where eliminators (methods) are how you define the class to begin with [15:07:51.0557] * Justin Ridgewell: i don't think you can get fields out of an ADT without pattern matching. the point of ADTs is that you have N type constructors to create the data, and on the other side you have "eliminators" to unwrap the type constructors and get the field out. usually, the eliminator is pattern matching [15:09:40.0460] but that part of my life is behind me now, never to be thought of again [15:09:56.0790] have a hard time imagining going from that to C++ [15:10:04.0943] waldemar: I would describe the problem as "there is a common need today to create related but distinguishable values, and there's many different ways to do it. language support would unify these strategies, make code more approachable, provide useful info to tooling to do things like exhaustiveness checks, etc" [15:10:43.0774] Justin Ridgewell: you should check out recursion schemes [15:10:44.0279] that doesn't cover sum types, though [15:11:06.0720] but the intention was not to cover sum types in this proposal, right? [15:11:08.0609] * but the intention was not to cover sum types in this proposal, right? [15:11:14.0733] ptomato: not clear to me [15:11:24.0261] definitely sounded like sum types were in scope? [15:11:42.0883] sum types are the interesting part of this proposal, that we can't currently do in the language [15:11:44.0750] the last slide said "simple enums", with other stuff being later [15:12:06.0539] but they do have a fairly large impedance mismatch given how dynamically typed ecmascript is [15:12:28.0906] Michael Ficarra: As well as additional affordances that novel syntax would present, such as the possibilities for constant inlining, decorators, serialization, and consistent patterns for construction (and deconstruction) of these values. [15:13:05.0932] I'm frustrated that this couldn't reach stage 1. I think it met the criteria, but just wasn't presented in a way that made that clear, no offense to the champion group. [15:13:30.0445] rbuckton: true [15:14:04.0641] I think what's missing here is some clear examples of the current way of doing what enums do are problematic. [15:14:23.0363] I'd view the problem more as providing a lightweight statically analyzable way of defining constants in general. But all of the options are biased to do other things by using the `enum` keyword. [15:14:25.0003] s/examples of/examples of how/ [15:15:00.0618] For example: ``` const Color = { Red: 0, Green: 1, Blue: 2 }; const data = { color: Color.Red }; fs.writeFileSync("foo.json", JSON.stringify(data)); ``` Writes `{color:0}`, which isn't helpful when maintaining config files, while: ``` const Color = { Red: Symbol(), Green: Symbol(), Blue: Symbol() }; ... ``` Would be safer at runtime, but would fail to stringify. [15:15:09.0455] "JavaScript doesn't have enums" isn't a problem all on its own. [15:16:34.0766] rbuckton: that's a start. I'd love to see a presentation with at least a half dozen such examples and explanation of what the desired behavior is. [15:17:18.0359] and why it's hard with current language constructs to get that behavior [15:17:58.0383] > <@rbuckton:matrix.org> For example: > ``` > const Color = { Red: 0, Green: 1, Blue: 2 }; > const data = { color: Color.Red }; > fs.writeFileSync("foo.json", JSON.stringify(data)); > ``` > Writes `{color:0}`, which isn't helpful when maintaining config files, while: > ``` > const Color = { Red: Symbol(), Green: Symbol(), Blue: Symbol() }; > ... > ``` > Would be safer at runtime, but would fail to stringify. How is this not solved by `const Color = { Red: 'red' , ..}` [15:23:21.0972] 😂 I didn't do a good preparation cause I didn't figured out how to express those ideas in my brain. with suggestions and feedbacks from the chat I think it can be better next time. and as I said in the presentation, I'm not push the proposal forward until it has a complete design and proven to has benefit to add it. I agree that frozen object (or TypeScript/flow.js enum) is enough today (mostly?) so my main focus point is on the ADT enum. [15:31:24.0042] Jack Works: I'm really pleased you gave this presentation. It seems like there were plenty of people interested in this space. So hopefully they can help you to work more on the use-cases and problem definition. (And I am biased because I love enums) [15:33:15.0407] Thanks 🙏 [15:35:49.0303] Jack Works: I would happy to be involved with this proposal if it's something that's going to be moving forward. We had a lot of discussion with both library authors and end users, and examined many use-cases, in preparation for the design of Flow Enums, and then listened and iterated based off of feedback. But again for us a large amount of the value derived is from when enums are used with the type system. We have also begun research on an ADT extension to Flow Enums, and have analyzed use-cases and so on. [15:39:19.0889] > <@sarahghp:matrix.org> How is this not solved by `const Color = { Red: 'red' , ..}` When I initially started talking about an enum proposal several years ago, a number of current committee members were strongly in favor of symbol-valued enum members for better runtime safety. Yes, you could do `{ Red: 'red', ... }`, but you lose out on that safety. [15:43:01.0555] Authenticity of enum values (provided by Symbols) is something folk won't reach for unless it has sweet syntax. And I'd argue it's what you normally want for robustness reasons - no typos. [15:44:23.0040] enums-as-constants is a different problem than ADT enums [15:44:42.0182] until they're separated or more clearly articulated to need to be solved together i'm uncomfortable with the proposal [15:44:42.0983] symbols also can't be serialized, so I don't think that helps the "would fail to stringify" case? [15:45:09.0147] even thuogh Jack Works says ADTs are deferred as a follow on it keeps coming up in the discussion so i'm not sure who's interested in solving what [15:48:09.0067] I know rbuckton is interested [15:50:16.0229] Ah I should go sleep first, I'm not clear headed now [15:59:45.0087] shu: Every time I've brought up enums in discussion with other members of plenary or folks in the TS/JS community, ADTs are invariably mentioned as a feature someone would like to see adopted. The use cases frequently overlap, and a number of languages support enums that can be used both for ADT and non-ADT scenarios. 2022-01-26 [16:00:54.0073] enums-as-constants isn't orthogonal to ADT enums. [16:02:19.0976] https://matrix.to/#/!vofPwuBJgbSdyEilYo:matrix.org?via=matrix.org Welcome to join the chat if you have interest in working on this together. ⭐ This is NOT a tc39 group cause it didn't reach stage 1, it's a public group but not following the ECMA policy (logged and published). I'll create an official group like pattern matching and pipeline after it reaches stage 1. [16:04:41.0893] we can probably make it an official group if the chairs choose so [16:05:07.0117] * we can probably make it an official group if the chairs decide that [16:07:51.0168] rbuckton: I agree, but I also think it wouldn't do any harm to pursue it in two phases [16:08:36.0367] > <@michaelficarra:matrix.org> rbuckton: I agree, but I also think it wouldn't do any harm to pursue it in two phases Even if we pursue it in two phases, we need to consider how ADT enums need to function to ensure we don't paint ourselves into a corner with non-ADT enums. [16:08:58.0605] I think we have the ability to do that though [16:09:04.0781] Rob Palmer, yulia my coworker Jenna couldn't access the Reflector today to get the meeting info. Can you confirm her github user is ok? https://github.com/tc39/Admin-and-Business/issues/174 [16:10:08.0157] leobalter: i just invited them; invites expire in 7 days so perhaps they didn't accept in time the first go [16:10:16.0383] Which means we need to do most, if not all, of the work we would need to do for ADT enums to ensure we have consistency across multiple other language features such as pattern matching. [16:10:41.0192] Thanks, ljharb! [16:14:59.0610] rbuckton: i'd like a tighter story than that, because the implementation complexity and the design space of the primitive enums vs ADTs are miles apart [16:29:24.0062] > <@jridgewell:matrix.org> I do recursion all the time. To give a concrete example of this for Jordan, I invariably use recursion when I write parsers. Recursive descent parsers are my favorite type. [16:29:41.0483] With or without PTC… [16:36:29.0949] I'm primarily interested in ADT enums for how they could possibly be optimized by engines in ways that regular objects can't (hence my comments about megamorphism earlier). Switching on `node.kind` in the TS compiler is often a performance cliff due to megamorphism, even if every object/shape seen by a function has a `.kind`. If V8 were able to optimize this case for regular objects, I'd be ecstatic. If not, and V8 instead was able to optimize for ADT enums in a similar fashion, I would happily rewrite the entire TypeScript compiler to use an ADT for `Node` instead of regular objects/constructors even if that meant a complete breaking API change for consumers. If there are no performance optimizations that V8 could offer for either case, then ADT enums are at least interesting to me as a data structure but not a necessity. [16:39:07.0313] There's a convenience factor for ADT enums coupled with something like Scala's "Extractor Objects" and pattern matching that is extremely interesting to me, but that's nowhere near as compelling to me as possible performance benefits. [16:40:45.0527] rbuckton: a dirty hack proposal... if the `.kind` property is special and you want to avoid the megamorphic de-opt, couldn't you rename it to be index zero? `node[0]` [16:43:25.0040] Does that work? I'd happily turn `kind` into a getter that just reads `this[0]` (for API compatibility) and replace all `node.kind` references in the compiler if that would actually improve performance. [16:44:55.0120] I'm not 100% sure but seem to recall the V8 object layout for elements permits direct lookups not based on the map type. If only we had someone who knew V8 here... [16:48:54.0546] by my reading keyed loads like [0] also checks receiver maps [16:51:03.0717] I wonder how off the “# of kinds of nodes in ts” is from the upper limit in v8 for optimization [16:51:33.0466] alternatively just rewrite it in go [16:51:58.0416] (this is a reference to https://kdy1.dev/posts/2022/1/tsc-go, not a serious proposal) [16:52:28.0116] i think if you want speed what you want is C [16:52:44.0714] you never want c under any circumstances whatsoever [16:53:03.0340] except writing aviation code with the very constrained dialect they use plus all of their static analysis tools I suppose [16:53:18.0644] and even then it's less "want" than "have no legal alternative" [16:54:18.0600] it is when we are constrained by the law that we are at our most creative [16:54:35.0032] doubt [17:23:25.0342] rbuckton: shu this microbenchmark suggests megamorphic access to index properties is 3x faster than the same for string properties https://esbench.com/bench/61f099d96c89f600a570158a [17:28:15.0875] oh wow - Axel Rauschmeyer has taken Dean Tribble's Proxy trick and blogged about it within 90mins of learning it... https://2ality.com/2022/01/symbol-factory.html [17:28:20.0947] We tried to improve perf by ensuring that frequently-used fields like `kind`, `pos`, `end`, and `flags` are all stored in-object: ``` 000003E4E0E47A91: [Map] - type: JS_OBJECT_TYPE - instance size: 160 - inobject properties: 17 - elements kind: HOLEY_ELEMENTS - unused property fields: 7 - enum length: invalid - stable_map - back pointer: 0x03e4e0e47a49 - prototype_validity cell: 0x034eb1241659 - instance descriptors (own) #11: 0x012f0b6cfb21 - prototype: 0x012f0b6cf441 - constructor: 0x013a75523b41 - dependent code: 0x020140ac1281 - construction counter: 6 [0]: 00000378FA033E49: [String] in OldSpace: #pos (const data field 0:s, p: 7, attrs: [WEC]) @ Any [1]: 0000009B539BD2B9: [String] in OldSpace: #end (const data field 1:s, p: 1, attrs: [WEC]) @ Any [2]: 0000028DD0EF42B9: [String] in OldSpace: #kind (const data field 2:s, p: 3, attrs: [WEC]) @ Any [3]: 0000007EABDD4071: [String] in OldSpace: #id (const data field 3:s, p: 9, attrs: [WEC]) @ Any [4]: 0000020140AC45D1: [String] in ReadOnlySpace: #flags (const data field 4:s, p: 8, attrs: [WEC]) @ Any [5]: 0000036E885DE309: [String] in OldSpace: #modifierFlagsCache (const data field 5:s, p: 10, attrs: [WEC]) @ Any [6]: 000001B37FD2DA09: [String] in OldSpace: #transformFlags (const data field 6:s, p: 0, attrs: [WEC]) @ Any [7]: 0000007EABDC4B09: [String] in OldSpace: #parent (const data field 7:h, p: 6, attrs: [WEC]) @ Any [8]: 00000378FA0349F1: [String] in OldSpace: #original (const data field 8:h, p: 5, attrs: [WEC]) @ Any [9]: 000001B37FD2D511: [String] in OldSpace: #decorators (const data field 9:h, p: 4, attrs: [WEC]) @ Any [10]: 000001B37FD24099: [String] in OldSpace: #modifiers (const data field 10:h, p: 2, attrs: [WEC]) @ Any ``` [17:36:01.0747] that should save you a load, yeah [17:58:38.0099] there's a spam comment on an ecma262 PR, what should I do? [17:58:49.0574] You should take a look at closure compilers AST layout [17:59:18.0172] Everything is firstchild lastchild nextchild [17:59:41.0215] Can’t have megamorphic access if everything has the exact same properties [18:18:48.0899] jschoi: I double checked `Array.fromAsync`, and since the content of the `[[Iterator]]` slot is never revealed to user code, the async iterator wrapper prototype is still spec internal only. It sure would be nice to have a way to explicitly note this, so that these internal only things don't get surprisingly exposed without anyone noticing in the future! [18:46:42.0441] Mathieu Hofman: do you mean like the note at https://tc39.es/ecma262/#sec-createlistiteratorRecord ? [19:08:28.0895] I suppose, but these things can be lost transitively. First, the `CreateAsyncFromSyncIterator` doesn't have this annotation. Second, really it seems that `GetIterator` creates a record for an iterator (possibly coming from user code, possibly internally built through `CreateAsyncFromSyncIterator`), but while that record transits through a lot of place, the iterator it contains is seemingly never exposed to user code. It's a weird invariant that is not well understood [19:08:42.0191] * I suppose, but these things can be lost transitively. First, the `CreateAsyncFromSyncIterator` doesn't have this annotation. Second, really it seems that `GetIterator` creates a record for an iterator (possibly coming from user code, possibly internally built through `CreateAsyncFromSyncIterator`), but while that record transits through a lot of place, the iterator it contains is seemingly never exposed to user code. It's a weird invariant that is not well understood [22:06:48.0377] > <@jridgewell:matrix.org> Can’t have megamorphic access if everything has the exact same properties I though location of the initial object creation matters too; for some engines where the hidden-class graph is a forest and not a tree [06:18:11.0121] > <@jridgewell:matrix.org> Can anyone give a demonstration of ADT without using pattern matching? that's depends on the semantics of ADT enum but it doesn't have a runtime semantics specified yet so I cannot give an example sorry [08:57:49.0129] jschoi: fair, but i hope you're not suggesting that writing a parser is anywhere remotely near a common use case [09:02:27.0098] ljharb: parsers are everywhere [09:02:49.0643] people are writing parsers all the time, whether they know it or not [09:03:04.0535] most are simple and can be expressed as a regexp or a series of regexps [09:03:12.0136] that sounds like either a really bold claim, or one so broad as to dissolve the context [09:03:30.0772] "writing a parser where recursion makes sense" is not a common use case. [09:03:36.0144] parsing is turning something less-structured into something more-structured [09:03:46.0898] * "writing a parser where recursion makes sense" is not a common use case. [09:04:17.0599] Yeah. It doesn’t even have to be on text input but any sequence of values. [09:04:17.0740] so parsing is anything that fights the entropy of the universe, gotcha [09:04:32.0665] * Yeah. It doesn’t even have to be on text input but any sequence of values. [09:04:38.0679] when i grow hair, i'm parsing? [09:05:06.0376] in the context we're discussing things, "writing a parser" such that you'd reach for recursion is simply not a common use case [09:05:18.0299] JSON validation is parsing, for example. [09:05:28.0503] i don't need recursion for that tho. [09:06:10.0449] Hm, is recursion not required to validate many JSON structures? After all, many JSON schemata are recursive. [09:06:42.0961] i'm sure a JSONSchema validator may be recursive, sure. but most people don't write those, they just consume them [09:07:13.0604] i'm not trying to claim that parsers don't affect a lot of devs. i'm saying that most devs don't author them. [09:07:52.0057] in the same way as "get intrinsics" affects a lot of devs, but most devs don't need to do that directly. and both are relevant when weighing the importance of including syntactic affordances in the language (which is why i'm not trying to pursue syntax for getting intrinsics - because it's *not common*) [09:08:08.0686] * in the same way as "get intrinsics" affects a lot of devs, but most devs don't need to do that directly. and both are relevant when weighing the importance of including syntactic affordances in the language (which is why i'm not trying to pursue syntax for getting intrinsics - because it's *not common*) [09:08:30.0273] Yeah, it may be that because I’m familiar with them, I reach for them more readily than most developers. [09:08:39.0839] But I do know I write a lot of ad-hoc parsers to validate stuff. [09:08:53.0822] Just the other day, I had to write an ad-hoc parser for some custom-formatted text file’s lines…and, before that, the Unicode Character Database’s source text files (though recursion wasn’t necessary for the latter). [09:08:59.0370] As I can recall from some of my friends, "it's very hard to find some candidates that understand what is recursion" [09:09:15.0032] * Just the other day, I had to write an ad-hoc parser for some custom-formatted text file’s lines…and, before that, the Unicode Character Database’s source text files. [09:09:39.0137] * Just the other day, I had to write an ad-hoc parser for some custom-formatted text file’s lines…and, before that, the Unicode Character Database’s source text files (though recursion wasn’t necessary for the latter). [09:10:25.0511] * But I do know I write a lot of ad-hoc parsers to validate stuff—both textual and non-textual. [09:10:47.0343] * Just the other day, I had to write an ad-hoc parser for some custom-formatted text file’s lines, as well as some JSON input from a hospital’s record system…and, before that, the Unicode Character Database’s source text files (though recursion wasn’t necessary for the latter). [09:10:57.0524] * Just the other day, I had to write an ad-hoc parser for some custom-formatted text file’s lines, as well as some JSON input from a hospital’s record system…and, before that, the Unicode Character Database’s source text files (though recursion wasn’t necessary for the last one). [09:12:02.0879] * Just the other day, I had to write an ad-hoc parser for some custom-formatted text file’s lines, as well as some JSON input from a hospital’s record system…and, before that, the Unicode Character Database’s source text files (though recursion wasn’t necessary for the last one). Regexes are super common, but I often need more power than regular expressions…and I often need to apply them to non-textual input. [09:12:21.0722] * Just the other day, I had to write an ad-hoc parser for some custom-formatted text file’s lines, as well as some JSON data from a hospital’s record system containing entities within entities…and, before that, the Unicode Character Database’s source text files (though recursion wasn’t necessary for the last one). Regexes are super common, but I often need more power than regular expressions…and I often need to apply them to non-textual input. [09:12:41.0006] i have the opposite experience - i have interviewed _thousands_ of candidates over the years who are incapable of NOT using recursion, since they were indoctrinated with it in university. our hiring panels always reject those, because recursion is often the wrong tool for the job, at least in frontend. [09:13:21.0295] at any rate, i'm not trying to debate the value of use cases/parsers or techniques/recursion, just that i strongly believe it's an uncommon combination. [09:15:42.0099] Yeah. I agree (I think get intrinsics are useful for a very limited set of people including me, but doubt if it worth an API) [09:16:29.0429] to be clear, i think getting intrinsics is worth an API (hence the proposal), but decidedly not worth syntax. [09:16:37.0380] * to be clear, i think getting intrinsics is worth an API (hence the proposal), but decidedly not worth syntax. [09:17:24.0010] the context from before was about functions having an immutable binding for their own name but lacking a `function.self` metakeyword, or similar - as compared to `class.self` or similar, where i think the use case is much more common. [09:17:51.0917] (i'd be _fine_ with `function.self` and `class.self` both, ofc, but i think the former would be much more rarely used) [09:19:29.0913] Hmm. Inside a named function, is the name mutable? [09:30:18.0950] Jack Works: If you scroll up, we discussed that. Apparently it is immutable but does not error if you try to assign to it. The assignment just does nothing. [09:31:09.0835] even in strict mode? (edit: checked, and yes, even in strict mode; that is super weird) [09:33:31.0457] * even in strict mode? (edit: checked, and yes, even in strict mode; that is super weird) [09:34:24.0581] it is an ur-const [09:36:05.0730] all these years, I just thought it was mutable [09:43:19.0520] "ur-const"? [09:43:33.0212] this behavior predates `const` [09:43:49.0810] it used to be the only immutable binding, so it wasn't inconsistent that it didn't throw [09:44:00.0142] Rob Palmer: https://www.oxfordlearnersdictionaries.com/us/definition/english/ur [09:44:14.0176] i would have named it "pre-const" [09:45:04.0786] pre-const somehow sounds like something which _isn't_ const but predates const for some reason [09:54:55.0061] i'm surprised that when adding strict mode, it was missed [09:57:45.0232] erights: was that omission intentional? [09:59:02.0939] We start plenary in 1 minute! [10:09:08.0395] jitsi always messes with my audio for some reason [10:09:26.0574] yesterday it wouldn't detect my headphones until i open preferences, but it goes away after i close preferences [10:09:35.0282] today, everytime i join, it moves the balance all the way to the left [10:09:35.0807] wtf [10:12:03.0871] if it's the system audio balance, that's a Mac OS bug that triggers when the CPU is pegged sometimes [10:12:15.0475] it's crazy and it has been known about for like a year now [10:12:25.0225] that is wild, how does that bug arise [10:14:37.0074] mac os audio subsystem is extremely buggy. Afaik, chrome had to move to a restart-able audio process to deal with macos issues. Zoom used to just ask for admin rights to be able to kill the system audio when issues were detected. [10:16:48.0679] this is very cool [10:16:56.0467] no kidding [10:20:05.0056] the idea one can generate test for test262 (ish) but also customize outputs [10:22:54.0664] ok, stuff like this would be _amazing_ to record [10:23:55.0432] * ok, stuff like this would be _amazing_ to record [10:25:15.0757] i am reminded of Futamura projections [10:25:31.0410] wow [10:25:33.0799] which_one_meme.jpg [10:28:52.0303] wut [10:31:20.0832] WHAT [10:31:23.0445] this is dope [10:32:18.0250] very [10:32:40.0994] this is why I wanted them to share it with committee 🙂 [10:32:48.0712] I think a lot of you will find this useful [10:32:53.0087] is the ECMA-402 spec too loose to try this? Let's get this working on 402 too! [10:33:28.0683] they will probably have to do a decent amount more work to make it work with ECMA-402 [10:33:42.0890] understandable ☹️ [10:33:49.0812] but we could help! [10:33:58.0447] remember, their contribution involved encoding the semantics of the phrasing we use in 262 [10:34:08.0348] reducing the variety of that phrasing will simplify things [10:34:18.0194] ecma-402 unfortunately has a greater variety [10:34:20.0623] yeah, that's what I was afraid of [10:34:39.0322] absolutely. That plus the fact that large parts of it are impl-defined (relatively anyway) I suppose... [10:34:50.0438] ryzokuken: it's all open source, so you actually can make it work [10:34:52.0044] * absolutely. That plus the fact that large parts of it are impl-defined (relatively anyway) I suppose... [10:35:02.0399] seems simple enough to add support for new phrases [10:35:25.0339] cool, I'll try to get it to work 😀 [10:35:26.0486] but I'd prefer just reducing the variety of your phrasing in 402 anyway [10:35:50.0388] that's not a bad idea either, did you have an issue or sth to track this in 262? [10:36:28.0653] nah, we've just been doing them one by one as we notice them [10:37:51.0550] fair, I'll kickstart something on #tc39-ecma402:matrix.org [10:39:22.0995] shared array buffers are going to be hard to formalize by anything similar to the way the rest of the language is formalized [10:39:33.0335] omgm [10:39:35.0405] though conrad watt has a formalization somewhere I think [10:39:50.0086] depends on what the goal of mechanizing the memory model would be [10:39:52.0546] loving this [10:40:02.0228] it's possible to "support" the memory model by just treating them as non-shared [10:40:12.0732] like, an SC execution is never wrong [10:40:14.0650] shu: i mean mostly that the memory model is not written in the same kind of way as the rest of the spec [10:40:31.0855] right, mechanizing that into something operational is original research [10:40:34.0904] and is unsolved last i checked [10:40:54.0072] but i'm saying they could just ignore it [10:41:28.0503] PEGs use ordered choice [10:41:40.0336] so it probably just adopts the order we wrote it in [10:43:41.0328] shu: I'm about to enter a 3 hour block of meetings, which ends with me leaving to pick up my daughter at school (I'm EST). Since there are no slides, or other information attached to "Let's talk about test262 maintenance and contribution", I'm not sure what else you want to discuss beyond the creation of the maintainers group. I'm concerned that I'm now going to miss this topic due to obligations on my end. What can we do about that? Can we defer it to tomorrow? [10:44:23.0690] i would prefer no deferral if there are no other agenda items for Thursday [10:45:02.0407] ptomato: if you integrated your proposal, as you would in a PR, I don't see why it wouldn't work [10:45:03.0068] i want to discuss the role of the maintainer group, the workflow, expectations from proposal authors, and stage requirements [10:46:11.0486] Rick Waldron: is there someone else you trust to present your viewpoint? are there also specific topics you want to raise? [10:46:29.0599] we could bring forward JS Choi's item next, and then do test262 last today - does that help Rick? [10:47:02.0645] yeah, a schedule reshuffle if possible would be ideal, i guess [10:47:26.0747] Rob Palmer: I think the end of the day for the meeting is when I'm feeding my daughter dinner [10:48:07.0364] end of the meeting is 14:00-15:00 PST after your 3 hours of meetings [10:48:38.0048] My meetings end at 5, and then I have to leave to pick my child up from school. [10:50:14.0020] ok so that won't work then [10:51:47.0633] I'm trying to figure out how long the 4pm thing will be [10:57:03.0170] Ben Newman (Apollo, @benjamn on GH): that was one of the questions the editors asked in our first call with them [10:57:20.0284] cool, I guess it's a natural one! [10:57:32.0505] editors are planning on fixing up regex chapter at some point [10:57:34.0921] we'll try to make more progress on it following initial integration after we finish up this completion record reform work [10:57:38.0483] it's already gotten a lot better thanks to jmdyck [10:59:45.0669] learning that the regex chapter used to be lisp definitely explains some things [11:00:55.0163] yep, the "ordered pairs" probably came from there [11:01:09.0764] why port it so literally? lol [11:01:38.0788] I guess we didn't have the same ambitions of running analysers on the spec back then [11:03:00.0624] Rob Palmer: shu My 4pm meeting was canceled. So 1pm PST? [11:03:13.0441] sure, i'm flexible for whatever time that works for rick [11:03:19.0191] (though still prefer today, not tomorrow) [11:03:30.0348] ok [11:03:41.0039] let's see if JS Choi can go next [11:04:26.0660] jschoi: can you go next after this? [11:06:27.0118] WH is right, the papers are actually pretty easy to follow [11:06:43.0411] and they're very nicely split up [11:07:00.0056] I do think we should have a central place for this though [11:07:13.0938] there's a lot of research, not all of it in academia, and it would be good to have it more discoverable [11:07:44.0835] e.g. jmdyck's ecmaspeak and WH's link from earlier are both relevant and do not have papers [11:11:37.0604] I support saving the final 10 minutes for after lunch [11:12:25.0147] there's some kind of sync issue [11:12:54.0938] https://jschoi.org/21/es-dataflow/ [11:13:05.0707] dang this page is pretty [11:13:32.0068] https://jschoi.org/21/es-dataflow/map/ [11:14:35.0968] is there like an extreme audio delay or something? [11:15:00.0578] there seems to be, yes [11:15:28.0080] it's certainly robot-ing here and there [11:15:34.0138] Now I can hear JS-Choi better [11:15:55.0513] i think js choi's connection is having issues. [11:16:10.0552] yes [11:16:58.0778] It would be great if we could read the presentations ahead of the meeting. I'd have appreciated some time to study the map of ES dataflow proposals ahead of time instead of in real-time at the meeting. [11:16:58.0866] but it seems to be workable now - i suspect it is js choi's upload quality/bandwith [11:17:58.0732] waldemar: the material was published ahead of time https://github.com/tc39/agendas/pull/1106 [11:18:01.0192] They stopped presenting, so the audio got better. [11:18:48.0424] Yeah, the whole point of assembling the agendas is precisely to allow you to review things ahead of time if you wish, and this in particular was put on the agenda about two weeks ago. [11:22:02.0236] The title was on the agenda, but there were no links to anything on the agenda. [11:22:35.0385] waldemar: that PR contains three links [11:22:39.0554] Yes there was - the PR shows that all the linkes were there. [11:23:34.0555] Sorry; my bad. [11:23:49.0937] I was looking at the wrong item. [11:26:54.0321] > <@bakkot:matrix.org> you can assign to it but it's immutable > the lambda scope is not mutable I'm not following, do you have an example? [11:27:22.0221] (sorry catching up on some previous discussions) [11:32:45.0410] Mathieu Hofman: `(function f(){ f = 0; console.log(f); })();` [11:33:01.0146] the assignment doesn't throw, but also doesn't change `f` [11:33:20.0954] * the assignment doesn't throw, but also doesn't change `f` [11:36:04.0161] It does in strict mode, doesn't it? `(function(){"use strict"; let foo = (function f() { f = 'foo'; }); foo(); return foo;})()` `Uncaught TypeError: Assignment to constant variable.` [11:36:24.0955] yeah [11:37:28.0703] it's like assignment to a readonly property in sloppy, it silently ignore it. But strict mode fixes it. [11:37:46.0185] oh hmm. i'm not sure why my earlier strict mode tests didn't throw then [11:38:32.0311] > <@ljharb:matrix.org> even in strict mode? (edit: checked, and yes, even in strict mode; that is super weird) I was confused by ^ [11:38:46.0153] my mistake then, sorry about that [11:39:13.0413] Was trying to double check things before raising this with MM ;) [11:42:17.0779] i thought it also didn't throw in strict mode [11:42:24.0392] because it's always created with _S_ = false [11:43:33.0593] been a while though [11:45:34.0716] `S = true` means that assignments to it will throw even in sloppy mode [11:45:55.0816] ah ha, got it backwards [11:48:43.0537] let's get to the queue imo [11:51:25.0743] Do we not have free overflow time later today? [11:52:06.0604] the hackmd says 15 minutes [11:52:23.0644] is 10 of that already filled up by this? [11:52:28.0963] yes [11:57:24.0253] did i hear voting [11:57:57.0206] can we have the "what voting system" fight again [11:58:09.0818] my position is, we should list every subset of these proposals and then do approval voting for the subsets [12:00:52.0480] damn it, i was getting so pumped for this [12:01:13.0373] gotta stay pumped for 1h [12:01:17.0976] come in kicking [12:01:46.0939] Thank you for splitting the topic (if needed, please continue without me) [12:01:57.0666] Have to give an interview... [12:03:02.0283] We shall return at 13:00 PST for a 10 minute continuation of the current topic on JS Choi's dataflow discussion. Please do not be late! [13:01:52.0015] it occurs to me throughout this agenda item, that it might be helpful to avoid using the word "this" to describe something that's not `this` :-) [13:01:54.0626] * it might be helpful to avoid using the word "this" to describe something that's not `this` :-) [13:02:09.0167] * it occurs to me throughout this agenda item, that it might be helpful to avoid using the word "this" to describe something that's not `this` :-) [13:13:00.0343] > <@ljharb:matrix.org> it occurs to me throughout this agenda item, that it might be helpful to avoid using the word "this" to describe something that's not `this` :-) _Non-Lexical use of `this` considered harmful_ [13:18:08.0718] yeah, I'm interested in this, but it's a bit hard to follow with nothing to look at [13:18:22.0852] shu: maybe it'd be good to structure the discussion by naming a topic that you'd like to start with? [13:18:34.0567] there are many topics that you touched on in your initial speech [13:19:02.0716] sarahghp: By the way, take a look at https://github.com/tabatkins/proposal-call-this-operator and let us know in the pipe room what you think. It’s another version of bind-this but which doesn’t overlap with the pipe operator. [13:22:45.0488] anba is indeed the GOAT when it comes to really weird edge cases [13:23:09.0276] * anba is indeed the GOAT when it comes to really weird edge cases [13:26:17.0101] it's also good to remember that as an implementer, it is infinitely easier to detect spec bugs in a proposal when tests exist and I can actually interact with the breakage [13:29:11.0499] An idea: stage 3 entrance criteria is a documented plan for authoring test262 tests (e.g. who will be doing work and when)? This might mean in practice folks will be thinking about it during stage 2. [13:30:29.0501] I was thinking it would be nice to have a few basic tests earlier -- this is why i added the comment about adding a branch that is for integration effectively [13:30:34.0946] * I was thinking it would be nice to have a few basic tests earlier -- this is why i added the comment about adding a branch that is for integration effectively [13:31:08.0429] implementers who start early can land there, those tests can be reviewed at stage 3 [13:31:56.0340] Stage 2.5 came up a few times on our side - the idea of "implement, but do not ship anywhere even flagged", and doing that sort of implies the creation of tests anyway [13:32:10.0412] * Stage 2.5 came up a few times on our side - the idea of "implemented, but not shipping anywhere even flagged", anddoing that sort of implies the creation of tests anyway [13:32:13.0588] * Stage 2.5 came up a few times on our side - the idea of "implemented, but not shipping anywhere even flagged", and doing that sort of implies the creation of tests anyway [13:32:18.0148] yeah, I believe a good thing to have would be an existing PR/branch with tests [13:32:34.0221] * Stage 2.5 came up a few times on our side - the idea of "implement, but do not ship anywhere even flagged", and doing that sort of implies the creation of tests anyway [13:36:16.0803] stage 2.5 seems like a good strategy to get champions more involved with the project [13:36:50.0726] I'd support it [13:37:04.0420] that would be awesome [13:37:09.0931] especially for large proposals [13:37:28.0254] yeah, in hindsight it would've been amazing for Temporal [13:37:59.0984] > <@yulia:mozilla.org> I was thinking it would be nice to have a few basic tests earlier -- this is why i added the comment about adding a branch that is for integration effectively > what if we had another branch for implementers to land pre-stage 3 tests that can help prove out the feature? test262 has always allowed early landing as long as there's a feature flag (during stage 2) [13:38:00.0918] I disagree, it would've been unfeasible for Temporal, and I can talk about that in the meeting if people would like to hear about it [13:38:17.0367] ye..es but [13:38:19.0837] i would love to hear about why it would have been unfeasible [13:38:36.0767] given that the suggested 2.5 above includes "implement it but only behind a flag", which matches temporal's current implicitly agreed state [13:38:47.0805] * given that the suggested 2.5 above includes "implement it but only behind a flag", which matches temporal's current implicitly agreed state [13:39:13.0804] if we take the example of iterator helpers, which -- yes, was incomplete, but the student working on that was told it won't be landed because we don't land until stage 3, i feel like this was not communicated [13:39:43.0587] I suppose it won't be a problem for smaller proposals because we can skip straight to stage 3, right? [13:40:01.0168] it'd be a shame to wait for 2 extra months to just get a tiny proposal through [13:40:08.0445] * it'd be a shame to wait for 2 extra months to just get a tiny proposal through [13:40:08.0531] sarahghp: is the maintainers' meeting on the tc39 calendar? [13:40:48.0172] ryzokuken: eg we could maybe even agree in plenary that a proposal is "2.5 now, but will be 3 once tests are landed and one implementer implements without finding normative issues" (something creative we all had consensus on, iow) [13:40:53.0297] * ryzokuken: eg we could maybe even agree in plenary that a proposal is "2.5 now, but will be 3 once tests are landed and one implementer implements without finding normative issues" [13:41:03.0369] thereby justifying the .5 designation [13:41:06.0157] * ryzokuken: eg we could maybe even agree in plenary that a proposal is "2.5 now, but will be 3 once tests are landed and one implementer implements without finding normative issues" (something creative we all had consensus on, iow) [13:41:08.0630] > <@ljharb:matrix.org> sarahghp: is the maintainers' meeting on the tc39 calendar? I have to find out how to do that. [13:41:12.0244] oh, without needing to come back to plenary? [13:41:12.0767] Can you help? [13:41:28.0416] sarahghp: yep! i can add stuff to the cal; DM me date/time/url/invitees [13:41:48.0766] ryzokuken: yes, we've given "conditional stage 3" a number of times before, usually "pending editor approval of the PR" or "pending tests being merged" [13:42:15.0919] sounds good, then [13:42:22.0266] ohh. that's really unfortunate if we're not even making it adequately clear _how_ to contribute 😔 [13:42:34.0333] * ohh. that's really unfortunate if we're not even making it adequate clear _how_ to contribute 😔 [13:42:36.0689] * ohh. that's really unfortunate if we're not even making it adequately clear _how_ to contribute 😔 [13:43:00.0480] I have a slight preference for actual tests (PR/branch) over a plan, but I support stage 2.5 (modulo naming bikeshed /s) [13:43:20.0773] Point of order: queue entries are still good when the queue is empty because it allows folks to reply to your topic [13:43:39.0627] we can decide anything we want as a group; 2.5 entry requirements could include "a complete non-draft tests PR must exist", eg (like how the stage 4 requirements already include "an editor-approved 262 PR") [13:43:40.0310] (brief placeholders are fine) [13:43:53.0036] * we can decide anything we want as a group; 2.5 entry requirements could include "a complete non-draft tests PR must exist", eg [13:44:08.0043] * we can decide anything we want as a group; 2.5 entry requirements could include "a complete non-draft tests PR must exist", eg (like how the stage 3 requirements already include "an editor-approved 262 PR" [13:44:09.0175] * we can decide anything we want as a group; 2.5 entry requirements could include "a complete non-draft tests PR must exist", eg (like how the stage 3 requirements already include "an editor-approved 262 PR") [13:44:23.0703] nit: stage 3 requires spec text, not pr [13:44:28.0233] stage 4 requires editor-approved PR [13:44:34.0978] oh right thanks, updated [13:44:38.0740] * we can decide anything we want as a group; 2.5 entry requirements could include "a complete non-draft tests PR must exist", eg (like how the stage 4 requirements already include "an editor-approved 262 PR") [13:45:15.0731] it's been years since i had to cite the process document every plenary, so i guess its entirety no longer has residence in my brain :-p [13:46:03.0765] so to be clear, the current stage 3 requirements will become 2.5 requirements and new stage 3 requirements will be the current + ? [13:46:42.0626] something like that, i guess? someone would have to take the time to write up a process doc PR for it, if it's something we want to do [13:46:47.0715] I think I must've missed whatever earlier stage there was regarding a maintainer group here, post-Bocoup [13:46:58.0658] that seems like it would've been more likely to work in the case of Temporal, though still not ideal [13:47:13.0119] * I think I must've missed whatever earlier stage there was regarding a maintainer group here, post-Bocoup [13:47:15.0743] ptomato: I think we already had a stage 2.5 [13:47:25.0654] like the whole "spec is frozen" thing [13:47:27.0590] can i get a time check? [13:47:35.0266] that was our stage 2.5, wasn't it? [13:47:39.0762] ptomato: what about that would have been less than ideal? [13:47:42.0174] per that definition, Temporal is in stage 2.5 currently? [13:47:51.0737] yes [13:48:04.0734] (not that it'd necessarily change just because 2.5 is created) [13:48:21.0120] but it'd also mean that "stage 2.5" would signify the same thing "stage 3" currently signifies, but without the connotation that it's yet a stage 4 candidate. [13:48:34.0444] yeah, I think existing stage 3 proposals don't need to be reevaluated [13:48:40.0952] * yeah, I think existing stage 3 proposals don't need to be reevaluated [13:48:59.0267] * but it'd also mean that "stage 2.5" would signify the same thing "stage 3" currently signifies, but without the connotation that it's yet a stage 4 candidate. [13:49:16.0960] I just think we're reifying in process something that already kinda exists? [13:49:17.0469] I'm happy to add a queue item if people want to talk about this - but tl;dr it would mean a large delay in the proposal's progress towards adoption, while we bottleneck on writing test262 tests [13:49:22.0022] as a sort of TC39 social contract? [13:49:48.0323] in general there's a notable difference between a proposal being "entering the stage" vs "ready to exit the stage", but it's only in stage 3 where that difference is particularly impactful [13:49:58.0971] > <@usharma:igalia.com> I just think we're reifying in process something that already kinda exists? exists "when all goes well" [13:50:11.0736] ptomato: nobody's shipping it unflagged, specifically to inhibit adoption; who's adopting it now? [13:50:12.0533] like I think there's already a slightly blurry period where this is the reality [13:50:21.0573] but we just don't have it in the process yet [13:50:41.0395] I mean progress towards adoption into 262 [13:51:22.0298] currently, implementors are implementing it behind flags. I'm thinking with a stage 2.5 they'd be more reluctant to do that until stage 3. maybe not? [13:51:23.0672] it wouldn't change the actual work that needs to be done prior to the PR being merged - it would just more accurately "milestone" the work [13:51:51.0176] i'd expect not; i think the implementers who are already hesitant to ship during stage 3 would have no problem shipping flagged during 2.5 [13:51:52.0384] I agree, delays to proposals that shouldn't be affected is my concern too [13:52:04.0166] but if we can skip 2.5 when it's not needed it's fine, right? [13:52:06.0991] iow i think it would actually _help_ have more impls ready to unflag in stage 3, if we added 2.5 [13:52:09.0911] "can you please write tests for X? we don't want to implement it without tests" [13:52:36.0981] ryzokuken: sure, we could. but if it's really not that needed than it could also get 2.5, and come back the next day, and get 3 :-p (because the work to get from 2.5 to 3 would be so trivial) [13:52:42.0146] * ryzokuken: sure, we could. but if it's really not that needed than it could also get 2.5, and come back the next day, and get 3 :-p [13:52:52.0396] > <@usharma:igalia.com> "can you please write tests for X? we don't want to implement it without tests" yes, it's that kind of chicken and egg problem I'm concerned about [13:52:59.0318] * ryzokuken: sure, we could. but if it's really not that needed than it could also get 2.5, and come back the next day, and get 3 :-p (because the work to get from 2.5 to 3 would be so trivial) [13:53:08.0330] hm, that's true. It's hard to write tests without impls [13:53:38.0613] but I think the way test262 tests are usually written, they don't NEED an implementation? leobalter ptomato feel free to correct me here. [13:53:45.0798] that's right [13:54:07.0456] i think that i've found myself in all of the positions of "tests first", "tests at the same time", and "tests after", depending on which thing it is, so i think a blanket statement's best avoided [13:54:11.0170] * i think that i've found myself in all of the positions of "tests first", "tests at the same time", and "tests after", depending on which thing it is [13:54:24.0697] * i think that i've found myself in all of the positions of "tests first", "tests at the same time", and "tests after", depending on which thing it is, so i think a blanket statement's best avoided [13:54:34.0810] since they test lines in spec instead of edge cases, you're technically writing tests for the spec [13:54:42.0430] that's the whole point [13:55:01.0253] you're supposed to write tests for the spec, and run them against implementations [13:55:10.0197] otherwise you're coupling tests to the implementation details [13:55:46.0405] (and when that process exposes deltas, it likely indicates either an impl "bug", or a spec "bug") [13:55:52.0162] * (and when that process exposes deltas, it likely indicates either an impl "bug", or a spec "bug") [13:56:31.0406] yulia: 👏 [13:56:31.0453] maybe we'll get automatic reference implementations from the KAIST work! at least for some proposals [13:56:52.0068] yeah ,thatt would be awesomme [13:56:56.0139] that would certainly make "writing tests" much easier :-D [13:56:57.0788] +1 [13:57:05.0698] I thought implementation-contributed was a historical artifact? [13:57:10.0933] and polyfills! i'm very interested in using KAIST's work, with es-abstract, to generate polyfills [13:57:21.0690] not that it can't be done, but I didn't think the existing thing was meaningful [13:57:25.0367] The many times we tried to make the review process stricter the gatekeeping flag has been frequently raised. There is actually a strong motion to loose the review process to land Test262 tests. Yet, in the meeting today I heard the tests are not carefully reviewed. [13:57:37.0941] I mean, the spec text is not the easiest format to read I'd say so I sympathize with people who prefer polyfills/impls before formalizing tests [13:58:07.0993] Rick Waldron: we can also prune the implementer tests using code coverage if we want to? maybe [13:59:09.0455] yulia: that used to be a job description at bocoup 🤣 [13:59:49.0609] it is a fact that many tests are not carefully reviewed. this comment is not a personal slight: it is a fundamental difficulty in reviewing tests testing a giant specification with many hairy corners, in using reviewers who are not proposal authors or champions, in having ad-hoc process, etc [13:59:53.0369] and that's what i want to address [13:59:53.0972] Part of becoming a test writer included reviewing and "up lifting" tests in the "implementer contributed" bucket. [14:00:15.0747] it is decidedly not a comment about any past failings or complaining about how previous maintainers were doing anything less than a stellar job [14:01:03.0571] > <@rwaldron:matrix.org> Part of becoming a test writer included reviewing and "up lifting" tests in the "implementer contributed" bucket. ohh that explains why that bucket always seemed "somehow not relevant" from a single engine's perspective [14:03:08.0456] We had an automated server that was collecting tests from https://github.com/WebKit/WebKit/tree/main/JSTests and https://github.com/v8/v8/tree/master/test/mjsunit for a couple years [14:03:28.0175] But the server was shut down 🤷 [14:03:41.0703] By "we" I mean my previous employer [14:04:51.0695] i presume there's no chance the code for that is easily resurrectable in some cloud provider? [14:05:03.0035] it looks like there are quite a few past task that the new maintainer group can discuss, and bring in those that are reasonable for this point in time. Personally speaking -- that sync would have been useful recently [14:05:35.0994] all I can say is that I did my job in good faith and in my bias I tried my best to review things carefully. Some things pass because it's still hard to have a base of tests where you often don't have a sample to run them or the size of everything. This includes indications to keep the flow running to avoid frustrating contributors. It's upsetting to see all of this reduced to "not carefully reviewed" [14:06:16.0299] > <@ljharb:matrix.org> i think that i've found myself in all of the positions of "tests first", "tests at the same time", and "tests after", depending on which thing it is, so i think a blanket statement's best avoided I've yet to see "tests first" being pragmatic. test cases / acceptance criteria first, sure, but not actual written tests.. just my exp; open and curious to situations demonstrating otherwise [14:06:37.0963] SoftwareChris: that is generally my experience as well, but there's a lot of TDD adherents who would debate that. in test262's case tho, the spec comes first, and then the tests, so the spec is kind of the "implementation" here :-) [14:06:59.0468] * SoftwareChris: that is generally my experience as well, but there's a lot of TDD adherents who would debate that. in test262's case tho, the spec comes first, and then the tests, so the spec is kind of the "implementation" here :-) [14:07:28.0804] I don't tie TDD to tests-first but I don't want to get into a flame war [14:07:40.0562] the tests are well reviewed enough that i generally can rely on them. on occasion things slip through -- and those moments are certainly more obvious than the times things are working smoothly [14:07:53.0248] i think we can all say that the test suite is something we rely on, and that speaks to its quality [14:08:26.0758] there are places that can be supported, such as more eager acceptance of browser tests in a controlled fashion, as they will be able to iterate and catch eachohers problems more quickly [14:08:47.0574] in my experience, when tests are written after the implementations is where you often find inconsistencies and gaps to meet web compatibility. [14:09:14.0493] my experience with TypedArrays was salvage [14:09:17.0305] the "complete" test suite also has significant benefits, it highlights specific segments of the spec that are being tested in case there are issues either with implementations or the spec. We have a high resolution view into what is changing in the language this way [14:09:43.0741] also, tests often helped improving the specs, with or without implementations ready [14:10:22.0899] I definitely don't think there's any question that the work you did was phenomenal, Leo [14:10:44.0154] leobalter: i implore you to not take what i said as a personal attack. it can be both true you did a great job, and not all tests were adequately reviewed [14:10:49.0862] rkirsling: as I mentioned, I know I lot of people recognizes this work and I'm always grateful for that. [14:11:20.0595] shu: I took that as offensive because it was an over simplification of a work I did for so long in good faith. [14:12:32.0364] I hope no one at TC39 has their work oversimplified to hear such a note. Not carefully reviewed seems like saying the work was poor. [14:13:09.0089] * shu: I took that as offensive because it was an over simplification of a work I did for so long in good faith. [14:17:20.0747] > <@leobalter:matrix.org> in my experience, when tests are written after the implementations is where you often find inconsistencies and gaps to meet web compatibility. in this situation, I agree. having a functional specification is sort of like having an implementation, like ljharb mentioned. so this is not an example of what I am thinking of when talking about test-first development. more reason not to generalize about these things [14:20:41.0285] my personal take on TDD'ish: - no test is good before documentation (or specs) - tests first is useful when you have multiple implementations relying on the same base. - I support experimenting with implementation regardless of tests but also writing a test when you know the expected outcome but the implementation feels more complex. [14:21:43.0764] so I break myself the rules for TDD in general, and yet I like tests being written at any point that feels comfortable to the developer. For test262, very often you have a very clear map of what you need. [14:22:29.0973] in general programs you should be able to explore more in the units to serve a final functional layer. [14:23:02.0583] * in general programs you should be able to explore more in the units to serve a final functional layer. [14:23:05.0443] TabAtkins: how could i use houdini outside of a browser? [14:26:37.0022] er that second Japanese linebreak is invalid though [14:26:42.0582] 推計 is a word [14:26:45.0381] * 推計 is a word [14:27:06.0162] shu: yes, anything i want to do in the browser wrt segmenting text, i want to do in node, for server rendering (re your queue item). also for email generation, and for producing PDFs. [14:27:12.0232] * shu: yes, anything i want to do in the browser wrt segmenting text, i want to do in node, for server rendering (re your queue item) [14:27:28.0978] * shu: yes, anything i want to do in the browser wrt segmenting text, i want to do in node, for server rendering (re your queue item). also for email generation, and for producing PDFs. [14:27:40.0474] I won't be able to attend the remainder of this meeting, but the Bloomberg team should be good for the Symbols as WeakMap keys. [14:29:21.0418] sorry the bot went down; my network dropped for a minute [14:29:37.0600] no worries 👍️ [14:29:47.0801] * no worries 👍️ [14:31:50.0782] I can't hear anything, is it only me? [14:32:05.0005] sound is on [14:32:07.0931] for me [14:33:09.0456] ok, close and rejoin fix my problem. [14:50:00.0215] `assert.equals(iframe.contentWindow.Symbol.iterator, Symbol.iterator)` [14:50:12.0634] Mathieu Hofman: `Symbol` itself is mutable (as is `global.Symbol`) but `Symbol.iterator`, eg, is nonconfigurable [14:50:13.0873] * `assert.equals(Symbol.iterator, iframe.contentWindow.Symbol.iterator)` [14:51:18.0273] True [14:51:22.0976] * Mathieu Hofman: `Symbol` itself is mutable (as is `global.Symbol`) but `Symbol.iterator`, eg, is nonconfigurable [14:51:32.0058] I guess you can still remove `Symbol` global tho [14:51:41.0238] or recreate it [14:52:54.0493] why are people still talking about well-known symbols, when the main issue is registered symbols? [14:53:13.0087] remnants from the conversation before it [14:53:35.0547] the good news from the temperature check on symbols as weakmap keys is that everyone wanted the feature - and wanted some form of symbols to be permitted (either all or some) [14:53:42.0593] sorry I just wanted to clarify why we considered well known to be equivalent to registered. [14:55:50.0864] shu: yes it was me, I talked about forgeability, and registered symbols is one such value. All strings and numbers obviously, and in the future, records/tuples which do not contain symbols [14:56:21.0063] Re: "the Houdini API doesn't work with non-HTML"; the *current spec* (which hasn't been touched in years) has a method signature that explicitly addresses the non-HTML case and would work in non-browser environments: https://drafts.css-houdini.org/font-metrics-api/#measure-api [14:57:56.0120] i feel like node core's use case is not one you'd want to put into a weakmap, and is if anything a good reason to _not_ allow registered symbols [14:58:55.0950] on the poll, no one voted for "no progress" [14:59:29.0982] > <@ljharb:matrix.org> i presume there's no chance the code for that is easily resurrectable in some cloud provider? I wouldn't bother. [14:59:41.0935] I agree with MM here [14:59:57.0009] well known ought to be treated like registered but I don't care enough to block [15:07:58.0041] i am inclined to trust browsers about what things are likely to be web-compat [15:08:33.0857] possible, but this is surprising to me [15:08:42.0401] same [15:08:59.0039] fwiw this is also the expectation I have [15:09:01.0908] and this argument kind of says we should never add the predicate, and should keep letting people do it themselves, thus causing their predicate to become wrong as the language evolves [15:09:10.0335] * and this argument kind of says we should never add the predicate, and should keep letting people do it themselves, thus causing their predicate to become wrong as the language evolves [15:09:15.0561] from interacting with _so much_ garbage code on the web at a whole [15:09:25.0030] ljharb: how does it say we should never add the predicate? [15:09:47.0004] the predicate should not change answers, it's fine for it to not give answers for things that don't exist yet [15:09:50.0779] because once we add the predicate that means "can you add this to a weak container?", how can we ever change what values pass that predicate? [15:10:01.0110] we... can't [15:10:02.0343] shipping amounts to an agreement that we are decided we're never going to change the can-be-used-in-weak-collection state of any existing value [15:10:03.0277] seems fine [15:10:03.0810] right, it would mean we can never allow something existing, to start being accepted [15:10:16.0600] which is precisely what "symbols as weakmap keys" is trying to do [15:10:16.0932] could not parse [15:10:22.0380] i definitely do not want to have this discussion ever again [15:10:42.0306] like, let's say we'd shipped, with ES6, a "WeakMap.canBeKey()" predicate or something [15:10:49.0795] then we couldn't have this proposal [15:10:52.0959] does that mean, in that timeline, we'd never be able to add symbols? [15:10:54.0142] wow, ok [15:10:54.0848] in that counterfactual, we can't have this proposal at all [15:10:55.0767] yes [15:11:00.0631] that's very surprising to me. [15:11:02.0066] but, once we allow non-registered non-well known symbols, we have added all of the things it is even coherent to add [15:11:07.0019] so it is fine for things to be settled at this state [15:11:09.0409] we make decisions like this all the time [15:11:17.0656] i don't agree with that tho (that there's never anything else coherent to add) [15:11:24.0288] * but, once we allow non-registered non-well known symbols, we have added all of the things it is even coherent to add [15:11:31.0866] there literally is not, for the predicate that says "is forgeable or not" [15:11:31.0917] what other things currently in the language would be coherent to add? [15:11:38.0235] it is literally exhaustive [15:15:26.0263] ljharb: i have in the conclusion "JHD does not immediately rescind previously expressed blocking objection to _not_ allowing registered symbols"; does that capture your position at this moment in time correctly? [15:15:40.0987] that's fine, i'll review the notes anyways [15:15:44.0980] √ [15:16:19.0135] https://github.com/tc39/Reflector/issues/416 [15:16:38.0460] I guess this is the chat where I claim kudos for participating in note taking? Rob Palmer [15:16:46.0389] yes! [15:16:47.0552] 😁 [15:16:56.0504] thank you Bradford Smith ! [15:17:02.0892] who else took notes? [15:17:08.0427] I did yesterday [15:17:10.0525] I think sarahghp did notes [15:17:20.0043] thank you ptomato ! [15:17:25.0149] I helped with notes for like.. 20 minutes at the end yesterday. and just randomly here and there a few times [15:17:48.0762] that is much appreciated SoftwareChris ! [15:17:50.0796] thank you all of the note takers, Bradford Smith ptomato sarahghp SoftwareChris Robin Ricard (i think also did a lot?) [15:17:53.0582] I invented tc39 notes. [15:17:54.0296] Robin Ricard and Ashley Claymore took many many notes [15:17:57.0208] 🤷 [15:17:58.0483] and anyone who did it invisibly [15:18:00.0960] Rick Waldron: LMAO [15:18:10.0663] and thank you Rick Waldron [15:18:14.0863] thanks to bakkotbot also [15:18:22.0230] * thanks to bakkotbot also [15:18:23.0196] > <@yulia:mozilla.org> and thank you Rick Waldron Take that back [15:18:23.0292] I did slack a bit, Ashley Claymore did not [15:18:25.0059] ;) [15:18:32.0183] Rick Waldron: the OG of notes [15:18:33.0407] so we will not have meeting tommorow? [15:18:40.0516] HE Shi-Jun: correct [15:19:01.0418] Correct HE Shi-Jun - plenary has finished one day early [15:19:04.0507] Ha I can barely take notes, everyone else is so fast [15:19:06.0600] I love not taking notes. I love that other people love to do it now and are proud of the notes they took. I am proud of them. [15:19:25.0124] HE Shi-Jun: We do have a non-plenary continuation of the dataflow-proposal talk tomorrow though. [15:19:54.0522] If you can come, please leave a comment on tc39/Reflector#416. [15:20:50.0091] jschoi: happy to know that, I'm not sure I can be there tomorrow, but I will leave comments in the issue, if I can't attend. Thank u! [15:25:41.0294] all hail bakkotbot! 2022-01-27 [17:21:17.0794] Btw, re symbols, I'm still surprised no engine considers registered symbols separately from unique symbols, and simply implements them as a wrapped string. At that point there is no need to track instances of registered symbols and collect them, at least any more than roping the strings they wrap, and `Symbol.for` can simply recreate the value, `Symbol.keyFor` can unwrap the description, and comparing would match the subtype (registered symbol) + description value. [09:52:51.0189] if you want to talk more about the presentation from the KAIST research group yesterday, I've started a thread on the Reflector: https://github.com/tc39/Reflector/issues/417 [10:02:33.0659] > <@mhofman:matrix.org> Btw, re symbols, I'm still surprised no engine considers registered symbols separately from unique symbols, and simply implements them as a wrapped string. At that point there is no need to track instances of registered symbols and collect them, at least any more than roping the strings they wrap, and `Symbol.for` can simply recreate the value, `Symbol.keyFor` can unwrap the description, and comparing would match the subtype (registered symbol) + description value. maybe would have added a bit of complexity to other places (e.g. `typeof` to now handle 2 different representations for the same type). And if `Symbol.for` is only called a few times per application run, not a large optimization saving. [10:03:04.0170] https://hackmd.io/yDDJCsS-Sv2AJwo8arAn3w?view [10:05:09.0470] the data flow call has begun; there's only 4 of us so far. jschoi, coming? [10:05:15.0933] * the data flow call has begun; there's only 4 of us so far. jschoi, coming? [10:10:19.0264] oops, we're in the jitsi, not the meet on the calendar invite [11:32:26.0867] TabAtkins: I meant uncurry-this [11:32:40.0870] I assumed that was what was meant by call-this [11:33:49.0897] because there is zero mention of `call-this` in either article [11:34:53.0609] so if that's not what was meant then I have zero idea what was meant by that phrase [11:35:21.0880] https://github.com/tabatkins/proposal-call-this-operator [11:35:44.0947] literally just "`.call()`, but a calling operator" [11:35:58.0488] `method@(reciever, arg)` === `method.call(receiver, arg)` [11:36:18.0020] I see [11:36:29.0484] Do people remember the reasons why named argument syntax was rejected in JS? A la `foo(argname: 1, arg2name: 2)`? [11:36:29.0849] that too seems inoffensive (in that it _adds onto_ existing syntax) [11:36:41.0688] * that too seems inoffensive [11:37:06.0728] * that too seems inoffensive (in that it _adds onto_ existing syntax) [12:16:58.0909] oh lol it's funny that my previous statement was in fact that `::` is less confusing than `->` https://github.com/tc39/proposal-bind-this/issues/10 [12:17:14.0591] * oh lol it's funny that my previous statement was in fact that `::` is less confusing than `->` https://github.com/tc39/proposal-bind-this/issues/10 [12:19:15.0799] sorry about that, I do still think that's true [12:22:32.0957] which means that my new point is really just that I'd have a preference for call-this [12:23:27.0640] rkirsling: Also, take a look at rbuckton’s new idea in the pipe room. `f(this: thisArg)`. Or maybe `f(thisArg:)`. [12:31:12.0069] I could see conflicts with type systems which also use : [14:14:17.0838] TabAtkins: i think mainly because its value-add is negligible over "an options bag, destructured in the function" 2022-01-28 [17:21:44.0281] > <@tabatkins:matrix.org> Do people remember the reasons why named argument syntax was rejected in JS? A la `foo(argname: 1, arg2name: 2)`? I don't remember why, it was dead before I ever started attending meetings. Either way, it's a non-starter now because... > The Syntactic Grammar must not be extended in any manner that allows the token : to immediately follow source text that is matched by the BindingIdentifier nonterminal symbol. [17:22:15.0585] Mathieu Hofman: to your point ^^ > I could see conflicts with type systems which also use : [17:23:42.0756] That Forbidden Extension was written exactly for the case you mention [18:18:34.0284] > <@rwaldron:matrix.org> I don't remember why, it was dead before I ever started attending meetings. Either way, it's a non-starter now because... > > > The Syntactic Grammar must not be extended in any manner that allows the token : to immediately follow source text that is matched by the BindingIdentifier nonterminal symbol. > Huh! I had not known this was a thing. When was it added? Is it specifically to accommodate future ES type-like annotation, or is it specifically for ES extensions like TypeScript and Flow…? [18:42:45.0608] strictly speaking, forbidden extensions constrain implementations, not us. we could write this into the spec and then implementations could ship it and that would be kosher. the point (as I understand it) is to prevent stuff like happened in the earlier eras when browsers would ship new syntax _without_ it being in the spec (like function declarations in blocks, for example), and then we'd be stuck with it forever [18:42:56.0191] * strictly speaking, forbidden extensions constrain implementations, not us. we could write this into the spec and then implementations could ship it and that would be kosher. the point (as I understand it) is to prevent stuff like happened in the earlier eras when browsers would ship new syntax _without_ it being in the spec (like function declarations in blocks, for example), and then we'd be stuck with it forever [18:43:42.0437] that said, we probably should not ship `param: x` unless it means roughly what it does in TS. [18:49:52.0592] Does TS have `param: x` at call sites? I thought it was only function definition [18:51:45.0160] yeah, true [18:54:04.0789] wouldn't you need at definition too for named argument? I understand you may not need it for explicit receiver [18:55:09.0196] (Btw, I actually like that TS unlike Flow has the ability to type the `this` in function declarations, I wish it was more thoroughly leveraged though) [02:29:41.0770] re groupBy Justin Ridgewell we have another report involving the sugar.js library: https://github.com/webcompat/web-bugs/issues/98458 [06:37:06.0010] > <@jschoi:matrix.org> Huh! I had not known this was a thing. When was it added? Is it specifically to accommodate future ES type-like annotation, or is it specifically for ES extensions like TypeScript and Flow…? September 2014! Here's the meeting notes conclusion/resolution: https://github.com/tc39/notes/blob/8711614630f631cb51dfb803caa087bedfc051a3/meetings/2014-09/sept-25.md#conclusionresolution-2 and the topic starts here: https://github.com/tc39/notes/blob/8711614630f631cb51dfb803caa087bedfc051a3/meetings/2014-09/sept-25.md#types [06:39:47.0982] > Reserve syntax used by TypeScript, Flow, etc. for some form of annotation [06:39:51.0133] There it is, hmmm. [06:40:14.0757] I’m reminded of rbuckton’s withdrawn request to reserve `@@` syntax for extension languages’ decorators. [06:41:01.0891] > <@bakkot:matrix.org> strictly speaking, forbidden extensions constrain implementations, not us. we could write this into the spec and then implementations could ship it and that would be kosher. the point (as I understand it) is to prevent stuff like happened in the earlier eras when browsers would ship new syntax _without_ it being in the spec (like function declarations in blocks, for example), and then we'd be stuck with it forever It's actually both: Yes, to your point as stated here, but back in 2014 there was still a strong desire to ensure that TypeScript, Flow, etc were strict supersets of JavaScript. If JS suddenly made named parameters, then that would become exceptionally hard. I'm not even sure if that's still true of those systems, or still a goal, or what. [12:19:25.0566] fwiw it's never been true of those systems, but i think it's still a stated goal [12:19:37.0508] * fwiw it's never been true of those systems (maybe flow, but i haven't looked at it in awhile), but i think it's still a stated goal [14:39:33.0440] > <@mhofman:matrix.org> (Btw, I actually like that TS unlike Flow has the ability to type the `this` in function declarations, I wish it was more thoroughly leveraged though) Flow also has this ability... https://flow.org/try/#0PQKgBAAgZgNg9gdzCYAoVUCuA7AxgFwEs5swoAKfAC0IGcAuMAbwENHb8AnQ7AcwF8ANGAAejbJgC2AIwCmnAJTNUYMNToA6EdoDcYYMDABRAEomA8iZVhOs-Jk6l1tDSw20YhXLPIiFegzBzAGlUfiA [14:44:31.0119] Is that new? Last I checked, and according to https://github.com/niieani/typescript-vs-flowtype#declarable-arbitrary-this-in-functions-outside-of-objects, it was a TS only feature [14:45:11.0514] that file was last updated 2 years ago [14:46:03.0945] I would consider it largely inaccurate and would not use it as a source of information [14:47:57.0074] Well arguably I've not looked at flow closely in about a year. But I do not remember about this feature. Wondering when it was added. Maybe we were stuck on an older flow version in the codebase I worked on at the time. Anyway, glad it's there now, and I retract that specific flow complaint [14:49:24.0762] Improved typing of `this` was announced last year: https://medium.com/flow-type/sound-typing-for-this-in-flow-d62db2af969e [14:50:16.0263] Just saw that, yeah that's after last time I looked into flow [14:51:36.0706] And it looks like flow is being a lot stricter about this than TS, which is a + IMO