2022-03-01 [14:22:36.0271] Hey; I've got [a bug](https://bugzilla.mozilla.org/show_bug.cgi?id=1757162) which essentially boils down to this little test case ``` class A { #x = "hello"; constructor(o = this.#x) { this.value = o; } }; var a = new A; // Does new A throw? if not, does a.value have the value of `hello`? ``` [14:22:48.0705] I'm trying to figure out what the spec says and got a little confused [14:24:02.0915] https://tc39.es/ecma262/#sec-evaluatenew says that ArgumentListEvaluation happens before the constructor is invoked; but AFAICT it's the constructor that actually allocates the object... [14:24:35.0604] does ArgumentListEvaluation not actually... evaluate the arguments? ie, is the processing of the default argument deferred until later? [14:31:39.0687] `ArgumentListEvaluation` evaluates _the arguments_, not the parameters [14:32:16.0995] it's the thing which would trigger the `console.log` in `f(console.log(0));`, not the thing which would trigger the `console.log` in `function f(x = console.log(0)) {}; f()` [14:32:59.0899] yeah; I think I've got the latter traced down further into https://tc39.es/ecma262/#sec-functiondeclarationinstantiation [14:33:32.0804] (which seems to imply that the answer is that private fields ought to be available in that parameter expression) [14:33:55.0892] (I always get bit when coming back to arguments/formals/parameters) [14:36:38.0597] yeah [14:37:36.0990] specifically, for base classes, class fields are created/installed by [[construct]] step 6.b: https://tc39.es/ecma262/multipage/ordinary-and-exotic-objects-behaviours.html#sec-ecmascript-function-objects-construct-argumentslist-newtarget [14:38:04.0399] * specifically, for base classes, class fields are created/installed by [[construct]] step 6.b: https://tc39.es/ecma262/multipage/ordinary-and-exotic-objects-behaviours.html#sec-ecmascript-function-objects-construct-argumentslist-newtarget [14:39:12.0103] and parameter defaults (and other expressions) are evaluated later, in [[construct]] step 8, via OrdinaryCallEvaluateBody -> EvaluateBody -> EvaluateFunctionBody -> FunctionDeclarationInstantiation -> IteratorBindingInitialization [14:40:11.0699] so private fields (and all other fields) are available (for base classes) by the time the parameter list is evaluated [14:40:28.0166] Yep :) Was writing that out... less nicely than you in the bug :P 2022-03-02 [12:11:07.0493] the snippet of code for getting the time is wrong on the agenda; can someone fix it? https://github.com/tc39/agendas/blob/main/2022/03.md [12:11:33.0045] I can do it if I remember next time I have an opportunity [12:12:01.0489] (it has the wrong date) 2022-03-03 [16:06:48.0051] done 2022-03-07 [10:13:38.0587] A friendly reminder to delegates that there’s an incubator meeting about `Function` helper functions tomorrow! Hope to see you there. https://github.com/tc39/incubator-agendas/blob/master/2022/03-08.md 2022-03-08 [08:03:53.0082] ljharb: incubator call? [08:05:00.0615] I’ll be a few late, but I’m coming [08:25:12.0906] jschoi: "demethodize" is pretty gross imo, ftr :-p [09:01:10.0789] it sounds like a surgical procedure [11:51:46.0153] so, we have `x?.(y)`, where it doesn't call `x` unless `x` is non-nullish; is there no simple way to do `x(y)` when _y_ is non-nullish? (obv i can do `y == null ? y : x(y)` but that means i have to repeat the `y` expression more than once, or store it in a var) [12:01:17.0935] sounds like you want optional pipeline 😉 [12:01:34.0057] * sounds like you want optional pipeline 😉 [12:02:10.0572] `y ?> x()` [12:02:26.0534] optional pipeline :( [12:02:49.0120] we could just have do-notation, like a real language [12:03:07.0046] 🔥 [12:04:40.0003] real languages are statement based, only acceptable expressions are immediates and registers and addresses [12:04:46.0945] and immediates can't be too big [12:04:52.0405] and it'll be an awkward number of bits, like 21 [12:06:00.0164] all logic is ternary. true/false/unknown [12:11:13.0038] > <@aclaymore:matrix.org> sounds like you want optional pipeline 😉 There’s going to be a bikeshed around whether to use falsey or nullish for optional pipes. 🤔 [12:12:08.0125] nullish is the only reasonable choice for optional pipes [12:12:11.0812] also I don't want optional pipes [12:12:17.0408] but it's the only reasonable choice if we have to have them [12:22:57.0854] > <@aclaymore:matrix.org> all logic is ternary. true/false/unknown Also, we both have null and undefined. We can go further. https://www.computer.org/csdl/proceedings-article/glsv/1991/00143992/12OmNzzxusf Quaternary logic. We have the technology. Do we have the courage? [joke] [12:23:35.0286] * > <@aclaymore:matrix.org> all logic is ternary. true/false/unknown Also, we have null and undefined. We can go further. https://www.computer.org/csdl/proceedings-article/glsv/1991/00143992/12OmNzzxusf Quaternary logic. We have the technology. Do we have the courage? [12:24:22.0159] * > <@aclaymore:matrix.org> all logic is ternary. true/false/unknown Also, we both have null and undefined. We can go further. https://www.computer.org/csdl/proceedings-article/glsv/1991/00143992/12OmNzzxusf Quaternary logic. We have the technology. Do we have the courage? [joke] [12:30:58.0308] we have gone further [12:31:07.0359] we have an infinite number of `document.all`s available to us [12:31:18.0811] for as many non-null/undef nullish values as you want [12:46:45.0073] > <@jschoi:matrix.org> There’s going to be a bikeshed around whether to use falsey or nullish for optional pipes. 🤔 ? It would use the same rules as optional-call and ??; anything else would be a profound mistake. [13:59:53.0261] Yeah, I had thought there would be some disagreement on this, but it looks like everyone (including me) agrees with nullishness. [14:46:24.0173] I don't think it's *particularly* that everyone agrees on nullishness (tho maybe people do), it's just that it's extremely clear that all the things doing optionality with the same syntax pattern need to act the same. [15:39:44.0342] > <@bakkot:matrix.org> we have an infinite number of `document.all`s available to us not even limited to `document.all`, hosts can put `[[IsHTMLDDA]]` on any objects they choose [15:40:28.0658] owo [15:41:41.0154] "can", but "should" not [15:41:56.0611] "implementations should not create any with the exception of document.all" [15:42:00.0633] should've said "must" [15:42:22.0916] still could [15:43:09.0856] ^ [15:43:12.0141] with consensus, which, I definitely do not care enough about this to spend committee time on it [15:43:24.0213] also, now I've noticed that there's an issue with B.3.6.3 https://tc39.es/ecma262/#sec-IsHTMLDDA-internal-slot-typeof [15:44:17.0740] what's the issue? [15:44:41.0610] the left column of that table should separate all language values unambiguously [15:45:01.0817] an object with `[[IsHTMLDDA]]` will always fall into two rows [15:45:10.0479] either it has `[[Call]]` or it doesn't [15:48:45.0981] we should just have it insert a step into 13.5.3.1 instead of a row into the table [15:53:31.0030] https://github.com/tc39/ecma262/issues/2685 2022-03-09 [15:15:34.0307] 262 editors are planning on changing out `the result of evaluating |Whatever|` with `Evaluation of |Whatever|`, to better match other SDOs (`NamedEvaluation of |Whatever|`, etc) this makes it more consistent with the rest of the spec and also works better with tooling if anyone strongly objects to this change, speak now 2022-03-10 [16:16:36.0822] so many editors in agreement [16:32:50.0575] shu: array find-from-last shipped unflagged in M97, right? [16:32:55.0964] should probably close https://bugs.chromium.org/p/v8/issues/detail?id=11990 if that's so [16:33:25.0691] * shu: array find-from-last shipped unflagged in M97, right? [16:33:56.0690] good call, done [02:57:54.0594] can anyone access https://jschoi.org/21/es-dataflow/map/ ? [02:59:06.0403] No [02:59:37.0342] I get an error even on your homepage [03:44:48.0507] > <@jackworks:matrix.org> can anyone access https://jschoi.org/21/es-dataflow/map/ ? Not sure if jschoi removed it intentionally. I'm assuming it's not since the whole site is down. You can try https://web.archive.org/web/20220121194801if_/https://cdn.glitch.me/fce49fe7-f83b-4170-90d5-ab11ebc3ff25/21--es-dataflow--map.png [06:21:47.0649] Jack Works, legendecas, nicolo-ribaudo: Thanks for letting me know. My website host’s DNS settings had changed for some reason. I just updated them, so the website including the dataflow article should work now (though it might take up to several hours for the new DNS records to propagate). [06:22:38.0994] * Jack Works, legendecas, nicolo-ribaudo: Thanks for letting me know. My website host’s DNS settings had changed for some reason. I just updated them, so the website including the dataflow article should work now (though it might take up to several hours for the new DNS records to propagate). [13:24:55.0557] wait what's this about an in-person meeting? [13:25:12.0402] first I'm catching wind of that [13:27:45.0069] It was announced as part of the 2022 schedule last year. And in the last meeting I said I would give an update in the next plenary to confirm the details. I shall be sending out a Reflector post soon to collect numbers and feedback. It is hosted by OpenJS in Austin, Texas. The OpenJS organisers themselves plan to make a call on whether to proceed in just over a week. So it will also depend on their stance. [13:29:20.0726] We will still have dial in as always and there will be no pressure to attend in person. [13:41:17.0336] i hope they cancel it [13:43:45.0962] austin in summer is not the kind of weather i'd travel for [13:45:41.0319] erights phoddie do you have any additional info on this weakmap implementation 👀 [13:49:59.0146] These recent Texas news are also not really making me super enthused about traveling there anymore [14:23:18.0209] true, I think I would wait yet [14:44:52.0042] (both June and September are loosely planned to be in-person, as i understand it) [14:45:41.0082] * (both June and September are loosely planned to be in-person, as i understand it, in Austin and Tokyo respectively) 2022-03-11 [09:33:02.0704] Do we have a release candidate for 2022 yet? [09:33:40.0566] Not yet, we want to get one or two more things in [09:33:58.0614] but we'll be cutting it shortly (should be within a week) and will announce it on the reflector [09:34:52.0313] Awesome, thanks for the update! (just calling this out in the chair report) [11:09:06.0942] FYI for anyone who was unable to access the slides for the upcoming "extending built-ins" discussion linked from the March agenda: we were having IT issues with sharing, but they should be fixed now and the slides should be accessible again [11:09:19.0041] slides link for convenience: https://docs.google.com/presentation/d/1toEo_vh-UMqnaiQrj-gl3gWtvC34zzsraHnlIKouBtQ [11:09:39.0286] please let me know ASAP if the issue crops up again 2022-03-12 [16:42:49.0792] > Should Symbol.species continue to be an extension affordance generally? Remind me in case my memory is bad, but Everyone in TC39 agrees that Symbol.species was a Bad Idea that Should Be Removed If Possible, right? [16:55:38.0314] lotta people dislike it in the places it currently gets used - arrays, typed arrays, promises, regexes - but it is much less obviously a bad idea for Map and Set, even though those have no methods which use it [01:44:14.0519] 👀 does anyone know what's the status of iterator helper? 2022-03-13 [19:28:33.0647] cc Michael Ficarra; i'm not sure what's holding it back from seeking stage 3 [21:06:42.0466] the current binding constraint is the champions having time to pursue it, I am pretty sure 2022-03-14 [10:08:30.0630] ljharb: Yulia had done a lot of work on it in a time when I was very busy and couldn't follow, so she would be the best person to ask about what remains [10:09:26.0395] Right, there are a few small unresolved topics that i need to get to [10:09:57.0175] the major one is this: https://github.com/tc39/proposal-iterator-helpers/issues/122 [10:10:04.0193] i haven't had time to dig into this properly due to other priorities [10:10:13.0141] yulia: welcome back! [10:10:37.0450] Thanks [10:10:52.0887] I am happy to sit down with folks and hammer this out + update firefox's implementation to match [10:11:15.0194] the other issues in the repo, last i checked, were less significant [10:11:56.0993] I can see about getting it done by the end of the week, its been on my list for way too long [10:12:26.0563] Though, feedback / opinions would be very welcome... [10:12:47.0281] maybe, Michael Ficarra -- I summarize the proposed change, bring it to committee, and then the following meeting we try to advance? [10:13:33.0540] the following meeting isn't until June, so I think that gives us plenty of time, yes [10:26:10.0692] the issue title still confuses me, i continue to have no idea what "passing the protocol" means [10:42:41.0454] ljharb: it's just whether `return`/`throw` on an iterator produced by iterator helpers behave the same as if they were called on the original iterator [10:43:18.0128] see https://github.com/tc39/proposal-iterator-helpers/issues/122#issuecomment-909432348 [10:43:21.0343] ah k, thanks [10:43:59.0651] so like, forwarding the full iterator API (ie, return/throw)? [10:44:14.0011] yep [10:44:32.0996] it's harder to do than just making `next` work [10:44:57.0265] the unfortunate bit is that a whole class of usages only care that `next` works [10:45:59.0064] the argument against passing the full iterator api is that most of these methods are not intended to be communicating generators, and in this case does it make sense to pass return and throw [10:48:12.0720] ugh, `return` and `throw` are gross [10:52:15.0761] archival footage of TC39 adding generators to the language [10:54:30.0592] please don't besmirch the good name of shoehorns [11:00:09.0527] hm, it may get tricky in relation to the other issues like this one: https://github.com/tc39/proposal-iterator-helpers/issues/174 [11:00:17.0302] I'll do a more detailed review later this week [12:10:36.0275] Michael Ficarra: I think we were all agreed that `return` and `throw` should get forwarded and the remaining question is whether `.next` forwards its argument [12:10:52.0785] `return` needs to get forwarded so that the underlying iterator is properly closed [12:11:06.0938] (and `throw` doesn't really matter because nothing in the language calls it) [12:23:59.0786] > <@yulia:mozilla.org> hm, it may get tricky in relation to the other issues like this one: https://github.com/tc39/proposal-iterator-helpers/issues/174 Yeah I haven't had time to continue on this, and I had noticed that iterator helpers had some similar issues. Happy to chat since I did a deep dive on the return/throw behavior, especially in the erroneous cases. [12:47:52.0699] Mathieu Hofman: great, i will take you up on that [12:48:11.0284] maybe this won't make it to the end of the week, it is hairier than i remember [12:48:33.0287] but if you have time maybe we can sit down towards thursday/fri? [12:48:48.0779] or early next week [12:48:57.0250] i guess i can put a discussion item on the agenda anyway 2022-03-15 [18:00:00.0913] shu: re https://github.com/tc39/ecma262/pull/2646, did you know that TA.prototype.sort _also_ has a per-iteration detachedness check? [18:02:50.0433] it doesn't even get you anything because you have to read all of the values out of the buffer before the loop anyway, since `compareFn` can write to the buffer [04:35:29.0761] My guess is this was missed when https://github.com/tc39/ecma262/pull/1585 landed? Before es2021 the order of calls to [get] and `comparefn` was implementation defined. From es6 onwards there has always been that detached check [04:36:24.0254] * My guess is this was missed when https://github.com/tc39/ecma262/pull/1585 landed? Before es2021 the order of calls to [get] and `comparefn` was implementation defined. From es6 onwards there has always been that detached check [11:27:08.0357] bakkot: lol i did not 2022-03-16 [04:16:24.0786] I am unlikely to get anything done this week. [04:17:05.0658] ill try to post the issue for discussion though [07:40:46.0824] yulia | sick: take care and I hope you recover quickly (and please remember that almost nothing in standards is time-sensitive) [07:56:43.0027] best wishes for a speedy recovery, Yulia 2022-03-17 [10:21:14.0556] HE Shi-Jun: You had mentioned, in the ad-hoc dataflow meeting after last plenary, that you were planning to give an update on the Extensions proposal at the upcoming plenary. Are you still planning to give an update on Extensions? [10:40:30.0680] * HE Shi-Jun: You had mentioned, in the ad-hoc dataflow meeting after last plenary, that you were planning to give an update on the Extensions proposal at the upcoming plenary. Are you still planning to give an update on Extensions? (I’m planning to give an update on the bind-this/call-this and pipe operators.) 2022-03-21 [13:42:01.0463] Hello all, I've posted a request for feedback on the Reflector for the upcoming **real-life** June plenary in Austin as part of OpenJS World conference. https://github.com/tc39/Reflector/issues/423 2022-03-22 [20:33:48.0310] psyched for a nonfictional plenary [09:55:08.0824] could we add a blocking version of await, only available off the main thread [09:55:16.0580] we already have atomics.wait [09:55:28.0698] * could we add a blocking version of await, only available off the main thread [09:55:32.0090] is this a terrible idea [09:57:17.0446] the win being not worrying about red/blue functions? Or could there also be performance wins to blocking over using await mechanics ? [10:00:47.0793] bakkot: probably? [10:01:46.0968] what are the proposed semantics? remember `Atomics.wait` only gets woken up by another thread or timeout [10:01:51.0270] i don't think `await`s are like that [10:05:05.0658] IIUC we can not resolve a promise off the thread, so blocking version of `await` sounds like a deadlock. [10:06:33.0056] it doesn't have to be, but you'd have to invent a radically different set of event loop semantics [10:06:42.0873] which makes me think it is probably an infeasible idea [10:07:40.0336] * bakkot: probably a terrible idea? [15:58:46.0113] GetSuperBase makes a supposedly fallible call `? _home_.[[GetPrototypeOf]]()`, but AFAICT every [[HomeObject]] is a code-inaccessible built-in object created by either ClassDefinitionEvaluation step 14–15 or §13.2.5.4 Evaluation of |ObjectLiteral|, in either case with an infallible (and ordinary) [[GetPrototypeOf]]. Can someone check me here, providing example source text where it fails—or even where GetSuperBase observes an undefined [[HomeObject]]? MakeMethod($f, _object_) sets $f.[[HomeObject]] to _object_ and is called from only * DefineMethod with argument _object_ * MethodDefinitionEvaluation with argument _object_ MakeMethod($f, _homeObject_) sets $f.[[HomeObject]] to _object_ and is called from only * ClassFieldDefinitionEvaluation with argument _homeObject_ * ClassStaticBlockDefinitionEvaluation with argument _homeObject_ DefineMethod is called with argument _object_ from only * MethodDefinitionEvaluation with argument _object_ DefineMethod is called with argument _proto_ from only * ClassDefinitionEvaluation * for the ConstructorMethod of the class body * where _proto_ is OrdinaryObjectCreate(_protoParent_), exposed as the "prototype" property of the returned class constructor * where _protoParent_ is `null` for `extends null`, x.prototype for `extends x` where it is `null` or an object, and %Object.prototype% for missing `extends` MethodDefinitionEvaluation is called with argument _object_ from only * PropertyDefinitionEvaluation with argument _object_ * ClassElementEvaluation with argument _object_ ClassFieldDefinitionEvaluation is called with argument _object_ from only * ClassElementEvaluation with argument _object_ ClassStaticBlockDefinitionEvaluation is called with argument _object_ from only * ClassElementEvaluation with argument _object_ ClassElementEvaluation is called with argument _proto_ from only * ClassDefinitionEvaluation * for non-static class elements * where _proto_ is OrdinaryObjectCreate(_protoParent_), exposed as the "prototype" property of the returned class constructor * where _protoParent_ is `null` for `extends null`, x.prototype for `extends x` where it is `null` or an object, and %Object.prototype% for missing `extends` ClassElementEvaluation is called with argument _F_ from only * ClassDefinitionEvaluation * for static class elements * where _F_ is the returned class constructor (and subject to later prototype mutation) PropertyDefinitionEvaluation is called with argument _obj_ from only * Evaluation of |ObjectLiteral| * where _obj_ is OrdinaryObjectCreate(%Object.prototype%) * where _obj_ is returned (and subject to later prototype mutation) [16:04:21.0348] Richard Gibson: your analysis sounds right to me [16:05:43.0662] I strongly suspect there's a number of remaining cases where there's a `!` which should be a `?` [16:05:57.0158] or, I should say the non-throwy-ness sounds right; I haven't looked for how it might be `undefined` 2022-03-23 [00:44:34.0978] > <@bakkot:matrix.org> I strongly suspect there's a number of remaining cases where there's a `!` which should be a `?` might be a dumb question, but why do we even annotate uses of AOs with `?` and `!`? If the AO is fallible, then probably *every* use of it should be flagged with `?`. Flagging a use of a fallible AO with `!`, to be meaningful, would require a proof that the use of the AO in that case (or cases) can never fail. If an AO is, on the other hand, infallible, then *every* use of it should be marked with `!`. Marking a use of an infallible AO with `?` would be an editorial mistake, and flagging the use as `!` would be redundant. So the only informative case I can see is (1) fallible AO, (2) used in an infallible way [01:16:40.0990] Historically at least the ? took care of unwrapping the return value, but I'm not really sure what the state of play is these days as there has been some refactoring [04:32:04.0748] > Flagging a use of a fallible AO with !, to be meaningful, would require a proof that the use of the AO in that case (or cases) can never fail While I like the rigidity of having a proof with each assertion in the spec, that sounds easiest said than done. Maybe one day, as the spec becomes more and more machine understandable? I do think there is still value in the assertions, when reading the spec it is very help to immediately see that we believe a certain AO call will not fail. But yes this is done on trust of the spec authors [04:32:19.0233] * > Flagging a use of a fallible AO with !, to be meaningful, would require a proof that the use of the AO in that case (or cases) can never fail While I like the rigidity of having a proof with each assertion in the spec, that sounds easiest said than done. Maybe one day, as the spec becomes more and more machine understandable? I do think there is still value in the assertions, when reading the spec it is very help to immediately see that we believe a certain AO call will not fail. But yes this is done on trust of the spec authors [04:48:15.0477] It's not like removing the assertions would magically make it more correct either. 🙂 [05:59:42.0504] * > Flagging a use of a fallible AO with !, to be meaningful, would require a proof that the use of the AO in that case (or cases) can never fail While I like the rigiditysafety of having a proof with each assertion in the spec, that sounds easiest said than done. Maybe one day, as the spec becomes more and more machine understandable? I do think there is still value in the assertions, when reading the spec it is very help to immediately see that we believe a certain AO call will not fail. But yes this is done on trust of the spec authors [06:00:06.0998] * > Flagging a use of a fallible AO with !, to be meaningful, would require a proof that the use of the AO in that case (or cases) can never fail While I like the rigiditysafety of having a proof with each assertion in the spec, that sounds easier said than done. Maybe one day, as the spec becomes more and more machine understandable? I do think there is still value in the assertions, when reading the spec it is very help to immediately see that we believe a certain AO call will not fail. But yes this is done on trust of the spec authors [06:00:49.0194] * > Flagging a use of a fallible AO with !, to be meaningful, would require a proof that the use of the AO in that case (or cases) can never fail While I like the rigiditysafety of having a proof with each assertion in the spec, that sounds easier said than done. Maybe one day, as the spec becomes more and more machine understandable? I do think there is still value in the assertions, when reading the spec I have found it very helpful to immediately see that we believe a certain AO call will not fail. But yes this is done on trust of the spec authors [06:34:06.0820] Jesse: turns out there are a _lot_ of places where there is a fallible AO used in an infallible way [06:34:16.0989] that is, in fact, every use of `!` in the spec now [06:34:30.0225] (infallible AOs are not called with either `?` or `!`) [07:52:40.0397] > <@bakkot:matrix.org> or, I should say the non-throwy-ness sounds right; I haven't looked for how it might be `undefined` I came back to this today, and the only use of GetSuperBase() (step 3 of MakeSuperPropertyReference) is immediately preceded by an "_env_.HasSuperBinding() is *true*" assertion, which confirms that [[HomeObject]] is not undefined (the only location I found where it _could_ be is prevented by step 10.f of PerformEval; all others seem to be prevented by "… Contains |SuperProperty|" early errors). So GetSuperBase step 2 can be removed, and there is arbitrary flexibility between it and MakeSuperPropertyReference. [08:53:48.0414] **Reminder:** There is a request for feedback on the Reflector for the upcoming real-life June plenary in Austin as part of OpenJS World conference. Please respond by Friday 25 March. https://github.com/tc39/Reflector/issues/423 2022-03-24 [18:38:21.0538] ljharb or any other github admin: I dunno what's going on with this account but it is not... coherent; can y'all remove it? https://github.com/tc39/ecmarkup/pull/424#pullrequestreview-919612651 [18:38:46.0064] I don't know what our policy is for banning people for incoherence rather than actual CoC violations [18:38:49.0561] Not the review - github reviews can’t be moderated. I can hide the other one tho [18:39:02.0374] I meant like preventing them from commenting on tc39 repos [18:39:07.0639] oh they’re both reviews [18:39:27.0845] yeah, I could block them - but usually we don’t do that for 2 incoherent posts [18:40:09.0574] if it keeps happening I’ll be happy to do it tho [18:41:00.0888] there was also https://github.com/tc39/ecmarkup/pull/423#pullrequestreview-919592133 [18:41:10.0797] but yeah I guess may as well wait to see if there's more tomorrow [20:40:32.0587] cannot feel the hostility from the comment as a non-native speaker, maybe it's just inappropriate words from non-native speakers? [09:43:37.0860] **Reminder**: There is a request for feedback on the Reflector for the upcoming real-life June plenary in Austin as part of OpenJS World conference. Please respond by **tomorrow.** https://github.com/tc39/Reflector/issues/423 (and thanks all for the replies so far!) 2022-03-25 [12:54:17.0836] Would it be okay if, in the plenary agenda, I asked to move 15 minutes from one of my agenda items to another one of my agenda items? [12:55:59.0411] Please raise the PR now. The agenda gets adopted at the start of the meeting. [12:56:33.0252] And chairs are doing the scheduling right now. So we need the info ASAP. [12:57:43.0065] And a reminder to all delegates, if you have personal scheduling constraints, put them on the agenda ahead of time (or now). Otherwise we have very little wiggle room. [13:08:17.0084] Rob Palmer: Done, thank you. [13:18:05.0147] ljharb: Can you give magic powers to pzuraq? [14:47:18.0781] if i can find their full user id, yes :-) on mobile rn tho 2022-03-26 [17:03:41.0958] In https://github.com/tc39/proposal-decorators/issues/442#issuecomment-1079520819, Shu refers to new editorial conventions in Ecma262. Is this the recently added abstract-operation structured-data stuff, or is there anything else that’s new? [17:16:31.0962] i was specifically referring to completion reform [17:17:21.0295] we'll talk about it next week, in the meantime see https://docs.google.com/presentation/d/1h3SiBX5fGeu9RDKo88j8MSEsTe4DHtbgybhW02n5mGk/edit#slide=id.g11ede54a62a_4_0 [17:38:10.0080] if they've upgraded ecmarkup recently, it's not hard to follow the new conventions, as ecmarkup has many associated checks [17:40:27.0247] err, more like it's hard not to [18:33:15.0684] assuming you're using structured headers anyway [18:33:27.0703] with return types 2022-03-27 [12:20:17.0815] Chairs, any chance of having the "draft schedule" hackmd? 🙏 2022-03-28 [20:30:17.0137] My sincere apologies for the late notice, but I’ve opened an agenda pull request for a 1.5-hour constraint tomorrow. [21:47:51.0324] ES2022 candidate: https://github.com/tc39/Reflector/issues/424 [21:53:06.0546] Are we having the meeting tomorrow morning? I can't find the logistics anywhere: a schedule or a video link. [22:09:47.0560] usually the sign-in form is added an hour or so before the meeting, and that form's thank you page has the jitsi details [22:09:56.0057] (the draft schedule indeed doesn't seem to be up yet) [23:06:18.0745] We'll be updating the Reflector post details shortly. [01:36:23.0275] Draft schedule is nearly ready. I will say this meeting we receive a large volume of constraints, which makes catering to all folks tricky. [02:20:36.0810] Ujjwal has now prepared the draft schedule. Please see [the Reflector Post](https://github.com/tc39/Reflector/issues/420) [06:15:54.0853] Hope everyone is feeling full of energy. Plenary begins in 45mins! [06:36:49.0454] I have opened the video call. Whoever makes it through first, please say here so we know the passcode is working. [06:38:52.0640] Ok, we are confirmed good on the passcode. [06:55:05.0608] Good morning. I'm not going to be available until around noon, so if someone else from the Test262 Maintainer Group would like to give the update, that would be great! [06:58:10.0125] *** Plenary starts in 2 mins! *** 🎉 [07:20:17.0819] Rob Palmer: bterlson there's a few welcome emails waiting to be sent, eg https://github.com/tc39/Admin-and-Business/issues/209 [07:25:35.0797] is IS talking about the JSON standard [07:26:25.0784] I don't believe so [07:30:06.0520] i'm confused, isn't everything TC39 does an ecma thing? [07:30:52.0112] yulia: since we're over timebox i'll ask my question in here: my understanding was that whether to adopt the alternative copyright was a per-TC decision, not a per-spec decision [07:31:04.0142] is it in fact per-spec, and that's why we need to back to the IPR committee? [07:31:10.0598] it is a per tc request for a spec [07:31:25.0406] right, so we shouldn't need to go back to them for 262 or 404 [07:31:28.0854] err, 402 [07:31:34.0667] yeah, what waldemar's saying [07:32:42.0656] hm, ok something to clarify [07:33:52.0036] this is what happens when you go to meetings sick [07:33:55.0408] ill check the documents [07:35:50.0628] yulia: I'll check the special GA docs as well. [07:36:21.0014] thanks [07:41:59.0881] GA-2022-016 states After discussing TC39's motivation for using the alternative copyright notice there is this statement: _The IPR Ad hoc Group suggests the GA consult with Ecma Counsel and the IPR Ad Hoc Group when considering applying an Alternative Copyright Notice to any other Ecma Standards._ [07:43:42.0523] huh, so it _is_ per standard? that process could be streamlined certainly [07:45:56.0648] I should point out that ECMAScript is the specific standard talked about before the "_any other Ecma Standards_" comment. Therefore one reading of that statement is the 262 can adopt the ACN, but other standards like 402 would require consultation. [07:47:13.0861] * I should point out that ECMAScript is the specific standard talked about before the "any other Ecma Standards" comment. Therefore one reading of that statement is the 262 can adopt the ACN, but other standards like 402 would require consultation. [07:47:51.0350] * I should point out that ECMAScript is the specific standard talked about before the "_any other Ecma Standards_" comment. Therefore one reading of that statement is the 262 can adopt the ACN, but other standards like 402 would require consultation. [07:48:15.0994] I just found this as well -- yes this is what I was thinking of (sorry, still super foggy) [07:48:36.0088] * I just found this as well -- yes this is what I was thinking of [07:48:43.0148] * I just found this as well -- yes this is what I was thinking of (sorry, still super foggy)_ [07:48:45.0609] * I just found this as well -- yes this is what I was thinking of (sorry, still super foggy) [07:49:24.0046] waldemar: ^ it is in GA-2022-016 [07:49:47.0452] The problem has gone unaddressed for 5 years? [07:50:05.0025] That feels... unacceptable. [07:50:21.0116] sorry, which problem? [07:50:33.0532] not being able to get information from the IT people [07:50:59.0019] ah, yeah this is something we should solve. I am talking to someone about it [07:51:48.0006] worth noting the LF IT folks are highly responsive and have an SLA measured in days instead of years :-p [07:52:04.0413] shu: Visible with sun glasses on! [07:58:51.0376] Does ecmarkup now enforce AOs always having structured headers? [08:00:11.0271] jschoi: yes, though it does not mandate that you describe parameter types or return types [08:00:36.0189] please do so as much as possible (or at least explicitly mark unknown) so ecmarkup catches these kinds of errors [08:01:58.0346] > Does ecmarkup now enforce AOs always having structured headers? no it does not [08:02:30.0726] because "not having a structured header" is just "writing prose which happens to look like an AO" [08:03:40.0861] > <@rwaldron:matrix.org> Good morning. I'm not going to be available until around noon, so if someone else from the Test262 Maintainer Group would like to give the update, that would be great! Who will give the test262 update? [08:04:10.0352] sarahghp maybe? if rick isn't available [08:04:22.0550] yes I will do it [08:07:12.0443] ljharb: can you put the names in the notes [08:07:17.0472] I couldn't catch all of them [08:07:17.0582] re CoC: https://github.com/tc39/Reflector/issues/382#issuecomment-1029240838 [08:07:22.0699] > <@bakkot:matrix.org> ljharb: can you put the names in the notes yep! doing now [08:07:36.0482] maybe we should have somebody explicitly endorse the CoC committee candidates? [08:09:24.0973] Michael Ficarra: oh sorry, i should have mentioned that; by presenting them to plenary the CoC committee has implicitly endorsed them [08:20:42.0846] this is surprising [08:21:00.0866] I though it should work, so what I just said is wrong [08:22:21.0405] bakkot: is that really what we say about the current Realm for %name%s? [08:22:27.0249] bakkot: https://tc39.es/ecma262/#sec-well-known-intrinsic-objects isn't super clear [08:23:02.0376] i think the operative sentence is "before any code is evaluated" [08:30:28.0114] test262 relies on `@@species` in the runner? [08:31:38.0448] yes, this came up when we proposed restriction of species generally [08:31:58.0642] and i was afraid that what kevin found was related to that, to which i think the response would be -- can we do something that is test runner specific [08:32:09.0331] there are other blockers to general removal/restriction, this isn't the only one [08:32:17.0067] * there are other blockers to general removal/restriction, this isn't the only one [08:32:57.0272] this is another thing on the ever growing pile that grew ever higher while i was sick [08:33:42.0341] Michael Ficarra yulia hold on, that's not quite true. The runner does not rely on @@species. There are tests that test for @@species [08:33:55.0029] oh, i may have misremembered [08:34:15.0514] No problem, just clarifying 👍️ [08:34:29.0821] yeah, okay, that's what I would've expected [08:34:30.0996] Rick Waldron: it was a comment you made in relation to https://github.com/tc39/proposal-rm-builtin-subclassing and i think i just linked it wrong [08:34:53.0913] maybe it was related to type 2 subclassing which won't happen [08:38:36.0235] > <@yulia:mozilla.org> Rick Waldron: it was a comment you made in relation to https://github.com/tc39/proposal-rm-builtin-subclassing and i think i just linked it wrong I'm having trouble finding the discussion in the notes [08:39:29.0953] Rick Waldron: RW: So you were asking for examples of Type III. In Test262, we use Type III extensively for testing the behavior of built-ins across realms. We are heavily reliant on setting the species with a cross realm copy of the constructor to make sure the lookup chain of the constructor is preserved correctly. To make sure that the lookup chain is preserved correctly. If you look at it, I don’t want to rathole into that, we can look at it together offline. But that’s a pretty substantial example of where it’s being used in the wild. And I don’t know how else we would test cross realm behavior which is important to the language cause we have access to multiple realms in any given runtime. So I just wanted to put that on the board and say let’s chat about it offline. [08:39:45.0680] is that still true? [08:39:54.0820] maybe this changed [08:40:00.0366] Oh right, that makes sense. I was describing what we do when we test Symbol.species. [08:40:34.0868] Let check one other thing [08:40:42.0669] ok, yeah that was what i was worried kevin found [08:40:50.0673] but it wasn't fortunately [08:41:09.0355] I am super foggy today, so sorry if i am being confusing [08:41:18.0248] Ok, confirmed: we do not rely on Symbol.species in eshost or test262-harness. [08:41:40.0941] correction: Chrome never shipped and unshipped grouping because we saw this before we could ship [08:41:51.0770] Symbol.species is used in test262's harness files and tests themselves, for cross realm testing. That could be changed. [08:42:43.0827] > <@rwaldron:matrix.org> Ok, confirmed: we do not rely on Symbol.species in eshost or test262-harness. sweet! [08:43:07.0369] > <@rwaldron:matrix.org> Symbol.species is used in test262's harness files and tests themselves, for cross realm testing. That could be changed. ok, cool , this is what i thought and expressed poorly [08:43:29.0988] I think I may have expressed it poorly myself [08:44:02.0458] if we don't know what versions the websites use, can't we just do a functional test? [08:44:26.0177] My description above explain how its being used in the wild, but wasn't clear at which level [08:45:09.0764] groupedByTo doesn't compute in my brain [08:46:07.0222] yeah it feels bad [08:47:54.0262] groupMap [08:48:39.0743] groupedXX series sounds like what the array change by copy proposal is doing [08:49:23.0908] we could also go with `Object.group` and `Map.group` /ducks [08:50:23.0601] sadness [08:50:47.0547] i liked `groupBy` [08:51:04.0180] as much as i think it makes sense on Array.prototype, that does make the naming simpler, and opens up `Set.group` and friends in the future. i also prefer `groupBy` :-/ [08:51:15.0151] I feel like we gave up on `groupBy` way too easily, personally [08:52:11.0317] i mean, someone could still go evangelize [08:53:04.0103] As long as we don’t break Roll20 😉 [08:57:43.0538] I'm more worried about all the `.gov.br` sites [08:57:49.0232] breaking government services seems bad [08:57:56.0642] though I didn't actually check what they're hosting [09:00:21.0413] Facetious wink. 👆 [09:35:00.0386] I'm gonna verify I can project to the jitsi in one sec [09:35:49.0718] okay, looks good [09:35:56.0811] can someone verify? [09:36:24.0542] it works [09:37:02.0217] cool, thanks [09:42:51.0576] Are we starting again on the hour? [09:44:05.0777] yep! [09:45:09.0363] Really cool topics being discussed this afternoon! [09:46:04.0450] What are the reasons Promise.resolve(promise) consults promise.constructor for promises that pass the brand check? It would be useful for us in the hardened JavaScript community if Promise.resolve(promise) could be guaranteed to give control to the provider of the promise only in subsequent events. [09:46:53.0582] does it subclass? [09:47:19.0370] * What are the reasons Promise.resolve(promise) consults promise.constructor for promises that pass the brand check? It would be useful for us at Agoric if Promise.resolve(promise) could be guaranteed to give control to the provider of the promise only in subsequent events. [09:48:13.0283] I believe Promise was one of the first proposals to account for Symbol.species, so I assume so, but also assume that’s not useful. [09:48:48.0516] * What are the reasons Promise.resolve(promise) consults promise.constructor for promises that pass the brand check? It would be useful for us in the hardened JavaScript community if Promise.resolve(promise) could be guaranteed to give control to the provider of the promise only in subsequent events. [09:50:38.0966] ``` class P2 extends Promise {} let x = P2.resolve(1); P2.resolve(x) === x; Promise.resolve(x) !== x; ``` [09:50:42.0963] Maybe because of that? [09:50:52.0183] I should probably check the spec instead of guessing... [09:51:55.0223] That story checks out. [09:54:00.0396] that is almost certainly the reason, yes [09:54:07.0429] subclassing: it's bad [09:55:42.0556] In a way this is good news. That means that in a SES proposal, we can change the behavior of `Promise.resolve()` such that subclassing no longer works, but our delegation invariant is preserved (after the host program opts-in by calling `lockdown()`) [09:56:08.0292] * In a way this is good news. That means that in a SES proposal, we can change the behavior of `Promise.resolve()` such that subclassing no longer works, but our delegation invariant is preserved (after the host program opts-in by calling `lockdown()`) [09:56:32.0713] We start in 4 mins! [10:03:22.0009] why does this proposal allow `default`, instead of just `when(unused)`? [10:03:38.0481] or even just a bare `when {`, to go with `catch {` [10:04:13.0255] it allows either, but not both [10:04:16.0168] * it allows either, but not both [10:04:30.0351] we could use a bare `when` instead of `default`, sure, that's just bikeshedding [10:04:51.0759] but `when (unused)` has to be allowed for consistency with the way irrefutable patterns work [10:05:03.0510] TIL 0 can have a sign [10:05:16.0163] is there anyplace else in JavaScript where these sematics hold? [10:05:22.0948] ryzokuken: which? [10:05:45.0174] `0` matching both `+0` and `-0` [10:05:45.0432] I have no problem with `when (unused)`, I just don't see a use for `default` if you already have that [10:05:48.0926] * I have no problem with `when (unused)`, I just don't see a use for `default` if you already have that [10:05:49.0369] * `0` matching both `+0` and `-0` [10:05:52.0899] yes, `0 === -0` [10:05:56.0278] `===` [10:05:59.0289] * yes, `0 === -0` [10:06:00.0373] also sets and maps [10:06:08.0046] ah, okay, thanks [10:06:31.0611] bakkot: the use is that it's confusing and gross to have to write a binding when you don't want one, and `when {` i'd argue doesn't convey that it's the "everything else" category very clearly. [10:06:35.0869] does `match(expr) { if (bool): expr }` mean matching against constant bools? [10:06:56.0396] legendecas: against an expression that resolves to a truthy or falsy value, yes [10:06:59.0286] like any other `if` [10:07:25.0597] also what's the use case for the bare `if` one [10:07:27.0788] it seems like [10:07:29.0279] not so useful [10:07:44.0284] I have a hard time seeing a case where you don't also need to name the match-ee [10:07:46.0260] > <@ljharb:matrix.org> like any other `if` thank you. well, in the context of slides, i'm confused that why it isn't `match(expr) { if(expr): expr }` [10:07:46.0396] it's cleaner than `when (unused) if (condition)` [10:07:48.0069] > <@ljharb:matrix.org> yes, `0 === -0` Wrt differences between +0 and -0, `1/-0 === -Infinity` vs `1/0 === Infinity`. [10:07:54.0715] ljharb: does that ever happen [10:07:59.0428] > <@legendecas:matrix.org> thank you. well, in the context of slides, i'm confused that why it isn't `match(expr) { if(expr): expr }` yeah fair, it's a confusing example [10:08:05.0573] bakkot: yes, there's examples in the readme. [10:08:43.0836] > <@ljharb:matrix.org> yeah fair, it's a confusing example looks like this part is not in the spec, yet. [10:08:59.0180] so to match an array with holes I'd need to do `[undefined, undefined, "foo"]`? [10:09:00.0406] legendecas: most things aren't in the spec; it's only going for stage 2, where only an initial spec is required. [10:09:03.0504] the readme is what you want [10:09:10.0701] ljharb: the example in the readme is `match (res) { if (isEmpty(res))` but that's still naming the matchee [10:09:12.0512] > <@usharma:igalia.com> so to match an array with holes I'd need to do `[undefined, undefined, "foo"]`? or `[,, 'foo']`, yes [10:09:14.0478] it's just repeating the expression [10:09:15.0404] seems bad [10:09:24.0790] why? [10:09:36.0314] i see what you mean, that a bare `if` would still need to reference the matchable [10:09:58.0631] but why would it be bad to not be forced to create a new binding just to reference it, via `when (res) if (isEmpty(res))`? [10:10:21.0693] > <@bakkot:matrix.org> I have no problem with `when (unused)`, I just don't see a use for `default` if you already have that yeah. `default` just make it easier to read [10:10:22.0790] I'd just write `when (_) if (whatever)` [10:10:25.0651] so you don't have to learn a new form [10:10:38.0000] or `default if (whatever)`, maybe [10:10:41.0018] having to write the underscore is gross [10:10:55.0116] and `default` has to be last - it'd be confusing to have `default if` be allowed all over the place [10:11:17.0321] hm [10:11:19.0480] not sure I agree [10:11:34.0695] having a bare `when` would be alright, but then you have `when {` and `when if (x) {` and that reads odd to me [10:11:48.0799] > <@bakkot:matrix.org> also what's the use case for the bare `if` one `if (isSomethingWeWant(expr)): ` an escape path when pattern is not expressive enough and you want to do a complex check [10:11:49.0455] maybe actually the thing I want is to be able to bind the name in the `match (e)` part [10:11:53.0836] `match (e as x)`, maybe [10:11:59.0167] you can, just like that. specifically so you can name the matchable when it's complex expression [10:12:05.0957] imo `default` is also nice because it's a structure that feels not dissimilar from other uses of `default` in the language [10:12:13.0387] * you can, just like that. specifically so you can name the matchable when it's complex expression [10:12:13.0453] wait, then there should not be `when (identifier)` [10:12:26.0142] it falls out of the ability to do `when ([identifier])` [10:12:29.0943] that's just `match (e as x) default` [10:12:34.0738] what's the case for `when (unused) {}` [10:12:40.0708] an irrefutable pattern works everywhere, and not being able to use it at the top-level is an inconsistency [10:12:45.0000] not in the video call atm [10:12:57.0656] > <@devsnek:matrix.org> what's the case for `when (unused) {}` like switch `default`, or an "else" - it's the last uber-catch-all match clause. [10:13:04.0834] not being able to mix irrefutable patterns and a default is also inconsistent [10:13:07.0258] but that's fine [10:13:12.0651] oh right [10:13:15.0434] its when not match [10:13:16.0574] I prefer the inconsistency of not allowing both `match (e as x)` and `when(x)` [10:13:18.0525] i am caught up now [10:13:22.0012] you can, with `when (foo)` as the last clause [10:13:27.0847] i think eliding makes sense [10:13:36.0172] `when {}` [10:14:26.0259] `when {` is a reasonable alternative spelling for `default {`, and that can and should be bikeshedded during stage 2 [10:14:31.0107] > <@bakkot:matrix.org> I'd just write `when (_) if (whatever)` yeah `when(_) if (expr)` give you a temporally binding of the matched expression when it is not a simple identifier. 👀 this is an interesting case [10:14:32.0402] * `when {` is a reasonable alternative spelling for `default {`, and that can and should be bikeshedded during stage 2 [10:15:31.0203] oh god are we going to have both `Symbol.match` and `Symbol.matcher` [10:15:35.0545] `Symbol.match` was a mistake [10:15:40.0014] are these slides on the protocol new? I didn't see these [10:15:47.0649] > <@bakkot:matrix.org> `Symbol.match` was a mistake yes it was [10:15:50.0604] > <@bakkot:matrix.org> `match (e as x)`, maybe we have that in previous design. we think it's useful but can also be added in the future `match (e) as x {}` [10:15:55.0956] > <@bakkot:matrix.org> oh god are we going to have both `Symbol.match` and `Symbol.matcher` happy to bikeshed the symbol name; the overlap sucks [10:16:31.0369] > <@jackworks:matrix.org> we have that in previous design. we think it's useful but can also be added in the future `match (e) as x {}` i think we have `match (e) as x {` in the current proposal (or maybe `match (e as x) {`, i forget which we agreed on) [10:16:47.0244] excited for us to say Symbol.matcher was a mistake in 6 years [10:17:26.0347] > <@devsnek:matrix.org> excited for us to say Symbol.matcher was a mistake in 6 years Symbol.match [10:17:44.0241] `Symbol.decons` [10:18:05.0120] do any of the built-in prototypes implement the matcher protocol? [10:18:17.0161] > <@bakkot:matrix.org> oh god are we going to have both `Symbol.match` and `Symbol.matcher` 😂 yeah and we cannot bikeshedding on this because people will always try `Symbol.match` whatever we named `Symbol.matcher` to [10:18:25.0661] I dislike this brand checking part more than any other part of the proposal [10:18:27.0396] > <@michaelficarra:matrix.org> do any of the built-in prototypes implement the matcher protocol? imo many of them will, as part of this proposal [10:18:32.0544] per this slide [10:18:43.0698] these are constructors, not prototypes [10:18:47.0850] ljharb: that's on the constructor, not prototype [10:18:56.0561] oh sorry [10:19:03.0228] no, i wouldn't expect builtin prototypes to have it [10:19:06.0955] * no, i wouldn't expect builtin prototypes to have it [10:19:10.0941] do you have something in mind? [10:19:20.0004] yeah, what if I put a regexp in there? [10:19:28.0830] I claim `and` and `or` have an obvious precedence relationship [10:19:33.0308] or at least a very well-precedented one [10:19:37.0681] ah right. yes, regexes definitely do implement it (with the same logic the literal patterns apply) [10:19:54.0461] where do I find the information on what does and what doesn't? [10:19:55.0657] > <@michaelficarra:matrix.org> yeah, what if I put a regexp in there? * ah right. yes, regexes definitely do implement it (with the same logic the literal patterns apply) [10:20:03.0379] in theory it's all in the readme [10:20:17.0919] during stage 2 it'll all end up in the spec [10:20:47.0996] > <@bakkot:matrix.org> `Symbol.decons` If we take rbuckton 's unapply proposal to replace the custom matcher ```js const Some(x) = val match (val) { when (Some(x)): x } ``` and we first teach people this feature in the deconstructing instead of pattern matching, we can be a little confortable than let people figuring out `match` vs `matcher` which is the symbol they need🤔 [10:21:05.0428] Michael Ficarra: https://github.com/tc39/proposal-pattern-matching#regex-pattern is the literal pattern; https://github.com/tc39/proposal-pattern-matching#bindings-from-regex-patterns-with-named-capture-groups says "Regexes (both literals and references inside interpolation patterns) implement the custom matcher protocol" [10:21:19.0874] wait, are these actually _stacked_ bindings [10:21:27.0962] like if I leak one with an arrow in a `${}` does that refer to the outer one [10:21:35.0021] * like if I leak one with an arrow in a `${}` does that refer to the outer one [10:22:20.0884] after `match ([0, 1, 2]) when `([a, ${(probe = () => a, 1)}, a]) {}`: if I call `probe`, does it see `0` or `1` [10:22:41.0544] ljharb: okay that answers the question for `RegExp.prototype`, am I to assume that no other built-in prototypes implement it? [10:22:48.0570] yes, if you have others in mind, please file an issue [10:22:59.0365] * yes, if you have others in mind, please file an issue [10:24:00.0479] hmm Isn't tagged template pattern are banned? [10:24:10.0358] ```js when (tag`x`): expr ``` [10:24:16.0932] i remember this is invalid [10:24:18.0097] currently yes [10:25:34.0074] bindings should be reusable across `or` alternatives, definitely [10:25:48.0177] but that does not mean they need to be reusable not across `or` alternatives [10:27:37.0730] related: https://github.com/bakkot/proposal-duplicate-named-capturing-groups [10:35:12.0509] calling this "initial spec text" is somewhat generous [10:35:39.0855] our bar for initial spec text is historically VERY low, and I'm okay with that [10:35:53.0699] as long as the explainer is fleshed out enough, of course [10:35:54.0357] I think it is higher than this [10:36:20.0895] the process document is very not clear on this [10:36:27.0850] if there's a higher bar then it should be codified there. [10:36:32.0813] https://github.com/tc39/proposal-pattern-matching/pull/251 NOTE: Part 1 (adding interpolation pattern back to deconstruction) is NOT a nececssary part of the proposal [10:36:50.0398] we've talked about it in plenary before and opted not to set a minimum [10:38:19.0942] waldemar: reviewing spec text isn't necessary for stage 2. it's necessary for stage 3. [10:38:29.0114] ljharb shu TabAtkins I think we can have a direction to achieve consensus for the current direction this proposal is leading towards and come back in the next meeting with the spec draft updated. [10:38:48.0222] setting the direction is not exactly a stage advancement but we can agree with the current direction, right? [10:39:05.0459] sure. and the process issue waldemar is bringing up is only really relevant if that's the only potential "blocker" for stage 2 [10:39:10.0400] I oppose asking the champions to write complete spec text for this proposal before it reaches stage 2 [10:39:18.0488] * https://github.com/tc39/proposal-pattern-matching/pull/251 NOTE: Part 1 (adding interpolation pattern back to deconstruction) is NOT a nececssary part of the proposal [10:39:25.0738] i don't think complete spec text is being asked for [10:39:28.0047] the explainer is detailed enough [10:39:51.0373] i think there's value in the exercise of writing out a grammar for a very syntax-heavy proposal [10:40:00.0159] the fact that it hasn't been done is a fair objection imo [10:40:40.0486] I also still have open questions about things, but they will not torpedo the proposal, so they can be figured out during stage 2 [10:41:05.0721] if you think the general direction of the proposal is wrong, fair, object to advancement [10:41:15.0589] but details are meant to be figured out and codified during stage 2 [10:41:31.0169] i also reject the notion that "initial spec text" means any text document that's published as a spec draft [10:41:35.0067] > <@shuyuguo:matrix.org> i think there's value in the exercise of writing out a grammar for a very syntax-heavy proposal yeah we have a spec syntax PR 😂 i think it's already covered the current shape of proposal [10:41:57.0610] it should've been merged for general review before the plenary, then? [10:42:08.0861] > <@shuyuguo:matrix.org> i also reject the notion that "initial spec text" means any text document that's published as a spec draft i agree with that. i think the current text still somewhat applies - it's just the parts inside `match (…) { … }` that need lots of work [10:42:34.0397] hax is talking about: he think ```when (${String} with s): expr``` to check if it is a string is wordy [10:42:34.0447] maybe it doesn't feel "enough" for some, but applying vague adhoc requirements seems undesirable compared to having more specific wording in the process doc [10:42:42.0639] part of the pushback i'm hearing is that there's no sensible intermediate state to have an initial spec text that's not a complete grammar working out [10:42:43.0869] * hax is talking about: he think ```when (${String} with s): expr``` to check if it is a string is wordy [10:42:46.0096] I think it's fair to have minimal matching specs. People can consume the proposal by the explainer, other people do it better from the specs, as waldemar pointed out. I might disagree with the heated parts, but asking for some basic specs seems pretty fair and I'd stick to that committed to present something at the next TC39 meeting. [10:42:47.0220] Jack Works: I think if your PR landed that would definitely meet the bar [10:42:49.0908] but I didn't know to look for it [10:42:51.0471] i also don't think that's true, but it might be in this particular case? [10:42:59.0910] > <@jackworks:matrix.org> hax is talking about: > > he think > > ```when (${String} with s): expr``` to check if it is a string is wordy to check if something's a string you'd do `if (typeof x === 'string')`, no? [10:43:21.0086] leobalter: no, the point is that explainers are precisely *not* substitutes for specs [10:43:40.0731] `when (x) if (typeof x === 'string')` is the obvious way to write this [10:43:46.0932] (this particular thing) [10:43:47.0627] > <@ljharb:matrix.org> to check if something's a string you'd do `if (typeof x === 'string')`, no? oh yeah, it's another case for bare `if` 😂 [10:44:06.0431] shu: I agree with that, my opinion is that both explainer and specs should have some minimal content for everyone to understand the direction for Stage 2. [10:44:13.0210] it's not a use for bare `if` because you need to refer to the match-ee [10:44:14.0635] One doesn't replace the other [10:44:20.0443] which requires you to name the thing being matched [10:44:23.0039] > <@bakkot:matrix.org> `when (x) if (typeof x === 'string')` is the obvious way to write this but it's more wordy than `when (${String} with x)` [10:44:28.0359] > <@bakkot:matrix.org> it's not a use for bare `if` because you need to refer to the match-ee `when (blah) as S {` lets you refer to it [10:44:32.0565] Jack Works: but less clear [10:44:44.0805] this is a good reason to not allow the `when (${String} with x)` [10:44:53.0374] which I also want to get rid of for other reasons [10:45:14.0567] @ljharb: Process requires "all major semantics, syntax and API are covered, but TODOs, placeholders and editorial issues are expected" for entry to stage 2. Process also states that changes during stage 2 are expected to be incremental. [10:45:16.0790] `when (${String} and x)` is shorter :-p [10:45:23.0845] Can `when (${String} with x)` match String wrapper object? [10:45:39.0588] waldemar: that column describes the spec quality WITHIN stage 2, not for entering it. the only cell on the stage 2 row that applies to proposals *entering* stage 2 is "Entrance Criteria" [10:45:46.0024] * waldemar: that column describes the spec quality WITHIN stage 2, not for entering it. [10:46:11.0181] `if (typeof x === 'string')` is very clear that it can not match string wrapper object [10:46:23.0659] * waldemar: that column describes the spec quality WITHIN stage 2, not for entering it. the only cell on the stage 2 row that applies to proposals *entering* stage 2 is "Entrance Criteria" [10:46:30.0165] > <@legendecas:matrix.org> Can `when (${String} with x)` match String wrapper object? yes. [10:46:59.0344] ljharb: I have to disagree. My understanding is that fundamental spec quality should also match entrance for Stage 2. [10:47:04.0762] > <@legendecas:matrix.org> Can `when (${String} with x)` match String wrapper object? Yes [10:47:20.0810] > <@leobalter:matrix.org> ljharb: I have to disagree. My understanding is that fundamental spec quality should also match entrance for Stage 2. then the process document should be refined; thats not the bar i've seen previous proposals held to. [10:47:28.0810] ljharb: The entrance criteria require a spec text, and the spec quality column describes the quality of that spec text. [10:48:23.0381] yeah [10:48:28.0023] stage 3 requires complete text [10:48:29.0241] ljharb waldemar we may schedule a proper venue to discuss this. I don't think this chat will be super productive. We have to agree there is a diversity in interpretations here. [10:48:33.0670] that's not something you do during stage 3 [10:49:02.0014] bakkot: I believe @waldemar is never saying complete spec text. [10:49:22.0201] i can certainly see that interpretation - that "spec quality" is an entrance criteria. but that's not how i read it, or have read it in the past, nor is it clear to me from the table. [10:49:26.0540] leobalter: sorry, I was just saying I agree with waldemar's intepretation of the "spec quality" column [10:49:33.0185] I think some are just misreading the process document. [10:49:45.0582] if that's what we all want, maybe we should add some clarification to the "entrance criteria" cell so it references the "spec quality" cell [10:49:56.0587] which is that stage 3 requires "Complete: all semantics, syntax and API are completely described", which means that stage 2 requires "Draft: all major semantics, syntax and API are covered, but TODOs, placeholders and editorial issues are expected" [10:50:02.0355] leo, this isn't about a diversity of interpretations, i think it's just misreading? [10:50:06.0309] waldemar: if we interpret the document differently, one has to be wrong. [10:50:37.0175] yes, and what bakkot said has to be correct [10:50:49.0242] unless we have disagreement that stage 3 can be obtained without a complete spec text, which i really hope not [10:50:59.0238] shu: I read basic specs as entrance criteria for Stage 2, not only as a expectancy for during Stage 2 [10:51:33.0848] and I'd be supportive for all proposals to go through the same criteria. [10:51:41.0759] we have accepted thorough explainer docs as "spec text" for stage 2 many times in the past [10:51:52.0460] have we? [10:52:04.0121] and for something that is super syntax heavy? [10:52:10.0362] like if it's for one array method, sure [10:52:14.0562] with a pseudocode implementation, even [10:52:24.0150] for something this big, probably not. but for multiple things, certainly [10:52:35.0476] few proposals are as big as this one, so I don't know what your bar is [10:53:32.0573] i have said my bar: for syntax-heavy proposals, major syntax should be spelled out in the spec text, which it isn't currently because it's in an unmerged PR [10:54:04.0527] shu: fair, at least that gives the champions clear guidance on expectations [10:54:04.0874] array grouping had fairly complete text at stage 2: https://github.com/tc39/proposal-array-grouping/blob/6c1e6880eeb58a2f2cae3a0763c884821f730893/spec.emu [10:54:13.0951] I'm trying to think of other examples [10:54:21.0938] where there might not have been [10:54:24.0266] tbf API proposals are the easiest ones to make complete spec text for [10:54:37.0323] please stop with the "complete" strawperson [10:54:43.0005] nobody is asking for complete for entrance to stage 2 [10:54:49.0125] oh i don't mean that's what's being asked for [10:55:06.0416] i'm saying that API proposals are much easier to hit even the stage *3* requirement, far earlier [10:55:09.0808] re: ysv's point, I definitely like having large proposals like this presented multiple times before we agree to the major semantics [10:55:12.0416] temporal did that IIRC [10:55:17.0539] though, maybe that was during stage 2 [10:55:37.0966] yeah, that was at a later stage [10:56:15.0403] I think this is a good discussion to have, but I do want to say that to demand that Tab put the stub spec text up on the screen for it to be criticized, is both a waste of committee time, and condescending towards the champions. I think that kind of thing is not befitting of a healthy collaboration in the committee [10:58:07.0359] i feel like there are benefits to both sides, but we are running into issues with the fear that -- if we don't get everything in then we will have classes again (or, maybe i misunderstood -- do you mean, this should be shown multiple times before advancement to grok all the details? with this i agree) [10:58:24.0531] hax's meaning: he think `if` is `else if`, and is not the necessary part of MVP [10:58:47.0795] > <@bakkot:matrix.org> re: ysv's point, I definitely like having large proposals like this presented multiple times before we agree to the major semantics * i feel like there are benefits to both sides, but we are running into issues with the fear that -- if we don't get everything in then we will have classes again (or, maybe i misunderstood -- do you mean, this should be shown multiple times before advancement to grok all the details? with this i agree) [10:58:48.0728] and he think `when (_) if (expr)` can replace the bare if [10:59:05.0939] yulia: the spicy take is that this is a committee, we're not going to get cohesive big ideas through [10:59:25.0415] as you know, i am a fan of process ;) [10:59:37.0077] we're going to get things that hopefully aren't too far off course from what any individual delegate's cohesive big idea is [10:59:45.0891] > <@jackworks:matrix.org> and he think `when (_) if (expr)` can replace the bare if it totally can. it's just that then you're forcing people to type that extra boilerplate when they don't conceptually need it [10:59:53.0239] OK my last concern for short: [11:00:09.0701] I prefer an alternative syntax for the custom matcher. Current: ```js when (${Some} with x): expr when (${None}): expr ``` rbuckton 's unapply ```js when (Some(x)): expr when (None()): expr // also works in deconstruction const RGB(r, g, b) = "#001234" ``` [11:00:15.0020] > <@shuyuguo:matrix.org> we're going to get things that hopefully aren't too far off course from what any individual delegate's cohesive big idea is so, my thinking is -- we could do what class fields did, which is that it had several proposals that eventually were merged [11:00:24.0374] > or, maybe i misunderstood -- do you mean, this should be shown multiple times before advancement to grok all the details? with this i agree that is the thing I mean, yes [11:00:29.0421] but do this more intentionally [11:00:44.0186] I don't have a problem with large proposals if they are presented a few times, so we have time to think about the whole thing [11:00:51.0587] and talk about all the details [11:01:07.0014] yulia: that might work, sure. the biggest hurdle i think is to get enough of committee continuity, well beyond just the champion group, to have the whole space be paged in [11:01:13.0447] yeah also, splitting it up is just a mechanism for doing precisely that -- but splitting it up also makes parts of it optional which may not be optional (so, why not introduce a construct for that) [11:01:18.0660] yes, I agree with yulia; or rather, I could live with an epic-type approach [11:01:19.0347] pattern matching and decorators as our first 2 proposal topics? time constraints must've been rough this time around [11:01:33.0871] though I would still rather my own weird simple + wacky breakdown :D [11:01:36.0410] > <@michaelficarra:matrix.org> pattern matching and decorators as our first 2 proposal topics? time constraints must've been rough this time around decorator is for stage 3 [11:01:42.0668] * yeah also, splitting it up is just a mechanism for doing precisely that -- but splitting it up also makes parts of it optional which may not be optional (so, why not introduce a construct for that) [11:01:49.0967] TabAtkins: just to say, because everyone including me was talking about their concerns (which is reasonable), I think pattern matching as presented is pretty rad [11:01:57.0656] Jack Works: decorators is 9th in order on the agenda though lol [11:02:04.0871] I have quibbles with details but do support the proposal [11:02:56.0321] I support the current decorator proposal, but the metadata part is sus and need more discussion [11:03:05.0457] yulia: because at the end of the day, as people have said before, we're mostly volunteering our time here, and the biggest problem is unless we're in the champion group, people are paging in a lot of stuff at possibly multi-month intervals. and unless you're already super sold on the motivation, that kind of working mode is going to prime you against large proposals [11:03:13.0630] > <@jackworks:matrix.org> I support the current decorator proposal, but the metadata part is sus and need more discussion same, also some concerns about the accessor keyword [11:03:22.0165] how would "epics" help this? genuinely asking, no idea what those are [11:03:38.0030] > <@bakkot:matrix.org> also what's the use case for the bare `if` one I'ts a minor case, but sometimes when figuring out how to produce a given value, you in fact don't need to worry about the structure of the matchable. [11:04:13.0656] > <@yulia:mozilla.org> same, also some concerns about the accessor keyword they say the `accessor` keyword is necessary and not blocking the future extension of the Grouping accessor proposal so I guess it is ok for me [11:04:17.0909] TabAtkins: that use case doesn't seem worth its own syntactic form, I guess is my feeling [11:04:26.0397] > <@shuyuguo:matrix.org> how would "epics" help this? genuinely asking, no idea what those are often, when something like temporal has been presented i found myself checking out because i didn't have focus for the whole proposal. if we had a process that was like. Here is the big proposal and what it is trying to do, and it is composed of these parts. we are talking about part 1, which has it's own design concerns -- i would find this easier to think about [11:04:28.0117] * TabAtkins: that use case doesn't seem worth its own syntactic form, I guess is my feeling [11:04:32.0605] If it required more than just "don't put the when()" in, I'd agree. [11:04:50.0037] yulia: okay i see. i support that [11:05:07.0463] > <@jackworks:matrix.org> they say the `accessor` keyword is necessary and not blocking the future extension of the Grouping accessor proposal so I guess it is ok for me yeah we were looking into the requirements there, we will have a discussion with that. I think Iain may have posted an issue (lemme check) [11:05:09.0539] But requiring `when (_) if(something)` is awkward when the shorter syntax form is *right there* and totally unambiguous [11:05:21.0332] that's fair [11:05:25.0102] > <@yulia:mozilla.org> often, when something like temporal has been presented i found myself checking out because i didn't have focus for the whole proposal. if we had a process that was like. Here is the big proposal and what it is trying to do, and it is composed of these parts. we are talking about part 1, which has it's own design concerns -- i would find this easier to think about I think such a process change would be really useful, thanks [11:05:38.0397] (so what's the "epic" part referring to?) [11:05:52.0799] the epic is the overall feature (like pattern matching) [11:06:00.0061] "this is useful for dependency injection" produces in me an immediate "kill it with fire" reaction [11:06:05.0928] perhaps that is not everyone's reaction to dependency injection [11:06:26.0470] we can say that, when a proposal is large and consists of many components, but they cannot be broken up without compromising the goal of the proposal, it should be treated as an epic (or maybe we can call it a modular proposal or whatever) [11:06:26.0893] it's certainly my reaction too [11:06:31.0365] it usually is, but my first reaction is always "what is dependency injection again" [11:06:32.0374] * it's certainly my reaction too [11:06:40.0942] function arguments, but implicit and magic [11:06:41.0336] and when i re-learn it as argument passing, then your reaction is my following one [11:06:50.0173] > <@ljharb:matrix.org> i think we have `match (e) as x {` in the current proposal (or maybe `match (e as x) {`, i forget which we agreed on) Nah we dropped the `as x` stuff entirely, in favor of using `x and ...` matchers. [11:07:51.0721] TabAtkins: ok so my feeling is that it would be very useful to bind the name at the top level of the match, because otherwise there's going to be a bunch of `match (expr) when (x) if (f(x)) ...; when (x) if (g(x)) ...;` etc [11:08:14.0774] * TabAtkins: ok so my feeling is that it would be very useful to bind the name at the top level of the match, because otherwise there's going to be a bunch of `match (expr) when (x) if (f(x)) ...; when (x) if (g(x)) ...;` etc [11:08:34.0554] maybe do-exprs are the fix for that though [11:08:42.0390] > <@bakkot:matrix.org> I claim `and` and `or` have an obvious precedence relationship I know the &&/|| precedence is *well-established*, I strongly object that it's *obvious*; I've been programming for 20 years and I still always parenthesize when I'm mixing those, because I never remember what the precedence is. [11:08:43.0654] `do { let x = expr; match(x) {...} }` [11:08:54.0562] so for the decorator, I guess the `metadata` part will be the hardest push at this meeting, maybe they will seek a conditional advancement (once the metadata problem is resolved, it will automatically advance to stage 3)? [11:09:00.0779] TabAtkins: that's fair but I stand by "well precedented" [11:09:03.0385] yulia: Reading through old issues I found this, which convinced me that there are good reasons for `accessor` to exist as a keyword (instead of making decorated fields into accessors by default): https://github.com/tc39/proposal-decorators/issues/348#issuecomment-736889352 [11:09:13.0951] people who don't know the relationship are already going to be struggling with the `&&` and `||` cases [11:09:22.0475] people who do are going to be annoyed every single time they use `and` with `or` [11:09:32.0307] which is why common linter rules/styleguides force parens around mixed && and ||, because it's so frequently confusing [11:09:37.0897] * which is why common linter rules/styleguides force parens around mixed && and ||, because it's so frequently confusing [11:09:44.0990] > <@iain:mozilla.org> yulia: Reading through old issues I found this, which convinced me that there are good reasons for `accessor` to exist as a keyword (instead of making decorated fields into accessors by default): https://github.com/tc39/proposal-decorators/issues/348#issuecomment-736889352 oh, great! thanks -- that comment is retracted then [11:09:51.0471] i was just going to ask [11:10:25.0835] > <@tabatkins:matrix.org> I know the &&/|| precedence is *well-established*, I strongly object that it's *obvious*; I've been programming for 20 years and I still always parenthesize when I'm mixing those, because I never remember what the precedence is. do you use unnecessary parentheses when mixing +/- with * in arithmetic expressions, too? [11:11:10.0158] yes, always. there's a linter rule for that too. [11:11:14.0962] yeah, same [11:11:29.0078] helps human brains if not machine ones and it's free! [11:11:37.0479] ljharb: there's also a linter rule to remove them 😉 [11:11:41.0882] that rule would be completely intolerable if it weren't auto-fixable [11:11:49.0920] I'm not going to write `a + (x * y)` by hand [11:12:07.0962] but making it a syntax error to write `x and y or z` means that I am forced to [11:12:17.0804] because eslint won't parse it [11:12:24.0408] seems like this is _very_ a case for linters [11:13:04.0673] that's why i exclusively use number of spaces to signal precedence [11:13:17.0469] `a + x*y` [11:13:25.0440] :D [11:14:26.0815] Can we just introduce the Polish notation to JS? https://en.wikipedia.org/wiki/Polish_notation#Explanation [11:14:33.0417] like, I agree that it can be a good idea to make these things an error in the absence of a well-precedented thing that many (not all) people will already know - but there is that, in this case [11:14:44.0912] > <@bakkot:matrix.org> TabAtkins: ok so my feeling is that it would be very useful to bind the name at the top level of the match, because otherwise there's going to be a bunch of `match (expr) when (x) if (f(x)) ...; when (x) if (g(x)) ...;` etc That's possible! Grammar's open to that, it was just killed as part of a general "remove the `as x renaming facility now that we have `and`. Could be brought back in for the matchable in the head specifically. Feel free to open an issue. [11:14:58.0128] nicolo-ribaudo: perhaps you'd like to propose `Math.add`, `Math.multiply`, etc? [11:15:03.0765] oops sorry this isn't TDZ [11:15:16.0609] Whops I thought I was in TDZ too [11:15:20.0333] we should have those, in seriousness though [11:15:31.0712] ngl agree [11:15:35.0036] * Whops I thought I was in TDZ too [11:15:47.0198] TDZ to proposal pipeline [11:16:32.0529] > <@michaelficarra:matrix.org> do you use unnecessary parentheses when mixing +/- with * in arithmetic expressions, too? No, +- and */ have a precedence relationship matching the precedence rules taught in math class since I was a little kid. (That said, I still often use spacing to make it clear - `foo*bar + baz`, and still parenthesize if the expr is large enough that spacing clues aren't sufficient.) [11:16:58.0024] What's `-x ** 2` again? [11:17:04.0591] sorry, not TDZ [11:17:14.0770] (I can think of a lot of beginners who would feel comfortable with the explicit language of a method, and who having those methods would help make more comfortable with syntax like `Array.isArray()` or `Object.hasOwn()`) [11:17:19.0375] TabAtkins: I know you know this, but in many ways `and` is `*` and `or` is `+`, so why is that hard to remember? [11:17:36.0880] for those who had opinions on the "spec quality" stuff, please share your thoughts https://github.com/tc39/process-document/pull/35 [11:17:37.0526] danielrosenwasser: that one is not well-precedented [11:17:51.0382] or rather, there are conflicting precedents [11:17:53.0647] That correspondence is very "college-level abstract math", not "elementar-school arithmetic"; they're entirely different [11:23:25.0709] Can't there be a placeholder for the class given to decorators, and a way to link the placeholder to the class after definition ? [11:24:42.0671] i'm sure it could get a symbol. but then how do you symbolicate (unsymbolicate?) it later? [11:25:14.0866] "angular wants this" is _so_ far from being compelling to me [11:25:33.0285] Unless we have symbols as WeakMap keys, I'd want an empty object [11:26:22.0551] having an object placeholder that wasn't frozen would be pretty weird [11:26:37.0022] And maybe "unsymbolicating" could be done as a class decorator ran last, that does get access to the final class and the placeholder, but without replacing the class [11:27:29.0195] aka an `@metadata class Foo {}` [11:28:03.0845] either way tho, then you have N + 1 identities to manage [11:28:30.0322] sidebar: anyone know what millions-of-downloads dependency injection framework was being referenced? [11:28:34.0386] I can't find any offhand [11:28:55.0375] shu: I confirm what Chris said about TS and Babel usage. LWC is TS based but uses the Babel impl. of Decorators [11:29:10.0030] * shu: I confirm what Chris said about TS and Babel usage. LWC is TS based but uses the Babel impl. of Decorators [11:29:36.0053] > "angular wants this" is so far from being compelling to me opposite of compelling really! [11:29:46.0225] and also angular wouldn't care about standard decorators as i said [11:30:09.0514] LWC -> Salesforce's Lightning Web Components. [11:31:20.0503] bakkot: the reply here points to something called Inversify: https://github.com/tc39/proposal-decorators/issues/442#issuecomment-1079544675 [11:31:39.0239] why do people love dependency injection though [11:33:19.0993] So I don't use DI, but I have consistently seen code editors rely on DI as their pattern for extensibility and even core functionality [11:33:26.0120] * So I don't use DI, but I have consistently seen code editors rely on DI as their pattern for extensibility and even core functionality [11:33:26.0421] Bonus [11:33:58.0368] setting the prototype without calling the constructor is very weird, yeah [11:33:58.0863] Basically "we only need one extension instance to be loaded ever, and it can happen at any time" [11:34:08.0896] Jack Works: good one [11:34:32.0195] VS Code uses it, and VS does (different language), and _I think_ Eclipse might have as well (also different language) [11:34:48.0238] * VS Code uses it, and VS does (different language), and _I think_ Eclipse might have as well (also different language) [11:36:11.0087] why we're having subclassing ArrayBuffer at the first time anyway, it does not expose any API to access the internal data structure (need to use the view) and extending cannot do anything useful (excepts exploits the browser) [11:36:14.0007] * VS Code uses it, and VS does (written in a different language), and _I think_ Eclipse might have as well (also different language) [11:37:54.0401] Jack Works: we're gonna have a whoooooole long discussion about subclassing builtins later this meeting! [11:39:58.0070] Jack Works: yeah, great question! [11:41:52.0687] I too would like to see motivation for metadata other than DI before advancing metadata [11:42:02.0595] I have some motivation for metadata in https://github.com/tc39/proposal-decorators/issues/441 [11:42:57.0154] wait [11:43:19.0588] "bubble"? [11:43:22.0635] or did i mishear [11:43:22.0638] I've never seen a proposal that had more venues for developer feedback than decorators [11:43:23.0794] babel [11:43:27.0286] ah, sorry [11:43:31.0455] thought it was a new toolchain [11:46:32.0936] > <@leobalter:matrix.org> I've never seen a proposal that had more venues for developer feedback than decorators but it's for the old version [11:46:36.0078] 🤔 [11:46:59.0320] we had this specific proposal presented here before this meeting, announcing the intention for Stage 3 [11:47:14.0782] right, but decorator _consumption_ is largely the same [11:47:18.0918] > <@jackworks:matrix.org> but it's for the old version * right, but decorator _consumption_ is largely the same [11:47:25.0334] the majority of the changes are for decorator authors [11:48:09.0658] I think this version of the proposal is over a year old? [11:48:15.0473] * I think this version of the proposal is over a year old? [11:48:27.0841] there have been minor changes but i think dan presented this redesign a while ago [11:49:20.0409] here is how I would write class-level metadata for decorators without explicit support: ``` let { decorate, finalize } = makeDecorator(); class A { @decorate property = whatever; } finalize(A); ``` where `makeDecorator` is a userland function that has an internal WeakMap or whatever. it's two extra lines. does this do the thing you want metadata to do? [11:49:31.0478] seeing "old proposal" in context of decorators is very scary 😅 good to see its still a function [11:49:41.0291] oh [11:49:54.0484] we have 10 minutes extra [11:50:03.0518] should we continue to pattern matching? [11:50:50.0431] pzuraq: i can help you make the repo for the metadata part, DM me to coordinate [11:52:10.0881] * we have 8 minutes extra [11:52:56.0383] if the decorator doesn't get access to the class, what is the WeakMap key? [11:53:04.0919] * if the decorator doesn't get access to the class, what is the WeakMap key? [11:53:10.0960] ljharb shu yulia so we consider Decorators - Metadata a Stage 3? [11:53:17.0915] ptomato: `finalize(A)` passes in the class [11:53:25.0105] contingent stage 3 on for the split [11:53:32.0419] * contingent stage 3 on for the split [11:53:32.0732] and the `decorate` and `finalize` functions are paired [11:53:57.0958] > <@bakkot:matrix.org> here is how I would write class-level metadata for decorators without explicit support: > > ``` > let { decorate, finalize } = makeDecorator(); > class A { > @decorate > property = whatever; > } > finalize(A); > ``` > > where `makeDecorator` is a userland function that has an internal WeakMap or whatever. it's two extra lines. does this do the thing you want metadata to do? Similar to what I proposed here a long time ago: https://github.com/tc39/proposal-decorators/issues/328#issuecomment-694240970 [12:08:17.0723] oh, or even ``` let { decorate, decorated } = makeDecorator(); @decorated class A { @decorate property = whatever; } ``` since class decorators get access to the class in `addInitializer`, as `this` [12:12:28.0195] so for the gnome use case linked above it would look like ``` let { registerClass, property } = GObject(); @registerClass class MyClass { @property({ type: Boolean }) x = false; } ``` where the `@property` decorator would stash the necessary fieldname->type mapping somewhere where the `@registerClass` decorator could get at it [12:14:40.0636] for composing decorators, there isn't a built-in util for that right? [12:15:09.0866] if someone already had a class-level decorator, and then a field-level one only worked if combined with it's class-level helper [12:15:23.0940] I don't think it has any built-in utils? [12:15:57.0030] true, no new namespace [12:17:13.0155] > <@bakkot:matrix.org> so for the gnome use case linked above it would look like > > ``` > let { registerClass, property } = GObject(); > > @registerClass > class MyClass { > @property({ type: Boolean }) > x = false; > } > ``` > > where the `@property` decorator would stash the necessary fieldname->type mapping somewhere where the `@registerClass` decorator could get at it I see, thanks. in practice though, I'd probably just not make a `makeDecorator()` style API if I knew metadata was likely to be coming and would enable a better API. I'd end up having to maintain them both [12:19:48.0197] That's reasonable, yes [12:20:04.0613] I remain unconvinced by the need for metadata, especially if this pattern actually does work the way I think it should [12:20:19.0312] I haven't written the implementation of the `makeDecorator` thing to confirm it does [12:20:28.0456] yeah, i remain most directionally comfortable with doing metadata all in userland [12:20:39.0512] bakkot: metadata seems particularly necessary for parameter decorators, which are another future extension [12:20:42.0373] i understand the "we need something to key off of" expressivity gap now, which i kept missing for a long time [12:20:51.0805] pzuraq: I am dead set against parameter decorators [12:20:52.0599] it's unclear that parameter decorators would do anything _besides_ add metadata [12:20:53.0410] i am... not very supportive of parameter decorators right now [12:21:01.0944] good to know [12:21:04.0384] given i've only seen it used for DI in angular and it looked awful [12:21:50.0336] primary use case does seem to be DI for them, I generally agree I prefer field based DI myself [12:22:10.0382] pzuraq: and great work, lots of sweat and tears! [12:22:18.0114] wait, doesn't `addInitializer` also provide you access to the class as `this` [12:22:28.0544] `addInitializer` for elements [12:22:32.0295] initializers run for every instance [12:22:38.0929] oh, right [12:22:47.0875] so it wouldn't really be a good place for adding/manipulating metadata [12:22:50.0241] you _could_ idempotently re-add metadata each instance creation [12:22:50.0541] yeah [12:23:03.0309] that's a pro move called "it's the library's problem, not the engine's" [12:23:07.0417] shu: that only works if you don't need the metadata before instance construction though [12:23:09.0671] lol [12:23:20.0243] bakkot: good point [12:23:20.0253] yeah, there's also that [12:23:28.0631] I have use cases for parameters decorators, that would need to couple with a method decorator [12:24:14.0136] And it's not a DI use case, but a shape / type validator use case [12:24:38.0030] that is another major use case for metadata [12:24:44.0590] validation libs in general [12:25:00.0101] you can do it with `accessor`, but then you have overhead for every property access [12:25:29.0272] and usually, you want to do the validation once at specific points in time (e.g. when you go to serialize) [12:25:32.0772] oh, serialization is another use case [12:25:44.0355] I believe a number of Node ORMs use decorators this way [12:26:10.0178] really there are a ton of use cases, I just thought DI was the most motivating one 😅 [12:26:43.0739] I don't see how accessor helps here. I want to validate before the code of the method runs so it can rely on the args being the right thing [12:27:02.0933] `accessor` helps for other forms of validation, not the one you're discussing [12:27:17.0052] e.g. "this field is a number" type validations [12:28:21.0239] there's two forms of decorator validation libraries out there, one which installs getters/setters to validate, and the other which adds metadata and then asks you to call `validate()` whenever you want to validate [12:35:07.0160] yulia: Would you consider the holistic dataflow discussions we’ve been having lately a TC39 “epic” about a broad feature? [12:35:10.0101] * yulia: Would you consider the holistic dataflow discussions we’ve been having lately a TC39 “epic” about a broad feature? [12:36:46.0281] Also to everyone: I’ve finished writing my updated material for the holistic dataflow redux discussion, scheduled at the end of this plenary. Please take a look if you are interested in the pipe operator, the bind/call-this operator, Extensions, PFA syntax, ecosystem schism, or the like: https://jschoi.org/22/es-dataflow/ [12:36:52.0669] * Also to everyone: I’ve finished writing my updated material for the holistic dataflow redux discussion, scheduled at the end of this plenary. Please take a look if you are interested in the pipe operator, the bind/call-this operator, Extensions, PFA syntax, ecosystem schism, or the like: https://jschoi.org/22/es-dataflow/ [12:36:53.0679] > <@shuyuguo:matrix.org> bakkot: is that really what we say about the current Realm for %name%s? it could be more explicit, but I think "it refers to the one from the current realm" is the only thing it could possibly mean? [12:38:03.0177] bakkot: i know it intuitively to be true, it just took me multiple readings of the paragraph i linked to get that reading i think [12:38:44.0721] oh wait, it is explicit actually: > Within this specification a reference such as %name% means the intrinsic object, associated with the current realm, corresponding to the name. [12:38:53.0695] "associated with the current realm" being the relevant part [12:40:00.0278] bakkot: right, but Mark's question was the meaning of current: current at time of execution, or current for the parse node [12:40:06.0263] and i don't think that is clear from the paragraph [12:40:15.0531] * and i don't think that is clear from the paragraph [12:40:28.0707] those are the same thing [12:41:26.0059] they are? huh, i guess so, we don't have a way to preparse for execution elsewhere [12:41:29.0624] see https://tc39.es/ecma262/multipage/ordinary-and-exotic-objects-behaviours.html#sec-prepareforordinarycall step 4/5: 4. Let calleeRealm be F.[[Realm]]. 5. Set the Realm of calleeContext to calleeRealm. [12:44:53.0732] the pre-parse then execute elsewhere observation is interesting for module blocks [13:45:36.0579] Unfortunately, I'm unable to attend plenary this week. I wish I were able to be present to argue for Metadata's inclusion for Stage 3 decorators. Requiring an entangled decorator pair (one for class, one for member) is over complex and highly unmanageable. [13:53:41.0102] There are many Metadata-only use cases. A compiler may want to emit Metadata and needs a consistent way to do so that works for both modules *and* scripts (and thus cannot depend on dynamically injecting an `import`). [13:54:04.0033] * There are many Metadata-only use cases. A compiler may want to emit Metadata and needs a consistent way to do so that works for both modules *and* scripts (and thus cannot depend on dynamically injecting an `import`). [13:56:47.0700] And as mentioned, there are many non-DI use cases: RTTI, ORM, controlling serialization (binary/json/etc.) [13:59:54.0533] Built-in support for Metadata is more important for now than the earlier Stage 1 version due to the restrictions imposed on the latest proposal (lack of ctor/proto access) [14:11:31.0383] * Built-in support for Metadata is more important now than the earlier Stage 1 version due to the restrictions imposed on the latest proposal (lack of ctor/proto access) [14:12:21.0769] > <@jschoi:matrix.org> yulia: Would you consider the holistic dataflow discussions we’ve been having lately a TC39 “epic” about a broad feature? I would consider it a broader design question, which maybe is more about vision. the different proposals target different problems. I am thinking of epics as proposals composed of interlinked components, where minmaxing will result in a poorer solution to the overall problem, but the components are separate enough that they should be considered independently and designed both independently and together. [14:14:00.0554] I’m still thinking how we might do that but i need to look again how this has failed in different ways. Split proposals don’t work, and I don’t think mega proposals are working either [14:15:14.0597] /me listens, while preparing to present a mega proposal tomorrow [14:15:46.0538] I think focus groups worked well for temporal [14:17:30.0714] But in many ways, it is simpler, it follows an established pattern for APIs [14:17:39.0073] Mega-proposals like the regex features proposal had significant pushback, but splitting them has caused a huge maintainability issue. [14:17:47.0326] It was the algorithm that was a question and we all agree that date time was an issue [14:18:36.0390] For Regex, one issue was that the problem of the overall proposal didn’t tie them together. The proposals are largely independent [14:18:55.0717] My only qualm with Temporal is how hard it is to use for its main purpose (date arithmetic, specifically relational comparison). [14:19:29.0693] Though, as I say this, all of this has degrees of relatedness [14:20:10.0371] `Temporal.Instant.compare(inst, Temporal.Now.instant()) > 0` is not a win, imo [14:20:12.0056] And it might be some of the regex proposals are more related than others [14:21:06.0491] > <@rbuckton:matrix.org> My only qualm with Temporal is how hard it is to use for its main purpose (date arithmetic, specifically relational comparison). Is this the lack of `isEarlier`/`isLater` APIs? Or concerns about how `compare` can return `0` for values where `equals` will return `false`? [14:21:42.0366] If the former, there's a clear path to add those APIs in a follow-up proposal. [14:22:02.0513] Quite a few are related in the "Why do we need A when we can have B" in both proposals A and B, leading to neither advancing when they're complementary proposals [14:23:12.0394] FYI, here's the "more comparison methods" issue for the Temporal V2 repo: https://github.com/js-temporal/proposal-temporal-v2/issues/6 [14:24:18.0040] I do think that Temporal's size did make it difficult for most delegates to go any deeper than superficial without investing tons of time [14:24:48.0302] `A.isEarlier(B)` is a bit harder to conceptualize than `A < B`, imo. And is very English-focused vs. `compareTo`. [14:25:45.0449] > <@rbuckton:matrix.org> `A.isEarlier(B)` is a bit harder to conceptualize than `A < B`, imo. And is very English-focused vs. `compareTo`. That's great feedback that you might want to add to https://github.com/js-temporal/proposal-temporal-v2/issues/6. 😄 [14:26:06.0923] `compareTo` you learn once and let math take care of the rest. A non-native-English speaker might need to refer to which is which (earlier/later) [14:26:55.0138] The same way I have to look up the difference between co- and contra-variant frequently and I work on a compiler with generics [14:31:40.0369] > <@rbuckton:matrix.org> Unfortunately, I'm unable to attend plenary this week. I wish I were able to be present to argue for Metadata's inclusion for Stage 3 decorators. Requiring an entangled decorator pair (one for class, one for member) is over complex and highly unmanageable. say more? it does not seem particularly complex or unmanageable to me, so far [14:33:27.0566] It does for a large number of disparate uses, your class becomes cluttered with a number of `@register`-like decorators for each use case. [14:34:01.0177] Is it common to have classes which use lots of different metadata-attaching decorators? [14:34:10.0244] from different libraries, that is [14:34:44.0637] Consider if I use an ORM (i.e. MikroORM) and a Json serializer to translate a complex object to a Rest endpoint [14:36:29.0367] wouldn't those both already have a class-level `register` decorator? [14:36:51.0398] That's already two separate "registers", and I could see more if your object interacts with multiple systems [14:39:08.0100] I've worked with systems that need to interact with different services in a similar fashion. This would quickly become untenable. [14:40:18.0047] I'd like to chat more, but really can't until next week. [14:44:11.0870] I'll open an issue. [14:54:53.0572] https://github.com/tc39/proposal-decorators/issues/455 [15:00:35.0396] bakkot: my concerns would be the same as rbuckton, that overlapping metadata would require multiple registers which could get confusing [15:00:58.0738] I am currently updating the proposal README to include an example like this however, specifically to showcase `access` [15:05:01.0826] > <@pzura:matrix.org> bakkot: my concerns would be the same as rbuckton, that overlapping metadata would require multiple registers which could get confusing And unless a *single* userland library is the *only* Metadata library, it could become even more complex to interoperate [15:05:56.0528] So either everyone rolls their own Metadata (which is a lot of wasted effort), or there are userland conflicts. Neither is a win [15:08:05.0988] if you want to have an explicit extension point for other people to get at your metadata, you can just add a symbol-named method to the class and then everyone can integrate with that [15:08:13.0680] there's no need for a central coordination point [15:09:01.0999] well they have to agree to use your method [15:09:07.0035] that's coordination [15:09:08.0407] metadata from someone else's decorator is only useful to you if you know its shape anyway [15:09:12.0179] which implies coordination [15:09:15.0380] you can't not have coordination [15:09:24.0919] Given the ecosystem around TS decorators as precedent, I disagree. And that only works because there really was only *one* Metadata library [15:10:06.0672] Which thing are you disagreeing with? [15:13:12.0587] bakkot: it's not about sharing _your_ metadata, it's two separate systems both using metadata [15:13:28.0151] thus both requiring their own `@register` decorator [15:13:48.0768] or, some way to coordinate around having only a single `@register` decorator [15:15:17.0348] I agree that, in the particular case where you didn't have a class-level decorator but were just adding metadata to individual fields, my design is more onerous in that it also requires a class-level decorator [15:15:26.0237] I don't understand the relevance of there being multiple systems here, though [15:15:33.0044] except that now you need two class-level decorators [15:15:40.0174] which... does not seem so high a cost to me? [15:16:15.0821] also the examples discussed so far (for metadata) all seemed like they'd have class-level decorators anyway [15:16:31.0737] it seems like a high cost when each decorator would generally not require a class level decorator [15:16:33.0102] * also the examples discussed so far (for metadata) all seemed like they'd have class-level decorators anyway [15:16:37.0341] so far none of them do? [15:16:44.0642] the gnome one did? [15:18:02.0435] I guess not all possible DI ones do [15:18:07.0948] though some designs would [15:18:20.0064] anyway, I stand by "requiring an additional class-level decorator does not seem like so high a cost to me" [15:18:34.0742] certainly not a high enough cost to justify this entire additional system being built into the language [15:19:06.0345] what if we go a much simpler route? [15:20:46.0112] the proposal as its stands is pretty complex, admittedly [15:21:09.0224] but really all we need is a sidechannel, similar to the one you've demonstrated [15:21:12.0654] simpler features are always an easier sell, but the burdern of the design I've discussed - _if_ it really is as simple as it looks to me - does not seem high enough to warrant any additional features in the language, personally [15:21:53.0655] I worry that it'll be a common footgun to forget applying the class decorator [15:22:07.0608] and there's not really an easy way to let users know that they haven't done so [15:22:33.0626] the simpler version of the feature would be to just have `addMetadata`, which would then add the metadata to an array on `Symbol.metadata` [15:23:00.0947] that I dislike for other reasons [15:23:02.0056] does that seem like too much of a burden compared to the improvement in DX we would get from adding it? [15:23:21.0862] I'm not convinced that would be an improvement in DX at all, really [15:23:25.0383] > <@pzura:matrix.org> but really all we need is a sidechannel, similar to the one you've demonstrated I believe all we need is for the decorators to receive a "context" allowing them to tie the decoration to the class [15:23:35.0290] since now all the decorators are fighting over that space [15:23:50.0235] they would not be fighting over it [15:24:06.0740] all metadata would be additive, and it would be trivial to mark your metadata separate from other metadata [15:24:12.0391] using a WeakSet or WeakMap [15:24:27.0536] Mathieu Hofman: that is another option, yes [15:24:45.0023] are Symbols as WeakMap keys a thing yet? It could just be a Symbol [15:24:57.0867] also, wait, the class decorator is passed the class, right? [15:25:07.0293] bakkot: yes [15:25:12.0321] but if not, it could be an object [15:25:32.0815] Yeah if we had symbol as weakmap keys, a symbol would work. Or a frozen object with no prop or proto. [15:27:50.0959] Actually a frozen object might be more interesting, as then you could use the proto chain to link nested contexts (see my comments on bakkot's issue above). In particular, the proto of this "context" object for a future arguments decorator could be the context object of the class/object on which the method is defined. [15:30:40.0505] ugh, there may be forward compatibility issues with that [15:31:03.0623] yeah I think if we went the more simple route that would be adding more complexity than necessary [15:43:56.0349] when a field decorator returns an initializer function, that initializer is invoked with the instances as `this`? [15:45:12.0675] so can't you just... ``` function inject(injectionKey) { return (_, context) => function(v) { if (!Object.hasOwn(this, INJECTIONS)) { this[INJECTIONS] = []; } this[INJECTIONS].push({ injectionKey, set: context.set }); return v; }; } ``` [15:49:29.0736] This would mean you need to inject field Metadata differently than method Metadata. This is becoming arbitrarily complex. [15:49:57.0993] you already do need that, because field metadata is associated with instances and method metadata is associated with the class, surely? [15:50:46.0994] Also my design here is strictly simpler than the DI example in the readme [15:50:55.0553] I wrote out the whole thing: https://github.com/tc39/proposal-decorators/issues/455#issuecomment-1081227211 [15:57:01.0351] I may be totally ignorant here (have not been following the proposal for very long), but what about a `context.metadata` property that is initialized to an empty object, and is then subsequently available on the class instance as `instance[Symbol.metadata]`? Users could add metadata like this: ```js const symbol = Symbol("my lib symbol"); function decorate(x, ctx) { ctx.metadata[symbol] = 'stuff'; return x; } class Foo { @decorate bar() {} } const f = new Foo(); console.log(f[Symbol.metadata][symbol]); // stuff ``` I don't know if this solves the actual concerns though. From what I understood, folks didn't like the `setMetadata` and `getMetadata` API. With a plain metadata object these "special" get and set methods go away. [15:57:22.0178] I guess "associated with the instance" is kind of wrong; rather, it's associated with the class prototype, if I'm reading this right [15:57:42.0271] oh right, yeah in this case it would be associated with the prototype [15:59:40.0490] but that doesn't change the general idea of using a plain object has the metadata holder rather than constructing that in the background via the `context.setMetadata` method [16:00:14.0572] the example stays the same, even if the metadata is actually a property on `Foo.prototype` rather than on the `f` instance [16:21:50.0004] > <@pzura:matrix.org> it seems like a high cost when each decorator would generally not require a class level decorator coming back to this: fundamentally I guess it just does not seem like a high cost to require a class-level decorator to add information to the class itself. maybe I'm missing something, and it would in fact be really painful in practice, but right now Im' not seeing it. [16:25:12.0884] I don't know what to say except that I am seeing it, personally [16:25:29.0527] especially given that the simpler version of this API really wouldn't add much complexity to the language at all [16:25:50.0203] > <@lucacasonato:matrix.org> but that doesn't change the general idea of using a plain object has the metadata holder rather than constructing that in the background via the `context.setMetadata` method Something like `context.setMetadata` isn't easily transpiled [16:26:27.0851] (unless it sets something on the class like the proposed `Symbol.metadata`) [16:27:34.0540] right, that was also the API that folks didn't seem to like. Would a plain `context.metadata` object be easier to transpile? [16:28:37.0963] the object would still need to be added to the target on `Symbol.metadata` [16:28:42.0552] IIRC that was the approach in the proposal. It's a design the champion and stakeholders have discussed for multiple years to meet those design goals. [16:28:44.0288] * the object would still need to be added to the target on `Symbol.metadata` [16:29:08.0532] > <@rbuckton:matrix.org> IIRC that was the approach in the proposal. It's a design the champion and stakeholders have discussed for multiple years to meet those design goals. What was presented today has a `context.setMetadata` and `context.getMetadata` API. [16:30:03.0403] My apologies, I'm OOF and wasn't able to attend plenary. [16:30:18.0538] No worries :-) [16:31:39.0015] The biggest problem with downleveling get/setMetadata is the size of the helper needed downlevel, as long as the end result is addressable via something like `Symbol.metadata` [16:33:17.0713] Anything stored on the function of a method/accessor would be a non-starter as it would complicate every replacement decorator (in order to maintain the Metadata). The constructor or prototype is the only (mostly) reliable place. [16:34:22.0672] Storing it on the instance for fields is also a non-starter since it would require construction to perform introspection, which is bad for DI and ORM scenarios [16:35:20.0033] to clarify, you could potentially place metadata related to a method on `Symbol.metadata` on the final method itself [16:35:22.0775] i.e., an ORM may need to know about circularities in the Object Model to optimize queries [16:35:27.0217] but you can't put it on the method function passed to the decorator [16:35:43.0326] because that requires each decorator to pass the metadata forward [16:36:12.0264] only clarifying because that is one avenue that's being discussed, as it would make future extensions (e.g. function/parameter decorators) more consistent potentially [16:36:31.0919] but it seems like there's strong pushback against parameter decorators so.... [16:36:33.0484] > <@pzura:matrix.org> to clarify, you could potentially place metadata related to a method on `Symbol.metadata` on the final method itself That overcomplicates the accessor vs field problem [16:36:54.0416] Plus any differentiation with future function decorators [16:38:55.0612] I agree it does overcomplicate those problems, but I'm not sure where parameter decorator metadata fits in otherwise [16:39:04.0150] I suppose we could just flatten that down onto the class [16:39:14.0793] but it becomes hard to figure out which parameter relates to which function [16:39:37.0324] need to pass in something to key off of [16:39:58.0875] if parameter decorators run _after_ method decorators it becomes possible, you pass in the final method that the parameters are applied to [16:42:36.0011] i still think the answer to where parameter decorators fit in is that we do not have parameter decorators [16:46:09.0724] totally valid opinion to have, but until we can say that definitively I would like to design in a way which does not preclude them [16:47:24.0467] that said, I think metadata for existing agreed upon decorators is much more important, and would definitely prioritize a simpler API that can get consensus over one that leaves room for param decorators [16:52:48.0658] so i've read all the backlog [16:52:51.0779] and the github thread [16:53:17.0832] do i understand correctly the main pushback against bakkot's sketched solution is DX burden? [16:54:29.0099] I would say that's the main pushback, yes [16:58:01.0322] Secondary pushback would be cases where metadata does want to be shared between multiple libs [16:58:17.0360] But that is less common [16:58:57.0679] it's fine for a thing to be possible but onerous; the question remains why a thing that's possible but onerous meets the bar for language inclusion [16:59:18.0318] arguments like "this is work all metadata producers have to do" as jordan has said seems to assume there are a lot of metadata producers [16:59:19.0223] are there? [16:59:27.0941] for a few frameworks to bear the burden seems... okay? [16:59:53.0963] * arguments like "this is work all metadata producers have to do" as jordan has said seems to assume there are a lot of metadata producers 2022-03-29 [17:00:04.0424] There were more frameworks and libraries that used metadata than not in our survey, IIRC [17:00:28.0307] let me put another way, if a burden is placed on all the libraries in the JS universe, that still seems okay [17:00:45.0302] vs, a burden put on a majority of all JS programmers [17:01:25.0245] Fair enough, this would only be a burden on users of those specific frameworks and libraries [17:01:37.0792] my proposed sketch has a (slight) cost to anyone making use of such a library, to be clear, not just to the library itself [17:01:45.0701] good point, i'm trying to weigh that [17:01:48.0117] (it's actually arguably simpler for the library itself) [17:01:53.0044] the `let GObject = makeGObject()` thing? [17:01:57.0300] yup [17:02:09.0034] and the need to put a decorator on the class itself, in the case that need did not previously exist [17:02:37.0410] my experience, as someone whose day job is not using frameworks, to be clear, is that frameworks involve incantations already [17:02:47.0076] this could be a death-by-a-thousand-cuts thing, of course [17:03:06.0143] Yeah, I wouldn’t think it’d be much of a burden either way tbh [17:03:10.0174] For decorator authors [17:03:10.0517] i'm also not against a simpler metadata sketched solution [17:03:45.0997] v8's main dislike is the intricate hierarchy of the metadata object that's created [17:05:07.0605] perhaps Mathieu Hofman can sketch out what he meant by having an object [17:05:37.0254] There's an old sketch here: https://github.com/tc39/proposal-decorators/issues/328 [17:05:41.0626] > <@shuyuguo:matrix.org> i still think the answer to where parameter decorators fit in is that we do not have parameter decorators The way TS does parameter decorators today is it passes through a `__param` decorator on the method that essentially adapts it to a method decorator, so Metadata is still associated with the class [17:07:00.0770] > <@rbuckton:matrix.org> The way TS does parameter decorators today is it passes through a `__param` decorator on the method that essentially adapts it to a method decorator, so Metadata is still associated with the class They way we've thought about it is that your decorating the declaration, not the value. Decorating a method parameter means the decoration is associated with the class [17:07:25.0744] Essentially the object handle version is to replicate the old semantics, where we received the class itself, as close as possible. So to do that, we pass in a target object to the decorator [17:07:45.0812] And then we associate that with the class on `Symbol.metadata` [17:08:15.0591] The object can be used as a WeakMap key to the decorator’s metadata [17:08:24.0054] rbuckton: i am not interested in the mechanics of it until we decide it's actually a good idea? [17:08:41.0665] That’d be simplest possible API here, though it’s a bit odd [17:09:21.0367] I would feel better about it if Symbols could be used as weakmap keys, and then we can just pass in a symbol, call it `metadataKey` [17:09:33.0374] But a frozen object also works [17:09:57.0400] or rather, until fairly strong opposition to the mere idea of parameter decorators fade away, not necessarily we all decide it's a good idea [17:10:12.0257] > <@shuyuguo:matrix.org> rbuckton: i am not interested in the mechanics of it until we decide it's actually a good idea? There are more than a few large projects using TS parameter decorators, so there is definite interest [17:10:38.0613] VS Code is one of them [17:11:34.0537] "people use this feature in another language" is not very compelling, on its own? there's a lot of C programs doing raw pointer arithmetic but we sure aren't gonna add that to JS [17:11:42.0159] agree [17:11:45.0941] though i do want pointer arithmetic [17:11:55.0984] VSCode is a TS project? [17:12:24.0045] > <@pzura:matrix.org> That’d be simplest possible API here, though it’s a bit odd I think the _simplest_ API for metadata is to have an associated object which lives on the `context`, which is created per class definition, and which is passed to every decorator within the class. if a decorator _wants_ to expose the metadata to the class, a class-level decorator add a symbol to the class which exposes the context object. [17:12:25.0783] > <@pzura:matrix.org> VSCode is a TS project? Yes [17:12:46.0456] Sorry, I meant in response to the assertion about other languages [17:13:02.0539] Like, these are JS/TS examples [17:13:03.0638] That’s something of an understatement, is it not, since TS and VS Code both originate in the same lab? [17:13:16.0661] Unless I missed something [17:13:22.0714] > <@kriskowal:matrix.org> That’s something of an understatement, is it not, since TS and VS Code both originate in the same lab? The same, very large company. Not the same lab. [17:13:30.0617] Ah. [17:13:39.0711] TS with decorators is a different language from JS [17:14:10.0054] since there's nontrivial runtime stuff going on [17:14:21.0318] > <@bakkot:matrix.org> I think the _simplest_ API for metadata is to have an associated object which lives on the `context`, which is created per class definition, and which is passed to every decorator within the class. if a decorator _wants_ to expose the metadata to the class, a class-level decorator add a symbol to the class which exposes the context object. I meant the simplest API in which decorators don’t need to invent their own sidechannels, and which prevents excessive burden on a decent subset of JS devs [17:15:01.0887] we have pretty divergent personal understandings of "decent subset" i think [17:15:25.0554] I'm not sure what you mean by "invent their own sidechannels"? [17:15:41.0191] and the "excessive burden" is just the need to use a class-level decorator, I think? [17:15:59.0903] not even the `GObject = makeGObject()` bit, with that design [17:16:58.0011] i would be fine with the "stand-in associated object" design, at first blush [17:18:01.0361] > <@shuyuguo:matrix.org> we have pretty divergent personal understandings of "decent subset" i think I would defer to you there, I think I have less experience with the ecosystem as a whole. Also FWIW I'm no longer using or working on a framework that relies on decorators directly, so I have somewhat less insight these days [17:18:31.0669] also, a meta-comment about using large projects as existence proofs for the desirability of a new feature. my opinion here is that if that feature is about new expressivity, i.e. making something impossible today possible, i then find that existence proof very compelling. if that feature is instead about ergonomics, then i don't find that existence proof very compelling [17:18:59.0110] there's of course a lot of nuance [17:19:12.0282] where some things are so difficult and so unergonomic it borders on impossible, like e.g. shipping ICU data to do localization [17:19:28.0129] > <@bakkot:matrix.org> not even the `GObject = makeGObject()` bit, with that design Most decorator libraries don't have you create a decorator inline like that, so that would be part of the extra burden [17:19:47.0434] would be nice if you could somehow have that be part of the import statement. Maybe you could do it with top level await? [17:19:48.0097] well what kevin was saying the stand-in object design wouldn't even require that [17:19:50.0279] so there's no burden there [17:20:41.0356] stand-in-object design? Did I miss that somewhere? [17:21:29.0316] that's what i'm calling this: [17:21:38.0199] > <@bakkot:matrix.org> I think the _simplest_ API for metadata is to have an associated object which lives on the `context`, which is created per class definition, and which is passed to every decorator within the class. if a decorator _wants_ to expose the metadata to the class, a class-level decorator add a symbol to the class which exposes the context object. ^ [17:22:05.0556] gotta run for today, see you all tomorrow [17:22:25.0636] that design is only a slight tweak from the design where the associated object is automatically placed on the class's `Symbol.metadata` field [17:22:37.0437] I am mostly just spitballing with that, to be clear [17:22:50.0524] I'm sorry, I did the thing where I didn't read the whole thing before responding 🤦‍♂️ [17:23:32.0190] I guess I don't have a fundamental objection to the design where you automatically stick the associated object on `Symbol.metadata` [17:23:42.0715] that's roughly as simple, really [17:24:39.0877] and arguably better, if the associated object is frozen and so only usable as a weakmap key [17:25:23.0459] I do think that would be better than `GObject = makeGObject()`, that's what I meant by inventing their own sidechannels [17:25:25.0989] (because weakmaps don't have the problem where decorators from different libraries might contend for the string-key space on the associated object) [17:25:35.0478] same [17:26:38.0999] that was always something that didn't sit completely right with me about the Symbol-key-based metadata design [17:26:54.0337] what was? [17:27:45.0142] that symbols were used to key/associate metadata. It avoided the collision problem, but it just felt not as nice as using weakmaps [17:27:55.0722] habits I guess, I use weakmaps a _lot_ in framework/library dev [17:27:59.0808] ah [17:28:00.0761] * habits I guess, I use weakmaps a _lot_ in framework/library dev [17:28:04.0833] I actually like symbols better personally [17:29:01.0984] but it does make it very strange that other decorators get to see your data by default [17:29:06.0547] like, that's just weird [17:29:26.0302] if you [a decorator author] are using metadata to coordinate with yourself, you are probably not also intending to create a public API, but you inherently are, by accident [17:29:41.0976] and you have to work hard to make it not-public [17:29:56.0742] * if you [a decorator author] are using metadata to coordinate with yourself, you are probably not also intending to create a public API, but you inherently are, by accident [17:30:17.0598] That was my problem with the current metadata approach, you had to jump through hoops to communicate with yourself privately [17:31:34.0217] sidebar: this is yet another place where the fact that `class A extends B` creates a prototype relation between `A` and `B`, not just `A.prototype` and `B.prototype`, is going to bite us [17:32:01.0592] because `A[Symbol.metadata]` gives you _B_'s metadata, unless A overwrites it [17:32:16.0483] I guess if we create Symbol.metadata on every class, even those without decorators, that's not a problem [17:33:04.0999] that's a feature IMO, you generally want metadata to be inherited [17:33:26.0586] most metadata is applied to the instance, and you don't really care whether or not it was on a specific parent class [17:33:44.0095] One of the benefits of Metadata is discoverability, as it helps with library interoperability. If you don't want the Metadata to be discoverable, you can create your own empty object key to store the Metadata for the class and use a WeakMap internally. [17:33:58.0723] pzuraq: even for static fields? [17:34:03.0242] Which was something we discussed in the champion/stakeholder calls [17:34:23.0490] encapsulation should be the _default_, not opt-in [17:34:40.0735] if you want to create a public API, you should do that on purpose [17:34:43.0650] it shouldn't happen by accident [17:35:44.0337] > <@bakkot:matrix.org> encapsulation should be the _default_, not opt-in Encapsulation is not inheretence. Almost all Metadata use cases have leveraged inheretence (even reflect-metadata leverages it) [17:35:59.0429] sorry, I'm talking about two different things here [17:36:19.0606] the first is, communicating with yourself, which should be encapsulated by default [17:36:24.0541] the second is, how does inheritance work [17:36:29.0075] > <@bakkot:matrix.org> pzuraq: even for static fields? hmm, that's a fair point for some use cases. Easy enough to get around (check for own property when applying metadata for static fields) but could be a footgun [17:36:32.0878] for when you want it to be public [17:36:35.0435] there are other use cases where you would still want it though [17:36:38.0401] e.g. validation [17:36:53.0658] hm. [17:37:24.0946] I can see why you would want that, yeah [17:39:07.0576] with the frozen-associated-key-object design, the decorator author would have to remember to walk up the prototype chain to see if anything in the chain had WeakMap associated data [17:39:10.0215] but that is maybe not so bad [17:39:11.0375] and is not a cost to users of the decorator [17:39:13.0504] What are the validation use cases where the validator piece wouldn't have access to the internal state of the decorator? [17:39:26.0779] yes, that's something the current design tried to avoid [17:39:35.0843] but that's where the complexity starts to come in 🙃 [17:39:58.0341] inheritance is basically 90% of the complexity [17:40:50.0773] crawling the prototype chain is something that framework authors though are familiar with in my experience [17:40:56.0859] I guess if the object is frozen you don't necessarily need it to be a _prototype_ chain [17:41:34.0057] you can just have the key be like `Object.freeze({ __proto__: null, parent: (the superclass's Symbol.metadata property ) })` [17:41:53.0986] not really any advantage in a prototype relation for frozen empty objects, really [17:42:07.0004] hmmm, yes [17:42:24.0948] could allow you to get parent metadata during decoration too [17:44:11.0962] > <@mhofman:matrix.org> What are the validation use cases where the validator piece wouldn't have access to the internal state of the decorator? which internal state exactly? [17:45:11.0605] Maybe I misunderstood, but it seemed above it was suggested that validation use cases benefit from public metadata, but I didn't see how [17:45:47.0846] or maybe I mixed up 2 different things ? [17:46:05.0748] a typical validation library looks like `import { string, number, object, validate } from 'validator-lib'` [17:46:18.0226] you then apply the type decorators to a field or other element [17:46:24.0681] and then call `validate()` later on on the object [17:47:01.0238] without a way to get which decorators were applied to the object being validated, you can't really validate [17:50:12.0195] well if `@string`, `@number` etc. receive a stand-in object for the thing being decorated, then the main issue is linking the thing being decorated to the stand-in object, which can be done by adding an explicit `@validated` decorator to the thing to be validated? [17:51:18.0977] or as mentioned, automatically add that standin-object to the thing being decorated as a `[Symbol.metadata]` prop [17:51:55.0203] correct, both of those solutions would work [18:12:20.0421] opened an issue to record the associated-object design: https://github.com/tc39/proposal-decorators/issues/457 [18:12:24.0915] Metadata use cases: DI, plugin/extensibility, ORM, WSDL/ws*, REST discovery/routing, FFI/Marshaling (esp parameters), serialization control (binary, JSON, XML), validation/contracts, RTTI, debugging (watch/locals window control, stepping behavior), proxy/membrane permeability,... [18:32:31.0389] shu: what's the result example you're referring to here https://github.com/tc39/proposal-pattern-matching/issues/253 [18:44:18.0517] > <@rbuckton:matrix.org> Metadata use cases: > DI, plugin/extensibility, ORM, WSDL/ws*, REST discovery/routing, FFI/Marshaling (esp parameters), serialization control (binary, JSON, XML), validation/contracts, RTTI, debugging (watch/locals window control, stepping behavior), proxy/membrane permeability,... Many of these can't be accomplished by method replacement. Class decorators could do the job, but then the decorator isn't located near the thing it is ostensibly decorating. If using a `@register` approach, any more than one or two uses starts to seem wasteful, and I could definitely see overlap in an API that used REST routing and WS routing for the same endpoint and DI for composition. Then add debugging extensions (like "step over this function") and we're up to 4 "registers". It becomes unwieldy quickly [18:45:14.0866] I contend that a class which is making use of decorators from four different libraries is already unwieldy. [18:45:59.0360] The alternative is duplicating code or 4 different adapters to the same code, which increases maintenance [18:48:08.0834] It may be a rare occurrence to see more than two, but requiring entangled decorators makes things dramatically worse [18:52:32.0156] Also, you essentially need to create an entangled decorator pair per class declaration, you can't rely on execution order to handle association. [18:54:44.0280] ``` const { register, meta } = makeMeta(); @register class A { @meta x; static B = @register class B {} // oops } ``` [18:55:40.0245] devsnek: the one from the slide deck: https://docs.google.com/presentation/d/1sJoXU1ysK6eZn04pjnQ-1z6EetsVf9VfHeU0Ht8hiFQ/edit#slide=id.g112a5d188b1_0_231 [18:55:44.0089] So if you have more than one class per file you need multiple calls to `makeMeta`, which again can quickly become untenable [18:57:55.0113] "untenable" is, I think, not how I would describe that, but I agree that's what it would look like [18:58:04.0529] man we have pretty different definitions of "untenable", rbuckton [19:08:33.0278] ah i see [19:08:42.0914] yeah matches:bool is not fantastic [19:11:59.0760] it would be nice if there was a way to teach match syntax about custom discriminated unions [19:12:18.0725] > <@shuyuguo:matrix.org> man we have pretty different definitions of "untenable", rbuckton I'd rather not have ``` const meta1=..., meta2=..., meta3=...,... @meta1.register class A { @meta1.dec x; ... } @meta2.register ... ``` [19:12:26.0293] i have a feeling a lot of custom matchers are actually just fancy discriminated unions [19:13:36.0656] > <@shuyuguo:matrix.org> man we have pretty different definitions of "untenable", rbuckton I'm using the "not able to be maintained" definition. This approach is a maintenance nightmare, coming from someone who has used Metadata decorators extensively. [19:14:12.0781] class fields are already pretty nuts, this doesn't seem too much worse by comparison [19:16:16.0925] Entangled decorators can work well in isolated cases (and I've used a similar approach in those cases), but the pattern does not extend well to a general practice. [19:16:57.0181] oh, we never addressed https://github.com/tc39/proposal-decorators/issues/417 :( [19:17:00.0120] I completely forgot about that one [19:18:27.0720] IIRC, we chose `isStatic` over just `static` because `static` is a keyword and doesn't work well with destructuring. [19:19:07.0577] That was several years ago when Yehuda was championing the proposal, though so there may be other context I'm unaware of. [19:19:17.0768] `{ static: isStatic }` seems fine to me [19:19:22.0634] * That was several years ago when Yehuda was championing the proposal, though so there may be other context I'm unaware of. [19:20:05.0397] But why force that on end users? [19:20:44.0434] (by that I mean decorator authors) [19:20:50.0208] https://w3ctag.github.io/design-principles/#naming-booleans [19:20:53.0006] I don't have a strong preference either way [19:23:27.0727] I was under the impression switching from`static` to `isStatic` was at the committee's request during an update several years ago. I'd have to dig through the meeting notes to be sure. [19:25:45.0577] I also don’t have a strong preference [19:26:51.0113] if we have an extra five minutes this meeting I'd like to revisit that specific question, before anyone ships it [19:28:41.0303] I can't find either "isStatic" or "isPrivate" in the notes, but it's possible the notes didn't capture it (under those names) [19:28:48.0002] > <@rbuckton:matrix.org> I was under the impression switching from`static` to `isStatic` was at the committee's request during an update several years ago. I'd have to dig through the meeting notes to be sure. * I can't find either "isStatic" or "isPrivate" in the notes, but it's possible the notes didn't capture it (under those names) [19:28:56.0762] Yeah sounds good, ideally we should address it now [19:29:07.0377] we have to address it now [19:29:10.0349] or wait to the next meeting [19:29:15.0516] normative changes can only happen by consensus at this point [19:29:30.0461] This was several versions and several champions ago, so again I'm not 100% sure of the context [19:29:47.0751] i hope we just go with whatever the design principles say, sucks to have that kind of thing around and still argue about it [19:30:09.0840] * i hope we just go with whatever the design principles say, sucks to have that kind of thing around and still debate it [19:30:40.0461] I honestly think I may have just chosen the name based on what I thought made sense at the time, I didn’t have the context of the naming standards in the language [19:30:57.0447] And the only reason we didn’t update was because, as others pointed out, these are keywords [19:31:04.0797] we do not always consider ourselves bound by the web platform's design principles, for better or worse. there are some rare cases where I think it makes sense to deviate (mainly where the language is doing something language-y), but this I think is not one of them. [19:32:19.0365] I suppose it's not a disaster if we have to wait 'till next meeting for that change; it's not like anyone's going to ship a feature of this size unflagged before then, and it's a small change in implementations [19:32:24.0282] still, would be real nice to address now [19:32:49.0204] Yeah, sounds fine to me. If we can work it in let’s do it. I’m not available for the first part of tomorrow, but if you end up finding time to address then my position is “whatever the committee thinks is best” [19:32:56.0423] √ [19:33:20.0795] And any other time I can hop on, though I may be in and out due to meetings [19:34:51.0650] Ah, at one point it was `placement: "static"` [19:35:20.0724] you may have been thinking of https://github.com/tc39/proposal-decorators/issues/421, also [19:35:25.0232] `placement: 'private-static'` [19:35:39.0067] or maybe `static-private` 😉 [19:35:42.0419] Please no, I don't want to have to parse strings [19:35:57.0691] implementation defined order [19:36:15.0920] Because that list could grow [19:36:35.0209] `placement: 'the abyss'` [19:37:12.0431] `placement: 'binary blob of a png of the source code with a red square around the declaration'` [19:37:26.0811] At least 6 years ago it was `static: true`, according to a gist I wrote to investigate type definitions for the decorator context object [19:37:44.0556] did es4 have decorators [19:37:48.0183] Dated June 15, 2016 [19:37:57.0415] Not that I recall [20:31:54.0210] My memory might be off, but at some point wasn’t there additional syntax for field decorators that wanted to also modify the class? So there was a small, but local, opt-in cost to the extra complexity. ``` class C { init @inject(Service) #f } ``` [20:35:49.0788] * My memory might be off, but at some point wasn’t there additional syntax for field decorators that wanted to also ~modify~ access the class? So there was a small, but local, opt-in cost to the extra complexity. ``` class C { init @inject(Service) #f } ``` [20:36:22.0019] * My memory might be off, but at some point wasn’t there additional syntax for field decorators that wanted to also modify access the class? So there was a small, but local, opt-in cost to the extra complexity. ``` class C { init @inject(Service) #f } ``` [20:36:46.0739] * My memory might be off, but at some point wasn’t there additional syntax for field decorators that wanted to also access the class? So there was a small, but local, opt-in cost to the extra complexity. ``` class C { init @inject(Service) #f } ``` [20:47:08.0662] I was miss remembering `@init` for methods to add logic to the instance. [05:42:53.0493] ok, the spec text and README for the proposal have been updated [05:43:20.0284] so it should be ready for stage 3 with the agreed upon changes :D [06:17:19.0436] Daniel Ehrenberg 👋 [06:32:37.0701] Rob Palmer and Keepers of the Schedule: https://github.com/tc39/agendas/pull/1153 [06:59:35.0508] Rob Palmer: ^ see above for https://github.com/tc39/proposal-decorators/issues/417, is there a 5-15minute timeslot somewhere? [07:00:49.0776] bot's up [07:01:01.0608] show time [07:13:54.0182] this proposal is less about memoisation and more about making procedures idempotent [07:14:19.0071] the memoisation-y parts are just because we have to do *something* about a return value [07:17:43.0075] I fail to see what the utility of returning undefined is. What would that actually be useful for? [07:17:59.0709] callbacks [07:18:21.0310] we don't expect return values from callbacks like eventemitter/eventlisteners [07:19:22.0674] virtually every use case i have for "once" is either as an async callback, where the return value doesn't matter, or where i'm trying to sync log a warning (like node does, for deprecation warnings) and i don't use the return value. [07:19:36.0144] this capability doesn't seem to be common in other languages; I see https://doc.rust-lang.org/std/ops/trait.FnOnce.html in Rust but can't find an analog in Python, Ruby, or Go [07:19:36.0519] (iow node's own `emitWarning` thing would likely use this) [07:19:59.0549] We've used the return value constantly [07:20:09.0273] Eg, to guard creation of an expensive object [07:20:27.0967] that's a good example [07:20:45.0310] hm, that is a good example [07:20:50.0939] but that seems like a "memoize" helper not a "once" helper [07:20:53.0154] since you'd want it to vary based on input, esp to avoid the confusion waldemar talked about [07:20:58.0903] Justin Ridgewell: that's just a special case of a memoisation function with no arguments [07:21:03.0072] i think it'd be far better to solve those problems separately [07:21:23.0742] * since you'd want it to vary based on input, esp to avoid the confusion waldemar talked about [07:21:25.0403] Yes, but once is a mini memoization function as used in the ecosystem [07:21:26.0314] and in general probably wouldn't want a "once" helper to encapsulate a strong reference [07:22:18.0288] then I guess I'm leaning toward caching the return value but ignoring passed arguments [07:22:41.0208] not in JS, but I've used "once" functions many times in C and C++ to initialize a static variable, which is morally equivalent to wanting a return value out of it [07:22:44.0973] the oddity waldemar brought up is compelling to me [07:22:46.0979] > <@michaelficarra:matrix.org> then I guess I'm leaning toward caching the return value but ignoring passed arguments that seems like a footgun [07:22:58.0969] ljharb: a little bit, yeah [07:23:00.0283] throwing if you pass it arguments, maybe [07:23:06.0020] oh unless you mean, never passing anything through the once function to the wrapped one? [07:23:27.0000] I don't understand why we would break with precedent [07:23:33.0614] *that* seems totally fine to me, it's like `() => (called ? () => {} : original)()` [07:23:34.0874] bakkot: the reason I didn't say throwing is because you might pass it to a function you don't control which will call with arguments you don't want [07:24:02.0144] Michael Ficarra: in that scenario it would also break if you passed the raw (pre-once'd) version, no? [07:24:12.0336] > <@jridgewell:matrix.org> I don't understand why we would break with precedent i would be very shocked if it was widely known that `once` caches its return value [07:24:14.0222] how? [07:24:25.0516] > which will call with arguments you don't want [07:24:34.0149] oh, you just mean, your function ignores its arguments [07:24:35.0661] ok, yeah [07:24:37.0469] yes [07:25:42.0004] > Repeat calls to the function return the value of the first invocation. — https://lodash.com/docs/4.17.15#once [07:26:15.0690] i hope you're not implying that people actually read documentation :-p [07:26:34.0077] i looked; the example code in both underscore and lodash only uses it for side effects, and that's what i bet people will notice [07:34:18.0140] We use something like `once` for lazy-init in the TS code base quite often. In my own projects I just call it `lazy` (and it errors on circular init) [07:36:11.0532] i'm already sold on the use cases for `memo` + `once`. what i'm not on board with is conflating the two in a way which i think would be surprising to those not already aware of that behavior in the ecosystem. [07:38:06.0763] For what it’s worth, I am willing and plan to champion a configurable `memoize` (`memo`?) helper function, based on the support for it I saw today. [07:38:16.0816] * For what it’s worth, I am willing and plan to champion a `memoize` (`memo`?) helper function, based on the support for it I saw today. [07:38:27.0831] * For what it’s worth, I am willing and plan to champion a configurable `memoize` (`memo`?) helper function, based on the support for it I saw today. [07:39:00.0565] good luck [07:39:11.0967] lotta weird corners in that design space [07:39:42.0152] We’ll just min–max a MVP design. Nothing can go wrong… [07:39:44.0027] yeah, you might want to do some research on the designs of that function in underscore/lodash first [07:39:53.0006] The problem with n-argument `memo` is that it has to hold the arguments for repeated calls. 0-arg `memo` is easier, but then it isn't really a memorize function [07:39:59.0632] those are some of the longest threads I've participated in [07:40:58.0588] > <@michaelficarra:matrix.org> those are some of the longest threads I've participated in I get the same vibe from this as I do when I look at the talk page of a Wikipedia article and see that it’s dozens of pages long… [07:41:13.0335] I am filled with foreboding. [07:41:59.0750] > <@rbuckton:matrix.org> The problem with n-argument `memo` is that it has to hold the arguments for repeated calls. 0-arg `memo` is easier, but then it isn't really a memorize function 0-arg `memo` would be a core use case of `memo`, I figure. [07:42:12.0433] yeah there's an inherent difficulty in anything that tries to make a universal definition of "equivalence" [07:43:58.0703] > <@jschoi:matrix.org> 0-arg `memo` would be a core use case of `memo`, I figure. But it would be a misnomer in the FP space. 0-argument `memo` is just `lazy` (for lazy init). [07:44:01.0523] we already have at least 4 definitions in the spec as-is [07:45:04.0826] rbuckton: I don't know what this `lazy` function you're talking about is [07:45:16.0022] > <@jschoi:matrix.org> 0-arg `memo` would be a core use case of `memo`, I figure. This is the inverse of my experience for using memoization [07:45:32.0631] 😀 [07:45:36.0207] > <@rbuckton:matrix.org> But it would be a misnomer in the FP space. 0-argument `memo` is just `lazy` (for lazy init). I guess I’m used to memoization from Clojure, in which there’s just one `memoize` function and you can do `((memoize f))` if you want and it’s idiomatic. [07:48:10.0411] By misnomer I mean that `memoize` in the FP space can accept functions that take n arguments, even if it's commonly only used with 0 argument functions. A memoize that only can take 0 argument functions isn't a true memoize. [07:48:37.0553] So it could be confusing/frustrating. [07:49:26.0504] I don't think anyone has suggested that a hypothetical `memoise` function would only accept nullary functions [07:49:37.0954] Yes, `memoize`’s functions definitely would not take only zero arguments. They could take zero arguments, but they could take many too. [07:49:49.0019] It falls out of what memoize is. Zero arguments is just a special case. [07:49:52.0734] * It falls out of what memoize is. Zero arguments is just a special case. [07:50:18.0846] It's the N-ary version of memoize that gets complicated wrt GC [07:51:32.0929] > <@michaelficarra:matrix.org> rbuckton: I don't know what this `lazy` function you're talking about is C#/F# has `Lazy` (and F# has the concept of "lazy expressions" which evaluate to `Lazy`) [07:51:52.0009] okay but that does that mean? [07:52:15.0944] It's a result whose value is lazy-initialized when it is requested. [07:52:44.0413] ... that's the same as `T` [07:53:44.0302] Incidentally, please direct-message links to any of those threads that you remember! (I’m finding https://github.com/lodash/lodash/issues/2115 and https://github.com/jashkenas/underscore/issues/1862.) [07:54:58.0335] > <@michaelficarra:matrix.org> those are some of the longest threads I've participated in * Incidentally, please direct-message links to any of those threads that you remember! (I’m finding https://github.com/lodash/lodash/issues/2115 and https://github.com/jashkenas/underscore/issues/1862.) [07:55:07.0764] > <@michaelficarra:matrix.org> ... that's the same as `T` No, it's different. A `Lazy` has a "value" property that evaluates the expression at most once when first requested. [07:56:37.0112] rbuckton: I guess I'm used to lazy-by-default and forcing strictness where necessary, instead of the other way around [07:59:37.0004] I'm not sure what you mean by "lazy by default" in this case. [08:04:58.0272] rbuckton: imagine every `T` is instead a `Lazy`, implicitly, everywhere [08:06:10.0618] I'm not sure we're talking about the same things. [08:07:51.0210] rbuckton: Just to confirm, `const lazyF = Function.memoize(expensiveF); lazyF(); lazyF();` works for the lazy use case, doesn’t it? [08:07:59.0534] * rbuckton: Just to confirm, `const lazyF = Function.memoize(expensiveF()); lazyF(); lazyF();` works for the lazy use case, doesn’t it? [08:08:05.0141] * rbuckton: Just to confirm, `const lazyF = Function.memoize(expensiveF); lazyF(); lazyF();` works for the lazy use case, doesn’t it? [08:08:20.0489] Yeah, it works just fine. [08:10:13.0323] so, PSA everybody: i'm organizing the github teams on the tc39 org. as a result, you may get notifications that you're added to a "Member: Something" team, and removed from the "Delegates" team - your "member" team will be a child team of Delegates, so no permissions should change. Please let me know if: a) you run into any github permission issues b) i've gotten your affiliation wrong c) you have multiple affiliations and i've forgotten some of them Thanks! [08:14:44.0975] My only concern with `memoize` is that it's not a true memoize unless it can take functions that accept multiple arguments and only evaluates once "for each unique sequence of arguments", and that has GC implications. It's not a blocking concern, but may be a source of confusion for anyone coming from an FP language or library that does have a true "memoize" implementation. I'm wary of borrowing something from FP but have a implementation that doesn't match the FP version. [08:16:25.0536] (and yes, TS has a function called `memo` internally that only supports 0-arg, and I wrote it, but it's internal only so 🤷) [08:17:25.0420] > <@rbuckton:matrix.org> My only concern with `memoize` is that it's not a true memoize unless it can take functions that accept multiple arguments and only evaluates once "for each unique sequence of arguments", and that has GC implications. It's not a blocking concern, but may be a source of confusion for anyone coming from an FP language or library that does have a true "memoize" implementation. I'm wary of borrowing something from FP but have a implementation that doesn't match the FP version. Is the GC concern that memoized functions permanently cache their arguments? [08:19:27.0016] python has lru_cache for this [08:19:30.0613] which I like a lot [08:20:11.0617] > <@jschoi:matrix.org> Is the GC concern that memoized functions permanently cache their arguments? Yes, though you could potentially use a weakref for objects [08:20:26.0119] rbuckton: I think you can solve the GC issues by using a tree of WeakMaps for the argument storage [08:20:44.0503] only if the arguments are objects [08:20:56.0552] it'd be easier if we could shove anything into WeakMaps though... [08:20:57.0341] if the arguments are all primitive and the return value is not, now you have no gc [08:21:04.0106] > <@bakkot:matrix.org> python has lru_cache for this Re LRU/LFU, IBM’s patent on ARC lapses in just a few more years :-) [08:21:07.0476] bakkot: you know where I stand on that [08:21:17.0091] > <@michaelficarra:matrix.org> rbuckton: I think you can solve the GC issues by using a tree of WeakMaps for the argument storage Agreed, but I think this is the reason why `memoize` for n-arg could be potentially difficult to standardize [08:22:04.0455] Michael Ficarra: I only know things after 9am [08:22:10.0536] so, remind me? [08:22:52.0910] https://github.com/tc39/proposal-symbols-as-weakmap-keys/issues/21#issuecomment-1016934180 [08:26:01.0700] That item on the queue for a stage between 3/4 for shipping flagged vs. unflagged is something I would be interested in discussing one of these days [08:27:22.0232] (hey, I'm not the one who opened the can of worms :D ) [08:31:33.0205] guess it depends on what that means [08:31:39.0782] I am often writing code that is trying to be defensive against a malicious `Function.prototype.call` exfiltrating my function, and yet I don't feel it's inconvenient to create a helper `const call = Date.call.bind(Date.call);` [08:32:22.0471] danielrosenwasser: i wouldn't find slowing down feature release cadence to be as slow as TC39's own schedule to be acceptable [08:32:32.0896] post stage 3, that is [08:33:47.0700] I'd guess that not all proposals would benefit from such a stage [08:34:31.0154] also big +1 [08:34:39.0448] if we codify an optional stage for proposals that need it [08:34:48.0413] that seems pretty good! details tbd ofc [08:36:03.0711] right, definitely only a subset of proposals [08:36:17.0622] i remind again of my "risk factors" process doc PR, one of which could be this :-p [08:36:40.0734] if anyone has avenues to reach Pzuraq, please check if they can present Decorators sometime in the next 30mins (the overflow item) [08:36:58.0203] I have tried Matrix and Twitter DM. [08:38:51.0162] Rob Palmer: they said last night they were not around this morning in particular but were OK with whatever the committee wants [08:38:55.0796] assuming this is the `isPrivate` thing [08:39:04.0409] I can present that issue, if pzuraq cannot be located in time [08:39:44.0507] https://matrixlogs.bakkot.com/TC39_Delegates/2022-03-29#L171 [08:39:59.0274] we can always do it Thursday - there is no time pressure, (and maybe no time at all) if it's better for pzuraq [08:40:28.0971] i say no time pressure - i mean, it fits, so long as NO ONE OVERRUNS [08:40:50.0020] pzuraqalso said he dosen't feel strongly and is comfortable with whatever consensus committee reaches [08:40:57.0297] would rather we don't risk not discussing this imo [08:41:20.0225] I want to register, informally, that “call this” is a net negative for the precious understandability of the language. I do not think it’s useful to sweep “call” and “bind” under the syntax of the language. “call” and “apply” are perhaps warts, but they’re instructive warts. [08:42:04.0048] > <@kriskowal:matrix.org> I want to register, informally, that “call this” is a net negative for the precious understandability of the language. I do not think it’s useful to sweep “call” and “bind” under the syntax of the language. “call” and “apply” are perhaps warts, but they’re instructive warts. can you elaborate on that? my belief is the opposite, that it increases understandability [08:42:24.0258] it is quite difficult to search syntax [08:43:41.0254] what if we shipped editor macro for every popular editor that expands `~.` or whatever syntax the user chooses to `.call` [08:43:44.0001] sure, that's fair. but i believe most wouldn't need to search it, because it's pretty intuitive once you know about `this` [08:43:49.0614] * sure, that's fair. but i believe most wouldn't need to search it, because it's pretty intuitive [08:43:52.0893] * sure, that's fair. but i believe most wouldn't need to search it, because it's pretty intuitive once you know about `this` [08:43:54.0793] also auto-converters for code viewers and searches i guess [08:44:10.0687] Rob Palmer: shu As noted above, I’m ok with whatever consensus the committee reaches on the static/isStatic naming issue [08:45:14.0516] You can discuss without me, I’m not available until 1:30pm ET [08:45:25.0131] pzuraq: thank you. we will do it in the first spare time we have. [08:45:51.0219] shu: i think it will fit in this meeting. we have some time profit. [08:45:53.0308] I also have some hope that we will reserve `~` (tilde) for eventual send, since it has the obvious in retrospect “stream” mnemonic. [08:46:07.0155] * I also have some hope that we will reserve `~` (tilde) for eventual send, since it has the obvious in retrospect “stream” mnemonic. [08:47:35.0840] > <@ljharb:matrix.org> can you elaborate on that? my belief is the opposite, that it increases understandability Syntax does not obviate the need to know about `this` binding and does not replace having to understand `.call`, `.apply`, and `.bind`. [08:48:04.0720] All, if you get a mail saying Jordan has removed you as a member of TC39 Delegates on Github, fear not, you are still part of the Delegates team. Jordan is creating Github sub-teams per-member to help us track membership better. [08:48:22.0742] thought i was free [08:48:38.0097] So, as a reader of the language, you need to know more, not less, and `call` and `apply` are a more searchable teaching moment, to Yulia’s point. [08:49:01.0536] > <@shuyuguo:matrix.org> thought i was free tbh we thought it was a coup [08:50:06.0406] > <@kriskowal:matrix.org> So, as a reader of the language, you need to know more, not less, and `call` and `apply` are a more searchable teaching moment, to Yulia’s point. yes, this is more of an expert feature. However, we have done similar moves with `=>`. There is something wrong, users struggle with .bind and .call. It's more about ambiguity around `this` than word order though. I do think there is something to fix but i don't know how, and this might do it? [08:50:19.0700] > <@kriskowal:matrix.org> So, as a reader of the language, you need to know more, not less, and `call` and `apply` are a more searchable teaching moment, to Yulia’s point. * yes, this is more of an expert feature. We have done similar moves with `=>`. There is something wrong, users struggle with .bind and .call. It's more about ambiguity around `this` than word order though (so, i disagree with the thesis). I do think there is something to fix but i don't know how, and this might do it? [08:52:47.0112] I’m personally happy with arrow functions, but anecdotally, I’ve been told by people who assume me a JavaScript partisan, that arrow functions marked the moment JavaScript ceased to be friendly to newcomers. [08:52:56.0243] * I’m personally happy with arrow functions, but anecdotally, I’ve been told by people who assume me a JavaScript partisan, that arrow functions marked the moment JavaScript ceased to be friendly to newcomers. [08:53:02.0053] like the case i keep thinking about is `obj.method.{call,bind}(obj, val)` -- this is a bit weird [08:53:27.0648] im not so concerned about `obj.method.{call,bind}(anotherObj,val)` that seems valid. [08:54:14.0497] my more common use cases are `const method = obj.method; /* much much later */ method.call(otherObj) /* vs */ otherObj~>method()` [08:54:39.0379] it feels like that isn't so bad [08:54:42.0044] "bitwise XOR is not very common" [08:55:00.0283] > <@yulia:mozilla.org> it feels like that isn't so bad i mean it's "fine", but the reversed word order makes readability and writability suffer [08:55:23.0327] > <@yulia:mozilla.org> like the case i keep thinking about is `obj.method.{call,bind}(obj, val)` -- this is a bit weird when does one need to write this. It used to be the case with `apply` before spread [08:55:27.0911] Rick Waldron: yes I'm sure there are entire programs that are nothing but xor, but that's not representative of the majority [08:55:46.0201] > <@ljharb:matrix.org> my more common use cases are `const method = obj.method; /* much much later */ method.call(otherObj) /* vs */ otherObj~>method()` fwiw I do not see code which does that basically ever, except for code which is being defensive [08:55:56.0043] used to be a lot more common before spread, because you had to work with `arguments` objects [08:55:58.0601] > <@mhofman:matrix.org> when does one need to write this. It used to be the case with `apply` before spread react. like, all the time [08:55:59.0558] but now? not really ever. [08:56:08.0747] yes, i agree, but "code which is being defensive" is quite common for me [08:56:12.0189] well [08:56:17.0807] mm [08:56:21.0013] and for node core [08:56:32.0319] I do not think "this code is common for jordan, in particular", is a good reason to syntax to the language [08:56:36.0060] and thus it's important for all the users of all that code, at a minimum [08:56:48.0905] ljharb: same, but we can be expected to go through the minor inconvenience of saving off a call-bound call [08:56:50.0631] i totally agree that no one person's needs should justify addition of anything [08:57:15.0862] but in node core, in particular, this syntax would (mostly) resolve a long-standing debate about the tradeoffs of readability vs robustness [08:57:40.0737] ljharb: how is that even a debate in node core? [08:57:41.0065] * but in node core, in particular, this syntax would (mostly) resolve a long-standing debate about the tradeoffs of readability vs robustness [08:57:47.0327] that seems like a node core problem to me... [08:57:56.0713] Michael Ficarra: good question, yet it is [08:58:06.0502] the debate itself is a node core problem [08:58:27.0765] but the readability harm of the status quo, that call syntax would address, is a general problem - just not a universal one [08:58:46.0036] > <@michaelficarra:matrix.org> Rick Waldron: yes I'm sure there are entire programs that are nothing but xor, but that's not representative of the majority Every time there's discussion about making new operators/adding syntax, there is inevitably a contingent that either never knew that bitwise operators existed, or think they are so uncommonly used that they could just be re-used again for something else. [08:58:48.0024] ooo remapping, can we use apl syntax :D [08:58:58.0799] can we just... introduce apl actually [08:59:11.0543] i have 2 days. shit why didn't i add this to the agenda [09:00:51.0343] jschoi: please give folks on the queue a chance to speak for themselves unless the item says no need to speak [09:01:05.0683] shu: Will do, sorry. [09:01:19.0831] > <@ljharb:matrix.org> but the readability harm of the status quo, that call syntax would address, is a general problem - just not a universal one generally speaking, I am opposed to adding new syntax unless it is either a.) making a very common case more readable [e.g. arrows] or b.) making an effectively-impossible case possible [e.g. bigint] [09:01:55.0227] "cases where node is using `.call`" does not meet either bar, being neither very common nor effectively impossible [09:02:17.0666] sure, fair [09:05:45.0323] https://github.com/tc39/process-document/pull/35 [09:06:41.0791] bakkot: I might have missed it earlier, but were you still going to bring up decorators and `.static` vs. `.isStatic`? [09:06:48.0008] yes [09:07:00.0875] whenever we have time to put it in [09:07:11.0654] Rob Palmer: fwiw you're still not muted despite it showing you muted [09:07:33.0444] seems like you've fixed it :P [09:07:43.0257] errr.... [09:08:08.0263] the fragility of software mute... [09:08:26.0722] > <@yulia:mozilla.org> i have 2 days. shit why didn't i add this to the agenda APL needs an EMOJI reboot. [09:08:43.0290] i have a friend who wants to introduce an emoji combinatorics proposal for tc39 [09:09:07.0287] fn📢method [09:09:21.0711] > <@kriskowal:matrix.org> APL needs an EMOJI reboot. We should make a Unicode proposal to make emoji variants of every APL symbol. [09:09:46.0804] jschoi: just use variation selector 16 [09:10:24.0772] ... why do I know about VS16 [09:10:58.0188] Yes, but they still don’t have the Emoji property! Imagine…opening your emoji picker and seeing your old APL friends in cartoony, colorful emoji glory. [09:11:10.0099] > <@michaelficarra:matrix.org> jschoi: just use variation selector 16 * Yes, but they still don’t have the Emoji property! Imagine…opening your emoji picker and seeing your old APL friends in cartoony, colorful emoji glory. [09:11:39.0011] > <@michaelficarra:matrix.org> ... why do I know about VS16 My excuse is working on Emoji Quest and OpenMoji in the “spare time”. [09:12:57.0205] I have been careful not to mention stuff like Node core with call-this—in the end, it’s about the fact that `.call` is one of the most common operations in the language (cf. the corpus analysis), and common × clunky → worth optimizing. [09:12:59.0641] > <@kriskowal:matrix.org> fn📢method this but unironically [09:14:52.0006] > <@bakkot:matrix.org> I do not think "this code is common for jordan, in particular", is a good reason to syntax to the language * I have been careful not to mention stuff like Node core with call-this—in the end, it’s about the fact that `.call` is one of the most common operations in the language (cf. the corpus analysis), and common × clunky → worth optimizing. [09:16:12.0462] > <@jschoi:matrix.org> I have been careful not to mention stuff like Node core with call-this—in the end, it’s about the fact that `.call` is one of the most common operations in the language (cf. the corpus analysis), and common × clunky → worth optimizing. I like the argument, but it’s more like common * clunky = value, value / cost > 1 == worth optimizing. [09:17:07.0058] And when every objective argument runs to ground, there’s still a value judgement to be made. [09:17:12.0468] * And when every objective argument runs to ground, there’s still a value judgement to be made. [09:18:25.0282] I think I could be swayed by an argument of the form “this obviates the need for uncurryThis”, but I don’t have the spoons to make that argument. [09:19:03.0206] As for syntax, there’s also a very high opportunity cost. [09:20:16.0739] Yeah, it’s true, we do have to consider cost. I wonder if there are truly any significant concrete costs to call-this—enough to come close to outweighing the improvement in common × clunky. [09:20:37.0339] > <@kriskowal:matrix.org> I like the argument, but it’s more like common * clunky = value, value / cost > 1 == worth optimizing. * Yeah, it’s true, we do have to consider cost. I wonder if there are truly any significant concrete costs to call-this—enough to come close to outweighing the improvement in common × clunky. [09:21:17.0594] e.g., https://github.com/tc39/proposal-eventual-send#completing-the-proxy-analogy proposes some uses of tilde that would establish a precedent for tilde indicating an async operator. [09:22:30.0868] There’s also the matter that common is not necessarily bad. [09:24:06.0390] Yeah, commonality is just a multiplier. In this case we’re multiplying the commonality by something that is bad (the clunkiness of `.call`). As for eventual-send syntax, we certainly can try to be careful to bikeshed both proposals to not conceptually conflict with each other. It’s true that introducing new syntax makes it slightly harder to introduce newer syntax in the future. [09:24:08.0228] But, this is an olive branch 🕊, I’m already strongly in support of eliminating uncurryThis. [09:25:06.0663] I am rooting for eventual send. Even if Reading about E and Cap’n Proto still stretches my brain. [09:25:09.0420] * I am rooting for eventual send. Even if reading about E and Cap’n Proto still stretches my brain. [09:25:37.0099] I could be convinced that syntax is a good solution to uncurryThis even if its usage is limited to Node.js core development. [09:26:17.0643] Did you know Q had eventual send support? :-) [09:27:14.0834] > <@kriskowal:matrix.org> I could be convinced that syntax is a good solution to uncurryThis even if its usage is limited to Node.js core development. Next time I present call-this, I will devote time to a slide titled “This Is Not For Node Core”, haha. [09:55:12.0663] I won't be able to do note taking for the upcoming 2 hour block, so it'd be great if someone else could help out there. [09:55:57.0346] thanks for all your help so far Luca Casonato ! [09:56:40.0194] thanks, Luca [09:56:50.0619] Yulia will be chairing Types as Comments today. I'll be recusing as chair because I'm invested in the proposal. I will also try to convey this through the medium of light. A blue background means I'm on types. Yellow means I'm on chairing. [10:01:07.0344] I can do some notetaking but I'm nodding off occasionally, so will need at least one other person [10:08:27.0004] I can help with notes for a while [10:15:19.0374] what the hell [10:15:21.0560] > You’ve been removed from the "Delegates" team on the "Ecma TC39" organization. [10:15:48.0212] rkirsling: https://matrix.to/#/!WgJwmjBNZEXhJnXHXw:matrix.org/$qaDYVljoQO2iG0kW3fltpvxxLyKK4oi51kViN-FVWNY?via=matrix.org&via=mozilla.org&via=igalia.com [10:16:07.0167] ah cool [10:16:08.0888] All, if you get a mail saying Jordan has removed you as a member of TC39 Delegates on Github, fear not, you are still part of the Delegates team. Jordan is creating Github sub-teams per-member to help us track membership better. (from Rob Palmer further up) [10:16:20.0456] rkirsling: also, check your DMs [10:16:41.0235] * All, if you get a mail saying Jordan has removed you as a member of TC39 Delegates on Github, fear not, you are still part of the Delegates team. Jordan is creating Github sub-teams per-member to help us track membership better. (from Rob Palmer further up) [10:17:23.0024] thanks 🙇 [10:18:00.0440] should've also noticed the Admin-and-Business notifications, whoops [10:18:41.0923] np, it's a scary warning from github :-( sadly they don't notice that removal from the delegates team while leaving you on a child team of delegates is a noop [10:19:45.0578] oh weird [10:20:27.0728] * np, it's a scary warning from github :-( sadly they don't notice that removal from the delegates team while leaving you on a child team of delegates is a noop (in this case. in the general case, it might not be, so i understand this choice) [10:26:06.0448] > <@lucacasonato:matrix.org> All, if you get a mail saying Jordan has removed you as a member of TC39 Delegates on Github, fear not, you are still part of the Delegates team. Jordan is creating Github sub-teams per-member to help us track membership better. (from Rob Palmer further up) also got this and immediately DM'ed Brian lol [10:29:55.0986] lol [10:30:09.0028] i wish i could include an explanatory message in that notification [10:31:37.0168] sorry sorry I just restarted it [10:31:44.0801] but yes we probably don't need to capture this part [10:35:18.0087] wish these slides did not use the maximally verbose form of comments here [10:35:43.0798] it feels like a strawman [10:36:37.0725] can you show the normal, terser form? [10:38:50.0026] flow's are the concise version which exists today, but you could also imagine plenty of other forms, e.g. ``` //: (number, number) => number function (a, b) { return a + b } ``` [10:39:29.0725] cool, thanks [10:39:33.0244] the closest thing they had to that was ``` /* * @type { (a: number, b: number) => number } * */ ``` or something like that [10:39:38.0302] note that this form is not available in typescript [10:39:46.0869] isn't, but could be [10:39:50.0326] well, that's TS's decision [10:39:55.0813] yea the second example ts can do today [10:40:24.0942] yea that is true, just clarifying [10:41:41.0867] are we just trying to make it so people can run their code without first running a program that strips the signatures? [10:41:50.0148] that program would complete nearly instantly [10:42:21.0105] that is the thing we are trying to do, yes [10:42:44.0571] the only value I can see in this proposal is formalising some comment attachment rules [10:42:51.0048] the goal is not just to strip ts to be clear, it is mostly to reserve syntax space for a new kind of comments [10:43:05.0999] this would happen to match types [10:43:21.0089] Robin Ricard: the syntax space is already reserved though? [10:43:39.0705] also we can do that without making it a valid program [10:44:04.0013] well, `:` is reserved, `interface` just isn't used yet [10:44:10.0035] > <@michaelficarra:matrix.org> Robin Ricard: the syntax space is already reserved though? you mean `: something` ? [10:44:25.0545] Robin Ricard: yep [10:44:35.0551] Many things need to be reserved, for example, class elements modifiers. [10:45:04.0592] I have to go in 10 mins, we will need another note taker [10:45:05.0439] (my agenda item is going to say "what if we just reserve '`:` followed by anything with balanced-brackets' in a few spots") [10:45:13.0711] nicolo-ribaudo: I'll pick it up again [10:45:38.0832] there is still a difference between reserving and tolerating it [10:45:52.0667] should i request more note takers? [10:46:24.0055] > <@yulia:mozilla.org> should i request more note takers? No, we are enough now [10:46:32.0772] > <@rricard:mozilla.org> there is still a difference between reserving and tolerating it what's the diff? From the tooling perspective it seems same...? [10:46:38.0246] Robin Ricard: yeah and again, the value of allowing it is just that you don't have to run some incredibly simple annotation stripper? [10:46:47.0395] reserving means the engine will syntaxerror [10:47:07.0299] > <@rricard:mozilla.org> reserving means the engine will syntaxerror already ? [10:47:08.0901] ok I have a dumb example [10:47:19.0502] I need to test out some code in a repl [10:47:40.0186] I need to copy, run the typestripper and then paste in my inspector [10:47:42.0935] > <@michaelficarra:matrix.org> Robin Ricard: yeah and again, the value of allowing it is just that you don't have to run some incredibly simple annotation stripper? Yes, but this "just" is much much more painful than it initially sounds. Having the engine do this natively would be a huge win for very very many people. [10:47:55.0202] shu: I love your TCQ topic [10:48:07.0676] for instance, with deno, I can just throw it in the repl [10:48:13.0740] are you reading a value judgment into it Michael Ficarra ? [10:48:14.0639] Luca Casonato: can you back that up somehow? [10:48:19.0781] > <@rricard:mozilla.org> for instance, with deno, I can just throw it in the repl also with `npx ts-node` [10:48:45.0150] which is ok, I would like to do it in my browser if possible [10:49:02.0346] browser console could do this if it wanted [10:49:13.0881] I might be narrowing the motivation here, it is just an example [10:49:22.0939] it already allows you to write `{ [x]: foo() }` which is not valid JS (on its own) [10:49:26.0776] I will organize the queue according to topic, FYI [10:49:28.0872] > <@michaelficarra:matrix.org> Luca Casonato: can you back that up somehow? Yes. Deno does this and folks are incredibly happy about it compared to the current situation in browsers and Node. Deno effectively does TS type stripping during module loading, before loading it into the engine, fully transparently. [10:49:51.0265] Please make it clear what specifically your topic is about, first set will be around syntax [10:50:19.0567] Luca Casonato: a node REPL wrapper like `ts-node` can also make it just as easy to do [10:51:16.0408] Next round is on the goal [10:51:24.0015] You can see with the proliferation of tooling like `esbuild` and `swc` that folks want to make the "inner loop" much faster. The amount of investment in the space shows that this is a real problem that many people run into. I think that alone should qualify the topic as something we should consider in some form. [10:52:03.0179] biiiiig difference between a .1s tool and a 20s tool [10:52:08.0239] Luca Casonato: if this "inner loop" is build time, I am sure that just stripping types will not take long [10:52:09.0709] which is my experience of esbuild vs webpack or whatever [10:52:25.0759] Also, reminder -- this is going for stage 1: we want to answer "is this problem space worth exploring" [10:52:30.0424] > <@michaelficarra:matrix.org> Luca Casonato: a node REPL wrapper like `ts-node` can also make it just as easy to do ts node is not very friendly to es modules [10:52:35.0274] not so obvious there is similar big difference between no tool and .1s tool [10:52:36.0348] it's also your own dx when starting a new project [10:52:37.0705] > <@bakkot:matrix.org> which is my experience of esbuild vs webpack or whatever handing that off to the browser though may not be better, right? [10:52:57.0052] I actually make use a lot of the comments syntax for that reason, I just don't want to set up any tooling [10:53:03.0390] Michael Ficarra: It's not just time, it's also project complexity. Many smaller projects that currently have build steps would not require any build steps if types would not have to be stripped. [10:53:10.0452] * Michael Ficarra: It's not just time, it's also project complexity. Many smaller projects that currently have build steps would not require any build steps if types would not have to be stripped. [10:53:20.0544] comments are just very clunky as my project grows [10:54:06.0289] I admit the flow syntax from earlier is looking good still [10:55:20.0905] 14 items on the queue, that might be a record [10:55:31.0314] I still think the only problem shown here is a need to associate comments with particular portions of the program [10:55:42.0768] that is not even shown here [10:55:46.0155] on-brand for types: lots of context for the same output :P [10:55:48.0184] different tools can have different rules, that's fine [10:55:58.0200] bakkot: you have to read between the lines [10:56:18.0065] waldemar If you want a specific exaple for one of your topics, `a ? (b): c => (d): e => f` is fully ambiguous (it has two possible parser results) [10:57:48.0886] > <@nicolo-ribaudo:matrix.org> waldemar If you want a specific exaple for one of your topics, `a ? (b): c => (d): e => f` is fully ambiguous (it has two possible parser results) But this is probably not a discussion for stage 1 [11:01:06.0451] Each person with concerns each should all try to be clear if they are blocking Stage 1. [11:01:36.0673] * Each person with concerns each should all try to be clear if they are blocking Stage 1. [11:02:47.0456] jschoi: "blocking stage 1" is more likely to be "unconvinced that a problem worth solving has been clearly identified" [11:03:22.0612] "blocking" is usually a thing that happens when a particular design decision has been made that is unacceptable, but pre-stage-1 proposals have nothing like that set in stone [11:05:00.0009] HE Shi-Jun: since the types are ignored, we don't really need a type definition -- that can be done in comments [11:05:04.0322] for example, as an iterative approach [11:05:18.0191] > <@nicolo-ribaudo:matrix.org> I have to go in 10 mins, we will need another note taker I'm going now, one more note taker will be really appreciated! [11:05:27.0396] should i pause and ask? [11:05:29.0199] > <@jschoi:matrix.org> Each person with concerns each should all try to be clear if they are blocking Stage 1. I don't think this is a good framework in which to think about it. I would prefer that we assume people are giving constructive feedback, identifying concerns, and discussing opinions on the tradeoffs the proposal authors have made. This way of thinking about it seems needlessly adversarial to me [11:05:31.0245] do we have anyone? [11:05:41.0546] There is a single person [11:05:41.0548] so, my point is that `:` is already the main way you use types [11:05:41.0985] and incentivises paying more attention to people who claim that they will block stage 1 [11:05:47.0691] I can help with notes [11:05:52.0215] the motivation to me targets 2 populations: - end users setting up projects - tooling developers for end users: - I can setup a typed project without ever downloading something from npm for instance, npm to me is not js - copy-pasting in a repl is very cool tooling developers: - if the syntax carve out is clearly defined, I can just implement ecma262 syntax and forget about ts - for instance today eslint ecosystem is split, you have to use a special parser for ts [11:05:56.0184] `function (a: number, b: number): number {}` would be legal with my proposal [11:06:01.0714] Thanks yulia!! [11:06:09.0034] it's only the `interface {}` stuff which would not [11:06:29.0339] > <@pchimento:igalia.com> and incentivises paying more attention to people who claim that they will block stage 1 This is reasonable. It makes me wonder what the purpose of discussion before Stage 1 ought to be, then. [11:06:30.0653] you'd have to write `:interface {}` or something [11:06:40.0752] * the motivation to me targets 2 populations: - end users setting up projects - tooling developers for end users: - I can setup a typed project without ever downloading something from npm for instance, npm to me is not js - copy-pasting in a repl is very cool tooling developers: - if the syntax carve out is clearly defined, I can just implement ecma262 syntax and forget about ts - for instance today eslint ecosystem is split, you have to use a special parser for ts [11:06:55.0658] > <@jschoi:matrix.org> This is reasonable. It makes me wonder what the purpose of discussion before Stage 1 ought to be, then. it's "is this actually a problem space we want to spend more committee time on" [11:07:39.0772] > <@ljharb:matrix.org> it's "is this actually a problem space we want to spend more committee time on" Yes, which then makes me wonder: should we discourage bikeshedding questions before Stage 1? Because I think there are a lot of bikeshedding questions in the queue. [11:08:14.0058] yes, we should and often do [11:08:37.0708] this proposal's a bit tricky tho since it's got a pretty large and fleshed out solution space [11:09:03.0304] we should definitely discourage bikeshedding before stage 1 [11:09:33.0267] we often fall into the trap of pre-stage-1 bikeshedding when the proposal contains an example solution that is unnecessarily fleshed out [11:09:48.0774] this proposal sure does have a lot of flesh in [11:09:55.0244] I agree, these syntax questions are really not that important yet [11:10:02.0082] yes, sometimes that is necessary, but most of the time it is not [11:10:09.0652] I'm strong on bakkot's side here, of keeping this much more generic rather than including all these grammars. For example, I'm *actively hampered* regularly by Python's type annotations being meaningless-but-interpreted, because it tries to resolve names at runtime and affects how I have to write the rest of my code. The more uninterpreted we can make this, the better. [11:11:13.0528] re: wanting a more pleasant syntax than jsdoc: just make ts accept more pleasant comment syntax than jsdoc [11:11:15.0320] jsdoc is awful [11:11:28.0421] `//: (number, number) => number` would be fine [11:12:03.0261] "doctor, it hurts when i copy Java" [11:12:10.0805] see: date [11:12:16.0417] bakkot: `Number -> Number -> Number` please [11:12:23.0126] no [11:12:24.0161] no no nono [11:12:34.0915] to what Rob said, I'd really like to never have to use TypeScript and just get shouted at by ESLint when my code doesn't match my type comments [11:12:40.0327] Curried functions strike back… [11:12:50.0900] A clearly defined generic carve out based on : would be very good progress I think [11:13:11.0275] Michael Ficarra: even haskell lets you write it either way, we can be a bit forgiving ^_^ [11:13:32.0176] before you all murder me, it was a joke! [11:13:34.0736] > <@bakkot:matrix.org> `//: (number, number) => number` would be fine I could see a potential special comment syntax [11:13:38.0514] Michael Ficarra: that's a different thing [11:13:52.0045] we have `x => y => z` and `(x, y) => z` [11:13:53.0838] like `: (number, number) => numer` maybe that would help? [11:13:57.0458] gotta be able to type both [11:14:04.0060] yes yes I know [11:14:04.0923] yulia: yeah that was my concrete proposal for new syntax [11:14:11.0939] that we say `:` is a new comment form [11:14:18.0351] look for my next proposal, removing higher-order functions [11:14:23.0090] ooh yes yeah that sounds kind of cool [11:14:27.0726] and would allow, e.g., an identifier or a paren-balanced thing after it [11:14:27.0729] I'm sad that's the perception because the way I read the minisite was that it was trying to specifically provide a root tool that can be used by Flow, TypeScript, and other types tools. [11:14:39.0415] > <@bakkot:matrix.org> that we say `:` is a new comment form Would it still resolve names in the core language? [11:14:50.0938] * > <@bakkot:matrix.org> that we say `:` is a new comment form Would it still resolve names in the core language? [11:14:55.0203] DEF STATEMENT IS_SHU_SERIOUS(INT TIMES_SHU_SHITPOSTED_TODAY_SO_FAR) { RETURN TRUE } [11:15:41.0608] TabAtkins: better make it a bigint, just to be safe [11:15:54.0509] -> go to TDZ [11:16:04.0209] apologies yulia [11:18:41.0377] Back to serious: yeah I'm 100% for being able to drop in more comment syntaxes that let us comment-annotate at a fairly tight granularity (functions, args, etc), with only the minimum amount of grammar restriction to ensure they're parseable. [11:18:58.0525] need to step away from note taking for like 2 minutes [11:19:09.0586] So we can do the "build script, but also runnable immediately" thing that was mentioned by one of the presenters. [11:20:01.0904] > <@tabatkins:matrix.org> Back to serious: yeah I'm 100% for being able to drop in more comment syntaxes that let us comment-annotate at a fairly tight granularity (functions, args, etc), with only the minimum amount of grammar restriction to ensure they're parseable. Looking at your comment about Python, you would be against any checking by ordinary JS compilers in those comments for whether identifiers are in scope, right? [11:20:46.0261] yes, god yes, that's really bad unless your language is designed up-front to have scoping/importing rules that are designed to mesh well with types [11:21:39.0054] like, Python's treatment of circular imports makes it *godawful* for this. mypy has a terrible hack around this (it sets a TYPE_CHECKING global, wherein you can import things that would cause a circular import error if done at runtime) [11:22:03.0100] Rust works good as far as I understand, for instance, and was designed from the get-go for it. [11:22:05.0542] any objections to me moving this forward? [11:22:19.0514] I think it's still productive [11:22:51.0221] I especially appreciate hearing from Flow devs on this [11:23:00.0829] am I missing something, I feel like this boils down to `adding new ways to add comments`, since most of this will be handled by IDE's, and it was said that these are handled as comments? [11:23:17.0792] > <@yulia:mozilla.org> any objections to me moving this forward? I think it not worth to add this to the language [11:23:33.0506] if you want not to focus on the syntax, don't propose a bunch of syntax [11:24:29.0447] bakkot: as daniel said, the syntax has been written by an enthusiastic community member, the champions are in favor of discussing syntax [11:25:29.0522] yeah but [11:25:35.0966] don't merge it, if you don't want to talk about it [11:25:41.0726] yes it is maybe clumsy [11:25:48.0437] jschoi: is your topic about typecheckers outreach covered? [11:25:51.0869] * jschoi: is your topic about outreach covered? [11:26:07.0306] > <@yulia:mozilla.org> jschoi: is your topic about outreach covered? Yes, thank you, I will delete. [11:26:07.0998] * jschoi: is your topic about typecheckers outreach covered? [11:26:13.0251] I think the repo does not come from ts people [11:26:17.0592] originally [11:26:43.0822] Jack Works: i didn't quite understand the malicious misleading comment. surely malicious actors can do that today in many devious ways [11:26:53.0033] Incidentally, I think the champions should consider adopting a GitHub Action that throttles new comments, like how the pipe-operator repository uses https://github.com/js-choi/github-comment-floodgate. I could not keep up with its comment traffic and had to unsubscribe. [11:26:53.0404] in a worse way, arguably, with actual program logic [11:27:01.0915] > <@rricard:mozilla.org> bakkot: as daniel said, the syntax has been written by an enthusiastic community member, the champions are in favor of discussing syntax The grammar was added by Daniel? https://github.com/giltayar/proposal-types-as-comments/commit/9dc597e69674e13098cdb830b1569f1e7d47e55c [11:27:34.0021] sure, then sorry about the confusion [11:28:27.0676] I thought it was from gil [11:29:09.0358] having been in the community meetings it did not seem they wanted to impose a syntax today [11:30:08.0172] just the idea, as all stage 0 proposals should be [11:33:27.0576] aren't those hints basically guards shu ? [11:34:23.0199] yulia: all sorts of tools rely on comment attachment: linters, templating tools, etc [11:34:30.0597] yulia: no, not guards, actually hints [11:34:34.0357] i see [11:34:41.0077] imagine `UNLIKELY_BRANCH()` [11:34:44.0303] stuff like that [11:34:49.0708] or `: this is hot` [11:34:57.0374] oh i see [11:37:29.0713] wrote up the colon thing in a little more detail: https://github.com/giltayar/proposal-types-as-comments/issues/127 [11:38:41.0089] Jack Works: I think shu meant that for the hint guided optimization, the comment space would be used for a different syntax (think asm.js), not regular TS / flow syntax [11:39:03.0071] yes, completely separate from the current types usage [11:39:23.0765] imagine each expression getting a 0-1.0 weight of hotness determined by some profiling, etc [11:39:53.0738] > <@bakkot:matrix.org> wrote up the colon thing in a little more detail: https://github.com/giltayar/proposal-types-as-comments/issues/127 it's interesting, I just have one question: how do you delimit the end of that comment? [11:40:06.0969] " a colon followed by an identifier, possibly with a following no-lineterminator-separated balanced-braces block" [11:40:31.0186] * " a colon followed by an identifier, possibly with a following no-lineterminator-separated balanced-braces block" [11:40:44.0276] all braces right? [11:40:50.0148] yeah [11:40:54.0893] or, for some definition thereof [11:41:00.0908] I imagine Svelte and other languages that want to extend/modify the language in interesting ways wouldn't mind that proposal 🤔 [11:41:10.0782] * I imagine Svelte and other languages that want to extend/modify the language in interesting ways wouldn't mind that proposal 🤔 [11:41:16.0358] again, very much looking forward to not having to use TypeScript for types and just get free type checking from ESLint :P [11:41:18.0123] yes exactly that is a huge use case for this (replying to pzuraq ) [11:41:33.0721] probably not quotey brackets [11:41:34.0540] * yes exactly that is a huge use case for this (replying to pzuraq ) [11:41:57.0857] reorged the queue to allow support statements at the end [11:42:04.0916] and all topics to be covered before [11:42:28.0656] we have 18 minutes, so please add your items to the queue so that any new topics can be covered before the end of the time box [11:42:36.0765] I imagine Node.js could also have "validate types" as a runtime option and eject if types fail, again without TypeScript or Flow or whatever the next cool types tooling is. [11:42:48.0308] Robin Ricard: specifically bakkot 's proposal, with leading `:` on statements [11:43:06.0214] looks a lot like the way they use labels [11:43:13.0094] > <@shuyuguo:matrix.org> Jack Works: i didn't quite understand the malicious misleading comment. surely malicious actors can do that today in many devious ways malicious type comments are more deceptive than the normal comment [11:43:20.0097] I did mean in general but bakkot 's idea achaieves that goal [11:43:22.0630] > <@bitandbang:matrix.org> I imagine Node.js could also have "validate types" as a runtime option and eject if types fail, again without TypeScript or Flow or whatever the next cool types tooling is. This would require standardizing the type system itself though, wouldn't it? [11:43:30.0286] I still feel like this proposal is "what could we do with different types of more granular comments?" which is an interesting question but just doesn't qualify as a problem statement for stage 1 [11:43:55.0328] the problem to be solved is "I want to write type annotations and not strip them before running code on a real engine" [11:44:03.0437] you have a different problem in mind than the champions [11:44:11.0273] but they've been fairly clear about what the problem they're interested in is [11:44:35.0128] yes, i think the replies to my question made that clear that the thing i noticed is really an unintended consequence [11:44:35.0338] their response to Shu was "yeah maybe we could do that too" [11:44:38.0993] > <@lucacasonato:matrix.org> This would require standardizing the type system itself though, wouldn't it? Would it? Given the most basic definition in this specification, _if_ Node.js parsed the comments and validated them, I don't know if it would. I could absolutely be wrong, though. [11:44:43.0053] > <@bakkot:matrix.org> the problem to be solved is "I want to write type annotations and not strip them before running code on a real engine" and solving this opens up a bunch of possibilities for both end users and tools developers [11:44:59.0712] > <@bitandbang:matrix.org> Would it? Given the most basic definition in this specification, _if_ Node.js parsed the comments and validated them, I don't know if it would. I could absolutely be wrong, though. I guess it depends on what "validate" means. Does validate == type check? [11:45:24.0068] also I'd like to understand WHY they want to write the types inline, if they have no effect, and they're not fully compatible with TypeScript types [11:46:08.0049] > <@lucacasonato:matrix.org> I guess it depends on what "validate" means. Does validate == type check? "eject on mismatch between reality and type comment" is what I mean and also could probably be defined as type checking [11:46:51.0774] > <@bitandbang:matrix.org> "eject on mismatch between reality and type comment" is what I mean and also could probably be defined as type checking Ok, I don't think that would be possible with the current scope of the proposal. [11:47:01.0832] > <@lucacasonato:matrix.org> Ok, I don't think that would be possible with the current scope of the proposal. fair enough :) [11:47:13.0933] yulia: before we ask for stage 1 advancement, I'd like the champions to explicitly restate the problem that we've identified [11:47:36.0368] I will raise it before we go to stage advancement discussion [11:47:42.0255] thank you [11:48:24.0735] > <@michaelficarra:matrix.org> also I'd like to understand WHY they want to write the types inline, if they have no effect, and they're not fully compatible with TypeScript types they said that too: it makes the build loop smaller, particularly for small projects and newbies [11:49:20.0889] bakkot: build loop of what? what have they written? [11:51:17.0904] of... programs... [11:51:21.0075] I can't find my earlier comment on that, but what if you could open your editor, write some typescript code and run it in your browser [11:51:26.0563] without touching stuff like npm [11:51:38.0173] I will move the support comments quickly [11:51:41.0365] please keep them short! [11:52:38.0571] The "inner loop" is the "write code, then run code" - if you're writing TS itself there's a third step of "transpile code" inbetween those two, which this proposal lets the authors avoid until they actually want to check their types [11:52:55.0169] as a data point, I've seen people actually avoid using TS syntax despite wanting strong types/IDE support specifically because they prefer the ability to copy/paste JS into a repl [11:52:56.0772] Robin Ricard: many delegates have said that they would oppose adding he full typescript syntax here, so that is not a covered use case [11:53:07.0642] they try to use JSDoc comments, but it's not great [11:53:07.0668] Ashley Claymore: I'm +1 to your +1 comment in the queue: this proposal set good rulers for the syntax that will support TC39 and superset frameworks such as TypeScript to expand syntax capabilities. [11:53:19.0928] > <@michaelficarra:matrix.org> Robin Ricard: many delegates have said that they would oppose adding he full typescript syntax here, so that is not a covered use case ok I meant subset of ts code [11:53:24.0695] so I think the DX improvements of having these inline comments would actually be meaningful [11:53:29.0274] that happens to match this proposal [11:53:32.0568] And yeah, avoiding that required transpile step in my inner loop is precisely why *I* don't use TS right now. [11:53:47.0176] I actually meant writing ts in those comments [11:54:23.0470] then I refer back to Waldemar's comment about creating some weird hybrid between TS and JS [11:54:24.0113] yeah you couldn't use actual typescript with this proposal, they'd have to change TS syntax [11:54:41.0583] at which point... https://github.com/giltayar/proposal-types-as-comments/issues/127 [11:54:44.0674] yep sorry I confused things here [11:54:56.0079] I'd be more interested in advancing this after TS/Flow devs expressed interest in making the proposed syntax valid in their languages [11:55:24.0385] Michael Ficarra: perhaps a good reply to current topic? [11:55:27.0738] that actually is the current question [11:56:29.0107] Jack Works: since we are low on time, can we move on to summarization? [11:56:33.0544] HTML inline comments can be considered a precedent for this proposal. Not a joke. [11:56:47.0785] ok we have two such comments [11:57:02.0124] yep that is fine [11:57:20.0120] jsut wanted to make sure this got visible on the queue [11:57:58.0064] HE Shi-Jun: sorry, we are out of time so I am cutting the queue now [11:58:03.0730] please feel free to bring this up in the issue tracker [11:58:11.0594] I am people [11:58:22.0891] I am people too [11:58:30.0885] problem statement needs to include "and there is no way to do this with existing comment syntax", which I am still not convinced of [11:58:56.0213] * problem statement needs to include "and there is no way to do this with existing comment syntax", which I am still not convinced of [11:59:40.0719] fwiw i still think "does TC39 care about long-term unforking of vastly popular JS forks" is a pretty important problem for the ecosystem [11:59:55.0221] just not one our composition is well suited for discussion [12:00:15.0981] shu: we can have a longer/open-ended discussion topic for it one day [12:00:20.0153] +1 [12:00:39.0021] > <@bitandbang:matrix.org> I am people I agree, we should narrow the gap between js/ts , at least we should clearly reserve some syntax for that. [12:01:17.0757] I guess I can get behind stage 1 for making it more ergonomic to represent metadata in comments, but I don't see it working out well without major changes in TS/Flow [12:01:19.0317] is anyone uncomfortable with the presented developer experience? [12:02:20.0701] ts/flow would probably need to run stuff by tc39 in this thoeorical unforked future before adding things [12:02:20.0849] We can't separate TypeScript from the Ecosystem. [12:02:28.0714] it's not all the JS Ecosystem, but a very relevant part of it. [12:02:36.0575] > <@michaelficarra:matrix.org> I guess I can get behind stage 1 for making it more ergonomic to represent metadata in comments, but I don't see it working out well without major changes in TS/Flow * ts/flow would probably need to run stuff by tc39 in this thoeorical unforked future before adding things [12:02:48.0171] Extremely -1 on a typescript mode [12:03:18.0704] Robin Ricard: we would probably only be willing to carve out a narrow (but infinite) syntax space for them, like what bakkot suggested, and they will need to adapt [12:03:43.0165] I like shu's suggestion of adding a more general feature of comments that are directly tied to syntax objects. Such comments could be use for multiple purposes, as he pointed out. I feel like people got distracted by his suggested other purposes and didn't understand what he was actually proposing. [12:03:47.0644] I feel the ecosystem is already JS/TS , at least 50% JS devs are actually writing TS every day 😅 [12:03:59.0830] SoftwareChris: we had a clarification regarding the problem statement, should it be restated? [12:04:20.0802] can't we conclude that the remainder of the TS features are aimed at "power users" and thus behind the compile wall? [12:04:33.0497] > <@michaelficarra:matrix.org> Robin Ricard: we would probably only be willing to carve out a narrow (but infinite) syntax space for them, like what bakkot suggested, and they will need to adapt I am not a ts team member so I can't speak for them but yea that should probably be considered [12:04:34.0361] there are two parts: 1) ergonomic types as comments that run in the browser 2) consolidating popular js forks is a problem, and ts is very popular [12:04:37.0295] and that we only need the small common denominator of features instead [12:04:52.0082] > <@usharma:igalia.com> can't we conclude that the remainder of the TS features are aimed at "power users" and thus behind the compile wall? I like that phrasing [12:04:57.0253] I think the problem spaces could be "narrowing the gap between JS and TS/flowtype/any other type checkers ... [12:04:57.0609] ryzokuken: sure yeah, but then we've created a hybrid/in-between language that people need to know [12:05:30.0560] it's just JS, people are writing JS with additional optional comments, right? [12:05:52.0158] my hope is that by carving out a space (like I proposed), then TS (and flow, and other tools) could move to that space [12:06:55.0048] > <@yulia:mozilla.org> there are two parts: 1) ergonomic types as comments that run in the browser 2) consolidating popular js forks is a problem, and ts is very popular SoftwareChris: [12:07:08.0693] > <@yulia:mozilla.org> there are two parts: 1) ergonomic types as comments that run in the browser 2) consolidating popular js forks is a problem, and ts is very popular is this the problem statement? [12:07:23.0212] the first is a solution, and the second states a problem without describing why/how it's a problem [12:07:34.0859] "standardize somewhat the hitherto non-standard type annotation syntax that is massively popular and essentially a de-facto standard" [12:07:42.0012] this is what was described by the champions [12:08:02.0300] ok so i still don't see a problem statement [12:08:10.0092] ljharb: to be fair, it's a lot closer to a problem statement than where we started! [12:08:27.0892] true [12:09:21.0328] ljharb: do you mean it's not a problem statement in the sense that you disagree those are problems? [12:10:15.0076] no, i mean that the problem is implicit and i don't understand what it is [12:10:30.0116] "consolidating popular JS forks" is not a problem, it's an action [12:10:38.0111] what problem does consolidating those solve [12:10:41.0382] * what problem does consolidating those solve [12:10:47.0933] "there are many unconsolidated forks" is a problem [12:10:52.0922] 1. It in currently difficult to express type information in the language in an ergonomic manner, which has led to 2. divergence/forking of the language which erodes TC39 as the primary venue for determining and expanding the syntax of the language [12:10:52.0924] at least, some people regard it as such [12:11:05.0233] does that sound more like a problem statement? [12:11:30.0251] i understand 1) to mean "some people don't like transpilation steps, and want to get rid of them" and i meant 2) as "TC39 cares about its own primacy and about JS's primacy, presumably, and forking and the rising popularity of forks is a problem" [12:12:05.0721] pzuraq: thank you, yes, that is much better [12:12:18.0559] "some people don't like transpilation steps" is not a problem i want TC39 to explore further, so hard block on stage 1 for that [12:12:20.0318] > <@pzura:matrix.org> does that sound more like a problem statement? it's definitely better [12:12:20.0613] danielrosenwasser: are you available at the end of day 4 (thursday)? [12:12:23.0156] we have 30 min [12:12:23.0225] Wait, sorry—did it reach Stage 1? [12:12:27.0640] * "some people don't like transpilation steps" is not a problem i want TC39 to explore further, so hard block on stage 1 for that [12:12:39.0394] jschoi: nope [12:12:51.0104] Thanks! [12:12:57.0501] so, I would actually have gone for a different problem statement, which is, "the current syntax forms for comments are unergonomic to use as inline annotations, which has lead to forks of the language" [12:13:05.0515] +1 [12:13:20.0403] "people want to use types without stripping them" is a subset of that problem [12:13:23.0274] either one of those (bakkot's and pzuraq's) are actual problem statements that can be meaningfully discussed [12:13:27.0814] * either one of those (bakkot's and pzuraq's) are actual problem statements that can be meaningfully discussed [12:13:34.0307] Jack Works: my only point was that you said something like "we should try to add those transpilers in the devtools" and i just wanted to respond that we can only have that be a *request*, not a requirement [12:13:36.0109] thank you [12:14:00.0167] so are those of us that like dynamic/weak typing going to be dragged kicking and screaming into the world of strong typing? asking for a friend [12:14:14.0315] did everyone understand Shu's comment about this proposal allowing for "unambiguous comment attribution" (that is, attribution to AST nodes) [12:14:31.0718] comment attachment is definitely an issue for tooling [12:14:36.0577] it would be *really* cool to have a kind of comment that is syntactically associated with a specific non-comment parse node [12:14:43.0750] SoftwareChris: the only comment in the direction of having actual types has been from Waldemar. champions have strongly disavowed that as a goal thus far [12:15:04.0006] trailing/leading/dangling comments are a heuristic nightmare for AST tooling [12:15:06.0739] SoftwareChris: I think the fact that this proposal isn't actually trying to add real typing shows that's not the case? [12:15:26.0741] > <@softwarechris:matrix.org> so are those of us that like dynamic/weak typing going to be dragged kicking and screaming into the world of strong typing? asking for a friend `// tool-disable-checking-next-line` is your new best friend! :D [12:16:07.0332] > <@aclaymore:matrix.org> `// tool-disable-checking-next-line` is your new best friend! :D Y I K E S [12:16:15.0350] FWIW I was quite skeptical of strong typing for some time after a few years of terrible Java/C experiences, but I've come around to enjoying the latest wave of typed languages a lot [12:16:35.0058] Types as Comments strives to provide a foundational building block within the language upon which type systems can grow off of. Having such a system tackles multiple problems on different parts of the ecosystem: - it enables JavaScript developers to have portable/transferrable knowledge of types, so they can write the same code but change tooling as needed - it reduces the necessity for a build step, benefetting both tooling developers by allowing them to simplify their tools and end-users in having faster build times Additionally, both of those end up benefitting the overall ecossytem in that we get a lower barrier to types and the resources of a Microsoft or a Facebook aren't required to build nifty and useful tooling around types which helps support the next innovation in types. [12:16:46.0174] ^ my thoughts as someone who didn't contribute to the proposal and is relatively anti-typescript in their own projects [12:17:04.0214] but I still think that weak JS should always be an option, I drop down to it on occasion when I'm just sketching things out [12:17:14.0555] "actual comments" would work fine for those purposes too tho [12:17:21.0091] they're just slightly less ergonomic, and attachment is trickier [12:17:25.0140] * ^ my thoughts as someone who didn't contribute to the proposal and is relatively anti-typescript in their own projects [12:17:35.0424] ljharb: that gap is worth closing IMO [12:17:58.0655] ljharb: the existence of another language specifically to close that gap is pretty solid evidence that the ergonomics are not good enough, no? [12:17:58.0700] > <@ljharb:matrix.org> "actual comments" would work fine for those purposes too tho I mean, they would have worked from Day 0 of JavaScript but yet we have TypeScript. [12:18:01.0511] it's infinitely trickier, in some sense (ambiguous, undecidable) [12:18:21.0957] The fact that they haven't really been selected as a solution by the community is telling imo [12:18:23.0995] day zero of typescript included runtime features as well [12:18:34.0540] and at that point, why not also have non-comment syntax forms [12:18:36.0634] * it's infinitely trickier, in some sense (ambiguous, undeciable) [12:18:46.0906] flow is a better example, I think [12:18:50.0782] * it's infinitely trickier, in some sense (ambiguous, undecidable) [12:18:53.0436] since it's always, only, been type annotations [12:19:05.0553] (afaik) [12:19:25.0096] > <@pzura:matrix.org> SoftwareChris: I think the fact that this proposal isn't actually trying to add real typing shows that's not the case? maybe, but it runs the risk of becoming the de facto standard, at least as it currently appears in the proposal [12:19:34.0989] > <@bakkot:matrix.org> and at that point, why not also have non-comment syntax forms does this mean actual types? [12:19:54.0154] > <@bakkot:matrix.org> since it's always, only, been type annotations Flow also has enums :) [12:19:57.0350] the "as comments" part of it is a bit misleading [12:19:59.0545] SoftwareChris: why would anything in this proposal impact someone who wanted to write plain JS? [12:20:10.0363] > <@aclaymore:matrix.org> Flow also has enums :) oh, booooo [12:20:13.0689] guess I forgot that [12:20:32.0062] > <@pzura:matrix.org> SoftwareChris: why would anything in this proposal impact someone who wanted to write plain JS? if it's new syntax standardized, then it _is_ plain js [12:20:49.0031] that's dodging the question [12:21:12.0829] why would anyone who wants to write JS w/o comments be impacted? [12:21:20.0023] > <@bitandbang:matrix.org> does this mean actual types? I don't know what "actual types" means. what I'm saying that if you're already committed to not being legal JS (because you have `enum` and whatever), it makes a lot more sense to also add other new syntax, as typescript has done [12:21:29.0185] folks -- its getting a bit spicy in here [12:21:36.0546] that does not, in itself, mean that comments would not be adequate for the goal of _just_ having types [12:21:44.0275] if you set out to do that in the first place [12:22:00.0725] > <@bakkot:matrix.org> I don't know what "actual types" means. what I'm saying that if you're already committed to not being legal JS (because you have `enum` and whatever), it makes a lot more sense to also add other new syntax, as typescript has done I guess I'm confused where not being committed to being legal JS is coming from [12:22:03.0553] see my comment about it becoming the de facto standard (way of writing js) [12:22:18.0113] Tierney Cyren: all the runtime stuff they had at the beginning [12:22:18.0328] > <@pzura:matrix.org> why would anyone who wants to write JS w/o comments be impacted? * see my comment about it becoming the de facto standard (way of writing js) [12:22:21.0153] enums and decorators and stuff [12:22:26.0748] ah [12:22:39.0683] I might have been devouring a subway sandwich during that part [12:22:50.0336] SoftwareChris right, but the standard doesn't actually prevent you from writing code not in the standard. Are you worried that companies and teams will decide to adopt it, and so it might be difficult to find a codebase to work in regularly that does not use these comments? [12:22:58.0963] I'm just trying to understand what the concern is, concretely [12:23:25.0265] SoftwareChris: well, TS's meteoric rise and widespread penetration means that ship has sailed for now from where i'm sitting [12:24:32.0359] bakkot: to be clear, the ts team is not specifically recommending the use of "runtime" features like enums, namespaces, and we are seeing all new feature just be purely in the "type world" [12:24:55.0657] right, but I'm talking about the history here [12:25:27.0606] ok I'm a bit brain fried [12:25:36.0932] I'm just saying that the existence of typescript using non-comment syntax for types does not _in itself_ prove that comment are not adequate for types, since when TS made the decision to not use the existing comment syntax it was basically costless, because they wanted runtime stuff, and so there was no point to being legal JS. [12:26:01.0678] (Separately, I can see an argument that the existing comment syntaxes are not adequate for types. My claim is just that the existence of TS, in itself, does not establish this.) [12:26:12.0504] * (Separately, I can see an argument that the existing comment syntaxes are not adequate for types. My claim is just that the existence of TS, in itself, does not establish this.) [12:26:20.0956] yes but today I can use a purely non-runtime affecting ts [12:26:52.0782] and that is actually what I do as I specifically use linters to prevent me from writing ts that generates additional js [12:26:59.0838] but you _can't_ use just comments and still use TS, except for a subset of the language and with awful ergonomics [12:27:11.0710] but that is a contingent fact about what TS has implemented, not a fact inherent in the world [12:27:22.0219] bakkot: I think the rotation on TS is because ergonomics issues in general are really, really hard to argue, because inherently they don't really have a basis in anything other than "devs like to do it this way, generally". So we have to rely on evidence for what has actually worked in the ecosystem and what hasn't [12:27:26.0986] I need colon syntax and a few statements that I wouldn't mind prefixing with colon [12:27:44.0134] > <@pzura:matrix.org> SoftwareChris right, but the standard doesn't actually prevent you from writing code not in the standard. Are you worried that companies and teams will decide to adopt it, and so it might be difficult to find a codebase to work in regularly that does not use these comments? to be clear, my original comment was probably better suited for #temporaldeadzone:matrix.org but there is some concern there. I'm not 'worried' about it. but I think it requires more attention and deliberation than the "as comments" aspect would seem to suggest. still think we need a better term for it than comment, as an aside [12:27:45.0216] JSDoc has been around for decades, but it never got mainstream adoption, never got phenomenal IDE support, never was expanded upon [12:27:51.0045] I can do most of my work including complex generic types in that space [12:28:03.0627] TS has been around for less than a decade and has gotten much much further in that space [12:28:06.0906] > <@pzura:matrix.org> JSDoc has been around for decades, but it never got mainstream adoption, never got phenomenal IDE support, never was expanded upon JSDoc didn't have an actual working type system to use with it [12:28:15.0692] JSDoc was just about generating API docs, it wasn't for type checking [12:28:24.0729] One issue with existing comment syntax, that I've mentioned before, is that `/* */` style comments can't be nested. And putting `///` at the start of every row really needs editor support to type ergonomically. [12:28:28.0791] ljharb: the ability to define a type system in comments has always been there, is my point [12:28:30.0783] and tsc's jsdoc dialect is missing a ton of TS features and also has a bunch of things that just don't work [12:28:38.0555] > <@ljharb:matrix.org> JSDoc didn't have an actual working type system to use with it I mean, this doesn't really negate the point IMO [12:28:42.0247] pzuraq: right, but that nobody's done it doesn't prove it can't be done [12:28:43.0820] JSDoc is just the closest we got to it [12:28:55.0071] flow is the closest we got [12:28:55.0139] again, not hard evidence here, soft evidence [12:28:56.0716] JSDoc was always *zero* about types. it was about documentation. [12:28:57.0730] if an ecosystem type system in comments hasn't evolved and gained mass adoption at this point, I don't think it will. [12:28:59.0747] flow's type comments are much nicer than jsdoc [12:29:13.0352] https://github.com/giltayar/proposal-types-as-comments/issues/41 [12:29:16.0729] https://flow.org/en/docs/types/comments/ [12:29:28.0095] * if an ecosystem type system in comments hasn't evolved and gained mass adoption at this point, I don't think it will. [12:29:38.0797] much, much nicer [12:30:08.0636] And even though Flow supports that, they still built flow-syntax parsing into their JS engine :) [12:30:28.0359] I mean if you're gonna build a js engine, why not, right [12:30:49.0139] ljharb: sure, but the counter argument to this feature is "we could just do that in comments" and the reality is no one has done that, despite having decades of opportunity. So my point is this is soft-evidence that the concern is real and possibly worth addressing. [12:30:58.0227] nothing _can_ be definitely proven here, IMO [12:31:16.0773] sure [12:31:17.0645] I tried to do a flow comments codebase back 3 years ago. After 2 weeks the team was begging me to remove them [12:31:34.0512] It’s good for fast prototyping [12:31:37.0558] because of comments tho, or because flow's error messages were, at least at that time, inscrutable? [12:31:43.0639] Same for jsdoc comments [12:31:54.0474] Yea the code would be taken over by comments [12:32:01.0914] same tho. nobody's denying TS's usability improvement over the alternatives [12:32:07.0942] Maybe a better syntax highlighting would have helped [12:32:08.0131] I also tried `/*` style type comments and my little pinky finger was not up to the amount of `/` I had to type [12:32:15.0118] but "taken over by types" and "taken over by comments that are types" seems the same to me [12:32:50.0139] > <@bakkot:matrix.org> so, I would actually have gone for a different problem statement, which is, "the current syntax forms for comments are unergonomic to use as inline annotations, which has lead to forks of the language" ^ [12:33:04.0843] espeically as `/*:` is all on the right hand - really RSI inducing [12:33:16.0104] I think I can buy that `/*: number */` is enough worse than `: number` that it constitutes a problem worth solving [12:34:35.0673] > <@ljharb:matrix.org> but "taken over by types" and "taken over by comments that are types" seems the same to me Taken over by comment delimiters specifically [12:35:33.0331] > <@yulia:mozilla.org> danielrosenwasser: are you available at the end of day 4 (thursday)? Yes, should be free yulia [12:36:00.0382] good, i reserved 15 minutes so we can do clean up / incubator call stuff [12:36:35.0476] in terms of innovation, a question that was asked during plenary. It feels liberating if bundlers and minifiers could forget about keeping up to date with supporting different type syntaxes, and instead use that effort for their primary use-case [12:36:47.0577] * in terms of innovation, a question that was asked during plenary. It feels liberating if bundlers and minifiers could forget about keeping up to date with supporting different type syntaxes, and instead use that effort for their primary use-case [12:37:19.0820] not sure if the 'problem statement' was settled but in any case, can the proposal be updated with it? [12:41:18.0132] > <@aclaymore:matrix.org> in terms of innovation, a question that was asked during plenary. It feels liberating if bundlers and minifiers could forget about keeping up to date with supporting different type syntaxes, and instead use that effort for their primary use-case bundlers in particular would benefit, but many tools, like prettier, would actually need to parse the types themselves, and so would still rely on the more specific grammar which TS or flow or whatever actually used [12:45:12.0203] at the last tools outreach call, I can't remember the name of the engineer, but someone on the eslint team ( I think ) said that one benefit is that it would make the plugin size smaller [12:45:51.0059] e.g. for prettier. Prettier could mostly use its own parser, and then when it sees a type-comment only defer that part to plugins, and if the plugin fails it can gracefully fallback to treating it as a comment [12:46:00.0156] > <@dcrousso:matrix.org> Jack Works: my only point was that you said something like "we should try to add those transpilers in the devtools" and i just wanted to respond that we can only have that be a *request*, not a requirement adding it to the language is request every engine to implement it, I think they're the same thing [12:46:01.0793] having worked with those tools though it would significantly simplify them if the syntax was valid JS [12:46:09.0281] > <@bakkot:matrix.org> bundlers in particular would benefit, but many tools, like prettier, would actually need to parse the types themselves, and so would still rely on the more specific grammar which TS or flow or whatever actually used Prettier would not necessarily have to understand the type-annotation grammar if it has some generic prettifying algorithm, right? [12:46:16.0100] * e.g. for prettier. Prettier could mostly use its own parser, and then when it sees a type-comment only defer that part to plugins, and if the plugin fails it can gracefully fallback to treating it as a comment [12:46:19.0680] prettier does not have some generic prettifying algorithm [12:46:29.0310] I mean for the annotated types. [12:46:33.0639] * I mean for the annotated types. [12:46:46.0907] I don't think you could write a semantics-agnostic algorithm for that [12:47:10.0877] people want to replace `type x = { a: number, b: number }` with `type x = { a: number; b: number }`, e.g. [12:47:23.0591] and you can't just like `s/,/;/g` [12:47:33.0796] right now prettier will fail to format the entire file if one line has one new bit of TS syntax that it hasn't yet added support for. With type-comments it would have a way to gracefully fail only for the parts with the unsupported syntax [12:47:37.0397] you have to actually understand the ast [12:47:39.0652] > <@bakkot:matrix.org> people want to replace `type x = { a: number, b: number }` with `type x = { a: number; b: number }`, e.g. I suppose that is a dialect-specific problem, yes. [12:47:44.0344] Yeah, what Ashley said. Graceful degradation. [12:47:47.0847] Or progressive enhancement. Whatever. [12:47:55.0539] * Yeah, what Ashley said. Graceful degradation. [12:48:30.0745] right now most projects have to wait until all their tools support new type syntax before they can use it anywhere. Being able to do that more gradually would be lovely [13:04:00.0462] Having made a variety of contributions to Prettier, I do not see at all how it would be possible to have some kind of "progressive enhancement" or "graceful degradation" - we would be talking about creating a whole new tool [13:05:05.0773] > <@jackworks:matrix.org> adding it to the language is request every engine to implement it, I think they're the same thing i feel like we're talking past eachother here a bit. are you suggesting that we consider the TypeScript transpiler "standardized"? or are you just suggesting that we add developer tooling support for the types as comments proposal that was presented earlier today? [13:08:19.0459] > <@dcrousso:matrix.org> i feel like we're talking past eachother here a bit. are you suggesting that we consider the TypeScript transpiler "standardized"? or are you just suggesting that we add developer tooling support for the types as comments proposal that was presented earlier today? if the core need of the proposal is to run code without transpile, devtools built-in ts & flow transpile can help people so we don't have to add that in the core language 👀 [13:09:42.0205] > <@jackworks:matrix.org> if the core need of the proposal is to run code without transpile, devtools built-in ts & flow transpile can help people so we don't have to add that in the core language 👀 sure, but TS/Flow/etc. is *not* standardized, so we as a standards body cannot *require* that developer tooling (which are all also *not* standardized) add support [13:10:12.0698] > <@gkz:matrix.org> Having made a variety of contributions to Prettier, I do not see at all how it would be possible to have some kind of "progressive enhancement" or "graceful degradation" - we would be talking about creating a whole new tool Interesting! Even if it takes effort to architect to support it I think the proposal adds a new avenue of innovation there. It was explained to me similar to how tools support codeblocks in markdown [13:10:38.0884] like i dunno that WebKit would want to add support for TS in Web Inspector given the cadence or release cycles, availability of engineers, etc. [13:12:25.0663] And even if dev tools add support via plugins/extensions. It doesn’t solve the issue of the grammar ambiguity between js-with-types and official js. [13:14:00.0721] > <@dcrousso:matrix.org> sure, but TS/Flow/etc. is *not* standardized, so we as a standards body cannot *require* that developer tooling (which are all also *not* standardized) add support That's right, so I think we should make friendly advice them to add. If they are added, we can be free from adding a bench of syntax that doesn't do anything [13:15:19.0302] ok cool that sounds fine 🙂 [13:15:23.0526] friendly advice is good [13:16:40.0307] An example, Firefox devtools support syntax highlighting for JSX [13:18:17.0720] 😴 really need get to sleep, see you tomorrow [13:28:15.0034] > <@gkz:matrix.org> Having made a variety of contributions to Prettier, I do not see at all how it would be possible to have some kind of "progressive enhancement" or "graceful degradation" - we would be talking about creating a whole new tool FWIW I think ESLint would benefit here moreso than Prettier [13:29:17.0413] Agreed that with Prettier you pretty much have to make a whole new tool for each language combination, it's really hard to do generic things (built a few plugins for templates-in-js type things) [15:15:58.0894] terrifying reorg lol https://gc.gy/116297145.png 2022-03-30 [21:27:16.0364] > <@shuyuguo:matrix.org> fwiw i still think "does TC39 care about long-term unforking of vastly popular JS forks" is a pretty important problem for the ecosystem this is the only reasonable goal for me that might push this proposal forward, to unfork the fork but that also skeptical. Remember CoffeeJS? If TypeScript no longer popular like CoffeeJS used to? [21:55:40.0194] coffeescript, is maybe what you're thinking of? but that wasn't really a fork, it was just a different language which compiled to JS [00:13:14.0965] coffeescript did _fork_ the community though. es2015 brought a lot of folk back to js [00:15:16.0511] I’m not sure if cs directly motivated any of the design of es2015. Maybe those who were involved will recall? [00:18:32.0925] Maybe the same happened with Java? Have recent versions been motivated by people’s adoption of Kotlin (Kotlin feels more like Java++ compared to other jvm languages like Scalar/Clojure that feel like entirely separate languages) [00:25:02.0109] > <@jackworks:matrix.org> That's right, so I think we should make friendly advice them to add. If they are added, we can be free from adding a bench of syntax that doesn't do anything _friendly advice_ is still not a requirement for stage advancement, no? [05:09:07.0192] > You’ve been removed from the "Delegates" team on the "Ecma TC39" organization. Got that email from GitHub, but didn't really see anything explaining it [05:11:21.0019] Oh, I think I see what it might be [05:11:23.0176] Teams are being reorganized. No permission changes should have taken place [05:12:02.0206] You are now in the Member: Mozilla team which is a child of the Delegates team [06:54:52.0218] *** Plenary begins in 5 mins! *** [07:12:30.0801] I understand that the scope is "whatever is in CLDR" [07:12:50.0501] which is maybe not the best definition but does tend to be what most languages do, as I understand it [07:13:21.0252] > Meta: What's the end-game for Intl? Is it ICU4JS? [07:13:25.0215] why not 👀 [07:13:36.0921] otherwise people will bring their own ICU4JS [07:13:50.0386] waldemar: the CLDR data file is at https://github.com/unicode-org/cldr/blob/main/common/supplemental/units.xml#L272 [07:28:44.0871] I don't disagree with Chip here, but if we wanted to have this discussion, it should've been a "discussion" topic on the agenda [07:31:12.0251] the point about person heights using different units depending on the actual height involved is a good one, I think [07:31:22.0660] hard to convey that properly in just a "what units are preferred" query [07:32:04.0533] > <@bakkot:matrix.org> the point about person heights using different units depending on the actual height involved is a good one, I think wait really? like if someone is over a certain height, they switch to metric [07:32:17.0397] no they switch between "feet and inches" to just "inches" [07:32:21.0037] for heights under 3 feet [07:32:22.0232] in the US [07:32:24.0844] ... apparently [07:32:32.0642] fascinating, TIL [07:33:23.0448] > <@bakkot:matrix.org> no they switch between "feet and inches" to just "inches" Ha, I never thought about this, but it is true for heights [07:33:52.0073] a lot of that data has ranges listed: road lengths are miles when long but feet when short [07:34:05.0434] ah yes that one is true [07:34:22.0993] this makes me feel really weird [07:34:26.0745] I would definitely be in favor of making TG2 more autonomous. I'm sure Chip and I are not the only people who tend to zone out during Intl proposal discussions. [07:34:32.0093] they also change the rounding precision: above 100 feet, round to the nearest 10, below round to the nearest 1 [07:34:37.0097] i have blocked stage 1 on this, i just feel like he wasn't prepared [07:34:58.0929] wait yulia did you block stage 1 [07:35:03.0164] the notes do not say that [07:35:03.0294] no [07:35:07.0072] i feel bad that i didn't [07:35:28.0702] the problem statement _is_ what stage 1 is for [07:35:35.0655] yulia: plenary is not over [07:35:50.0916] i actually do not understand any more why 402 is not just a different body with a different process altogether [07:35:51.0285] im not going to block, i understand that he won't have time to work on this if it isn't stage 1 [07:36:10.0013] shu: because we have not made it so [07:36:11.0608] but we could! [07:36:12.0538] seems to make more sense to tie their process closer to unicode cadence, have better liaising there [07:36:14.0319] but it feels unfair to allow this to stage 1 when other proposals without problem statements are blocked on this [07:36:16.0393] but also a bunch of the work there is API design [07:36:19.0222] well why did they even end up in Ecma? [07:36:26.0434] I would support intl having powers to advance up to stage 2 [07:36:46.0648] yulia: that sounds great [07:36:56.0675] your invariants notion would help to that end [07:37:17.0735] i think the only things we might have to comment on could be captured in invariants in general [07:37:19.0265] i guess there's no great non-web-biased body that standardizes JS APIs [07:37:23.0066] this however [07:37:42.0294] > <@bakkot:matrix.org> but also a bunch of the work there is API design ^ this sorry* [07:37:45.0303] I think we definitely would comment on the API design, even beyond invariants [07:37:57.0689] we benefit from the discussion in plenary around API design [07:38:00.0640] though, in practice we don't, much [07:38:06.0460] > <@kriskowal:matrix.org> your invariants notion would help to that end yeah its been a rough beginning to the year, I still have it on my desk [07:38:07.0921] > <@bakkot:matrix.org> I think we definitely would comment on the API design, even beyond invariants like, our experience so far is that limiting stage advancement powers to TG1 has not stopped weird API designs [07:38:16.0170] > <@shuyuguo:matrix.org> i guess there's no great non-web-biased body that standardizes JS APIs We are that body. 🥲 [07:38:19.0415] well, that's on us [07:38:51.0627] i know, but unless people are going to start zoning in, or we own up to reality and cede that watchdog power? [07:39:19.0857] i guess having the invariants written down would be a requirement, and that would reduce the level of review necessary [07:39:29.0412] you would still need to review, but certain things would be a given [07:40:03.0662] the TG2 group is fairly honest at keeping ourselves up to the standards Zibi and Shane talked about [07:40:12.0985] > <@shuyuguo:matrix.org> like, our experience so far is that limiting stage advancement powers to TG1 has not stopped weird API designs iterator subclassing trees come to mind [07:40:49.0004] like i have no idea what is going on in this preso [07:41:28.0548] the thing going on in this presentaiton, as far as I can tell, is that there is a specific text format for templates which people want to use for messages which get formatted in different languages [07:41:43.0036] so the proposal is to bring in that parser and its corresponding template engine [07:41:52.0424] ryzokuken: the editor groups should collaborate more; frankly, I don't think 402 has the same editorial quality that 262 has [07:42:14.0644] this template format is further standardized/being standardized by Unicode? [07:42:19.0150] well, I'd be happy to fix that! [07:42:19.0828] * this template format is further standardized/being standardized by Unicode? [07:42:31.0183] yeah [07:42:31.0782] or [07:42:33.0125] by someone [07:42:34.0991] not sure by unicode [07:42:44.0209] I think Unicode [07:42:48.0219] > <@michaelficarra:matrix.org> ryzokuken: the editor groups should collaborate more; frankly, I don't think 402 has the same editorial quality that 262 has perhaps we could start dropping by the editors meeting? [07:42:52.0559] yes, unicode [07:42:55.0610] https://github.com/unicode-org/message-format-wg/ [07:43:00.0856] yulia: I will work with Younies to make sure he addresses the concerns about the problem statement [07:43:12.0748] ryzokuken: the meetings are open access, please do! [07:43:12.0755] sffc: thanks, that would be great [07:44:46.0021] this, in particular, seems like it should be a userland library, unless I'm missing something [07:44:46.0847] sure, though it's scheduled at a difficult time for me 😓 in the meantime, please feel free to file a bunch of editorial issues or just DM me here anytime. Richard has been making improvements in the last few weeks but I understand that there's still a bunch to be done. [07:44:54.0339] at least until it gets more common [07:45:00.0264] the format isn't even decided right now [07:45:02.0667] I don't know how I feel about changing the TG2 process. I think it's working just fine the way it is. Intl is responsible for less than 10% of TG1 plenary time this meeting and in most meetings. [07:45:34.0511] i understood chip's point to mean that he'd like it to be 0 [07:46:08.0516] > <@bakkot:matrix.org> the format isn't even decided right now +1 [07:46:41.0240] I guess that doesn't matter so much at this stage, to be fair [07:48:02.0873] Michael Ficarra: I don't have the necessary permissions to answer in that room [07:48:04.0213] I have various concrete examples of how TG1 feedback has been valuable and shaped the direction of TG2 proposals, which would not have happened if proposals had advanced within TG2 alone. [07:48:19.0611] I do fear this might be a bit premature [07:50:12.0633] Perhaps it would be sufficient to clearly divide scheduled plenary time between Ecma-262 and Ecma-402 proposals, so folks can skip parts they aren't interested in? [07:50:46.0274] > <@michaelficarra:matrix.org> I do fear this might be a bit premature for stage 1 too? [07:51:00.0168] Bradford Smith: I think the draft schedule serves that purpose already... both of these proposals are moving forward at their scheduled times [07:51:58.0635] sffc: We're pretty fast and loose about moving stuff around, during the meeting, though. [07:52:03.0648] is the problem statement for stage 1 "we want to format messages for internationalization" or "we want specifically the Unicode message formatter" [07:52:14.0499] because those have different motivations [07:52:16.0037] i understood the latter [07:52:38.0560] definitely seems like the latter, which is why I think it's probably premature [07:53:26.0364] honestly probably the latter seems more motivated but I'd want it to be, like, something lots of people are doing [07:53:42.0789] the repo has this sentence: "To help with this, we introduce Intl.MessageFormat as a native parser and formatter for MessageFormat 2.0." [07:53:51.0777] another thing I might like to discuss if we get to decorators again on the agenda: https://github.com/tc39/proposal-decorators/issues/459 [07:54:00.0252] should we make a decorators matrix room also? [07:54:15.0254] pzuraq: why would that not be allowed [07:54:22.0961] sffc: Where is that draft schedule, anyway? The agenda doesn't say when the topics will be presented. [07:54:37.0180] Bradford Smith: it's linked from the reflector issue [07:54:43.0745] [deleted] [07:55:01.0397] oh speaking of, bakkot, you're still planning to present the `isStatic` thing? [07:55:05.0525] yes [07:55:17.0643] bakkot generally the syntax is pretty restricted, you can only do chaining of static property names ending in a call [07:55:20.0636] assuming chairs can find me a time for it [07:55:28.0388] sffc: Ah, the thing that is labeled "Purely a guide, never a promise " :) [07:56:54.0605] ``` // Allowed @foo @foo() @foo.bar() @(foo['bar']('baz')) // Not allowed @foo().bar @(foo).bar @foo['bar'] // Not sure yet @(foo['bar'])() @this.#x() ``` [07:56:58.0040] sffc: please don't paste links from the reflector into Matrix [07:57:36.0184] Michael Ficarra: sorry, I wasn't sure whether that link was okay or not [07:57:41.0209] this decision on syntax was made prior to my taking on the proposal, so I'm not 100% sure what the context was, other than ASI hazards and such [07:57:43.0138] the draft schedule links to the notes docs... [07:57:46.0998] FWIW, "message" has a long precedent - it's been called "message" in gettext and its predecessors for decades https://www.gnu.org/software/gettext/manual/gettext.html [07:58:09.0720] why isn't that library called `getmessage` then? 🤔 [07:58:10.0467] collections of "messages" are called "message catalogs" in gettext, not sure if that also exists in Unicode [07:58:37.0894] What I'm suggesting is something like "Day 2 is specifically for Intl proposals" [07:59:43.0484] bakkot: i think fundamentally, almost all things in Intl are library-y, because it's a really a library. the main driving factor from my POV for "it's worth it to ship in the language" has been "runtimes ship all this data anyway let's put it to good use", with "it'd be good to have a standard" with a secondary [07:59:53.0440] > <@shuyuguo:matrix.org> why isn't that library called `getmessage` then? 🤔 decades ago they were bad at naming things. the predecessor was called `catgets` [08:00:03.0698] shu: that's fair but my point is that this proposal does not appear to contain any data [08:00:05.0028] just a parser [08:00:14.0370] and template engine [08:00:18.0502] and maybe I'm wrong about that [08:00:18.0737] > <@michaelficarra:matrix.org> sffc: please don't paste links from the reflector into Matrix It should probably be deleted from the Matrix logs, since they are public and that hackmd is editable by anyone [08:00:24.0198] > <@bakkot:matrix.org> shu: that's fair but my point is that this proposal does not appear to contain any data No, the formatting and templating engine depends on ICU data AFAIK [08:00:37.0479] how? [08:00:44.0629] yeah that's the part I'd like to understand more [08:00:46.0263] I have a reference on why it is not as simple as using a template engine, but I'll have to dig it up [08:00:50.0233] it looked to me like the formatters are just passed in [08:00:52.0844] https://projectfluent.org/ explains this really well [08:00:52.0965] I'll open an issue in the proposal repo [08:01:28.0022] For example in ``` tabs-close-tooltip = {$tabCount -> [one] Close {$tabCount} tab *[other] Close {$tabCount} tabs } ``` The `[one]` and `[other]` are locale specific aliases for different counts. [08:01:36.0679] Some npm stats about i18n libraries https://www.npmtrends.com/fbt-vs-fluent-vs-format-message-vs-i18n-vs-i18next-vs-intl-messageformat-vs-messageformat-vs-polyglot-vs-react-intl-vs-react-i18next [08:01:52.0355] npm stats are not useful [08:02:01.0442] I refer you all again to https://www.npmjs.com/package/har-validator [08:02:18.0277] 20m downloads / week for a validator for https://github.com/ahmadnassri/har-spec [08:03:07.0221] bakkot: yeah most people spend most of their day validating HARs, do you not? [08:03:47.0389] > <@lucacasonato:matrix.org> For example in > ``` > tabs-close-tooltip = {$tabCount -> > [one] Close {$tabCount} tab > *[other] Close {$tabCount} tabs > } > ``` > > The `[one]` and `[other]` are locale specific aliases for different counts. In other languages, these aliases might be more complex. For example in polish, between "one" and "many", there is "few": ``` tabs-close-tooltip = {$tabCount -> [one] Zamknij kartę [few] Zamknij {$tabCount} karty *[many] Zamknij { $tabCount } kart } ``` [08:04:02.0830] I think MessageFormat has the same justification as most Intl APIs but even more extreme: IIUC, it'd take a large amount of locale data in order to achieve this, which would be difficult to ship with a web bundle but could be shipped easily with a browser [08:04:17.0613] maybe the champions can correct me [08:04:24.0719] > <@bakkot:matrix.org> npm stats are not useful I swear to never use NPM stats in my proposals again. 😔 [08:04:28.0983] > <@lucacasonato:matrix.org> In other languages, these aliases might be more complex. For example in polish, between "one" and "many", there is "few": > > ``` > tabs-close-tooltip = {$tabCount -> > [one] Zamknij kartę > [few] Zamknij {$tabCount} karty > *[many] Zamknij { $tabCount } kart > } > ``` These plural rules are included in CLDR: https://cldr.unicode.org/index/cldr-spec/plural-rules [08:05:16.0612] number of dependents on npm is more meaningful, if you want to look at stats, but that of course only brings in published packages [08:07:56.0009] > <@pzura:matrix.org> another thing I might like to discuss if we get to decorators again on the agenda: https://github.com/tc39/proposal-decorators/issues/459 I think people are unlikely to have strong opinions on this and it doesn't much matter. If you think it should be other than it is, it's fine to bring it back and make a case for it, but if you just want to discuss it, I don't think that's gonna be particularly productive [08:08:00.0794] because I don't expect anyone to really care much [08:08:59.0772] I guess would making a change like this require consensus at this point? [08:09:04.0128] yes [08:09:15.0939] all normative changes require consensus at this point [08:09:30.0652] This is a good catch. I strongly want `@(expr)() class {}` to be disallowed, like how the explainer says it would be, because of distinguishing it from the topic reference `@(arg)`. [08:09:33.0330] * This is a good catch. I strongly want `@(expr)() class {}` to be disallowed, like how the explainer says it would be. [08:09:34.0987] unless the previous spec text was incoherent, which is kind of an edge case [08:09:42.0415] well, we can talk about it this meeting or next then, there will likely be other small changes and tweaks to consider (e.g. the inclusion of private fields in decorator expression chains) [08:09:50.0795] * This is a good catch. I strongly want `@(expr)() class {}` to be disallowed, like how the explainer says it would be, because of parsing the topic reference `@(arg)`. [08:09:54.0634] * This is a good catch. I strongly want `@(expr)() class {}` to be disallowed, like how the explainer says it would be, because of distinguishing it from the topic reference `@(arg)`. [08:10:02.0581] * well, we can talk about it this meeting or next then, there will likely be other small changes and tweaks to consider (e.g. the inclusion of private fields in decorator expression chains) [08:10:06.0107] * This is a good catch. I strongly want `@(expr)() class {}` to be disallowed, like how the explainer says it would be, because of distinguishing it from the topic reference in `x |> @(arg)`. [08:10:15.0035] not a huge deal and I expect it to be uncontroversial [08:10:28.0652] * This is a good catch. I strongly want `@(expr)() class {}` to be disallowed, like how the explainer says it would be, to make distinguishing decorators from the topic reference in `x |> @(arg)` still easy. [08:11:08.0579] didn't realize that `@` would be used in pipelines, I need to look at the latest on that proposal [08:11:11.0410] ... `stabilize` doesn't write to a property [08:11:39.0309] i thought it did for _some_ objecs [08:11:41.0606] like arrays? [08:11:53.0873] We decided that at plenary just yesterday, so the explainer and spec haven’t been updated. Take a look at https://docs.google.com/presentation/d/1dDucwsW8qM22yWLr\_NHFmAiAltQSht3AXYW00kET4GA/edit?usp=sharing. [08:12:03.0604] > <@pzura:matrix.org> didn't realize that `@` would be used in pipelines, I need to look at the latest on that proposal * We decided that at plenary just yesterday, so the explainer and spec haven’t been updated. Take a look at https://docs.google.com/presentation/d/1dDucwsW8qM22yWLr\_NHFmAiAltQSht3AXYW00kET4GA/edit?usp=sharing. [08:13:36.0135] I think this proposal should've probably been incubated in TG3 before coming to plenary [08:14:18.0497] pzuraq: if you want to bring one or both of those up this meeting, should ask the chairs about it [08:14:27.0542] so far I have only asked for time for specifically the "isPrivate" thing [08:15:00.0815] will do 👍️ [08:20:36.0741] I can't speak sorry [08:21:47.0703] rob was wondering what you were +1ing since a lot was discussed [08:22:32.0148] i believe it was your point on introducing a new integrity elvel [08:23:49.0569] i like read-only collections as a seperate thing from this proposal because they would just not have the relevant methods, rather than having them but they throw [08:25:46.0814] man, I wish any of my software "guarantees" were enforced by the hardware [08:26:01.0297] instead of being actively subverted by them [08:26:04.0829] my main confusion now is that IIUC this _isn't_ an integrity level [08:26:06.0755] there are no guarantees [08:26:08.0122] /me shakes fist at spectre [08:26:23.0250] it seems to be just a new protocol with ad-hoc behavior for built-ins [08:26:44.0466] shu: if this wraps up early can we move your resizable buffers item to before lunch? [08:26:50.0274] happy to present sure [08:27:18.0785] shu: thank you sir, please get ready to present [08:28:38.0866] shu: I think I've been convinced that the stabilisation behaviour on different kinds of objects is too disparate [08:28:48.0029] I think instead of having a proper protocol for this I would want to have just a well-known symbol-named method [08:28:52.0640] so you can test for its presence [08:29:04.0056] also maybe not even symbol-named [08:29:12.0974] Michael Ficarra: yeah [08:29:22.0329] i don't get peter's point either [08:29:24.0156] pzuraq: would you be ready to do decorators continuation before lunch if needed [08:29:32.0538] there's no broad-stroke "is stabilized" guarantee he can rely on in this proposal to put things into ROM AFAIU [08:29:47.0301] you still have to understand what each object's stabilization does [08:30:08.0756] shu: I understand peter's perspective of trying to have a spec formalisation of something they already do, but I don't think it's simple and uniform enough to be considered one concept [08:30:18.0879] agreed, yes [08:30:57.0973] my actual fear is this: this will be become a popular exploit vector because it'll be brittle, tightly coupled to object representation, and lightly used and so doesn't get much hardening through heavy use [08:31:59.0440] bterlson: yes [08:32:10.0244] this is going to be yet another proposal where we have a hard time agreeing on a problem statement [08:33:30.0863] how to make the language more confusing: here's a thing that's not freeze, but is the real freeze :( [08:33:35.0646] I guess I would say there's a need for unmodifiable variants of built-ins and we need to figure out how to provide that? [08:34:05.0187] isn't that the problem statement of the RO collections proposal? [08:34:14.0602] i'd say for this proposal, it broadens the problem statement to "all JS objects" [08:34:17.0564] which i doubt and disagree with [08:34:53.0782] then maybe we should ask them to work together? [08:35:13.0600] i think they already are, this is a fruit of that collaboration actually? [08:35:13.0954] they are working together, as I understand it [08:35:16.0007] pzuraq: please prepare to go with decorator continuation prior to lunch. shu you're off the hook til after lunch! [08:35:24.0804] bterlson: roger [08:35:33.0020] comic sans disengaged [08:36:27.0859] copy that v8 actual. Confirm garish colors are disarmed, over. [08:36:53.0068] freezing typed arrays, in particular, seems like the maximally bad case for Shu's usefulness-vs-engine-exploits tradeoff [08:40:55.0103] pzuraq: mind zooming in a bit? [08:46:59.0436] re: w3c recommendation to avoid `is` prefix for booleans, does someone have a reference for that? [08:47:50.0249] https://w3ctag.github.io/design-principles/#naming-booleans [08:49:43.0597] Boolean properties, options, or API arguments which are asking a question about their argument _should not_ be prefixed with `is`, while methods that serve the same purpose, given that it has no side effects, _should_ be prefixed with `is` to be consistent with the rest of the platform. [08:49:50.0618] * Boolean properties, options, or API arguments which are asking a question about their argument _should not_ be prefixed with `is`, while methods that serve the same purpose, given that it has no side effects, _should_ be prefixed with is to be consistent with the rest of the platform. [08:49:58.0639] * Boolean properties, options, or API arguments which are asking a question about their argument _should not_ be prefixed with `is`, while methods that serve the same purpose, given that it has no side effects, _should_ be prefixed with `is` to be consistent with the rest of the platform. [08:51:09.0783] I'm little bit confused, does `@(expr)` already conflict with topic ref? [08:51:29.0601] * > Boolean properties, options, or API arguments which are asking a question about their argument _should not_ be prefixed with `is`, while methods that serve the same purpose, given that it has no side effects, _should_ be prefixed with `is` to be consistent with the rest of the platform. [08:51:41.0508] Only in the ``` a |> @(expr) class B {} ``` case because of ASI [08:51:55.0632] i.e. that wouldn't be a topic ref but a decorator [08:52:25.0159] oh! so it introduced an ASI! 😭 [08:53:18.0572] And only ASI in pipeline? oh my god... [08:53:37.0288] Just use semicolons 😛 [08:53:52.0367] doesn't help [08:54:40.0078] because when sb write @(expr) class B {} , very likely they mean decorator ... [08:54:52.0672] Yes, and it means the decorator [08:55:11.0303] ``` a |> @(expr) class B {} ``` is the same as ``` a |> @(expr) class B {} ``` [08:55:11.0375] sorry i mean there is a newline between. [08:55:32.0676] It's like ``` a [b] ``` is the same as ``` a[b] ``` [08:55:36.0909] We are banning this by the way with a special early error. It must be parenthesized. Pipe bodies must not be unparenthesized decorated expressions. [08:55:40.0703] oh. i c [08:55:45.0626] sounds better [08:56:23.0399] > <@jschoi:matrix.org> We are banning this by the way with a special early error. It must be parenthesized. Like this? ``` a |> (@(expr) class B {}) ``` ? [08:56:29.0800] * We are banning this by the way with a special early error. It must be parenthesized. Pipe bodies must not be unparenthesized decorated expressions. [08:56:31.0930] though it make semi-less style even much harder... [08:56:33.0423] > <@nicolo-ribaudo:matrix.org> Like this? > ``` > a |> (@(expr) > class B {}) > ``` > ? Yes. [08:56:45.0235] (Also, developers should not be putting decorated expressions in pipe bodies anyway!) [08:57:13.0090] > <@jschoi:matrix.org> Yes. Oh I see, that solves the ASI hazard because it's not a possible class declaration anymore [08:57:50.0211] Also, `a |> @(expr) class C {}` would have been banned anyway. Because the pipe body doesn’t use the topic reference! Pipe bodies must use the topic at least once. [08:58:07.0524] But `a |> @(@) class C {}` could have been a hazard. So that’s why we have the extra error. [08:58:13.0724] * But `a |> @(@) class C {}` could have been a hazard. So that’s why we have the extra error. [08:58:18.0270] * Also, `a |> @(expr) class C {}` would have been banned anyway. Because the pipe body doesn’t use the topic reference! Pipe bodies must use the topic at least once. [08:58:40.0396] Is this also banned? ``` a |> new @(@) class A {} ``` [08:58:41.0349] oh jeeeeeze [08:58:44.0216] we have too much syntax [08:58:57.0479] > <@nicolo-ribaudo:matrix.org> Is this also banned? > ``` > a |> new @(@) > class A {} > ``` Yes, because the pipe body is an unparenthesized decorated expression. [08:59:09.0141] > <@jschoi:matrix.org> Yes, because the pipe body is an unparenthesized decorated expression. The pipe body is a NewExpression [08:59:15.0335] Oh wait, crap, missed that. It is not currently banned. [08:59:23.0857] anyway, I really hope we could use @{foo} instead of @(foo) for decorator [08:59:34.0218] * Oh wait, crap, missed that. It is not currently banned. [08:59:35.0783] it seems this will never confilict with topic ref [08:59:52.0753] > <@haxjs:matrix.org> anyway, I really hope we could use @{foo} instead of @(foo) for decorator That doesn't solve the hasi azard? ```js a |> @ {foo} class B {} ``` [08:59:55.0958] > <@haxjs:matrix.org> anyway, I really hope we could use @{foo} instead of @(foo) for decorator `#[decorate()]` a'la rust [09:00:11.0705] can we at least "NLT here"? [09:00:15.0493] > <@haxjs:matrix.org> anyway, I really hope we could use @{foo} instead of @(foo) for decorator * That doesn't solve the asi hazard? ```js a |> @ {foo} class B {} ``` [09:00:35.0718] In decorators? I have always written them with a line terminator before the class... [09:00:42.0192] > <@lucacasonato:matrix.org> `#[decorate()]` a'la rust yes ! I actually proposed that several years ago [09:00:44.0552] > <@michaelficarra:matrix.org> can we at least "NLT here"? * In decorators? I have always written them with a line terminator before the class... [09:00:57.0296] nicolo-ribaudo: no, after the `@` [09:01:05.0349] but now it's tuple :-) [09:01:14.0884] * That doesn't solve the asi hazard ```js a |> @ {foo} class B {} ``` [09:01:18.0157] * Oh wait, crap, missed that. It is not banned, and I think it is clear enough. [09:02:02.0912] > <@michaelficarra:matrix.org> nicolo-ribaudo: no, after the `@` There is also an issue do disallow any space after `@` (I disagree with that, but you might like it) [09:02:08.0562] * Oh wait, crap, missed that. It is not banned, and I think it is clear enough as two statements. [09:02:20.0273] > <@nicolo-ribaudo:matrix.org> That doesn't solve the asi hazard > ```js > a |> @ > {foo} > class B {} > ``` no whitespaces after @ for decorator solve that [09:02:22.0802] They just talked about it. I believe the resolution is to allow `@ blah class {}`. [09:02:31.0009] > <@nicolo-ribaudo:matrix.org> There is also an issue do disallow any space after `@` (I disagree with that, but you might like it) * They just talked about it. I believe the resolution is to allow `@ blah class {}`. [09:02:46.0085] Oh lol I was distracted [09:03:08.0251] I'm saying we could have "[no LineTerminator here]" to allow spaces but not newlines [09:03:24.0957] it's an option between allowing any whitespace and not allowing any whitespace at all [09:03:41.0927] yes NLT! [09:03:58.0627] If we want an NLT, we had better make one more agenda item about this before plenary ends, haha…because otherwise it’s going to end without it. [09:04:15.0380] we should... [09:04:31.0540] * If we want an NLT, we had better make one more agenda item about this before plenary ends, haha…because otherwise it’s going to end without it. [09:04:46.0817] it's really strange to allow LT after @ for decorator [09:04:49.0165] I guess I should've gotten on TCQ [09:04:50.0270] pzuraq: Some people still want an NLT after `@`. Might want to make another agenda item? [09:05:00.0481] * pzuraq: Some people still want an NLT after `@`. Might want to make another agenda item? [09:05:14.0867] > <@haxjs:matrix.org> it's really strange to allow LT after @ for decorator Well, it's allowed almost everywhere [09:05:24.0787] ok, happy to keep discussing it 👍 [09:05:28.0244] * Well, it's allowed almost everywhere [09:05:57.0937] > <@nicolo-ribaudo:matrix.org> Well, it's allowed almost everywhere not everywhere there already many things require NLT... [09:08:10.0659] I don't think anyone will object to it [09:33:34.0750] bakkot: https://github.com/js-choi/proposal-function-memo I really wish WeakMaps supported primitives…It’d make specifying the cache’s behavior so much easier. [09:35:54.0186] I suppose we could just make it a Map (with argument-tuple keys?) and punt managing memory to the user…I wonder if an LRUMap might be worth adding to the language along with function-memo. [09:36:08.0276] * I suppose we could just make it a Map (of tuples?) and punt managing memory to the user…I wonder if an LRUMap might be worth adding to the language along with function-memo. [09:36:14.0705] * I suppose we could just make it a Map (with argument-tuple keys?) and punt managing memory to the user…I wonder if an LRUMap might be worth adding to the language along with function-memo. [09:36:49.0263] * bakkot, Michael Ficarra: https://github.com/js-choi/proposal-function-memo I really wish WeakMaps supported primitives…It’d make specifying the cache’s behavior so much easier. [09:38:48.0895] I would not mind an LRU cache at all [09:43:47.0700] LRU, LFU, and ARC are useful in different scenarios, all of which can underly a Map implementation. I’d suggest that a memo/cache primitive should use a Map protocol, but not be coupled to a specific cache strategy. Even the choice between Map (memoize) and LruMap (cache) is meaningful. [09:44:45.0630] Many years ago, I put together the {Lru,Lfu}{Map,Set} cross product e.g., http://www.collectionsjs.com/lru-map [09:45:21.0286] All of which have a parameterizable key, which is something Map doesn’t do yet. [09:46:53.0850] Maybe we should tackle LRU/LFU Map/Set as a separate proposal, then. I’ll create something about this. Perhaps `memo` should require a map-like cache object as an argument—if we can’t do a WeakMap strategy by default, then it’s up to the developer to manage their memory. Though there are cases there people just use memoized functions to return a singleton from no arguments, and requiring a cache argument would make that clunky…… [09:47:23.0685] * Maybe we should tackle LRU/LFU Map/Set as a separate proposal, then. I’ll create something about this. Perhaps `memo` should require a map-like cache object as an argument. [09:47:33.0940] * Maybe we should tackle LRU/LFU Map/Set as a separate proposal, then. I’ll create something about this. Perhaps `memo` should require a map-like cache object as an argument, if we can’t do a WeakMap strategy by default. [09:47:51.0533] * Maybe we should tackle LRU/LFU Map/Set as a separate proposal, then. I’ll create something about this. Perhaps `memo` should require a map-like cache object as an argument—if we can’t do a WeakMap strategy by default, then it’s up to the developer to manage their memory. [09:48:11.0978] * Maybe we should tackle LRU/LFU Map/Set as a separate proposal, then. I’ll create something about this. Perhaps `memo` should require a map-like cache object as an argument—if we can’t do a WeakMap strategy by default, then it’s up to the developer to manage their memory. Though there are cases there people just use memoized functions to return a singleton from no arguments…… [09:48:20.0233] * Maybe we should tackle LRU/LFU Map/Set as a separate proposal, then. I’ll create something about this. Perhaps `memo` should require a map-like cache object as an argument—if we can’t do a WeakMap strategy by default, then it’s up to the developer to manage their memory. Though there are cases there people just use memoized functions to return a singleton from no arguments, and requiring a cache argument would make that clunky…… [09:57:09.0918] *** Plenary restarts in 3 mins! *** [10:01:54.0991] > <@jschoi:matrix.org> bakkot, Michael Ficarra: https://github.com/js-choi/proposal-function-memo > I really wish WeakMaps supported primitives…It’d make specifying the cache’s behavior so much easier. hard agree https://github.com/tc39/proposal-symbols-as-weakmap-keys/issues/21#issuecomment-1016934180 [10:02:03.0866] I will do some note taking [10:02:36.0659] yeah it's me [10:02:49.0840] I am at the computer the bot is running on, sorry for the confusion [10:03:55.0696] > <@kriskowal:matrix.org> Many years ago, I put together the {Lru,Lfu}{Map,Set} cross product e.g., http://www.collectionsjs.com/lru-map on a related note, I want to bring a MultiMap proposal, any interest in co-championing? [10:05:29.0079] Is 8x8 down? Having issues rejoining [10:06:52.0141] seems like a machine-specific issue, not sure why [10:14:11.0773] > <@michaelficarra:matrix.org> on a related note, I want to bring a MultiMap proposal, any interest in co-championing? I'd love a MultiMap, but I'm more interested in being able to specify equality/hashing semantics for custom map/set key comparisons (*not* operator overloading) similar to `@esfx/equatable`/`@esfx/hashmap` [10:15:35.0638] rbuckton: okay sure but I don't see how that's related [10:16:40.0811] All that and mutation observers and we’d have a cocktail, but I’m no longer working in the context of a motivating use case. [10:16:49.0044] More about time investment. I'd co-champion, but if I have free cycles for that I'd rather put them into something higher priority for me [10:17:08.0597] I would want to prove it out in userspace. [10:17:32.0417] i mostly just want computeIfAbsent, which gets you 90% of the way to multimap [10:17:46.0116] The one thing that would be super useful for proving it out in userspace would be records and tuples as keys. [10:17:58.0455] MultiMap is like Function.prototype.once for me, I write it in like 50+% of my projects [10:18:17.0594] > <@kriskowal:matrix.org> The one thing that would be super useful for proving it out in userspace would be records and tuples as keys. This would be excellent for proposal-function-memo. [10:18:24.0479] Relatedly, if anyone is interested in co-championing https://github.com/js-choi/proposal-policy-map-set, then let me know. [10:18:26.0079] I'm having trouble with focusing on the notes, a third person would be appreciated because I feel almost unuseful [10:18:30.0454] I also have `@esfx/multimap`, but it's based on my hashmap impl [10:19:06.0639] > <@jschoi:matrix.org> Relatedly, if anyone is interested in co-championing https://github.com/js-choi/proposal-policy-map-set, then let me know. I may be but will likely not have much time available until after decorators is finished [10:21:48.0012] I also have been tinkering with `@esfx/collection-core` which is a symbol-based protocol for abstracting collection operations that covers (with shims) Array, typed arrays, Map, Set, WeakMap, and WeakSet and is designed for the user-defined Map-like scenario. [10:25:15.0355] The (with shims) was the design mistake I made for `collections`. [10:25:52.0057] But largely the same idea: protocols all the way down. [10:27:21.0561] The shims are optional [10:27:49.0727] In any case, if folks are interested in investing in that approach in userspace, I’m sitting on both `collections` and `@collections` on npm and I’m easy to find. 👋 [10:27:57.0039] (ie, in `@esfx/collection-core-shim`) [10:30:36.0503] I didn't realize ljharb wasn't in attendance today and apparently he is unhappy with the outcome surrounding `private`/`static`, should we revisit? [10:31:07.0573] I’ll be there tomorrow, I’m just on a plane right now. [10:31:59.0999] It seems the queue is still in the last topic? [10:34:21.0233] sorted [10:38:07.0714] you can use `concat` to do a non-mutating "push", right? [10:38:18.0987] Yes exactly [10:38:31.0675] That's why the number of methods was reduced from 10 to 4 [10:38:44.0846] (many were mostly duplicates) [10:39:42.0191] this is a really good proposal 👍️ and well presented [10:42:45.0238] pzuraq: FYI, might also want to talk about https://github.com/tc39/proposal-decorators/issues/460 during this plenary too. I am willing to reallocate holistic-dataflow time (currently 60 min) to more decorator stuff, because decorators are more urgent, having formally reached Stage 3. [10:42:53.0760] * pzuraq: FYI, might also want to talk about https://github.com/tc39/proposal-decorators/issues/460 during this plenary too. I am willing to reallocate holistic-dataflow time to more decorator stuff, because decorators are more urgent, having formally reached Stage 3. [10:42:59.0890] * pzuraq: FYI, might also want to talk about https://github.com/tc39/proposal-decorators/issues/460 during this plenary too. I am willing to reallocate holistic-dataflow time (currently 60 min) to more decorator stuff, because decorators are more urgent, having formally reached Stage 3. [10:43:22.0616] strong agree with MM [10:43:35.0158] pzuraq: Also https://github.com/tc39/proposal-decorators/issues/461. [10:43:49.0723] yes, saw both of those pop up [10:44:00.0447] happy to discuss [10:44:00.0778] haha does it really do that with `undefined`? TIL [10:44:03.0960] bakkot: `toSorted` is as much a new method as it is an analogue of an old method, I think we're free to choose the less-bad precedent [10:44:21.0998] "new" versus "old" isn't a meaningful precedent [10:44:25.0691] users don't know that sort of thing [10:44:33.0502] * users don't know that sort of thing [10:45:02.0967] why do users need to understand this method as "the same as `.slice.sort()` and not just "it gives you a sorted copy"? [10:45:09.0441] https://github.com/tc39/proposal-decorators/issues/204 might also be worth discussing, I thought this was in the previous versions of the spec I ported but I just double checked and it didn't seem to make it [10:45:16.0055] * why do users need to understand this method as "the same as `.slice.sort()`" and not just "it gives you a sorted copy"? [10:45:20.0219] because what "sorted" means includes this behavior for holes [10:45:36.0164] it's not like there's some algebraic property we're trying to provide here [10:46:19.0519] right, so, the natural thing is to use the existing behavior rather than introducing a new, slightly different one [10:47:22.0482] users aren't going to run into this oddity, and when they do, I think they'd prefer the proposed behaviour because they won't know what the `sort` behaviour is (like shu) [10:47:49.0553] whoa whoa, slap to the face [10:47:57.0241] eh [10:47:58.0297] that's fair [10:48:10.0204] but in that case I'd also fix the `undefined` wart [10:48:12.0653] shu: I also didn't know how `sort` treated holes off the top of my head before this [10:48:17.0694] * shu: I also didn't know how `sort` treated holes off the top of my head before this [10:49:36.0379] well, the actual hazard is somebody is doing `.sort()` in-place, then refactors to `.toSorted()` later [10:49:48.0019] and their input has holes or is weird in some way, and now they have a subtle difference [10:49:59.0962] the hazard being that their broken holey array gets fixed? [10:50:10.0441] holes are terrible and nobody should be relying on them [10:50:11.0368] i care about the likelihood of that, not as much the likelihood of users knowing the behavior of current sort [10:50:15.0375] yeah the bug was having a holey array in the first place IMO [10:50:16.0029] "fixed" [10:50:20.0165] but matter of perspective [10:50:35.0299] yes the way array spread and Array.from and the ES6+ array methods fixes it [10:50:39.0463] we only like holy arrays, not holey arrays [10:50:53.0833] we’ve already decided to fix it whenever we can, in other places. That’s the precedent i hope we follow here. [10:51:21.0338] * yes the way array spread and Array.from and the ES6+ array methods fixes it [10:51:41.0661] ljharb: sidebar, what's your objection to the `private` renaming [10:51:47.0667] I feel very strongly that `isPrivate` is wrong [10:51:56.0509] and would prefer we not fight about it on plenary time if we can avoid it [10:52:03.0173] wait, I’m confused [10:52:15.0875] which names did plenary decide on? [10:52:23.0539] as of today, "private" and "static" [10:52:25.0023] `private` and `static` [10:52:31.0918] ohhhh ok then I’m happy with that [10:52:38.0053] i just misunderstood, sorry for the confusion [10:52:42.0177] ah, cool [10:52:50.0674] all good 👍️ [10:52:53.0147] I’ll clarify my comment on that issue if i can find it [10:52:55.0668] * all good 👍️ [10:53:03.0492] yeah it got stage three with "isPrivate" and "isStatic" but no one had actually thought about it [10:53:13.0363] so we talked about it again today and changed to "private" and "static" [10:53:19.0700] i was under the impression it was already private/static :-) [10:53:23.0395] > <@ljharb:matrix.org> ohhhh ok then I’m happy with that Whew… [10:53:24.0377] aha [10:55:48.0192] this is a fair point from hax [10:55:53.0900] we already have some non-mutating methods without `to` [10:56:03.0256] and this behavior is not quite the same as `spliced`, since its return value is different [10:57:10.0443] (if we’re going to rename anything in the array method proposal I’d like to be present for that decision) [11:01:55.0968] Is there any problem with "remove species" other than backwards compatibility? [11:02:14.0834] (not in this proposal, from the proposal just to remove species) [11:02:32.0341] i think just compat [11:02:36.0606] one problem is that it will make core-js add its very slow regex polyfill [11:02:40.0612] which isn't exactly a compat issue [11:06:14.0733] isn’t at all one [11:06:22.0127] and might incentivize people to update core-js [11:06:32.0629] haha, updating [11:06:36.0951] who updates things [11:06:39.0534] no one [11:06:44.0734] * and might incentivize people to update core-js [11:08:32.0194] this dedenting problem (in HTML) is honestly one of the reasons I wrote Bikeshed. [11:08:56.0557] splice() / toSpliced() is so bad. I would like to propose something like arr.replace(start, end, arr2) /toReplaced() which follow slice(start, end) . [11:09:08.0355] (before this, we did some *horrifying* comment hacks to allow 
 to have indented text that looked reasonable in both source and output)

