2021-11-08 [12:19:34.0348] Could someone with permissions to tc39-transfer finish the transfer process for the proposals that advanced to Stage 1 last meeting? [13:03:36.0121] (that'd be the chairs) [15:30:52.0344] Aki: bterlson: Rob Palmer: ^ (would also appreciate finalizing transfer of structs, which i forgot to transfer to tc39-transfers after last meeting) [15:44:48.0796] Also when possible, I would like a chair to turn on GitHub Actions in proposals-bigint-math and proposals-array-fromasync and switch their repository homepages to their spec pages on tc39.github.com. 2021-11-09 [21:01:38.0133] github actions should be automatically on for everything, is it not? [21:01:41.0254] * github actions should be automatically on for everything, is it not? [11:40:20.0464] shu: what's `Atomics.waitAsync` waiting on? just a second implementation? [11:40:55.0600] correct [11:41:13.0789] it is actually pretty tricky to implement, and the use case is fairly niche, so probably not prioritized [11:41:23.0079] you have a use case? [11:45:55.0297] not really [11:46:02.0472] I was just going to publish a pure-JS `setTimeout` polyfill [11:48:38.0474] ah 2021-11-10 [11:29:06.0083] What was the deadline for October-plenary notes edits, again? I was planning to edit them over the weekend. [11:55:35.0313] jschoi: "They will be published on November 11th" per the reflector [11:55:50.0143] though I imagine you could ask to hold off a couple of days to get your edits in 2021-11-11 [16:03:46.0024] I'm happy to delay publishing until Monday. [16:08:08.0055] > <@ljharb:matrix.org> github actions should be automatically on for everything, is it not? GitHub Actions are not active for https://github.com/tc39/proposal-bigint-math/. (I was wrong about proposal-array-from-async, though. Actions are active on that one—although, for some reason, https://tc39.github.io/proposal-array-from-async/ doesn’t work.) [16:14:26.0880] jschoi: presumably you don't have github pages on, which is a distinct thing from having github actions on [16:16:13.0555] > <@bakkot:matrix.org> jschoi: presumably you don't have github pages on, which is a distinct thing from having github actions on Ah yeah, that’s right. That’s under repository settings, right? So I have two TC39 repositories in which the GitHub Pages option needs to be turned on, as well as editing the repository home page. One repository also needs to have Actions turned on. [16:17:18.0623] If you’re an admin on those repos you can do it yourself; if not, then that’s the ask id make of the chairs :-) [16:18:01.0634] Yes, I would like to be made admin of those repositories by a chair. I’ve pinged before but they’re busy, and it’s not urgent anyway. 😄 [16:18:14.0745] * Yes, I would like to be made admin of those repositories by a chair. I’ve pinged before but they’re busy, and it’s not urgent anyway. 😄 [16:22:39.0298] unfortunately when you transfer your own repo to an org, you lose admin rights on it by default; i usually try to restore those rights while it's in tc39-transfer but sometimes the chairs transfer the repos before i get to it 2021-11-15 [09:13:21.0177] @Rob Palmer: Sorry, I’m working on the previous plenary notes right now. I’ll try to have them done within the next five hours. [09:13:55.0299] * @Rob Palmer: Sorry, I’m working on the previous plenary notes right now. I’ll try to have them done within the next five hours. [09:25:54.0666] Alright. Please do finish soon! [11:08:07.0964] Someone has created a website that scrapes the tc39/proposals repo and then provides a UI to see various summaries/indexes. https://www.proposals.es/ It somewhat duplicates the official website, but has extra data, e.g. proposals are sorted by star count. [11:14:52.0104] There was https://github.com/bevacqua/prop-tc39 which was active for few years, also there is https://jsfeatures.in [shameless plug] we should request the author of proposals.es to contribute to the official site rather? [11:15:39.0218] * There was https://github.com/bevacqua/prop-tc39 which was active for few years, also there is https://jsfeatures.in [shameless plug, old needs update] we should request the author of proposals.es to contribute to the official site rather? [11:18:53.0389] official site definitely should not include star counts [11:18:55.0773] star counts are poison [12:14:37.0335] should include randomized star counts on every load [12:14:39.0687] keep'em guessing [12:15:36.0584] also include some other kind of emoji counts, like 🥦 or 🪁 [12:19:49.0640] Putting aside the broccoli for a moment, I think there was a related plenary discussion on maintaining authoritative structured data to enable more folk to create live websites for viewing proposal summaries. https://github.com/tc39/notes/blob/master/meetings/2020-11/nov-19.md#dealing-with-tc39-data [12:23:43.0796] We can ask Yulia the status of this, but I read it as general agreement with the principle, modulo Leo's test262 experience with trying this previously. My guess is that, like many things in TC39, we just need some energetic volunteer willing to lead an initiative to make it happen. [12:24:03.0211] oh Rob Palmer while you're here, do you have access to finish the transfer for https://github.com/tc39-transfer/proposal-structs? [12:25:46.0494] that is now transferred, Shu [12:27:55.0883] much appreciated, thank you 2021-11-17 [07:45:32.0655] jschoi: how do you do your corpus analyses? i'm interested in gauging the popularity of some Array methods [07:46:50.0227] shu: Take a look at the “What methodology was used” disclosure element at the end of this section: https://github.com/tc39/proposal-bind-this#bind-and-call-are-very-common. [07:47:40.0562] ah you did mention Gzmenid [07:47:42.0385] neat, thank you! [07:47:55.0416] Basically, download Gzemnid’s slim.code.js.txt.lz4 and search.topcode.sh. Then run: ```bash ./search.topcode.sh '\.bind\b' | awk 'END { print NR }’ ``` …or whatever. [08:52:25.0017] Not as impressive as what jschoi has done but we also did a bit of corpus research for change-array-by-copy: https://github.com/tc39/proposal-change-array-by-copy/issues/37 [08:53:35.0018] regex matching, so .slice could be string or array 2021-11-18 [11:35:41.0988] why is `WeakRef.prototype.constructor` normative optional? https://tc39.es/ecma262/#sec-weak-ref.prototype.constructor [11:36:14.0396] SES IIRC? [11:43:19.0397] how so? I could see WeakRef itself being normative optional, but what is the point of shipping a WeakRef whose prototype does not have a `constructor` property? [11:45:12.0978] and I don't see discussion at https://github.com/tc39/ecma262/pull/2089 other than "we're adding inline normative optional spec text" from yulia in the PR description without further explanation [11:49:30.0455] The motivation is that it can be removed so you wouldn't be able to create a new WeakRef from an instance. Aka sharing an instance to observe the liveness of one object doesn't allow you start observing the liveness of any object. [11:51:27.0778] but why would an implementation ship that rather than requiring code to delete the property? [11:52:51.0713] it seems bizarrely special-cased from an implementation perspective [11:53:21.0107] same reason an implementation would "ship" without any other normative-optional thing [11:53:26.0402] The idea is that an environment without access to the contructor through the prototype would still be a compliant JavaScript environment. Aka not introduce code that expects it to be there. [11:53:40.0139] code that requires normative-optional things to exist isn't portable; it's reasonable for an implementation to only support portable code (where "implementation" could include "any environment that's been prepared with first-run JS code") [11:54:01.0592] * code that requires normative-optional things to exist isn't portable; it's reasonable for an implementation to only support portable code (where "implementation" could include "any environment that's been prepared with first-run JS code") [11:54:30.0032] Richard Gibson Is there any reason you would want it to always be there? [11:54:55.0724] besides the "it's different [11:55:28.0028] to avoid the cognitive burden of an exception to the rule that every built-in constructor's prototype has a `constructor` property referencing it [11:56:52.0288] `delete builtInConstructor.prototype.constructor` is always allowed, but only in this one case is a conforming implementation allowed to ship without the property present at all [11:58:37.0884] Do you have a specific use case, or is it conceptual only ? [11:58:51.0417] the latter [11:59:51.0331] it's not even like it allows SES or similar to avoid the `delete WeakRef.prototype.constructor` code, because conforming implementations can and do ship with it [12:01:04.0796] No but it means the environment SES/lockdown creates is still a fully compliant JavaScript environment [12:01:27.0624] no, that isn't true because of the other mutations [12:01:42.0865] Function.prototype, Date.now, Math.random, etc. [12:03:04.0116] Ok, fair, it's one less difference, and we're working on mitigating the others. E.g. all those you mention are there, but they throw. Doing that on `Function.prototype` is ok because SES has to virtualize `Function` anyway. [12:04:18.0003] an implementation that shipped with a https://tc39.es/ecma262/#sec-math.random that throws exceptions would not be conforming with https://tc39.es/ecma262/#sec-math.random [12:04:36.0343] Having the spec say "this may not be there" encourages programs to not rely on it being there. [12:06:53.0694] SES lockdown intentionally restricts the environment in ways that violate the spec; why should there be a special exception for WeakRef.prototype.constructor? [12:07:09.0632] Right, I think we're trying to compare something that was there from the beginning, and something that is introduced more recently. E.g. for arrays, most original methods seem to skip over holes, but all newer ones don't. It's a difference that avoids repeating previous mistakes in light of new knowledge [12:08:44.0612] if that were the case, then shipping it should be considered a violation. This allows for differences that are rightfully discouraged elsewhere [12:10:33.0206] we don't permit implementations to pass holes to Array.prototype.flatMap callbacks [12:12:35.0036] so I guess I have my answer about why the annotation is there, but the answer doesn't make sense [12:15:32.0549] There is no risk in allowing the WeakRef constructor in a non-SES environment, there is in SES. And SES strives to provide a fully compatible environment. So only SES needs to remove the constructor. I assume removing it always was not an option (I wasn't around when this was decided) [12:17:24.0028] in what sense is the SES environment "fully compatible" when it intentionally blocks execution of unsafe code that a conforming environment is required to support? [12:19:45.0261] "strives to" is the operating keyword here. The idea is to stop introducing further things that SES would have to willfully break, while working on remediating the ones that currently do (the override mistake is still around) [12:23:13.0506] doesn't SES also freeze all builtins, including new ones like WeakRef? [12:25:59.0221] it is important for ES conformance that they be mutable, and important for SES that they not be. There's an explicit divergence there that seems to me like it has exactly the same character as deleting and overriding properties in a way that is allowed by the spec but results in an environment that does not itself conform with the necessary initial state [12:35:42.0355] and worse, anyone who cares about restricting access to liveness information must control the global `WeakRef` anyway, even if the host implementation decided not to include `WeakRef.prototype.constructor`. There's just doesn't seem to be any benefit in shipping without it or in considering such an environment to be a valid initial state [12:37:20.0540] I would like to see code which assumes `WeakRef` contructor to be present on the global [12:48:19.0234] i just don't see what value SES gets from claiming compliance [12:48:31.0445] if it doesn't care about interop, my position is it doesn't need to care about compliance either [12:48:36.0270] it can still strive to be mostly interoperable [13:11:15.0082] Does SES claim to be “compliant” with ES? Last I checked it merely claimed to be a syntactic subset with “mostly” identical semantics. [13:12:05.0289] if it doesn't then i am further confused why mark cares about normative optionality of things [13:12:20.0652] * if it doesn't then i am further confused why mark cares about normative optionality of things [13:13:01.0042] Probably wanting to maximize the “mostly” part in “mostly identical semantics”, I guess, haha. [13:13:26.0788] he can perfectly well claim that without the spec having any special allowances [13:13:37.0023] just say they're willful violations, but very few and sensible for this use case [13:23:39.0629] * Does SES claim to be “compliant” with ES? Last I checked it merely claimed to be a syntactic subset with “mostly” identical semantics. Ditto for Jessie versus SES. [13:32:41.0830] Can someone in TG2 please add a String titlecase method so I can stop having conversations like this? https://twitter.com/smooshMap/status/1461445458253860864 [13:33:15.0899] Richard Gibson: given you worked on Intl.Segmenter, you might be interested ^ [13:44:43.0158] I saw some people asking for a camel-casing method too on Discourse, for what it’s worth. [13:51:11.0872] jschoi: if we had titlecasing, camel casing could be implemented easily with Intl.Segmenter [13:51:31.0460] but we just can't implement titlecasing without UNIDATA [13:57:17.0287] Richard Gibson: it sounds like we should discuss how SES requirements and JavaScript compliance interact, and if anything should be formalized. Maybe a good topic for a future SES meeting? [14:05:21.0626] Michael Ficarra: you should +1 https://github.com/tc39/ecma402/issues/294 if you want that [14:11:01.0090] > <@michaelficarra:matrix.org> but we just can't implement titlecasing without UNIDATA Titlecasing is definitely complex, but I suspect many developers just want a capitalizeWords or something, heh. [14:48:08.0907] why not toTitleCaseASCII [14:51:32.0220] jschoi: I think what Unicode calls title case, you call capitalise words [14:51:58.0207] which is still quite hard to do [14:55:52.0959] Well, in § 5.18 (https://www.unicode.org/versions/Unicode14.0.0/ch05.pdf#page=43), the Standard refers to “titlecasing” as a process in which not all words are capitalized, e.g., “The Merry Wives of Windsor” in English and “Les joyeuses commères de Windsor” in French. [14:58:47.0683] > <@michaelficarra:matrix.org> jschoi: I think what Unicode calls title case, you call capitalise words * Well, in § 5.18 (https://www.unicode.org/versions/Unicode14.0.0/ch05.pdf#page=43), the Standard refers to “titlecasing” as a process in which not all words are capitalized, e.g., “The Merry Wives of Windsor” in English and “Les joyeuses commères de Windsor” in French. [15:07:03.0844] jschoi: Looks like they use it in both ways > Titlecasing refers to a casing practice wherein the first letter of a word is an uppercase letter and the rest of the letters are lowercase. This typically applies, for example, to initial words of sentences and to proper nouns. Depending on the language and orthographic practice, this convention may apply to other words as well, as for common nouns in German. Titlecasing also applies to entire strings, as in instances of headings or titles of documents, for which multiple words are titlecased. The choice of which words to titlecase in headings and titles is dependent on language and local conventions. For example, “The Merry Wives of Windsor” is the appropriate titlecasing of that play’s name in English, with the word “of” not titlecased. [15:07:21.0671] * jschoi: Looks like they use it in both ways > Titlecasing refers to a casing practice wherein the first letter of a word is an uppercase letter and the rest of the letters are lowercase. This typically applies, for example, to initial words of sentences and to proper nouns. Depending on the language and orthographic practice, this convention may apply to other words as well, as for common nouns in German. Titlecasing also applies to entire strings, as in instances of headings or titles of documents, for which multiple words are titlecased. The choice of which words to titlecase in headings and titles is dependent on language and local conventions. For example, “The Merry Wives of Windsor” is the appropriate titlecasing of that play’s name in English, with the word “of” not titlecased. 2021-11-19 [19:20:30.0271] Ah, I suppose the first and second sentences do actually refer to simply capitalizing words. [19:21:11.0807] Though of course “word” is still locale dependent, like “L’Whatever” in French…but that’s Segmenter’s problem, of course. [19:22:05.0202] * Though of course “word” is still locale dependent, like “L’Whatever” in French…but that’s Segmenter’s problem, of course. [19:22:29.0111] * Ah, I suppose the first and second sentences do actually refer to simply capitalizing words. [10:10:35.0486] When will Oct notes be published? [11:25:49.0974] Tomorrow morning. Apologies I have been swamped. 2021-11-21 [02:15:58.0106] The notes PR is now up. Apologies for the delay. [14:27:23.0657] Rob Palmer: not to put more on you if you're already busy, but there are a few repos parked in tc39-transfer that hit stage 1 last meeting. I know my four RegExp proposals are ready, though I cant recall the status of the others. [15:16:13.0598] Thanks for the reminder rbuckton - those repos are now transferred. 2021-11-22 [18:41:48.0876] > <@robpalme:matrix.org> Thanks for the reminder rbuckton - those repos are now transferred. Thanks! [08:38:59.0851] Hi delegates; sharing a moderation action for transparency: the CoC committee has blocked a GH user from our organization for posting spam to the proposals repo. As always please let me know if you have any questions. Thank you! [09:57:43.0444] as always I am grateful to the CoC committee and the chairs for their good work and efforts both in wrangling community at its worst and in helping us all to work together effectively [12:25:27.0342] Is there a reason why the RegExp pattern semantics are written in a way that is far different from the rest of the spec? It uses terms like "ordered pair" as opposed to using Records, and "captures `m`" instead of using internal slots. [12:55:55.0829] rbuckton: I think it was probably just written by someone else [12:56:00.0914] we're actively working on fixing those [12:56:30.0811] e.g. recently landed https://github.com/tc39/ecma262/pull/2531 [12:57:03.0081] and https://github.com/tc39/ecma262/issues/1742#issuecomment-675745153 tracking the "ordered pair" thing [12:58:52.0137] and https://github.com/tc39/ecma262/issues/1884 for the "captures `m`" thing