2022-08-03 [12:30:33.0312] any opinions on how to refer to a "plain-old" unregistered Symbol in an error message [12:31:52.0978] oh "unique" [12:36:58.0791] rkirsling: not-registered [12:37:14.0327] all symbols are unique [12:39:01.0105] darn [12:39:03.0444] alright [12:39:42.0254] hopefully users know what they're doing then [13:59:05.0978] rkirsling: they won't 2022-08-07 [18:18:38.0793] With regards to https://github.com/tc39/proposal-pipeline-operator/issues/91#issuecomment-1193358142……can someone confirm that `<>`, without any tag name, actually means something in JSX? [18:22:46.0669] jschoi: Can confirm. It transpiles down to something along the lines of `React.createElement(React.Fragment, ...)`. Here is the react docs page: https://reactjs.org/docs/fragments.html#short-syntax. [18:29:20.0667] `<>` is the start of a JSX fragment, with `` marking the end of a fragment. 2022-08-09 [06:48:51.0044] Hey folks, i am brushing up the invariants proposal repo to prep for presentation of a system near the end of the year [06:49:33.0638] I'd like to get more feedback on invariants that you consider important. They do not have to be "established" (as in, agreed with the whole committee). Instead, they should be existing aspects of the language that you consider important to maintain [06:49:44.0587] this is fact finding, not "absolute" -- repo is here: https://github.com/codehag/documenting-invariants [06:49:55.0480] ideally, you can make a PR, but an issue is fine and I'll reach out later to ask questions [06:50:10.0686] there is a template at the bottom of the known_invariants.md file [06:52:27.0446] > lighter weight process like what we do for normative specification adjustments +1 2022-08-15 [12:00:58.0274] Hello delegates, please could we collect your feedback on scheduling the final plenary meeting of the year. There is the potential to have an in-person meeting in Europe if we get sufficient interest. https://github.com/tc39/Reflector/issues/444 [13:16:32.0536] kind of exciting that by being in Japan, CET meetings will be at a reasonable hour [13:17:02.0534] ...though the opposite side is that US meetings will require a flight lol [14:35:45.0203] so in implementing Array#toSorted i learned that Array.sort doesn't skip own-holes in the array, but it actually skips missing properties all the way up the prototype chain [14:35:47.0246] like wtf [14:35:51.0047] come on [14:36:14.0228] i always thought when we talked about skipping holes it was calling HasOwnProperty [14:36:16.0643] but it calls HasProperty [14:55:18.0432] #10daychallenge 2022-08-16 [18:46:17.0858] > <@shuyuguo:matrix.org> but it calls HasProperty Is that related to Array-like objects? [01:02:08.0835] > <@robpalme:matrix.org> Hello delegates, please could we collect your feedback on scheduling the final plenary meeting of the year. There is the potential to have an in-person meeting in Europe if we get sufficient interest. > > https://github.com/tc39/Reflector/issues/444 Thanks to everyone who has completed the survey so far. We're hoping to get all feedback by Wednesday 24th August (a week away). [07:11:54.0979] Jack Works: i doubt it? it's probably just how it's always worked 2022-08-18 [00:21:32.0249] Thanks to the 21 people who have completed the plenary survey for the Nov/Dec meeting. For anyone who hasn't seen it yet, please check it out - your feedback is desired by Wednesday 24th August (6 days away) https://github.com/tc39/Reflector/issues/444 2022-08-21 [20:07:24.0228] I’m starting to write Test262 tests for Array.fromAsync. Is there any way to check that a promise in an async function has been awaited only once? For example, in `await Array.fromAsync([ Promise.resolve(0) ])`, the input promise must be awaited only once. How can that be verified? (This is the same behavior as in `for await (const v of [ Promise.resolve(0) ]) …`, and I can’t find any test in https://github.com/tc39/test262/tree/master/test/language/statements/for-await-of that verifies this for `for await` either.) [20:07:37.0757] * I’m starting to write Test262 tests for Array.fromAsync. Is there any way to check that a promise in an async function has been awaited only once? For example, in `await Array.fromAsync([ Promise.resolve(0) ])`, the input promise should be awaited only once. How can that be verified? (This is the same behavior as in `for await (const v of [ Promise.resolve(0) ]) …`, and I can’t find any test in https://github.com/tc39/test262/tree/master/test/language/statements/for-await-of that verifies this.) [20:08:21.0557] * I’m starting to write Test262 tests for Array.fromAsync. Is there any way to check that a promise in an async function has been awaited only once? For example, in `await Array.fromAsync([ Promise.resolve(0) ])`, the input promise must be awaited only once. How can that be verified? (This is the same behavior as in `for await (const v of [ Promise.resolve(0) ]) …`, and I can’t find any test in https://github.com/tc39/test262/tree/master/test/language/statements/for-await-of that verifies this for `for await` either.) [21:15:49.0276] Outside of test262 I would patch `then` to record how many times it is called. Not sure whether test262 has any other mechanisms. [22:53:32.0581] was the sf community event recorded anywhere? 2022-08-22 [08:31:21.0668] we really should merge the Array#group test262 tests, i'd like to ship [08:32:35.0128] can someone take those PRs over? https://github.com/tc39/test262/pull/3354 and https://github.com/tc39/test262/pull/3353 [10:14:23.0405] Yeah that would be great, we are also waiting on those [10:14:36.0055] Also, no compat issues appear to have arisen [10:15:17.0963] They look almost done 2022-08-23 [00:32:55.0833] Thank you to the 29 people who have completed the plenary survey for the Nov/Dec meeting 👍 For anyone who hasn't seen it yet, please check it out - your feedback is desired by Wednesday 24th August (**tomorrow**) 🔥 https://github.com/tc39/Reflector/issues/444 2022-08-24 [14:42:43.0917] littledan (or anyone else): thoughts on the spec editors having discretion to declare a contribution as non-significant for the purposes of the IP agreement, instead of needing to ping contributors? I don't know if ecma's policies would allow that but it would be nice for stuff like https://github.com/tc39/ecma262/pull/2863 2022-08-25 [03:55:17.0691] err, yeah, I think this change does not have copyright, and I agree that this is editor discretion (who else would decide?), but also I think it's a good idea to generally try to get people to sign anyway if they haven't. Is this becoming too burdensome? [03:55:54.0963] There is no Ecma infrastructure for having policy/opinions here--the W3C has that, but we're sort of on our own. [03:57:22.0701] I would suggest something like, pinging the thread to ask people to sign, and if a week passes and they don't sign and the change doesn't seem to have meaningful IP (as this one seems to not, and yes I agree the editors decide), then landing it. I agree that you shouldn't stress yourself out intensely chasing people down. [03:57:51.0227] * I would suggest something like, pinging the thread to ask people to sign, and if a week passes and they don't sign and the change doesn't seem to have meaningful IP (as this one seems to not, and yes I agree the editors decide), then landing it. I agree that you shouldn't stress yourself out intensely chasing people down. [03:57:57.0994] In this case, exactly that strategy of just pinging on the thread already worked, so let's just keep doing that. [14:12:03.0563] > Is this becoming too burdensome? Not on the editors, but it's kind of an inherently burdensome request for contributors. It's several pages of legalese you're being asked to agree to, and also when I was a student if I were asked to sign an IPR I would probably have wanted to talk to the department lawyers to confirm that they weren't going to try to claim work I was doing, which they do sometimes do want to claim, before I was willing to represent that I did in fact have the rights to provide "all contributions I will make". (Probably talking to the lawyers would have been overkill, but I tended to be cautious about that sort of thing when I was in school.) So I'd prefer avoiding making the request when it's not actually necessary. 2022-08-26 [04:12:32.0615] Thanks to everyone who filled in the recent plenary survey. The November 2022 plenary meeting will be a hybrid meeting in A Coruña, Spain on 29 November. https://github.com/tc39/Reflector/issues/444#issuecomment-1228363201 [09:27:23.0791] there were 13 definite yeses? [10:54:42.0990] bakkot: Well, I guess I disagree here; I'd rather take that pushback as it comes. So far, everyone I've asked to sign this form has done so without complaints. If someone does push back, then in that case we can do the extra effort to make sure their contribution doesn't have IPR. [10:55:39.0170] (and at that point, yes I agree this is editor discretion) [10:57:40.0393] As a student I would not have pushed back, I'd've just either done that work or disappeared forever [10:58:18.0081] I guess I care more about reducing our exposure than being open to contributions from people who are wary of signing an agreement like this [10:58:48.0708] Fair enough. 2022-08-30 [18:01:21.0578] PSA: trying to schedule an incubator call before the next plenary on decorator metadata. please fill out the doodle on the reflector thread if interested! 2022-08-31 [11:45:31.0678] I drafted a letter to Ecma about the stenography issue: https://pastebin.mozilla.org/Jik8gc1N [11:46:09.0697] If you have any feedback, please let me know over the next 24 hours before I send it [11:46:20.0167] (or, let me know if you think I should wait longer before sending it) [11:55:57.0656] great. I wonder if it's not too dismissable, but you know the audience better than I do [11:56:13.0562] well, how could it be reframed to reduce that? [11:59:02.0011] I'm just worried about Istvan showing up and saying something like, "well I told them it wasn't necessary, so the matter is settled already" [11:59:27.0716] Istvan is excluded from most of these discussions; this is why he was expressing so much confusion in his update to committee [11:59:36.0196] ok [12:00:56.0163] one way to make it less ignorable could be to add that delegates are reluctant to go back to giving up their participation in the meeting just for taking notes; that ups the urgency a bit. but like I said, you know the audience better than I do, what I said might backfire [12:02:42.0099] Well, this could go either way, but I think explaining the threat of a note-taker strike would be better in the subsequent discussion. [12:03:41.0119] I also think Michael would respond negatively to any characterization of all note-takers saying one thing or another, since he takes notes sometimes, as he said in that discussion [13:25:08.0790] I used to take notes for most meetings, but I haven't done any note taking in the last year or so (probably longer) because it was taking away from my ability to participate [13:26:23.0709] of course, that just shifted that burden on to other delegate volunteers, so I would prefer a stenographer [13:28:15.0786] suspect that was re: the other michael [13:28:24.0333] woops [13:28:52.0176] I was like "please, characterise me!" [13:29:36.0901] also: reminder that there's TWO DAYS LEFT to get stuff on the agenda for this coming meeting [13:31:18.0605] it currently has approximately zero things [13:35:13.0510] a Temporal item is upcoming, as usual [15:21:07.0676] littledan: Were there any delegates that did NOT provide strong support? it seemed pretty unanimous to me [15:21:29.0056] oh ok later you said unanimous, it's just the "In plenary" part that was "many"? [16:43:23.0994] Not everyone who attended plenary voted in the end [16:43:32.0133] And there were two weak support votes [16:44:17.0108] Haha yes I was talking about msaboff [16:44:38.0772] Anyway, noted, I will characterize you in discussion if it comes up