[11:11:29.0765] 
hmm, trailing newline would be useful when writing files, for instance...

[11:12:54.0531] 
the "character lines" don't need to be contiguous, right?

[11:13:57.0656] 
are lines with only leading whitespace and an interpolation considered "character lines"?

[11:14:14.0748] 
> <@michaelficarra:matrix.org> are lines with only leading whitespace and an interpolation considered "character lines"?

I assume not?

[11:14:38.0989] 
I assume they would be

[11:14:46.0931] 
I think I would prefer them to be

[11:14:51.0425] 
Like, I'd be *incredibly* surprised if they didn't count as character lines

[11:15:33.0786] 
(`$` is a non-ws character anyway, so should qualify ^_^)

[11:15:55.0415] 
oh u mean leading whitespace and ${...} ?

[11:16:00.0795] 
yeah

[11:16:06.0308] 
yes, that's an interpolation

[11:16:16.0261] 
I guess it should be char line...

[11:16:59.0684] 
welp, question answered

[11:17:01.0494] 
oh, current slide give the anwser

[11:18:37.0263] 
nice, template tag composition!

[11:19:23.0561] 
note that this isn't possible for many tags

[11:19:27.0340] 
oh this stacking is cute, hm

[11:19:32.0553] 
but it happens to work for dedent, specifically

[11:19:42.0325] 
that is, dedent composes with any tag

[11:19:47.0220] 
but you can't generally compose arbitrary tags

[11:20:27.0801] 
`` ""` `` gives me hives

[11:20:48.0301] 
any syntax here gives me hives

[11:20:55.0051] 
template tag ftw

[11:21:14.0569] 
yeah def, they don't get that stacking behavior either

[11:21:17.0971] 
extremely opposed to syntax for this

[11:21:31.0290] 
well nm i guess they do

[11:21:35.0440] 
anyway no need for syntax, eah

[11:21:45.0650] 
feeling overwhelmed by the `@`s

[11:22:07.0688] 
is erights in the chat

[11:22:15.0447] 
I can probably explain how template tag composition works

[11:22:22.0685] 
> <@yulia:mozilla.org> feeling overwhelmed by the `@`s

We can use `#`

[11:22:26.0429] 
generally, markm’s not in chat.

[11:22:31.0135] 
alas.

[11:22:32.0565] 
> <@bakkot:matrix.org> I can probably explain how template tag composition works

i'd appreciate this too

[11:22:38.0741] 
the interpolated expression can have newlines in it, which might make things... weird, but shouldn't be a problem

[11:22:49.0073] 
so, the key thing is, the interpolations don't participate in dedenting at all

[11:22:59.0812] 
they are considered, basically, a placeholder character

[11:23:08.0709] 
a non-newline placeholder character

[11:23:18.0211] 
a ZWNJ

[11:23:25.0610] 
bless you

[11:25:21.0853] 
so basically you can imagine it as, replace all interpolations with a placeholder, do the logic as if it's just a string, then split it up again into a tagged-template-array argument

[11:26:23.0850] 
i see

[11:26:30.0651] 
in any case that seemed like not the actual question mark was asking

[11:26:36.0895] 
yeah, whoops

[11:26:38.0602] 
but your answer was to my question

[11:28:23.0674] 
hmmmmm wonder if `` String.dedent({tabSize:4})`...mixed tabs and spaces content here` `` could work

[11:28:30.0162] 
another branch in the call

[11:28:40.0033] 
I'm going to propose another branch in the call also

[11:28:41.0662] 
(for strings)

[11:28:44.0262] 
so, fun all around

[11:28:55.0142] 
I'm really hoping we can keep dedent simple and not parameterise it

[11:29:08.0622] 
is python's parameterized

[11:29:10.0693] 
I've never wanted that

[11:29:14.0273] 
I find that mixed tabs and spaces are common in real text

[11:29:36.0040] 
TabAtkins: what kinds of cursed codebases are you working in?

[11:29:41.0153] 
TabAtkins: but in the common prefix?

[11:29:43.0309] 
HTML, man

[11:29:46.0181] 
 * TabAtkins: what kinds of cursed codebases are you working in?

[11:29:47.0305] 
and yes, in the common prefix

[11:29:50.0357] 
I feel like even when mixed, the common prefix is not mixed

[11:29:51.0056] 
well

[11:29:52.0872] 
that sucks.

[11:29:53.0353] 
wtf

[11:29:55.0567] 
people indent like it's the wild west

[11:29:58.0152] 
i want to not optimize for that case

[11:30:01.0481] 
screw those people

[11:30:08.0806] 
I don't know if I'd call that indentation at that point

[11:30:23.0452] 
it's just... leading characters that happen to all be whitespace?

[11:30:54.0894] 
listen, i'm with you, people treating tabs as fixed-width are the devil

[11:31:03.0790] 
but i wrote code to handle this for a reason

[11:31:09.0539] 
strong +1 to justin's point here

[11:31:14.0973] 
I also indent the bodies of template tags

[11:31:29.0080] 
everyone does afaik

[11:32:18.0450] 
i... actually don't care about the format of the output, but i guess i'm in a small minority here

[11:32:18.0745] 
I'm lazy. Unlike with other, simpler helpers, I do not write myself a dedent helper, I just align my template bodies at 0.

[11:32:31.0695] 
YAML treats each tab equivalent to one space, I recall…?
I forget what Python does.

[11:32:31.0759] 
if I had a built-in dedent, I would gladly use it

[11:33:58.0048] 
> <@jschoi:matrix.org> YAML treats each tab equivalent to one space, I recall…?
> I forget what Python does.

yaml do not allow tab I think.

[11:33:58.0721] 
Python errors on mixed indentation for the same level.

[11:34:20.0530] 
You can mix tabs and spaces, but have to use them consistently at a given level; it doesn't treat N spaces as equivalent to a tab

[11:34:49.0119] 
> <@haxjs:matrix.org> yaml do not allow tab I think.

Ah, yes, you are right. https://yaml.org/spec/1.2.2/#rule-s-indent

[11:35:08.0116] 
That spec was the first parser I ever implemented (in Clojure)…Brings back memories.

[11:35:16.0828] 
 * That spec was the first parser I ever implemented (in Clojure)…Brings back memories.

[11:35:28.0707] 
> <@tabatkins:matrix.org> You can mix tabs and spaces, but have to use them consistently at a given level; it doesn't treat N spaces as equivalent to a tab

Not sure, I remeber python could treat N spaces as tab by some special comments?

[11:35:45.0669] 
oh possibly, but by default it doesn't

[11:36:27.0168] 
It's really weird that comments could change the semantic of a code 😂

[11:39:58.0000] 
hahaha oh man

[11:40:02.0187] 
if it treats strings as arraylike

[11:40:29.0717] 
HE Shi-Jun: check out Haskell's pragmas

[11:40:44.0049] 
I think I agree with bakkot here - the case i'm concerned about switching between a text var that needs dedenting, and inlining it into your code; the text var is likely gonna be formatted "normally" without empty first/last lines

[11:41:44.0914] 
I like michael's proposal actually

[11:41:49.0652] 
just so that we don't have this weird edge

[11:47:10.0554] 
yeah i suppose String.proto.dedent omitting the first/last line behavior makes sense

[11:48:27.0090] 
I just think it's a bit of a separate design space, so we should have separate functions so we don't feel obligated to make any less-than-ideal choices

[11:48:29.0785] 
(The "have to detect this in the spec and error immediately" just continues to support my point that treating strings as iterables/array-likes is always a mistake that every lang just keeps repeating.)

[11:49:01.0926] 
https://www.xanthir.com/b4wJ1

[11:50:03.0752] 
TabAtkins: unfortunately we don't have strings, we have sequences of UTF-16 code units

[11:50:15.0235] 
they shouldn't be iterable anyway though

[11:50:48.0140] 
for iteration, they are sequences of code points

[11:50:51.0967] 
the one that makes sense is an iteration over code units, though that's not what we chose

[11:51:10.0006] 
that doesn't make sense either

[11:51:14.0987] 
right, that's a mistake, it's always a mistake, exposing the internal impl of your strings *as a default iteration* is always wrong

[11:51:16.0113] 
tab's essay makes an excellent case

[11:51:51.0860] 
tab's essay makes an excellent case in a language where strings represent text

[11:51:55.0773] 
we are not such a language

[11:52:02.0220] 
we may as well have bytestrings

[11:52:03.0443] 
Yes, strings should be abstract text; segmentation is situation-specific; even code points are the wrong default, because there should be no default.

[11:52:17.0563] 
 * Yes, strings should be abstract text; segmentation is situation-specific; even code points are the wrong default, because there should be no default.

[11:52:18.0889] 
bytestring default iteration should be bytes

[11:52:37.0529] 
"our strings don't represent text" is only true if you are using "represent" in an unusual way

[11:52:42.0737] 
i don't understand how what i wrote is specific to "represents text"; alternatley, i don't know what sort of odd point you're trying to make about JS strings not being text (because, uh, what is "text" then?)

[11:52:50.0352] 
because they absolutely do represent text in the usual, english-language meaning of the word

[11:52:52.0099] 
If by "text" you mean "unicode codepoints", that's wrong.

[11:52:54.0524] 
they just don't do it all that well

[11:53:46.0242] 
codepoints aren't text, grapheme clusters aren't text, UCS2-ish code units aren't text, they're all impl strategies for storing text, a more abstract human concept. And all of them are interconvertable and wanted in different circumstances.

[11:54:33.0763] 
but also my essay makes some points that aren't related to "text", such as the "infinite iteration regress" problem you have to handle explicitly when dealing with iterable strings, but virtually never with any other iterable

[11:54:37.0190] 
syg: can you add the charted proposals to the notes

[11:54:55.0026] 
link me notes in DM?

[11:55:15.0574] 
done

[11:55:31.0725] 
(I also would say that language APIs should never use the word “char” or “character”, which is a very ambiguous concept; instead it should always say “bytes”, “code units”, “code points”, “grapheme cluster”, or “text”/“strings”. And their operations should generally prefer acting on arbitrary “text”/“strings”.)

[11:55:35.0527] 
 * (I also would say that language APIs should never use the word “character”, which is a very ambiguous concept; instead it should always say “code units”, “code points”, “grapheme cluster”, or “text”/“string”.)

[11:55:37.0393] 
codepoints are a representation of text, code units are a concrete way of storing and transmitting code points, and grapheme clusters are an artifact of rendering code points to be consumed as text

[11:56:05.0042] 
 * (I also would say that language APIs should never use the word “character”, which is a very ambiguous concept; instead it should always say “code units”, “code points”, “grapheme cluster”, or “text”/“strings”. And their operations should generally prefer acting on arbitrary “text”/“strings”.)

[11:56:09.0696] 
you're still arguing at a level that doesn't actually impact any argument i'm making

[11:56:19.0442] 
 * (I also would say that language APIs should never use the word “char” or “character”, which is a very ambiguous concept; instead it should always say “bytes”, “code units”, “code points”, “grapheme cluster”, or “text”/“strings”. And their operations should generally prefer acting on arbitrary “text”/“strings”.)

[11:56:50.0519] 
my essay isn't at any point about the theoretical purity of "text" or a type of string impl. it's all practicals.

[11:57:11.0199] 
apparently we disagree on what a string is

[11:57:41.0249] 
It doesn't matter. My essay stands for JS String values - every single argument there applies to them.

[11:58:02.0254] 
no, that is what I am arguing against, it doesn't apply to JS string values

[11:58:40.0348] 
1) string aren't collections, in people's mental models, 2) strings have infinite iteration regress, which is weird, 3) there are many ways to iterate a string and none of them make sense as a default

[11:58:42.0302] 
JS string values *are* in fact a collection, an ordered collection of two-byte ints

[11:59:02.0979] 
but that fact is completely irrelevant to people's mental models

[11:59:03.0619] 
^immutable

[11:59:34.0574] 
it's completely relevant to how they work, mechanically, though

[11:59:44.0787] 
Python strings are ordered collections of codepoints. That doesn't change the fact that `set("foo")`'s behavior is bizarre and unexpected

[11:59:45.0149] 
JS string concatenation is not text concatenation

[11:59:45.0990] 
JS string values can be conceptually thought as several different collections of several different kinds of elements on many abstraction levels.

[11:59:46.0154] 
so what

[12:00:00.0347] 
> <@michaelficarra:matrix.org> JS string values *are* in fact a collection, an ordered collection of two-byte ints

 * JS string values can be conceptually thought as several different collections of several different kinds of elements on many abstraction levels.

[12:00:09.0278] 
why does "how they work, mechanically" dictate whether they participate in the iterator protocol

[12:00:28.0513] 
or are indexable or whatever

[12:00:43.0071] 
 * A JS string value can be conceptually thought as simultaneously being several different collections, of several different kinds of elements, each on a different level of abstraction.

[12:00:46.0700] 
because when something actually does make sense to iterate in a specific way, you should be able to iterate it in that way by default?

[12:00:49.0142] 
(rather, dictate how they work *by default* - there are lots of ways that strings can be iterable, and that's reasonable)

[12:01:01.0998] 
my claim is that it does not actually make sense to iterate in that specific way

[12:01:08.0816] 
there are not a lot of ways that JS strings can meaningfully be iterable though

[12:01:12.0910] 
or at least does not make sense only in that way

[12:01:28.0793] 
for the overwhelming majority of strings, yes there are

[12:01:48.0712] 
I don't deal in overwhelming majorities, I talk about the whole class of strings

[12:01:49.0846] 
strings which cannot be iterated as code units or grapheme clusters (with some particular locale) are vanishingly rare

[12:02:05.0709] 
but users of the language do not

[12:02:26.0716] 
the fact that some of the ways you might iterate have edge cases, and one in particular happens not to, does not mean the last way is the One True Way to iterate

[12:02:38.0021] 
such that it should be blessed with the iteration protocol

[12:02:41.0633] 
I gotta go eat lunch 🥪

[12:03:23.0599] 
basic point is: if you have a function that takes a parameter that's either iterable or not, and it iterates over the former case, you *virtually never* want strings to act like the former case. 

[12:04:06.0873] 
specifically: an n-ary func that can take its arguments separately or in an iterable

[12:04:56.0219] 
(also, separately, if strings are considered to be a sequence of code units, then iterating should give you _number values_, not sequences-of-code-units-of-length-1)

[12:05:06.0949] 
I think there was a place in the Unicode FAQs or Specification in which APIs were encouraged to focus on concatenation, interpolation, and other abstract-text operations…and avoid using indexing, segmentation, or counting by code units or code points where possible? I don’t remember exactly where.

[12:07:02.0021] 
At the very least:

> A text element just means any sequence of characters that are treated as a unit by some process. A combining character sequence is a base character followed by any number of combining characters. It is one type of a text element, but words and sentences are also examples of text elements.

Text elements are very situation dependent; the user should ideally always explicitly specify what text elements they want—no default iterator.

[12:07:42.0402] 
See also: counting how many “characters” are in a string.

[12:08:11.0437] 
 * I think there was a place in the Unicode FAQs or Specification in which APIs were encouraged to focus on concatenation, interpolation, and other abstract-text operations…and avoid using indexing, segmentation, or counting by code units or code points where possible? I don’t remember exactly where.

[13:14:55.0278] 
new incubator call charter is up: https://github.com/tc39/incubator-agendas/issues/24, please sign up for the decorator metadata discussion if you're interested

[13:15:38.0818] 
shu: To be honest, I don’t remember what “precedence of async versions” precisely means again. If you don’t remember either, I can try digging back through the plenary notes.

[13:43:51.0359] 
jschoi: it was something like "are we going to have async versions of all the methods?" the immediate response was no, we do it case-by-case

[13:44:13.0185] 
so maybe the topic is something like, let's talk about what the criteria are for introducing async versions of existing methods


2022-03-31
[06:45:11.0146] 
Yes, would like to do that if possible

[06:45:24.0030] 
Sorry for all of the last minute additions 😅

[06:54:11.0978] 
Always been curious - Is there a formal difference between the incubator calls and other (non-plenary) calls where proposals may be discussed?

[06:54:35.0525] 
 * Is there a formal difference between the incubator calls and other (non-plenary) calls where proposals may be discussed?

[06:54:52.0690] 
 * Always been curious - Is there a formal difference between the incubator calls and other (non-plenary) calls where proposals may be discussed?

[06:55:44.0136] 
Ashley Claymore: incubator calls are usually just one-offs instead of recurring like most of the others

[06:57:25.0071] 
*** Plenary begins in 3 mins! ***

[07:28:38.0521] 
bakkot: thanks for the answer

[07:29:22.0864] 
not familiar with that meaning of "borrowability"

[07:34:03.0481] 
shu: "borrowing" a method and calling it on another instance

[07:45:00.0963] 
Richard Gibson: please mute

[07:48:26.0200] 
Did we discuss whether arguments can branch on whether it has the internal slot?

[07:49:05.0185] 
Eg, https://tc39.es/ecma262/multipage/indexed-collections.html#sec-%typedarray%.prototype.set

[07:49:08.0794] 
Justin Ridgewell: briefly during the presentation

[07:49:11.0703] 
haven't presented that explicitly, but yes, it's a possibility

[07:49:17.0745] 
This branches on whether the argument is a true TypedArray or an iterable

[07:49:18.0495] 
Michael Ficarra: we didn't talk about it for arguments specifically

[07:49:25.0284] 
 * This branches on whether the argument is a true TypedArray or an iterable

[07:49:27.0922] 
(fresh handler lookup was definitely a mistake tho, even if it's not why Proxy is slow)

[07:49:40.0086] 
We could have both a fast path and a customizable slow path

[07:50:01.0421] 
i like the idea of detecting argument slots, and only calling the method observably if it lacks the slot

[07:50:15.0553] 
V8 has said they don't want more than 2 paths because it becomes impossible to reason about

[07:50:17.0422] 
but without something like constructor hooks, that still breaks expected subclass invariants

[07:50:22.0625] 
and Justin Ridgewell's suggestion would satisfy markm, as I understand it

[07:51:10.0743] 
Ah, slide 10 discusses hybrid appraoch

[07:51:20.0771] 
Sorry, I need to pay more attention

[07:57:25.0123] 
pzuraq: Were you still planning to request extra time for decorators? It’s not in the TCQ agenda yet.

[07:58:06.0216] 
yes, will do

[07:59:19.0807] 
ljharb: thinking more, I don't understand why hooks would satisfy your use case

[07:59:36.0508] 
like, the reason you do `Set.p.add.call` is presumably because you want to _not_ use the user hooks

[07:59:44.0001] 
and if the hooks are built in, now you can't avoid it

[07:59:46.0647] 
so... seems bad?

[08:00:07.0177] 
like if you want to give the user the option to hook, you would just call `arg.add()`

[08:00:33.0647] 
no, it's because i don't want to depend on the `add` method being present

[08:00:52.0439] 
certainly if someone provides a hook that throws, then i'll just throw, and that's fine

[08:01:24.0883] 
but what it means is that at the time their instance is created - when i can just trust everything works - the proper behavior is set in stone, and i can invoke it later safely.

[08:01:53.0370] 
couldn't you just cache the methods off the instance?

[08:03:22.0939] 
my fn might be called with instances from N different subclasses, how would i cache them all

[08:03:42.0386] 
iow i can rely on the instance being correct when it was created - but "when it's passed to me" is potentially much later than that

[08:05:15.0719] 
so, wait, why do you not want to call the method when it's passed to you

[08:05:25.0416] 
why can you trust it any more when the instance is crated than when it's passed to you

[08:07:03.0362] 
if it's a subclass i probably can, tbh. but if it's not a subclass, i can't trust it because any random person could `delete Set.prototype.add`

[08:07:29.0542] 
i agree this stuff is murky, and the Set constructor's calling of "add" makes this specific example probably a bad one

[08:08:53.0249] 
i feel like, if someone passes you a set, and someone else has deleted `Set.prototype.add`, and you still want to work, it is not obvious to me that there's any benefit to anyone to still work

[08:10:56.0105] 
like a [[SetData]] -> set-like -> iterable fallback?

[08:11:01.0903] 
I guess that wouldn't hurt

[08:11:04.0531] 
bakkot:  for me, deleting builtins shouldn't cause any part of the app not to work, ideally.

[08:11:13.0752] 
 * 

[08:11:39.0457] 
 * @bakkot for me, deleting builtins shouldn't cause any part of the app not to work, ideally.

[08:11:45.0774] 
 * bakkot:  for me, deleting builtins shouldn't cause any part of the app not to work, ideally.

[08:13:57.0638] 
really? how can that be true?

[08:18:09.0538] 
as long as you delete them after the app is initialized, it should keep working just fine

[08:18:50.0917] 
wait but like, if my app uses `Math.sin` and you delete `Math.sin` how is my app supposed to work

[08:19:13.0345] 
i appreciate that desire but do not think it is reasonable when you are interoperating with other people's code, since their code almost certainly does not have this property. like if they made themselves a Set, and then someone else deleted Set.prototype.add, their code is gonna break

[08:21:46.0948] 
HE Shi-Jun: I would agree with that, but if we're discouraging subclassing built-ins, we shouldn't need it

[08:22:09.0676] 
and it sounds like we're mostly leaning toward discouraging subclassing

[08:25:10.0777] 
(also the constructor calls `add` lol)

[08:25:37.0140] 
because _my_ app at least would cache `Math.sin` on module evaluation, it wouldn't dynamically look it up at runtime on Math

[08:25:43.0129] 
> <@shuyuguo:matrix.org> wait but like, if my app uses `Math.sin` and you delete `Math.sin` how is my app supposed to work

 * because _my_ app at least would cache `Math.sin` on module evaluation, it wouldn't dynamically look it up at runtime on Math

[08:26:10.0729] 
> <@bakkot:matrix.org> i appreciate that desire but do not think it is reasonable when you are interoperating with other people's code, since their code almost certainly does not have this property. like if they made themselves a Set, and then someone else deleted Set.prototype.add, their code is gonna break

sure. but that doesn't mean i want my code to be the reason it breaks. i'm fine with their app breaking - i just don't want my code to be in the stack trace :-)

[08:26:11.0609] 
oh i see, yeah i think that style is vanishingly rare

[08:26:17.0472] 
it very much is

[08:26:20.0818] 
you literally never lookup on the prototype?

[08:26:24.0416] 
you cache every single thing?

[08:26:29.0123] 
yep, only at module level

[08:26:43.0705] 
in libraries, that is. in apps ofc i can have guarantees

[08:26:44.0535] 
keith_miller: in Java, all method calls are virtual, so subclasses "replace M" all the time

[08:26:59.0008] 
yeah I... do not want to optimize for this case

[08:27:36.0158] 
i understand that lack of desire :-) i'm not asking to optimize for this case exactly. it's just that constructor hooks happens to solve it, while also checking a lot of other boxes.

[08:27:47.0946] 
like your frozen set example

[08:28:18.0311] 
shu: I don't even think there's a single algebraic understanding of a Set, as we discussed when considering swapping out the "comparison operation" that doesn't actually exist in practice

[08:28:31.0692] 
i agree there isn't a single algebraic understanding

[08:28:41.0393] 
but it doesn't actively _resist_ an algebraic understanding like RegExp.exec?

[08:28:53.0567] 
sure, but that's still limiting

[08:29:43.0946] 
all i'm saying is if we have a minimal core for Set, it's reasonable to expect us being able to come up with and communicate an algebra

[08:30:04.0801] 
and i think it is most def not reasonable what Kevin has categorized as "low-level" on that slide

[08:30:12.0711] 
and that's the division in my mind

[08:30:16.0726] 
shu: are you willing to maintain two radically different Set implementations though?

[08:30:26.0988] 
i don't follow

[08:31:09.0111] 
shu: like if we had constructor hooks, would you also want to provide a Set implementation with a linear time `add` that repeatedly applies the provided comparison?

[08:31:10.0211] 
you mean, a fast path for builtin and a slow path for overridden?

[08:31:47.0087] 
Michael Ficarra: i mean depends on the algebra right?

[08:32:13.0421] 
actually i'm not sure what we're discussing anymore

[08:32:16.0112] 
shu: sure, but I imagine the algebra will often not align with that of your current, fast implementation

[08:32:19.0068] 
shu: a motivating question: is `clear` part of the minimal core

[08:32:30.0767] 
it is clearly possible in terms of iteration/`delete`

[08:32:36.0042] 
what does that do, in-place emptying?

[08:32:42.0759] 
yes

[08:32:45.0186] 
 * what does that do, in-place emptying?

[08:32:48.0303] 
okay

[08:33:04.0272] 
good question, i'd say yes

[08:33:11.0296] 
don't write per-item finalizing logic

[08:33:12.0015] 
bad idea

[08:33:36.0748] 
fwiw I find Temporal.TimeZone a reasonable case for a minimal core of methods

[08:33:57.0510] 
if you have implemented `getPossibleInstantsFor()` then you don't need to implement `getInstantFor()` as well

[08:34:05.0184] 
 * if you have implemented `getPossibleInstantsFor()` then you don't need to implement `getInstantFor()` as well

[08:34:35.0067] 
(which just calls `getPossibleInstantsFor()` and picks one of the values in the returned array based on the other parameter you give it)

[08:35:07.0647] 
I think TimeZone is definitely a "higher-level" built in, in the terminology used in the slides

[08:48:02.0297] 
ptomato: are there internal slots on a `Temporal.TimeZone`?

[08:48:54.0952] 
only one: the string identifier, e.g. `UTC` or `Europe/Berlin`

[08:49:26.0027] 
the default implementations of the methods aren't internal slots

[08:49:45.0122] 
I think we could write it that way & the difference wouldn't be observable, but I'm not 100% sure off the top of my head

[08:55:14.0439] 
As a heads up, we have Decorators coming back (again) for 20min in the afternoon slot today.

[08:55:23.0476] 
 * As a heads up, we have Decorators coming back (again) for 20min in the afternoon slot today.

[08:57:57.0888] 
FYI: The next discussion topic, holistic dataflow, doesn’t have slides—instead, it has a diagram and an article that you can read at https://jschoi.org/22/es-dataflow/.

[08:58:59.0056] 
More decorators?

[08:59:13.0751] 
Justin Ridgewell: more decorators

[09:00:41.0460] 
MORE DECORATORS

[09:10:44.0936] 
I was tying to imagine writing a decorator for enforcing that a field was initialised by the end of the constructor. Am I right in thinking this won't work super well the only way to add logic at the end is to add a subclass? 

[09:12:48.0090] 
 * I was tying to imagine writing a decorator for enforcing that a field was initialised by the end of the constructor. Am I right in thinking this won't work super well the only way to add logic at the end is to add a subclass? 

[09:13:40.0653] 
by replacing the class in a class constructor, maybe?

[09:15:30.0073] 
yeah "at the end of the constructor" is not one of the positions into which decorator allow you to inject code, except by replacing the class entirely

[09:15:34.0240] 
 * yeah "at the end of the constructor" is not one of the positions into which decorator allow you to inject code, except by replacing the class entirely

[09:15:52.0899] 
but you can indeed replace the class with a subclass which does that check

[09:16:56.0852] 
cool thanks, so it would be paired up with a class level decorator with a way to communicate to it

[09:17:07.0787] 
yup

[09:17:08.0507] 
 * cool thanks, so it would be paired up with a class level decorator with a way to communicate to it

[09:17:46.0692] 
(I should say, this is just from my understanding of decorators, which I might easily be forgetting something)

[09:17:56.0245] 
I was just thinking about the `!` initialisation assertion in TypeScript, and if that had a runtime equivalent 

[09:22:01.0347] 
how does that look in TS on fields?

[09:23:57.0998] 
```
class C {
  f!: string; // I promise this will be a string once constructed

  constructor() {
     this.#init();
  }

  #init() {
     this.f = 'hey';
  }
}
```

[09:25:11.0875] 
I use it more when adding type-annotations to existing .js code that has that seperate `init` pattern. Rather than in new code.

[09:25:33.0396] 
 * I use it more when adding type-annotations to existing .js code that has that seperate `init` pattern. Rather than in new code.

[09:44:33.0074] 
i assume it would depend on constructor params, otherwise you'd just initialize it as a field

[09:52:56.0676] 
yeah, my example was weak. Usually the value being initialised is more complex and based on arguments being passed around

[09:54:28.0577] 
If TypeScript sees a direct assignment to the field in the constructor body (not a closure) then the assertion is not required

[10:01:22.0443] 
https://jschoi.org/22/es-dataflow/

[10:10:56.0932] 
the module splitting thing is fake

[10:11:05.0421] 
we could totally optimize those cases in bundlers

[10:11:07.0613] 
we just don't

[10:11:35.0979] 
those cases = prototype-based fluent apis

[10:12:25.0041] 
i understand that to mean bundlers don't want to build more sophisticated static analysis, which, yeah, sounds like they can try to?

[10:12:32.0562] 
well

[10:12:36.0954] 
you really need types for it to work

[10:12:46.0043] 
We could (Closure can), but it's be incredibly hard (only TS has an equivalent type system and it's not a minifier)

[10:12:46.0534] 
and it's true there are many cases where you can't figure it out

[10:12:51.0417] 
And there are tons of deopts.

[10:13:12.0024] 
A single cast, and elimination isn't guaranteed anymore.

[10:13:33.0353] 
I don't think that's an acceptable "we could but don't"

[10:14:23.0033] 
so on paper the functional APIs have the exact same issue except the popular way to do it is simple enough (e.g. import foo and use foo without renaming or fancy namespace objects) to analyze?

[10:14:46.0529] 
Static analysis is trivial to perform, and it's built into every minifier

[10:14:54.0646] 
the functional APIs are always possible to analyze unless you do a `* as x` import

[10:15:05.0556] 
so the rules to learn to stay on the happy path are easier

[10:15:07.0101] 
Virtual dispatch requires types, and only Closure has a type system and minifier combined to do it.

[10:15:28.0046] 
asked another way, functional APIs don't have complex flow like being passed to HOFs?

[10:15:33.0313] 
Namespace imports are DCEable depending on how it's used.

[10:15:44.0879] 
the complex flow isn't the problem

[10:15:46.0702] 
If you do `ns.foo()`, it's easy to see only `foo` import is used

[10:15:56.0407] 
ehhh

[10:16:06.0946] 
what's the problem if not complex flow?

[10:16:08.0877] 
namespace objects are exactly as difficult to analyze as OO-based modules

[10:16:09.0207] 
If you do `Object.values()`, then it becomes dynamic and you can't DCE

[10:16:17.0539] 
Not at all

[10:16:25.0245] 
yes at all; they're the same thing

[10:17:02.0596] 
There's a huge difference between a static `ns` import and a dynamic variable binding to an object.

[10:17:11.0394] 
 * There's a huge difference between a static `ns` import and a dynamic variable binding to an object.

[10:17:23.0935] 
you can pass `ns` imports around

[10:17:34.0321] 
and now they are dynamic variables bound to objects

[10:17:41.0224] 
You can treat a namespace as an object with key-values, but that's not the norm for imports.

[10:18:03.0131] 
Again, it depends on how it's used.

[10:18:09.0379] 
yeah.

[10:18:20.0795] 
that's what i'm asking, does it come down to norms

[10:18:24.0053] 
The point is it starts from a staticly analyzable point, so it can remain statically analyzable.

[10:19:08.0725] 
shu: anyway, the problem is if you have something like

```js
function pretty(x) {
  console.log(x.color())
}
```

and `print(y)` gets called, anywhere in your code, then in order to eliminate a prototype method named `color` on some class you have to prove that no instance of the class is ever passed to `pretty`

[10:19:21.0995] 
now, IME that's fairly practical, but no one really implements that optimization

[10:19:26.0881] 
bakkot: that is exactly the "complex flow" problem?

[10:19:32.0762] 
and it's true that there are places which become hard

[10:19:49.0140] 
you gotta monomorphize and have some kind of class hierarchy analysis to eliminate

[10:19:50.0219] 
ah, sorry, I didn't realize that's what you meant

[10:20:04.0594] 
sorry yeah it's an unclear term

[10:20:08.0486] 
then yes, the complex flow is the problem, and FP doesn't have nearly as much of that particular kind of flow

[10:20:57.0864] 
I like that we are acknowledging this ecosystem schism, I don't think we've really explicitly talked about this enough

[10:21:35.0756] 
a schism suggests there was some unified whole that split

[10:21:40.0107] 
there are two paradigms

[10:21:57.0685] 
i don't understand why the difference is so harmful yet

[10:22:10.0555] 
it's entirely possible that you can mix paradigms in the language in a way that does not discourage their use together in programs

[10:22:22.0483] 
and we have a semblance of that today

[10:22:24.0569] 
 * it's entirely possible that you can mix paradigms in the language in a way that does not discourage their use together in programs

[10:22:42.0864] 
i don't quite understand the line being drawn here as the one contended to be harmful

[10:24:28.0232] 
method call syntax and function call syntax don't mix as well as they could, so it currently forces you to pick a lane and stick to it

[10:24:49.0384] 
"zero cost" is also not true here; the FP paradigm gets megamorphic real fast, in a way the OO paradigm maybe does not

[10:24:58.0246] 
that's the contention. i don't see why that's so harmful

[10:25:07.0543] 
I think that "zero cost" line of thought comes from statically compiled languages

[10:25:15.0531] 
 * I think that "zero cost" line of thought comes from statically compiled languages

[10:25:20.0584] 
bakkot: that's a good point

[10:25:22.0128] 
Other delegates have argued it's harmful, I think JSC is trying to explain it's not that bad.

[10:25:43.0236] 
also this interop argument is a new argument to me: i though the main motivation thus far has been word order for the FP stuff

[10:26:27.0422] 
This is to explain that the schism some delegates are afraid of is actually improved by adding the call-op.

[10:26:43.0645] 
You can interop between the two styles better with both pipe and call.

[10:28:51.0026] 
bakkot: the runtime polymorphism point is very good, yes

[10:29:29.0829] 
if you have two distinct methods `ClassA.F` and `ClassB.F`, you've split it manually by just how you organize code into two contexts that gather type feedback independently

[10:29:48.0225] 
i have looked at automatically inferring such splits for functional-style programs in VMs and have never had any success

[10:30:03.0100] 
would be a fun grad problem but i don't know of any good heuristics

[10:30:55.0432] 
once you're into the optimizing tier you can get splitting like this for free with deep inlining, but the point is this is way way before all that, before you decide to even gather type feedback

[10:33:47.0342] 
shu: it's also worth considering that this feature may be used most often for high-level organisation and therefore may usually not be in the hot path

[10:34:07.0571] 
what is "this feature"?

[10:35:03.0863] 
I was thinking about the pipe operator

[10:35:38.0872] 
very skeptical of that claim, i don't think method chaining is any less likely in hot paths, if that's a suitable analogy

[10:35:49.0177] 
nor normal function application, if this makes some cases of that easier to read

[10:42:56.0799] 
I think the point that call-this is only useful for late-binding APIs, and at that point you are not using the OO paradigm at all and so should not be talking about `this`, is very good

[10:43:52.0066] 
like there's no reason not to just pass the context argument as the first API, over using call-this

[10:43:58.0566] 
no reason whatsoever

[10:44:31.0926] 
We’ve seen that `.call` is already one of the most common methods in the entire language, though. Like for conditional switching between methods.

[10:44:34.0764] 
> <@bakkot:matrix.org> like there's no reason not to just pass the context argument as the first API, over using call-this

Call site ergonomics will prevent adoption of this.

[10:44:36.0505] 
> <@bakkot:matrix.org> like there's no reason not to just pass the context argument as the first API, over using call-this

 * We’ve seen that `.call` is already one of the most common methods in the entire language, though. Like for conditional switching between methods.

[10:44:51.0393] 
jschoi: again, I don't think "people are already doing this" is a good enough reason to add it to the language

[10:44:57.0956] 
Firebase is so strange in a language that has settled on OOP designs

[10:45:00.0455] 
(also I didn't find your data all that convincing, to be frank)

[10:45:33.0805] 
> <@jridgewell:matrix.org> Call site ergonomics will prevent adoption of this.

I don't think inventing _entirely new syntax_ actually does amount to being a more ergonomic syntax

[10:47:42.0849] 
> <@jridgewell:matrix.org> Firebase is so strange in a language that has settled on OOP designs

the language hasn't "settled" on that tho, it's just parts of the ecosystem that have.

[10:47:46.0860] 
Are there any specific problems that you see in the data? Let me know, maybe later over DM or something, and I can see if we can examine them more closely.

[10:48:31.0523] 
> <@bakkot:matrix.org> (also I didn't find your data all that convincing, to be frank)

 * Are there any specific problems that you see in the data? Let me know, maybe later over DM or something, and I can see if we can examine them more closely.

[10:48:34.0728] 
> <@jridgewell:matrix.org> Firebase is so strange in a language that has settled on OOP designs

I've always found JS very unopinionated about whether applications should be written with an OOP pattern, and I see quite a lot of code written in a more functional style. Usually it's a mix.

[10:48:57.0488] 
> <@ljharb:matrix.org> the language hasn't "settled" on that tho, it's just parts of the ecosystem that have.

This is where the puck is heading, libraries designed for code splitting will become more prevalent

[10:49:09.0272] 
right but those aren't OOP

[10:49:13.0815] 
those are more functional

[10:49:39.0816] 
they may use some kind of "mixin" magic, or pipeline, to pretend it's OOP, but that doesn't make it that style - just written in that style

[10:49:43.0674] 
 * they may use some kind of "mixin" magic, or pipeline, to pretend it's OOP, but that doesn't make it that style - just written in that style

[10:54:26.0294] 
 * Are there any specific problems that you see in the data? Let me know, maybe later over DM or something, and I can see if we can examine them more closely. I’m not sure how we could have done better.

[10:54:32.0816] 
 * Are there any specific problems that you see in the corpus analysis? Let me know, maybe later over DM or something, and I can see if we can examine them more closely. I’m not sure how we could have done better.

[11:00:35.0629] 
`super` actually is totally reasonable

[11:00:44.0677] 
if it refers to the superclass, anyway

[11:01:11.0576] 
`this` is just a variable name; i had no idea it was distinguished in the grammar in any way and find that very surprising.

[11:01:14.0688] 
jschoi: Thx. for the presentation. It gave me a good overview and you addressed a lot of good points. Personally I agree with you - JavaScript is a multi-paradigm language and we should keep it that way. However I am also unsure, what that really means. :)

[11:03:05.0120] 
TabAtkins: so you would be surprised that `this = 0` fails to parse?

[11:03:38.0184] 
TabAtkins: I don't believe you

[11:03:39.0599] 
Assignment and reference are different contexts that I'm okay to distinguish between

[11:03:53.0688] 
Michael Ficarra: you don't believe me? how? what?

[11:04:30.0105] 
Prior art I'd say. Decorators have been using the `@` for ages...

[11:04:49.0425] 
TabAtkins: working on pattern matching, you became familiar with the fact that undefined/Infinity are identifiers, which means you should know that things like `this`/`null`/`true` are not

[11:05:38.0641] 
???? I have no idea why you'd think that's a necessity, notably the idea that `this` is definitely grouped in with the other values.

[11:05:56.0292] 
(But also, uh, "I don't believe you" is a pretty sucky thing to allege, dude.)

[11:06:59.0377] 
All those other things are literals in practice, even if they're technically identifiers for technicaly/legacy reasons. `this` is something completely unrelated

[11:08:46.0623] 
HE Shi-Jun:

```
class X {
  static decorate() {}
}

class Y extends X {
  @super.decorate
  foo() {}
}
```
something like that

[11:08:57.0858] 
 * HE Shi-Jun:

```
class X {
  static decorate() {}
}

class Y extends X {
  @super.decorate
  foo() {}
}
```
something like that

[11:11:52.0633] 
this isn't even a case we'd need to leave to a linter

[11:12:05.0395] 
either it's a sensible thing to do, in which case people would do it and a linter shouldn't ban it, or it's not, in which case there's no need for a lint rule

[11:12:29.0033] 
 * either it's a sensible thing to do, in which case people would do it and a linter shouldn't ban it, or it's not, in which case there's no need for a lint rule

[11:12:44.0618] 
right, this stuff - edge cases or not - only makes sense if someone actually has a decorator to reference

[11:12:49.0716] 
If there's not an actual problem with allowing them, then any restriction which requires authors to understand arcane details of the grammar is an unreservedly bad idea

[11:12:57.0413] 
if it's there, why not allow it? if it's not there, they'll get a TypeError anyways

[11:12:58.0208] 
> <@tabatkins:matrix.org> (But also, uh, "I don't believe you" is a pretty sucky thing to allege, dude.)

no offense meant, all I was saying is that I'm sure that if you had thought about it for a second, you'd have been able to figure it out, since the proposal you presented at this meeting specifically accounts for all identifiers that people don't think of as identifiers

[11:14:24.0791] 
I had thought about it for a second, and would not have figured it out, because you're assuming that I've read the grammar deeply and recently enough to immediately know what is "identifier" and what is "other things which look similar syntactically but are a different category". I assume *you've* done so, but I definitely have not.

[11:16:13.0456] 
I can rattle off the tip of my tongue arcane details of CSS syntax that would very likely confuse you (because I wrote the CSS Syntax spec and have written two parsers) but I don't have that level fo knowledge for JS.

[11:16:22.0906] 
 * Are there any specific problems that you see in the corpus analysis? Let me know, maybe later over DM or something, and I can see if we can examine them more closely. I’m not sure how we could have done better.
Your point is taken that “just because people are doing it, we shouldn’t necessarily encourage it,” but that’s separate from the validity of the data themselves.

[11:17:21.0924] 
> <@ljharb:matrix.org> HE Shi-Jun:
> 
> ```
> class X {
>   static decorate() {}
> }
> 
> class Y extends X {
>   @super.decorate
>   foo() {}
> }
> ```
> something like that

What does `super` reference here? It's decorating an instance method, so why would it reference the super constructor and not the super instance ?

[11:17:30.0331] 
@shu Ok, after second thought, I have to say disallowing @meta.property seems too strong... I'm still need some time to think about `@this` `@super`...

[11:17:49.0993] 
understood. now i'm confused again what the conclusion is

[11:18:17.0427] 
One question, do we allow `@this class {} ` now?

[11:19:04.0120] 
why not, as long as the `this` resolves to a decorator it'd work

[11:19:25.0651] 
shu: no conclusion

[11:19:26.0484] 
"that thing that falls out of consistency seems gross" is a reason to lint against it, not a reason to make it a parse error

[11:19:29.0721] 
I mean, because the issue is whether to allow `@this.dec`

[11:19:39.0775] 
bakkot: ok, thanks

[11:19:43.0489] 
A reminder:  Rob recuses as chair during Types as Comments.

[11:21:42.0396] 
> <@haxjs:matrix.org> I mean, because the issue is whether to allow `@this.dec`

Ok, I read the issue, `@this` is also not decided. I see.

[11:21:42.0982] 
> <@mhofman:matrix.org> What does `super` reference here? It's decorating an instance method, so why would it reference the super constructor and not the super instance ?

I would assume it has to be the super constructor; it shouldn't switch based on the kind of thing you're decorating

[11:21:51.0821] 
also the decorator is called before any instance is constructed

[11:21:58.0487] 
so calling an instance method (even from the prototype) is incoherent

[11:22:08.0446] 
the super constructor is the only thing which actually exists at that point

[11:23:11.0674] 
 * also the decorator is called before any instance is constructed

[11:24:11.0015] 
bakkot: so the context currently of decorator evaluation is the same as dynamic property name evaluation

[11:24:14.0248] 
so what does

[11:24:22.0671] 
hmm

[11:24:26.0580] 
My policy as a 10+ year language designer is that the line between "valid" and "invalid" code should be, as much as possible, simple and obvious from inspection by people with an average amount of experience and familiarity with the language. Mentally, the boundary that cleaves the two should be "smooth", rather than fractally textured, to the extent possible. Exceptions are allowed when something is actually problematic (but then, it might be good to disallow *more* than is strictly required to make the boundary smoother and easier to remember); exceptions for "nobody would do it" are bad unless they *also* serve to smooth out the boundary.

[11:24:28.0608] 
`class C { [super.foo]; }`

[11:24:28.0946] 
I kind of assumed it would be the same as `static {}` blocks

[11:24:30.0989] 
evalution to?

[11:24:44.0476] 
I should've caught that before

[11:24:59.0555] 
I would expect it to be the `super` of the _surrounding_ class, should it exist

[11:25:06.0916] 
`class C { [super.foo]; }` refers to the `super` from the outer context, yes

[11:25:07.0754] 
which would be the same as `this`

[11:25:20.0853] 
but `class extends B { static { super.x } }` refers to `B.x`

[11:25:57.0476] 
yeah, decorators evaluate before static blocks and generally have the same scope as code immediately outside of the class

[11:26:00.0433] 
same as property names

[11:26:03.0697] 
boo :(

[11:26:44.0296] 
I still think that we should allow these keywords

[11:27:05.0795] 
I just don't think there are many good use cases. It would be _gnarly_ code

[11:27:10.0143] 
ok so
```
class Parent {
  static decorate() {}
}
class Outer extends Parent {
  static x = @super.decorate class {};
}
```

[11:27:11.0077] 
Well I found that there could be use cases of `@super.deco class {}`, and it even could have use case of `@this.deco class {}`. but still such code look confusing. And people could always write `@(super.deco) class {}` if they want...

[11:27:24.0986] 
it's fine if bad code looks confusing

[11:27:30.0714] 
ljharb: I would expect that to be a syntax error

[11:27:37.0200] 
why?

[11:27:52.0347] 
it's important we don't make the parsing rules confusing; linters can keep the code clean.

[11:28:11.0731] 
same reason
```
class Outer extends Parent {
  [super.x] = 0;
}
```
is a syntax error

[11:28:17.0628] 
I think Wardmar 's point stands, @keyword seems like some special magic thing.

[11:28:23.0325] 
because `super` comes from the surrounding context, not from the class

[11:28:24.0233] 
same rules as dynamic properties, is why

[11:28:33.0798] 
I think the dynamic property rules are the wrong ones

[11:28:37.0989] 
static block rules would be better

[11:28:41.0665] 
or static initializers, even

[11:29:27.0174] 
the timing is more like dynamic props

[11:29:37.0209] 
ehhhhh

[11:29:48.0869] 
I don't think that difference matters in a relevant way for `super`

[11:31:02.0369] 
I also remember some people discussed the possible syntax like `@this` `@@this` in dsl proposal.

[11:31:11.0142] 
i'm pretty sure types that differ from all existing type checkers, especially with semantics, is a hard nonstarter

[11:31:22.0152] 
and i don't really see value in broadening the problem statement in that way

[11:33:22.0716] 
sorry, what is exactly being claimed here? is Waldemar's claim that Daniel says he is willing to consider other approaches but secretly will not be?

[11:33:38.0439] 
ill interupt

[11:34:26.0625] 
i don't agree with this actually. i did not take "types in JS" as the problem statement put forth by the champions

[11:34:36.0706] 
agreeing to that problem statement is a very different proposal to me

[11:34:41.0651] 
I think the high-level motivation should be narrow the gap between js and ts (or other type checkers).

[11:35:06.0906] 
I would be interested in hearing the TypeScript team's stance on whether they would adopt new syntax based on a syntax space we carve out, if that's what we decide to do

[11:36:33.0449] 
the slide before implies that yes ts would probably take hints from the standardization process

[11:36:57.0521] 
I mean that is how I interpret it

[11:37:04.0150] 
it's a two-way discussion

[11:39:00.0622] 
so like, concretely, if tc39 is like "all these declaration forms are too much, we're going to standardize on letting `:` be a new comment marker with unusual rules", would TS try to encourage users to shift over that or would they keep having `type x = 0;`

[11:39:07.0795] 
We are TC39. We are not M$. "They" present a proposal for stage 1. There is nothing, that suddenly explodes into a full-blown 200 page spec that we cannot block in any way. danielrosenwasser Has taken into consideration the various concerns and I see the proposal as broad as it should be. It is just stage 1.

[11:39:55.0355] 
bakkot: I'm gonna ask exactly that

[11:39:56.0662] 
bakkot: from what I understand, this discussion is on the menu for stage 1

[11:40:04.0375] 
ok cool

[11:40:13.0097] 
I am fine with stage 1 as long as those discussions are in scope

[11:40:54.0806] 
I mean I am no champion so let's see what is the answer to Michael's question

[11:41:42.0873] 
 * I mean I am no champion so let's see what is the answer to Michael's question

[11:43:57.0401] 
I'm unsure whether my topic counts as a reply anymore? that topic was kind of meandering

[11:44:07.0114] 
chairs: feel free to move it if you want

[11:46:45.0142] 
why should we tiptoe around singling out TS? i am kind of confused

[11:46:50.0441] 
it _is_ special in the ecosystem

[11:46:54.0420] 
The idea that we need something close to TS to express type semantics seems overstated on its face; mypy gets by reasonably on literally nothing more than `Foo[Bar, Baz]` for its types.

[11:46:59.0965] 
_we_ are not picking winners

[11:47:16.0545] 
shu: for one thing, TS keeps adding new syntax, so sticking with their current syntax is bad even if you ignore any other type checkers

[11:47:26.0115] 
that's not what i'm saying

[11:47:32.0850] 
seems reasonably likely that the type syntax of 2040 does not look like TS

[11:47:34.0272] 
 * seems reasonably likely that the type syntax of 2040 does not look like TS

[11:47:39.0023] 
even if it's still called that

[11:47:41.0659] 
i'm saying a non-technical thing, that it is fine to call out TS as part of the problem statement

[11:47:42.0941] 
(and it might not be)

[11:47:51.0406] 
hm

[11:47:55.0063] 
i agree that merging the grammars is infeasible

[11:48:06.0684] 
but apparently the two statements are somehow equivalent in folks' minds? that's confusing to me

[11:48:33.0826] 
yeah, calling out TS as something that should be accommodateable seems reasonable for the problem statement

[11:48:48.0012] 
like, i do _not_ want the problem statement to be "types in JS"

[11:48:59.0645] 
that's not a problem i'm actually interested in solving! but narrowing gap to TS certainly is

[11:49:30.0033] 
who's the speaker? for the notes

[11:49:45.0379] 
Francisco Tolmasky

[11:49:52.0161] 
Francisco Ryan Tolmasky I

[11:49:57.0665] 
shu I very much appreciated your earlier reframing to something like "non-functional syntax that is unambiguously associated with a syntax node"

[11:50:13.0269] 
this person does not have an acronym 

[11:50:13.0431] 
 * shu I very much appreciated your earlier reframing to something like "non-functional syntax that is unambiguously associated with a parse node"

[11:50:26.0901] 
Richard Gibson: thank you

[11:50:29.0883] 
like, nowhere?

[11:50:56.0308] 
hmm, that's surprising

[11:51:00.0004] 
https://github.com/tc39/notes/blob/main/delegates.txt

[11:51:01.0475] 
not seeing them

[11:51:10.0659] 
...

[11:51:20.0795] 
what's their affiliation?

[11:51:26.0202] 
he's from RunKit

[11:51:37.0662] 
somebody skipped an onboarding step

[11:51:48.0711] 
is that a member?

[11:51:58.0126] 
the application to TC39 was in his name but I'll add the issue to GitHub

[11:52:21.0643] 
RunKit, Inc. is an SPC member

[11:52:43.0076] 
 * RunKit, Inc. is an SPC member

[11:52:50.0059] 
thanks folks

[11:53:51.0399] 
I'm not seeing any onboarding issue for them in GH

[11:54:04.0059] 
(creating the onboarding issue, he was under the impression this was all done already)

[11:55:09.0715] 
> <@shuyuguo:matrix.org> that's not a problem i'm actually interested in solving! but narrowing gap to TS certainly is

if the problem the proposal is trying to solve is specific to TS, that needs to be made clear

[11:55:38.0292] 
genuinely asking, in what way is this currently unclear

[11:55:46.0644] 
and to be clear, there is nuance to "specific to TS"

[11:55:50.0993] 
it does not mean "make JS TS"

[11:56:02.0739] 
it means "narrowing gap to TS is part of the goal"

[11:56:16.0459] 
the responses to WH sounded like it was not specific to TS

[11:56:37.0748] 
to be clear, it is not solely around ts and there should be efforts to accomodate flow as well for instance even if it is less used

[11:56:38.0018] 
a solution can be not exclusive to TS and still be specific to TS

[11:56:40.0906] 
is how i understood it

[11:56:50.0993] 
flow and ts could evolve their type system in the same standardized space

[11:57:01.0428] 
 * flow and ts could evolve their type system in the same standardized space

[11:57:10.0416] 
> <@pouwerkerk:matrix.org> (creating the onboarding issue, he was under the impression this was all done already)

https://github.com/tc39/Admin-and-Business/issues/223

[11:58:07.0435] 
can we put the scope clarifications in the conclusion of the notes?

[11:58:32.0868] 
agree with ljharb we should be careful about community messaging

[11:59:02.0413] 
big +1 to kevin's thing

[11:59:47.0991] 
Community is already afraid: -> https://medium.com/codex/the-typescript-team-is-going-to-kill-javascript-59c65937258c

[11:59:55.0703] 
Daniel said the other day on the record that they would not give special treatment to TypeScript and would maintain neutrality among TS vs. Flow vs. X (with the caveat that what the committee decides is not up to him)

[12:00:13.0672] 
Which we will hope to see in upcoming discussions 

[12:00:25.0592] 
I assume the proposal repo will need to be updated to reflect this

[12:00:35.0346] 
That blogpost is jumping to some very wrong conclusions, so shrug.

[12:01:59.0098] 
> <@christianulbrich:matrix.org> Community is already afraid: -> https://medium.com/codex/the-typescript-team-is-going-to-kill-javascript-59c65937258c

this person is already severely mistaken in thinking that there will ever be a type system built into JS

[12:02:17.0786] 
we really gotta make, like, a formal statement about that somewhere

[12:02:19.0228] 
lol, but even if we did, we're still cool to do so with a pragma.

[12:02:24.0523] 
people keep thinking it will happen

[12:02:51.0191] 
how is TS's system not "real"

[12:02:51.0744] 
lol

[12:03:18.0443] 
i dunno, depends how you define "real" :-p

[12:03:34.0332] 
i define it by a thing that exists?

[12:03:41.0539] 
things not in the JS specification are not real

[12:03:46.0498] 
for example, console.log is fake

[12:03:49.0223] 
new worldview

[12:04:09.0074] 
"understood and given meaning by the browser" is a reasonable definition of "real" in this context

[12:04:35.0021] 
Thank you yulia. That was much needed.

[12:04:45.0426] 
Very great, where is the slide?

[12:05:00.0166] 
https://docs.google.com/presentation/d/1ls5RZiBaLekVrJoj4Ju8hBSGQdKLTXU1uI-0XcjcDvs/edit#slide=id.g1210bab1685_0_75

[12:05:06.0974] 
spec is here: https://ci.tc39.es/preview/tc39/ecma262/sha/efb411f2f2a6f0e242849a8cc8d7e21bbcdff543/#sec-apl-expression-rules

[12:05:07.0100] 
I'd like to share it to all chinese delegates because they are sleeping now

[12:05:21.0156] 
pr is here https://github.com/tc39/ecma262/pull/2717

[12:05:34.0056] 
it is april 1st in china, so we are shipping a bit early but it is april first somewhere 

[12:05:42.0434] 
TabAtkins: i had thought this, but! not being in ecma262 isn't what's stopping browsers from interpreting TS with a typechecker

[12:06:07.0648] 
we made it through everything?! no overflow! thanks chairs!

[12:06:18.0632] 
bakkot: another thing to consider re: `super` in decorators is that decorator evaluations are interwoven with dynamic prop evaluations 

[12:06:42.0222] 
it would be _possible_ to switch the context back and forth for each one, but certainly confusing

[12:06:50.0654] 
and I'm not sure if possible performantly

[12:07:07.0594] 
I guess in implementation it's probably different than in spec

[12:18:58.0587] 
Congrats on stage 5 yulia! Really record setting championing right there!

[12:23:34.0659] 
Really the best proposal ever! 👏 💯 😁

[12:31:05.0668] 
> <@pzura:matrix.org> it would be _possible_ to switch the context back and forth for each one, but certainly confusing

that's already how it works for `static` properties

[12:31:25.0520] 
?

[12:31:49.0322] 
static properties initialize in a separate phase interleaved with static blocks, after computed property names

[12:31:57.0479] 
the context remains the same for the whole phase

[12:32:05.0640] 
what, really

[12:32:13.0309] 
could've sworn we said it was going to be interleaved

[12:32:14.0724] 
well, whatever

[12:32:22.0028] 
I don't think anyone is actually going to notice the timing stuff

[12:32:39.0146] 
it would be confusing if you were an interpreter, but it's fine when you're just reading the code, since they're visibly different kinds of things

[12:47:58.0088] 
who among us can say we are not interpreters

[12:52:52.0023] 
"Types as Comments" is now renamed to "Type Annotations" as per Waldermar's suggestion  https://github.com/tc39/proposal-type-annotations

[16:46:31.0551] 
turns out there were many tests testing for the weird `Symbol.species` path in TypedArray constructors: https://github.com/tc39/test262/pull/3460

[16:46:40.0605] 
another data point for test262 is the main determinant of interop