2023-05-02
[09:24:08.0967] <Mathieu Hofman>
> <@littledan:matrix.org> We definitely could have done accessors for fields. It would have certain advantages and disadvantages. I am also very confident that, if we did that, people would have said “this has lots of footguns, look this basic code doesn’t work as expected”

enumerability of accessors is likely one of those footguns on the other side.

[09:24:23.0265] <Mathieu Hofman>
> <@littledan:matrix.org> We definitely could have done accessors for fields. It would have certain advantages and disadvantages. I am also very confident that, if we did that, people would have said “this has lots of footguns, look this basic code doesn’t work as expected”

 * non-enumerability of accessors is likely one of those footguns on the other side.


2023-05-03
[05:22:11.0137] <nicolo-ribaudo>
Could I get push access to https://github.com/tc39/proposal-json-modules, to "rebase" it on top of the updated import attributes proposal?

[10:05:16.0190] <bakkot>
PSA: deadline for advancement eligibility is in slightly less than two days

[10:05:33.0890] <bakkot>
for the May meeting

[10:05:34.0789] <bakkot>
(also the link to the countdown timer in the agenda is broken)

[10:15:26.0101] <Michael Ficarra>
fixed the link

[12:39:47.0128] <bakkot>
who owns `tc39.es`? did someone mess with the DNS settings recently? looks like the subdomain we were using for PR previews is gone

[12:42:17.0460] <shu>
Registrant	Ecma International


[12:42:21.0385] <shu>
fascinating

[12:42:40.0523] <bakkot>
/facepalm

[12:43:02.0021] <bakkot>
we could and maybe should switch to just using github pages, I guess

[12:43:44.0620] <shu>
also interesting that `.es` has no whois server

[12:43:46.0706] <bakkot>
(which would solve the problem by not being a subdomain, to be clear)

[12:58:10.0517] <nicolo-ribaudo>
The DNS has been recently transferred to Ecma, there is some discussion in #tc39-website:matrix.org

[13:00:24.0200] <shu>
Ecma does not have a good track record of having working technical infrastructure

[13:00:30.0915] <shu>
why... was that done

[13:05:52.0161] <Rob Palmer>
The DNS was metered.  Aki's bill rose dramatically following a DDoS attack.  We asked Ecma to switch to unmetered DNS.

[13:06:09.0830] <Rob Palmer>
s/bill/cheque for US folk

[13:06:56.0659] <bakkot>
I was not aware that it was possible for DNS to be metered

[13:07:01.0350] <Rob Palmer>
 * s/bill/check for US folk

[13:07:16.0357] <Rob Palmer>
AWS have more ways of making money than you may imagine.

[13:09:23.0366] <shu>
wow

[13:09:36.0990] <shu>
i'm learning a lot, all of it unpleasant

[13:18:06.0387] <Aki>
Lol my bill went from 1¢/month to… I haven’t checked in a minute. It was like $40 last I checked but on its way to $100 if traffic continued.

[13:35:20.0149] <bakkot>
$100 of dns queries is a distressing amount of dns queries

[15:26:06.0080] <Chris de Almeida (OoO until 05-14)>
bakkot: probably my fault. I must've missef a non-AWS A record. just let me know and I can add it

[15:26:16.0647] <Chris de Almeida (OoO until 05-14)>
* bakkot: probably my fault. I must've missed a non-AWS A record. just let me know and I can add it

[15:26:28.0976] <Chris de Almeida (OoO until 05-14)>
* bakkot:  probably my fault. I must've missed a non-AWS A record. just let me know and I can add it

[16:03:48.0054] <ljharb>
> <@softwarechris:matrix.org> bakkot:  probably my fault. I must've missed a non-AWS A record. just let me know and I can add it

it's the `ci.tc39.es` record, if you still can find the original ones

[16:04:50.0868] <ljharb>
> <@nicolo-ribaudo:matrix.org> Could I get push access to https://github.com/tc39/proposal-json-modules, to "rebase" it on top of the updated import attributes proposal?

done

[16:32:14.0111] <Chris de Almeida (OoO until 05-14)>
good to go


2023-05-04
[05:41:50.0218] <dminor>
Rob Palmer: Hi! A colleague from a different team at Mozilla just asked me about attending the upcoming plenary as an observer. Is there any process that needs to be followed for that, or can they just show up?

[05:42:54.0733] <ryzokuken>
I think just notifying on the reflector thread should suffice

[06:47:08.0279] <Rob Palmer>
The July plenary meeting is coming up and it scheduled to be in Bergen, Norway!

- https://github.com/tc39/Reflector/issues/471

Please fill out [the interest survey](https://github.com/tc39/Reflector/issues/471) by Wednesday so that we can predict attendance numbers and make a call on whether it will be hybrid or remote-only.

[07:22:24.0602] <littledan>
Do we have an issue tracking the details of the June plenary? I was having trouble finding one.

[08:01:25.0808] <Rob Palmer>
We have [the May plenary](https://github.com/tc39/Reflector/issues/470) next.

[15:39:48.0012] <shu>
is there some canonical example somewhere of "promise ticks are observable"?

[15:41:07.0232] <bakkot>
shu: 
```
(async () => {
  for (let i = 0; i < 100; ++i) {
    console.log(i);
    await 0;
  }
})();
// other stuff here
```

[15:41:25.0948] <bakkot>
order in which the `console.log`s fire relative to other effects in other stuff is observable

[15:41:36.0588] <bakkot>
that said engines are wildly inconsistent in a lot of cases so like

[15:41:40.0306] <bakkot>
don't worry too much about it

[15:41:45.0708] <bakkot>
users certainly shouldn't

[15:48:10.0489] <shu>
thanks


2023-05-05
[21:11:16.0451] <Mathieu Hofman>
I certainly hope the number of ticks is not something programs are not sensitive to since we have the faster promise adoption proposal that would likely change that.

[23:58:07.0973] <justingrant>
Are there normally automated Chinese-language spambots commenting in the tc39/proposals repo? I just posted an [issue](https://github.com/tc39/proposals/issues/470) there and got two Chinese-language responses within 4 minutes. General question: what's the normal process for dealing with spam comments in TC39 repos?

[23:59:40.0705] <justingrant>
 * Are there normally spambots commenting in the tc39/proposals repo? I just posted an [issue](https://github.com/tc39/proposals/issues/470) there and got two Chinese-language responses within 4 minutes. General question: what's the normal process for dealing with spam comments in TC39 repos?

[00:21:14.0774] <littledan>
What I have assumed in the past is that everyone with the appropriate permissions can simply delete spam comments without needing special permission (unlike bad behavior, best referred to the code of conduct committee). If they are persistent, you can escalate to the CoC committee or any chair to get a ban out in place.

[08:12:56.0041] <ljharb>
let’s not delete things since that leaves no record; certainly hide them as spam tho

[15:19:30.0652] <jschoi>
I’m a delegate of Indiana University but I’ll be leaving in June. I’m co-champion on several proposals, I’m interested in continuing to participate in TC39 afterwards – e.g., as an invited expert. What should I do to start that process?

[15:19:40.0806] <jschoi>
 * I’m a delegate of Indiana University but I’ll be leaving in June. I’m co-champion on several proposals, and I’m interested in continuing to participate in TC39 afterwards – e.g., as an invited expert. What should I do to start that process?

[15:30:09.0987] <ljharb>
jschoi: the https://github.com/tc39/Admin-and-Business/blob/main/.github/ISSUE_TEMPLATE/delegate-to-invited-expert.md issue template points to https://www.ecma-international.org/invited-expert-form/ for you to fill out - so i think if you fill that out and file an issue that'd kickstart the process?

[15:32:14.0963] <Michael Ficarra>
jschoi: I've been trying to reach you regarding `Array.fromAsync`

[15:32:27.0201] <Michael Ficarra>
I've added a topic to the upcoming plenary's agenda about it

[15:32:28.0384] <Michael Ficarra>
see https://docs.google.com/presentation/d/1mww3D5CO1uebUYiK7l8O5GLjUR98NJYgeHGxQEgnrNA/edit#slide=id.g23957a99532_0_0


2023-05-06
[17:22:57.0470] <jschoi>
> <@michaelficarra:matrix.org> jschoi: I've been trying to reach you regarding `Array.fromAsync`

My apologies for being lost to contact; I’ve been swamped with internal work over the past months. I will read this issue tomorrow and reply to you there.

[20:06:10.0023] <jschoi>
> <@michaelficarra:matrix.org> jschoi: I've been trying to reach you regarding `Array.fromAsync`

 * My apologies for being lost to contact; I’ve been swamped with internal work over the past months. I will read this issue tomorrow and reply to you privately.


2023-05-07
[12:28:55.0591] <Rob Palmer>
Hey all, a reminder that the Interest Survey for the July plenary in Norway is now up.

It takes 30 seconds to add yourself. Even if you plan to dial in, that information is useful.

Thank you to the 14 people who have already provided their intentions.

https://github.com/tc39/Reflector/issues/471


2023-05-08
[18:59:43.0488] <snek>
anyone gonna be at gamescom?

[11:20:02.0363] <littledan>
Orama is allowed to attend the TC39 plenary next week, right?

[13:21:11.0130] <Michael Ficarra>
littledan: (RE `Array.prototype.group`) I think the answer to "how do we choose web-compatible `Array.prototype` method names?" is obvious but we just don't want to accept it: stop trying to choose good names

[13:22:11.0055] <littledan>
Michael Ficarra: There's something in common with the `group` name as the previous `global` name: people searched for the name and found too many results, so it was too much to look through, and they sort of assumed it was compatible (but without reporting all of that logic to the committee in advance). In the future, if a search yields that sort of result, I think the next step is to choose something else.

[13:22:14.0358] <littledan>
so, I agree

[13:22:16.0769] <Michael Ficarra>
bad/verbose names are much less risky, but we *want* the name to be good, so we take the risks anyway

[13:23:23.0362] <littledan>
I think for Array methods in particular, we should just use things that we can demonstrate to be pretty unique

[13:23:34.0761] <littledan>
Array methods have been found to be uniquely risky unlike anything else

[13:23:43.0514] <Michael Ficarra>
yes, we need an especially high bar for Array prototype method names

[13:24:08.0180] <Michael Ficarra>
evidence of compatibility, not just lack of evidence of incompatibility

[13:24:50.0777] <littledan>
well, I'd like that if someone could provide it, but I'm not sure what such evidence would look like

[13:25:03.0673] <littledan>
what advice would you give to a new delegate who wants to take on the Array grouping project?

[13:25:47.0391] <Michael Ficarra>
a *new* delegate? "don't"

[13:26:09.0840] <littledan>
OK, then, an experienced delegate--what would you tell them to do?

[13:26:14.0839] <Michael Ficarra>
"hi I'm new here, let me try to solve this override mistake for y'all"

[13:27:01.0787] <Michael Ficarra>
if code search can show a name is effectively nonexistent on the web, that would be good evidence

[13:27:20.0568] <Michael Ficarra>
that would probably necessitate a pretty terrible name choice though

[13:27:51.0263] <littledan>
previously people tried GitHub code search and found results which initially appeared to be stronger support than what was ultimately shown

[13:28:12.0802] <littledan>
Let's try to give actionable advice to champions here (or declare bankruptcy on Array methods and just not do them)

[13:28:36.0645] <Michael Ficarra>
if they wanted to straddle the middle, they would have to do something like collect/analyse usage info in a large-ish browser

[13:29:08.0332] <Michael Ficarra>
yeah, GitHub code search should not be considered sufficient, most code is not OSS

[13:29:26.0279] <littledan>
people always say "analyze usage in a browser" but that doesn't really seem to be available in practice

[13:29:44.0031] <littledan>
I dunno if it ended up playing a role in `global` with some kind of work with Edge, but I haven't heard of it being used since

[13:30:07.0982] <littledan>
this is more awkward than adding other kinds of telemetry/usecounters since it's a property that doesn't exist

[13:32:21.0087] <Michael Ficarra>
may be awkward, but I don't see why it couldn't be done (by someone with the authority to ship in said browsers)

[13:32:53.0314] <littledan>
I just don't know how to do it (and I've contributed code which shipped in browsers after stopping working directly for one)

[13:33:11.0072] <littledan>
maybe you see a way to do it that I don't?

[13:34:43.0425] <littledan>
like, it'd be too slow to replace Array.prototype with a Proxy or something

[13:36:17.0025] <Michael Ficarra>
I was thinking a magic property like `document.all` which appeared not there but reported a use counter when assigned/defined

[13:36:23.0023] <Michael Ficarra>
I'm not talking about an existing facility here

[13:37:03.0141] <Michael Ficarra>
`Array.prototype.length` is already magical

[13:37:33.0435] <littledan>
I think property access on `Array.prototype` has to be faster than property access on `document`. And the magic of `length` is baked into a lot of places and difficult to replicate.

[13:38:17.0936] <littledan>
Anyway, if we want to call a pause on Array methods until someone puts in the work to do this very strong dynamic analysis, that's a conclusion we could come to, we should just expect this to take a long time.

[13:40:28.0718] <Michael Ficarra>
I'm personally okay with either approach: raise the bar so we can confidently ship come stage 3, or move to stage 3 with an unknown name, accepting that we may need to unship and retry with a new name an unbounded number of times before moving to stage 4

[13:40:49.0313] <Michael Ficarra>
browser implementors may have a different opinion though

[13:41:18.0906] <littledan>
yeah it'd be nice if we could find some strategy where the champion can be the one doing the work, rather than just implementers. Maybe some kind of search in HTTPArchive?

[13:49:54.0963] <shu>
> people always say "analyze usage in a browser" but that doesn't really seem to be available in practice

most definitely not scalable

[13:50:38.0149] <shu>
> may be awkward, but I don't see why it couldn't be done (by someone with the authority to ship in said browsers)

the "awkwardness" you refer to is really "unacceptably slow and cannot be shipped"

[13:50:45.0180] <shu>
it's not "impossible"

[13:50:54.0915] <shu>
well, it's in practice impossible

[13:51:01.0078] <shu>
but not impossible in the sense that like, we don't know how to code it

[13:52:00.0496] <shu>
a difference between JS engines and this kind of telemetry on other web APIs defined in WebIDL is the performance pressures are probably an order-of-magnitude different

[13:52:23.0797] <shu>
if you could get google and apple and mozilla to stop competing on performance at all then we can talk!

[13:54:59.0266] <shu>
oh and microsoft

[13:55:17.0646] <littledan>
to be clear: we want you to keep competing on performance

[13:58:18.0797] <shu>
yes sorry this is all a bit tongue in cheek. i don't think the current state of things is wrong: the optimal state of a widely used and supported language most likely should not be optimized for ease of changing

[14:38:01.0831] <TabAtkins>
> <@littledan:matrix.org> well, I'd like that if someone could provide it, but I'm not sure what such evidence would look like

Evidence of compatibility is something we get all the time for web-platform features. In Chrome, we add a Use Counter and (usually) wait until it hits the Stable channel, and see what the usage is.

[14:38:31.0881] <TabAtkins>
If it's super low, great. If not, we can dig into exactly what the usage is and see if it's innocent or not, but that does require more manual labor.

[14:39:32.0095] <shu>
what does a use counter look like for assessing compatibility of a new `Array.prototype` method?

[14:39:43.0175] <TabAtkins>
At least, I *presume* Use Counters are plumbed into the JS engine enough to be usable.

[14:39:43.0596] <shu>
i've added use counters mainly to assess the compatibility of removing things

[14:40:05.0622] <shu>
we have plenty of use counters, but they aren't free and some things are much easier to track than others

[14:40:06.0884] <littledan>
Use Counters are definitely plumbed through V8, I just don't know how to efficiently add a counter for this sort of thing

[14:40:10.0294] <TabAtkins>
Whatever c++ gets invoked for expandos, the use counter would monitor, I presume.

[14:40:29.0882] <TabAtkins>
yeah they're not free, but we still have a bajillion of them bc they're useful

[14:40:35.0098] <shu>
alas it is not C++ but like, 10 different places across C++ and generated code (handwritten assembly)

[14:40:47.0848] <shu>
i guarantee you adding a check to Array.prototype object lookups will regress speedometer

[14:40:50.0515] <shu>
and we will back it out

[14:41:14.0571] <TabAtkins>
lol, well a telemetry run on nightly might be enough

[14:41:32.0870] <TabAtkins>
at least to give initial results, which probably would have shown the .group usage was high

[14:43:36.0861] <shu>
i think our performance mental models significantly differ

[14:43:41.0049] <shu>
mainly because you said expandos

[14:47:36.0849] <TabAtkins>
lol

[14:49:30.0198] <TabAtkins>
An attempt to get a given property name from the Array.prototype object.


2023-05-09
[15:18:26.0636] <rbuckton>
> <@shuyuguo:matrix.org> i guarantee you adding a check to Array.prototype object lookups will regress speedometer

Is this done by analyzing the creation of, or transition to, a new map that has an JS_ARRAY_TYPE type, or are you talking about patching actual assignments (i.e., to catch code that may not have moved to the optimizing compiler)?

[15:22:44.0497] <shu>
well, i elided a few thoughts

[15:23:29.0218] <shu>
i don't think it's sufficient to just check if e.g. someone added a new property named `group` to `Array.prototype`, because we know unconditional assignment is unproblematic

[15:24:15.0807] <shu>
so to add a more nuanced check that's a better measure of whether there's a problematic assignment to a particular `Array.prototype` name:

1. i don't know how to write that use counter
2. it's probably spread through enough parts of the code that adding that many branches is slow?

[15:25:25.0388] <shu>
we _could_ probably add a check just to see if someone added a new property named `group` to Array.prototype but i'd need to audit for all the places where we do that

[15:32:10.0529] <bakkot>
the actual problem with `group` was triggered by someone relying on the _absence_ of a property named `group` on array objects, IIRC

[15:32:26.0040] <bakkot>
so you'd need a use counter for lookup, not just assignment

[15:32:30.0766] <shu>
right, that's what i obliquely referred to as "lookup"

[15:32:58.0189] <shu>
i can imagine a use counter "through time" like, if i looked up 'group' then assigned to 'group', then maybe we bump the counter

[15:33:05.0959] <shu>
but there is just no way i can add a branch to every lookup

[15:34:04.0412] <rbuckton>
> <@bakkot:matrix.org> the actual problem with `group` was triggered by someone relying on the _absence_ of a property named `group` on array objects, IIRC

But did they then still assign to it, or just test for its presence and that's it?

[15:34:11.0032] <bakkot>
just test for presence

[15:34:22.0102] <shu>
oh they didn't even assign to it?

[15:34:22.0758] <bakkot>
they were using it as a type discriminant

[15:34:37.0739] <shu>
word

[15:34:39.0824] <shu>
ain't nothing i can do 

[15:36:08.0178] <bakkot>
https://github.com/webcompat/web-bugs/issues/112552#issuecomment-1291374679

[15:36:12.0372] <bakkot>
specifically that case ^

[15:36:13.0742] <bakkot>
there were others

[15:36:38.0198] <bakkot>
that is, there were other cases which were doing other more normal things, which a use counter might have been able to detect

[15:36:50.0081] <bakkot>
but this specific one was doing the type discriminant thing

[15:38:37.0805] <shu>
do you wonder what life would be like if you worked on a language that had just a little bit less baggage

[15:38:42.0086] <shu>
not a lot, maybe just like 10% less

[15:39:38.0227] <rbuckton>
> <@shuyuguo:matrix.org> do you wonder what life would be like if you worked on a language that had just a little bit less baggage

Like, one where the version can change but it doesn't break your code because your code is compiled and linked to a version-specific standard library?

[15:42:38.0491] <shu>
like chris lattner has it figured out man

[15:42:43.0341] <bakkot>
occasionally I stare forlornly across the bay in the direction of rust

[15:42:45.0474] <shu>
make a language, go somewhere else, make another language

[15:44:55.0628] <Andreu Botella>
> <@bakkot:matrix.org> https://github.com/webcompat/web-bugs/issues/112552#issuecomment-1291374679

Wait, so the issue is the method must exist, but old code is relying on it being falsy. This kinda rings a bell. Haven't we solved this problem once before...?

[15:46:06.0326] <bakkot>
whenever I suggest `document.all` as the solution to all our problems people start screaming in horror and also ominous chanting starts up and blood starts leaking from the walls

[15:46:10.0244] <bakkot>
so I've stopped suggesting it

[15:46:48.0519] <Andreu Botella>
The chanting and blood leaks are a bug in our piping infrastructure, there's an issue open years ago

[15:47:03.0545] <shu>
we can simply extend the MOP to include `emulates: val`

[16:25:39.0560] <Rob Palmer>
Hey all, a reminder that the Interest Survey for the July plenary in Norway will close in 24 hours time.

It takes 30 seconds to add yourself. Even if you plan to dial in, that information is useful.

Thank you to the 25 people who have already provided their intentions.

https://github.com/tc39/Reflector/issues/471


2023-05-11
[06:41:23.0621] <Rob Palmer>
The Chairs have decided the July 2023 TC39 plenary will happen in Bergen 🎉

Thank you to the 32 people who filled in the survey.  Full details are on [the Reflector post.](https://github.com/tc39/Reflector/issues/473)


2023-05-13
[09:36:43.0084] <ryzokuken.be>
Draft schedule on reflector now

[09:37:07.0066] <ryzokuken.be>
Thanks Luca Casonato and nicolo-ribaudo


2023-05-15
[01:46:46.0434] <eemeli>
What's the "TKTKTK intro" that's occupying the first hour of the schedule? Searching online suggests mainly ASMR videos, which would be a bit weird.

[01:56:13.0646] <nicolo-ribaudo>
It was a placeholder for the various initial reports; I helped ryzokuken preparing the schedule and forgot to replace it 😅

[01:56:42.0916] <nicolo-ribaudo>
* It was a placeholder for the various initial reports (secretary, editors, etc); I helped ryzokuken preparing the schedule and forgot to replace it 😅

[03:05:25.0630] <littledan>
TC39 starts in around 5 hours, right?

[03:05:39.0501] <littledan>
(Am I calculating correctly?)

[03:09:45.0773] <nicolo-ribaudo>
Yep, according to the TC39 calendar 

[04:29:35.0460] <ryzokuken>
oops, sorry, I'll do that now

[04:29:49.0329] <ryzokuken>
but it's supposed to be the opening of the meeting

[05:43:21.0760] <littledan>
Does that 60 minute topic include Samina’s introduction?

[05:43:29.0723] <ryzokuken>
Yeah

[05:43:56.0643] <pzuraq>
I've had a meeting come up so won't be able to make the first hour or so

[05:44:20.0224] <pzuraq>
don't expect to be presenting then but just in case

[05:45:02.0487] <littledan>
ryzokuken: how do you expect the time to divide up within that segment?

[05:48:31.0748] <ryzokuken>
just updated the hackmd

[05:48:37.0471] <ryzokuken>
apologies again for doing this last minute

[05:50:12.0695] <littledan>
Np thanks 

[08:17:52.0377] <eemeli>
I'm getting an error "Couldn't connect you to the video call" when following the Google Meet sign-in link. Is this just me?

[08:18:30.0905] <Lea Verou>
there are 33 people in the meeting right now

[08:18:31.0381] <Michael Ficarra>
yes, we have 33 people in here

[08:19:04.0637] <nicolo-ribaudo>
Are the slides frozen to the first one? (not that I'm missing much, but...)

[08:20:06.0357] <eemeli>
Got in by trying again. Dunno what was wrong.

[08:22:38.0784] <ljharb>
the first time i connected i heard no audio, i had to drop out and reconnect, definitely something a bit weird

[08:27:43.0720] <littledan>
s/master/authoritative/; s/slave/derived/

[08:27:58.0735] <littledan>
(this also explains it more clearly!)

[08:30:14.0983] <shu>
"we need a solution for pdf generation in 2024" needs to further define "we"

[08:30:17.0568] <ljharb>
i assume we all realize that the graph dropped there because we started hosting it on github then, not because of the pdf

[08:30:35.0819] <shu>
"we" means Ecma, not any TC39 volunteers

[08:30:44.0782] <bakkot>
print-to-pdf is a solution for pdf generation

[08:30:49.0253] <shu>
correct

[08:31:02.0534] <ljharb>
as is ecma providing the budget we've asked for for years for professional typesetters

[08:32:35.0421] <bakkot>
I am happy to believe that this PDF is downloaded more than any other PDF ecma provides but that doesn't actually make it important per se

[08:33:10.0352] <ljharb>
also an earlier slide implied that PDF quality impacts downloads, and that 402's PDF is better, but 402's PDF is a tiny fraction of 262's PDF.

[08:33:17.0436] <eemeli>
It sounds like it may be important to ECMA, but not to TC-39.

[08:33:18.0874] <ljharb>
 * also an earlier slide implied that PDF quality impacts downloads, and that 402's PDF is better, but 402's PDF downloads is a tiny fraction of 262's PDF.

[08:33:24.0082] <Michael Ficarra>
surely, if the PDF was not available, people would use the HTML version instead, right?

[08:33:32.0150] <shu>
eemeli: yes, that's a statement of fact

[08:34:49.0565] <Andreu Botella>
I'm curious which things are missing from print layout in CSS/browsers to be good enough for ECMA

[08:34:59.0072] <bakkot>
glad to hear the json spec is approved for the next 5 years

[08:35:09.0511] <ryzokuken>
> <@ljharb:matrix.org> also an earlier slide implied that PDF quality impacts downloads, and that 402's PDF is better, but 402's PDF downloads is a tiny fraction of 262's PDF.

I'm not sure if I'd say that the PDF quality is "better" since what we do is basically print-to-pdf with some tiny CSS tweaks

[08:35:26.0619] <Lea Verou>
it's not just about browsers, there are print formatters that are developed especially for printing (PrinceXML, Antennahouse etc). There are entire books typeset in HTML & CSS using these

[08:35:50.0063] <ljharb>
> <@usharma:igalia.com> I'm not sure if I'd say that the PDF quality is "better" since what we do is basically print-to-pdf with some tiny CSS tweaks

yeah i'm sure it's just that 262 has some content that makes it worse than 402, i was just pointing out the problem with istvan's argument

[08:36:30.0529] <ljharb>
> <@usharma:igalia.com> I'm not sure if I'd say that the PDF quality is "better" since what we do is basically print-to-pdf with some tiny CSS tweaks

 * yeah i'm sure it's just that 262 has some specific content that makes it print worse than 402, i was just pointing out the problem with istvan's argument

[08:36:41.0829] <littledan>
honestly it would be good to have a summary of topics like Istvan's, to understand what the main points are (I think this is usually not clear to the committee)

[08:38:20.0672] <ljharb>
also this kind of seems like it should be its own agenda item, not part of the secretariat's report

[08:38:51.0640] <littledan>
What do you mean, Samina's introduction?

[08:39:10.0558] <littledan>
She did put it on the agenda, and you can blame me if you think she did so in an incorrect way (as I walked her through that process of the agenda edit)

[08:39:45.0025] <littledan>
Do you have any particular questions or concerns for Samina?

[08:42:24.0468] <ljharb>
no no, i meant istvan's PDF concerns

[08:42:31.0826] <ljharb>
samina's topic was on the agenda and is perfectly fine

[08:42:43.0152] <ljharb>
 * no no, i meant istvan's PDF concerns that we'd been discussing in chat

[08:42:55.0338] <ljharb>
 * samina's topic was on the agenda and is perfectly fine, i met her last week and am happy to welcome her

[08:43:11.0867] <bakkot>
I don't want the pdf topic to be its own agenda item because I don't want to spend more time on it

[08:43:31.0030] <ljharb>
i agree, but it seems easier to convey that if it's separated :-)

[08:43:37.0571] <Michael Ficarra>
surprisingly 262 *does* have camel case AO names (though we are working on fixing that)

[08:43:43.0535] <bakkot>
fair

[08:43:46.0151] <littledan>
hehe yeah I think it concerns a small group of people and that group is sort of in touch by an email thread

[08:43:50.0393] <ljharb>
otherwise it'll be snuck into the secretariat's report for another year

[08:44:48.0806] <littledan>
well, Samina is onboarding here; I think we may see different communication styles here over time

[08:44:49.0360] <ljharb>
i'm confused, why were we talking about normative changes in this section

[08:44:52.0827] <littledan>
I'm pretty optimistic

[08:44:59.0982] <ljharb>
this was just a status update, not a consensus item

[08:45:37.0983] <Michael Ficarra>
normative 402 changes are always run by TG1

[08:45:42.0056] <littledan>
> <@ljharb:matrix.org> i'm confused, why were we talking about normative changes in this section

This is frequently done in ECMA-402 updates.

[08:45:51.0298] <littledan>
but it'd also be fair to ask for more explanation and discussion

[08:45:51.0302] <ljharb>
that's not my recollection, but ok

[08:46:02.0963] <ljharb>
we don't do that in 262 updates, and i definitely want more explanation than "go look at the PR"

[08:46:04.0341] <littledan>
it's true that it'd be nice to have more proactive support from the committee

[08:46:27.0341] <ljharb>
we have a separate section for "needs consensus"

[08:46:43.0875] <littledan>
> <@ljharb:matrix.org> we don't do that in 262 updates, and i definitely want more explanation than "go look at the PR"

the thing is, Ujjwal did explain the change, and also when there have been longer presentations here, they haven't gotten much engagement

[08:46:55.0206] <Michael Ficarra>
yes because TG1 members are expected to be much more familiar with 262 and 402

[08:47:10.0303] <Michael Ficarra>
 * yes because TG1 members are expected to be much more familiar with 262 than 402

[08:48:13.0975] <littledan>
can the code of conduct committee update their membership list?

[08:48:18.0070] <littledan>
(sorry I haven't gotten the queue up yet)

[08:48:22.0389] <ljharb>
it should be up to date

[08:48:40.0669] <littledan>
in what sense? it contains multiple people who are not delegates

[08:49:08.0238] <littledan>
if you have an idea of which 4 people are somewhat active, then shouldn't the list reflect that?

[08:49:26.0409] <ljharb>
everyone on the list is a delegate as far as i'm aware.

[08:49:37.0453] <ljharb>
and we haven't previously evicted people for not attending meetings

[08:51:09.0023] <ljharb>
regarding engagement, it's not that they need to be longer, it's that the agenda didn't include the item, nor any supporting materials, 10 days prior to the meeting, so how could anyone have reviewed it

[08:51:23.0167] <ljharb>
there's lots of reasons normative changes have their own section, and need their own item.

[08:52:06.0506] <ljharb>
 * regarding engagement, it's not that they need to be longer, it's that the agenda didn't include the item, nor any supporting materials, 10 days prior to the meeting, so how could anyone have reviewed it or known they needed to

[08:52:24.0671] <ljharb>
 * regarding engagement on 402 items, it's not that they need to be longer, it's that the agenda didn't include the item, nor any supporting materials, 10 days prior to the meeting, so how could anyone have reviewed it or known they needed to

[08:59:15.0933] <ryzokuken>
ljharb: I understand your concerns but at the same time this is how we've dealt with normative Intl stuff so far

[08:59:43.0066] <ljharb>
i guess i've missed it. but either way the specific items *must* be referenced on the agenda, 10 days in advance, per our policy

[08:59:51.0086] <ljharb>
 * i guess i've missed it. but either way the specific items _must_ be referenced on the agenda, 10 days in advance, per our current policy

[09:00:05.0386] <ryzokuken>
but I'm not against presenting every normative change as a separate item if that's useful

[09:00:36.0303] <ljharb>
i don't personally care if it's one "402 normative changes" item, or separate items, or whatever, i just care that it's called out with supporting materials on the agenda

[09:00:45.0667] <ljharb>
 * i don't personally care if it's one "402 normative changes" item, or separate items, or whatever, i just care that it's called out with supporting materials on the agenda, like every other normative change we approve

[09:00:47.0063] <littledan>
Yes, I agree that normative changes should be posted in advance like that, and for this topic it'd be reasonable to ask for an overflow item if you want to go into more detail

[09:01:00.0207] <ljharb>
 * i don't personally care if it's one "402 normative changes" item, or separate items, or whatever, i just care that it's called out with supporting materials on the agenda, like every other normative change we approve (and it's confusing to me to do it under "status report")

[09:01:11.0497] <ljharb>
i don't, on this specific item, i'm speaking in general

[09:01:15.0665] <ljharb>
 * i don't, on this specific item, i'm speaking about in general

[09:01:34.0177] <ljharb>
 * i don't personally care if it's one "402 normative changes" item, or separate items, or whatever, i just care that it's called out with supporting materials on the agenda, like every other normative change we approve (and it's confusing to me to do it under "status updates")

[09:02:03.0045] <littledan>
omg I don't remember this issue at all

[09:02:13.0194] <littledan>
I mean I don't remember posting it

[09:04:36.0010] <HE Shi-Jun>
It seems the issue mentioned wasm might allow 2**53 bigger Arraybuffer?

[09:06:04.0651] <shu>
like we're not going to have computers in the medium term future with that kind of memory i don't think?

[09:06:48.0711] <bakkot>
yeah but virtual memory

[09:07:05.0711] <littledan>
In general, don't we want to write the summaries collectively?

[09:07:08.0622] <bakkot>
as long as you don't actually try to _use_ all the pages you can still pretend

[09:07:10.0000] <littledan>
like, synchronously in the meeting

[09:07:16.0020] <littledan>
rather than just telling the presenter to write something

[09:07:20.0271] <shu>
ehhh maybe virtual

[09:07:21.0631] <littledan>
that way we can be sure we actually agree on it

[09:08:14.0418] <ryzokuken>
> <@littledan:matrix.org> that way we can be sure we actually agree on it

we can do that, but it could get somewhat time consuming

[09:08:53.0066] <ryzokuken>
but we're not so pressed for time this time around so it shouldn't be a problem I suppose

[09:08:55.0898] <Chris de Almeida>
yes, I think we previously at least paused for a moment till the conclusion was in reasonable shape

[09:09:25.0195] <ryzokuken>
alright then I'd pause a bit for the next items

[09:10:36.0005] <Chris de Almeida>
also allows the person writing the conclusion to participate in the next topic, rather than focused on the conclusion and missing the presentation

[09:11:12.0728] <littledan>
> <@usharma:igalia.com> we can do that, but it could get somewhat time consuming

well, concretely, pausing synchronously is what I had proposed to the committee. In the past, when we *didn't* pause, we just didn't get summaries.

[09:14:59.0960] <Justin Ridgewell>
IMHO, this feels like we're waisting time.

[09:15:38.0842] <Willian Martins>
That is useful to help us report back on our internal meetings.

[09:16:00.0649] <ryzokuken>
I'm with the general idea of summarizing items, but pausing for a long duration feels like a bit much

[09:17:09.0821] <Justin Ridgewell>
What is the point of blocking all other items while we committee a summary?

[09:19:00.0306] <Michael Ficarra>
I prefer doing this async as well

[09:19:03.0565] <littledan>
we can do it more quickly if the presenters are a little more active about it. They can just dictate a quick summary and conclusion at the end of their topic

[09:19:24.0141] <bakkot>
yeah that's my preferred option

[09:19:30.0395] <bakkot>
we did that last meeting IIRC and it was efficient

[09:19:33.0106] <ryzokuken>
I think doing it sync especially for these smaller items is not the best idea

[09:19:41.0770] <ryzokuken>
for instance the last item was 4 minutes by itself

[09:19:50.0343] <ryzokuken>
and we spent over 5 minutes coming up with the summary

[09:19:56.0908] <littledan>
last meeting I wrote many of the summaries. I want to get out of that pattern.

[09:20:15.0891] <littledan>
the champion should just dictate a really quick summary and conclusion at the end of their topic. It should take less than one minute

[09:20:24.0216] <littledan>
If the champion is not able to dictate it, then someone else can write it

[09:20:41.0260] <ryzokuken>
> <@littledan:matrix.org> last meeting I wrote many of the summaries. I want to get out of that pattern.

that's fair, we shouldn't be burdening someone with them, but I think the presenter should just be able to summarize 

[09:20:53.0320] <littledan>
I can keep writing the summaries but I really don't trust that anyone is reviewing them and that concerns me. It risks making the notes biased.

[09:21:04.0933] <littledan>
 * I can keep writing the summaries but I don't know if anyone is reviewing them and that concerns me. It risks making the notes biased.

[09:22:22.0485] <littledan>
heh, I wanted the main discussion points to be just part of the conclusion section but others disagreed hence we have two separate parts

[09:22:42.0279] <Michael Ficarra>
omg I just realised my camera was off that whole time lol, sorry

[09:22:43.0675] <ryzokuken>
littledan: how did you feel about that last one

[09:22:49.0690] <ryzokuken>
where someone just presented the summary

[09:23:00.0436] <ryzokuken>
and we can spend a few seconds to see if anyone wants to add to it

[09:23:00.0929] <littledan>
yeah that was good. There was nothing to write in the summary; we just had a conclusion.

[09:23:19.0667] <littledan>
In the future, I think a Stage 4 summary could list how the proposal meets Stage 4 requirements (e.g., where it's shipping, the fact that there are tests)

[09:23:20.0983] <ryzokuken>
> <@littledan:matrix.org> yeah that was good. There was nothing to write in the summary; we just had a conclusion.

that's true, maybe not a great example

[09:23:24.0347] <littledan>
but that's optional

[09:23:31.0237] <Michael Ficarra>
summary: proposal meets all stage 4 criteria

[09:23:41.0248] <littledan>
anyway Kevin quickly dictating a conclusion is a good case

[09:23:55.0396] <littledan>
> <@michaelficarra:matrix.org> summary: proposal meets all stage 4 criteria

this is quite a bad summary since it leaves out the content; it might as well be omitted

[09:24:16.0080] <Michael Ficarra>
that's what the content was meant to provide evidence for

[09:24:30.0581] <Michael Ficarra>
summary: just take my word for it

[09:25:19.0049] <Michael Ficarra>
I'm looking forward to chatting with Samina about it in Bergen

[09:25:59.0555] <nicolo-ribaudo>
For discussion these short "summary" and "conclusion" are basically the same thing

[09:26:16.0892] <shu>
supporting evidence should be out-of-line

[09:26:23.0671] <shu>
notes aren't adversarial!

[09:26:25.0904] <littledan>
OK yes this is fine

[09:26:36.0829] <shu>
i don't think someone is going to pull a fast one and then accidentally get something to stage 3+

[09:26:44.0297] <littledan>
we're just working on making the notes meaningful

[09:26:50.0430] <littledan>
no one is adversarial about this

[09:27:10.0090] <littledan>
it's fine to just have a conclusion and no summary for this kind of topic

[09:27:19.0295] <littledan>
summaries are more important when we have a big debate and people make important points, IMO

[09:32:42.0838] <Chris de Almeida>
it's contextual -- sometimes the points make sense, sometimes it would be overkill.  we'll get into a better rhythm with it, but just quickly getting it done when it's timely (at the end of the presentation) is the quickest and cleanest way to do it

[09:39:03.0516] <Michael Ficarra>
`toBase64String`/`toHexString`?

[09:39:09.0890] <Michael Ficarra>
seems like a stage 2 t hing

[09:39:17.0938] <Michael Ficarra>
 * seems like a stage 2 thing

[09:40:13.0871] <Justin Ridgewell>
Yah, definitely not blocking. I just like node's API

[09:41:24.0867] <ljharb>
to clarify, the streaming api is included in this in stage 2?

[09:41:47.0623] <Michael Ficarra>
ljharb: yep

[09:41:48.0749] <ljharb>
 * to confirm, the streaming api is included in this in stage 2?

[09:42:25.0537] <rbuckton>
The property names `more` and `extra` are a bit opaque, but I imagine anyone using the streaming API is going to likely need to refer to documentation anyways

[09:42:46.0585] <shu>
✨extra✨

[09:42:56.0891] <Michael Ficarra>
rbuckton: now that it's stage 2, it's the perfect time to suggest alternative names

[09:43:38.0855] <rbuckton>
> <@michaelficarra:matrix.org> rbuckton: now that it's stage 2, it's the perfect time to suggest alternative names

Agreed. I definitely support this for Stage 2

[09:46:04.0058] <bakkot>
chairs: advance the queue?

[09:46:11.0292] <bakkot>
oh wait that's done nvm

[09:47:46.0398] <HE Shi-Jun>
rbuckton: yeah, when we discussed base64 api in JSCIG meeting, it's hard for us to figure out the streaming api without check the full example in the proposal site

[09:48:11.0422] <Michael Ficarra>
I find Kevin's argument about it being better for developers if this is loud convincing

[09:49:36.0893] <Michael Ficarra>
(I didn't previously form an opinion about which semantics was better, just that the name needs to match)

[09:49:41.0730] <rbuckton>
The downside of throwing is that something simple like `array.filter(Symbol.isWellKnown)` may now require an arrow to do a typeof test to avoid throwing.

[09:50:19.0322] <HE Shi-Jun>
Is there any `isXXX` api in JS throws?

[09:50:24.0117] <HE Shi-Jun>
I don't remember any

[09:50:53.0453] <littledan>
BTW the summary for Shu's proposal is excellent

[09:50:56.0432] <rbuckton>
By throwing, we're mandating forced overhead 

[09:51:51.0350] <bakkot>
> <@rbuckton:matrix.org> The property names `more` and `extra` are a bit opaque, but I imagine anyone using the streaming API is going to likely need to refer to documentation anyways

yeah I don't love the names, and would be happy to take new ones

[09:52:30.0972] <bakkot>
TextDecoder has `stream` which must be `false` for the last call, which confuses people a great deal, and I was trying to pick a name which avoids that problem (hence `more`)

[09:52:44.0016] <ljharb>
jschoi: it is a predicate and definitely would start with "is"

[09:53:19.0154] <Michael Ficarra>
`streamMore`

[09:53:30.0248] <bakkot>
ugh

[09:54:10.0692] <bakkot>
I could imagine `last` instead of `more`? and you set `last: true` on the last call?

[09:54:42.0251] <rbuckton>
> <@bakkot:matrix.org> TextDecoder has `stream` which must be `false` for the last call, which confuses people a great deal, and I was trying to pick a name which avoids that problem (hence `more`)

I'm having a hard time conceptualizing what `more` actually does, from just  reading the spec. It seems like it means "if `true`, also return any unencoded bytes as a new array". would that be a correct interpretation?

[09:55:19.0961] <bakkot>
the exact opposite: if `false` return any unencoded bytes as a new array; if `true` then encode all bytes including any padding if necessary

[09:55:37.0436] <bakkot>
i.e., it indicates whether more input is expected

[09:55:44.0031] <Michael Ficarra>
`crossRealmObj[Symbol.iterator]()` needs to use a well-known symbol

[09:55:44.0779] <bakkot>
wait

[09:55:50.0657] <bakkot>
 * the exact opposite: if `true` return any unencoded bytes as a new array; if `false` then encode all bytes including any padding if necessary

[09:55:55.0526] <bakkot>
yes the thing you said

[09:56:01.0015] <bakkot>
I was thinking of the inverted one I just described

[09:56:06.0522] <bakkot>
 * ~~the exact opposite: if `true` return any unencoded bytes as a new array; if `false` then encode all bytes including any padding if necessary~~

[09:56:14.0700] <bakkot>
 * ~the exact opposite: if `true` return any unencoded bytes as a new array; if `false` then encode all bytes including any padding if necessary~

[09:56:22.0839] <bakkot>
 * [ugh matrix does not have strikethrough]

[09:57:32.0288] <bakkot>
the important part is, if `more` is `false` then all bytes get encoded, including any padding if necessary

[09:57:35.0725] <shu>
Michael Ficarra: so like, for iframes?

[09:57:48.0877] <ryzokuken>
> <@bakkot:matrix.org> [ugh matrix does not have strikethrough]

<del>it does?</del>

[09:57:57.0731] <bakkot>
how

[09:58:03.0576] <Michael Ficarra>
shu: yep

[09:58:08.0208] <ryzokuken>
it's cursed actually

[09:58:22.0965] <ryzokuken>
you need to surround it with `<del>` tags

[09:58:29.0800] <bakkot>
_what_

[09:58:37.0609] <rbuckton>
While I know choosing a single-word property might generally be preferrable, I think the underlying semantics are complex enough that a more descriptive name might be advisable, like `excludeOverflow` or something.

[09:58:47.0505] <Michael Ficarra>
"the following text has been struck: "

[09:58:50.0136] <ryzokuken>
ikr

[09:58:55.0491] <shu>
Michael Ficarra: do you think that rises to the level of needing a predicate in the language?

[09:59:05.0896] <ryzokuken>
`<del>this</del>`

[09:59:31.0712] <rbuckton>
I don't actually like the name `excludeOverflow`, tbh, just using it as an example.

[09:59:36.0914] <Michael Ficarra>
shu: eh, barely

[10:00:01.0730] <bakkot>
rbuckton: yeah, seems reasonable (in general, I also don't like that particular name)

[10:00:24.0038] <shu>
like, what is the thing you're writing other than polyfills that can benefit from this (and i still contend this adds major pain point to polyfills, but the counterargument there seems to be "we'll just ignore patching it when polyfilling because that's not realistic anyway)

[10:00:51.0047] <shu>
the sum of "what'll happen in practice" conclusions here leaves me mostly unhappy

[10:00:59.0423] <bakkot>
`extra` is more annoying because you need to shuttle it between calls - the value returned from one call gets passed into the next. so I wanted a name which could make sense in both positions, and that's tricky.

[10:01:18.0355] <bakkot>
 * `extra` is more annoying because you need to shuttle it between calls - the value returned from one call gets passed into the next. so I wanted a name which could make sense in both positions (so you can use destructuring and the property shorthand), and that's tricky.

[10:01:59.0103] <shu>
 * like, what is the thing you're writing other than polyfills that can benefit from this (and i still contend this adds major pain point to polyfills, but the counterargument there seems to be "we'll just ignore patching it when polyfilling because that's not realistic anyway")

[10:04:08.0943] <rbuckton>
I understand why you might not want to use `TextEncoder` directly, but is there a reason a similar API wouldn't be sufficient? Similar APIs in other languages usually have the number of bytes read or written as part of the result, leaving it up to the user to do any byte shuffling when streaming.

[10:04:37.0906] <bakkot>
a similar API would be sufficient, but much heavier - I'd really prefer to avoid adding an entirely new class to the language for this

[10:05:40.0960] <rbuckton>
I'm not saying you should add a new class. I'm just talking about the use of read/written counts for decode/encode instead, much like `TextEncoder`/`TextDecoder` do.

[10:05:56.0467] <bakkot>
Are we talking about the same `TextEncoder`?

[10:06:11.0243] <bakkot>
The one in HTML doesn't have a byte count afaik

[10:06:15.0290] <rbuckton>
Let me piece together an example

[10:06:40.0181] <rbuckton>
https://developer.mozilla.org/en-US/docs/Web/API/TextEncoder/encodeInto has `read`/`written`

[10:07:07.0201] <bakkot>
ah, I was thinking of `encode`, yeah

[10:07:58.0731] <Andreu Botella>
> <@bakkot:matrix.org> a similar API would be sufficient, but much heavier - I'd really prefer to avoid adding an entirely new class to the language for this

There's no actual state stored in `TextEncoder`, `encode` and `encodeInto` could very well be static methods

[10:08:13.0994] <bakkot>
Andreu Botella: Yeah I mean TextDecoder

[10:08:39.0687] <bakkot>
encoder is trivial but decoder has to handle surrogate pairs when streaming, so it needs to keep state

[10:08:54.0411] <ljharb>
shu: https://github.com/tc39/proposal-symbol-predicates/issues/12

[10:09:16.0810] <shu>
ljharb: excellent, thanks

[10:09:31.0608] <bakkot>
and you have the same issue with base64, where you need to encode 3 bytes at a time, and if your chunks are not == 0 mod 3 you need state

[10:16:44.0917] <bakkot>
shu: https://github.com/tc39/proposal-arraybuffer-base64/issues/21

[10:25:23.0099] <rbuckton>
bakkot: 
```js
// parameters:
//   start - optional offset into `bytes` at which to start encoding
//           (default: `0`, replaces `extra`)
//   count - optional number of bytes to read from `bytes` (default:
//           the length of the array minus `start`)
//   final - whether this is the final block to encode, e.g. overflow
//           bytes are truncated (replaces `more`, though has the
//           opposite meaning. could also be `done`)
// return value:
//   result - encoded text chunk
//   read - number of bytes read from `bytes` (replaces `extra`)

const { result, read } = bytes.toPartialBase64({ start, final });
```

This could be used in tandem with `copyWithin` to use a fixed-size buffer to encode incoming streaming data, rather than allocating new `Uint8Array` objects to hold onto the overflow.

[10:28:47.0327] <rbuckton>
I'm not sure if your proposal was just creating a new u8 array view over the underlying array buffer to hold onto the overflow, or if it was creating a brand new array buffer (the spec steps say "TODO" here, so its unclear).

If its the former, that would make it difficult to use a fixed-size buffer as a work area (which is fairly common when encoding/decoding a stream), since you could potentially overwrite the overflow in between calls.

If its the latter, then you're introducing a lot of overhead for a stream with all of the one or two-byte arrays you might generate.

[10:30:37.0664] <bakkot>
Proposal was an entirely new buffer. I figured that the overhead of making some new small arraybuffers wasn't actually worth worrying about, unless implementers say otherwise.

[10:31:17.0839] <bakkot>
In principle it should be any more overhead than making any other object, I would think.

[10:37:36.0935] <rbuckton>
That's where having an actual encoder class might be even more efficient, since you wouldn't be allocating all of these nursery objects for the options bag and return value.

[10:40:58.0117] <rbuckton>
but barring a class or something like `ref` parameters to avoid the potential nursery object allocations, an api that works with offsets/counts seems more efficient (by avoiding the extra arrays) and user-friendly (by avoiding hidden overwrite conflicts).

[10:43:11.0362] <bakkot>
with the offset/count design, how do users handle the extra bytes, in the case that they have e.g. two chunks (in different Uint8Arrays) where the first chunk has a length which is not a multiple of 3?

[10:43:38.0012] <bakkot>
concretely, let's say the first chunk is 10 bytes, and the second chunk is 4 bytes

[10:44:36.0592] <rbuckton>
In pretty much every other language, they copy from one array into the other, or copy both into a fixed-size buffer (which your spec steps also do)

[10:44:57.0234] <bakkot>
the spec steps are fictional; no reason an actual implementation would work that way

[10:45:13.0663] <bakkot>
the buffers aren't growable so you can't copy from one into the other

[10:45:20.0899] <rbuckton>
The code a user would have to write would be fairly similar to other languages, which is familiar.

[10:45:32.0584] <bakkot>
asking to copy into a new array seems like a big ask

[10:45:45.0368] <rbuckton>
> <@bakkot:matrix.org> the buffers aren't growable so you can't copy from one into the other

You can if one buffer has a fixed size, and you're using counts.

[10:46:03.0708] <bakkot>
... how?

[10:46:07.0830] <rbuckton>
> <@bakkot:matrix.org> asking to copy into a new array seems like a big ask

A big ask of who? This is usually how its done when you're at a low level like this.

[10:46:48.0714] <bakkot>
by "a big ask" I mean "that does not seem like it is a more ergonomic API than the current proposal"

[10:47:23.0280] <bakkot>
I am in general amenable to arguments of the form "we should do it like other languages", but in this particular case I'm not convinced, at the moment

[10:47:38.0988] <rbuckton>
> <@bakkot:matrix.org> by "a big ask" I mean "that does not seem like it is a more ergonomic API than the current proposal"

It may not be, but its no less ergonomic than the same low-level API in other languages.

[10:48:02.0555] <rbuckton>
If you want something more ergonomic, I'd advise a class that can maintain the state.

[10:48:30.0381] <bakkot>
I think the design in the proposal is more ergonomic than this design, and does not require a class to maintain the state

[10:48:36.0395] <bakkot>
so I like it best of the options discussed so far

[10:48:54.0914] <bakkot>
possibly there is some tweak to your design which allows you to avoid the copy, which is my main objection to it

[10:49:04.0856] <rbuckton>
My argument is that the current design is not friendly to memory or GC.

[10:49:12.0871] <bakkot>
I am still missing the claim about, how do you copy from one buffer into the other

[10:49:24.0060] <rbuckton>
Except that your design also performs copies, but they're out of the user's control

[10:49:32.0371] <bakkot>
My design doesn't perform copies

[10:49:38.0134] <bakkot>
The spec steps do but they are fictional

[10:50:06.0601] <bakkot>
If implementations object on the grounds of creating new objects I'd hear them out, but I'd want to hear that from them - generally speaking we create new objects all of the place and don't worry too much about it 

[10:50:19.0323] <bakkot>
concretely I would be reluctant to sacrifice the design if the _only_ concern is the new objects

[10:50:30.0642] <rbuckton>
No, not if you're returning a fresh array that is 0-2 bytes for the overflow. Its small, but its a copy.

[10:50:39.0856] <bakkot>
sure, yes, I am creating a copy of 0-2 bytes

[10:50:42.0858] <bakkot>
not of an entire chunk

[10:50:51.0002] <littledan>
> <@bakkot:matrix.org> If implementations object on the grounds of creating new objects I'd hear them out, but I'd want to hear that from them - generally speaking we create new objects all of the place and don't worry too much about it

well, you just heard an implementation request BYOB for streaming--I think that's the main "allow avoiding create new objects" request to worry about

[10:51:15.0862] <bakkot>
littledan: the BYOB thing isn't really related to this conversation afaict

[10:51:33.0495] <littledan>
err sorry I'm sort of agreeing with you

[10:51:43.0274] <bakkot>
ah, gotcha

[10:53:11.0263] <rbuckton>
The way you would normally do this in C++ or C# would be to have a working buffer. You block-copy bytes from your incoming chunk into the working buffer, and use offset/count to control where to read/write from.
If there is overflow, you block-copy the overflow bytes to the start of the temp buffer, and the next chunk would be written after those bytes.

[10:54:27.0614] <rbuckton>
Typed arrays have two copying mechanisms: `copyWithin` and `set` (though I'm not sure if they are block-copy operations when compiled/optimized).

[10:54:49.0744] <bakkot>
The way you work with binary data in C++ in general is sufficiently far from JS that I am not willing to trust that this will be familiar to JS developers

[10:55:35.0026] <bakkot>
and if your concern with the design in the proposal is memory, having something which requires manual management and copying with an additional working buffer seems like it is worse for memory concerns

[10:56:12.0046] <rbuckton>
This capability seems somewhat niche enough that the Venn diagram of entry-level JS devs and calls to `toPartialBase64` seems fairly small.

[10:56:46.0628] <bakkot>
Even non entry-level JS devs are not necessarily going to have written a bunch of C++.

[10:57:26.0312] <rbuckton>
> <@bakkot:matrix.org> and if your concern with the design in the proposal is memory, having something which requires manual management and copying with an additional working buffer seems like it is worse for memory concerns

Perhaps this might be a question for implementers, since this seems exactly like how the current spec text might be implemented at runtime.

[10:58:19.0337] <bakkot>
I mean if they want to implement that way that's certainly their prerogative

[10:58:32.0986] <bakkot>
and if they aren't worried about the memory involved I'm not either

[10:58:37.0362] <bakkot>
I don't want to worry about it for them

[10:58:50.0603] <bakkot>
if they _are_ worried about the memory it's easy to write in such a way that the copy of the full chunk is avoided

[11:00:17.0034] <littledan>
> <@rbuckton:matrix.org> Perhaps this might be a question for implementers, since this seems exactly like how the current spec text might be implemented at runtime.

There is truth to this: implementations often start out by literally copying the spec. So if there's a way to write the spec which demonstrates the optimization more straightforwardly, that'd probably result in faster initial implementations.

[11:00:31.0500] <littledan>
(as long as it doesn't look too obscure)

[11:01:01.0057] <bakkot>
I wrote it that way originally but it does end up looking pretty obscure

[11:01:22.0181] <bakkot>
I can add a NOTE pointing out the opportunity for optimization

[11:01:38.0814] <rbuckton>
Saying "the spec text is fictional" isn't a useful argument, IMO. This is working with memory in a way that the actual implementation that engines will end up using would have a significant bearing on the API design. If there are concerns about memory/GC efficiency of an actual implementation, that seems like useful information to consider before Stage 3.

[11:02:53.0825] <bakkot>
I agree that if engines say they don't like this design because of GC concerns then we'd want to reconsider. I just don't see it right now. And the _internal_ copy, if they choose to implement spec steps blindly, doesn't interact with GC at all.

[11:07:09.0996] <rbuckton>
Your proposal, however, observably creates new arrays for the overflow bytes, which will need to be GC'd. 

[11:08:29.0122] <bakkot>
Yes, I agree it creates two small objects rather than only one, and as I say if engines don't like that because of GC concerns then we'd want to reconsider

[11:09:06.0437] <bakkot>
The current design does rest on the assumption that "creates two small objects" is not a big problem

[11:09:16.0031] <bakkot>
 * The current design does rest on the assumption that "creates two small objects per chunk" is not a big problem

[11:09:46.0289] <bakkot>
(three, really, since the user needs to create one to pass in as an options bag)

[11:15:00.0008] <rbuckton>
This seems like the kind of API where you're _going_ to use it in a loop (i.e., encoding/decoding files in a resource-constrained environment), so ideally we'd have as few objects as possible per iteration (i.e., use multiple arguments rather than an option bag), unless implementations can optimize away the options bag at runtime.

[11:15:30.0883] <rbuckton>
Though the options bag can be made efficient if you just reuse the same object for each iteration.

[11:17:10.0770] <bakkot>
I worked out the current design in conjunction with Peter from moddable; if they're not worried about it, I'm not either. I'm not going to sacrifice the UX for concerns about devices which are more resources constrained than them.

[11:17:25.0500] <bakkot>
 * I worked out the current design in conjunction with Peter from moddable; if they're not worried about it, I'm not either. I'm not going to sacrifice the UX for concerns about devices which are more resource constrained than them.

[11:18:22.0629] <bakkot>
It is definitely true that using multiple arguments rather than an options bag would use fewer objects; I just don't think it's worth it.

[11:19:34.0946] <bakkot>
Similarly it is true that we could do a C++ style design where users are expected to manage copies into a working buffer themselves, and thereby create one fewer object; I just don't think it's worth the cost to the UX (and am not convinced that having this extra buffer would in fact be better for memory, even though it would be fewer total objects).

[11:26:58.0416] <rbuckton>
This design is halfway between efficient and ergonomic. One that works on offsets would be far more efficient, but far less ergonomic. One that utilized a class to encapsulate scope could be both extremely efficient and far more ergonomic, so I'm not very convinced of the argument that the UX benefit of the proposed design is worth the efficiency loss.

[11:29:14.0477] <bakkot>
I don't think "creates one fewer object per chunk" can reasonably be characterized as "far more efficient".

[11:29:31.0329] <bakkot>
It is _very marginally_ more efficient, at the cost of a much worse experience.

[11:30:47.0413] <bakkot>
(And I'm not even convinced it would be more efficient in practice, since it requires the user to manage an additional working buffer.)

[11:33:40.0229] <littledan>
+1 to Nicolo's answer

[11:49:29.0951] <HE Shi-Jun>
I have a question about "attach context" and "link", these two phase seems do not need to be in specific order? I mean currently is is designed to first attach context then link, but could first link then attach context also work?

[11:50:53.0248] <nicolo-ribaudo>
> <@haxjs:matrix.org> I have a question about "attach context" and "link", these two phase seems do not need to be in specific order? I mean currently is is designed to first attach context then link, but could first link then attach context also work?

"context" includes the "resolution context", i.e. instructions on how to load/resolve the dependencies.

But yes, "attach the globalThis context" could potentially happen after linking

[11:53:25.0477] <HE Shi-Jun>
oh, i see, thank u!

[12:00:50.0329] <nicolo-ribaudo>
Is TCQ down?

[12:00:56.0204] <nicolo-ribaudo>
I get an internal server error

[12:01:14.0342] <ryzokuken>
no

[12:01:20.0025] <Willian Martins>
It is fine here

[12:01:25.0961] <msaboff>
Seems good to me

[12:01:28.0938] <nicolo-ribaudo>
Uh ok it works on a different device

[12:03:25.0141] <Justin Ridgewell>
> <@rbuckton:matrix.org> This design is halfway between efficient and ergonomic. One that works on offsets would be far more efficient, but far less ergonomic. One that utilized a class to encapsulate scope could be both extremely efficient and far more ergonomic, so I'm not very convinced of the argument that the UX benefit of the proposed design is worth the efficiency loss.

Can you show an example API? I weakly preferred a stateful class instead of the objects myself in [#13](https://github.com/tc39/proposal-arraybuffer-base64/issues/13)

[12:03:45.0257] <rbuckton>
> <@jridgewell:matrix.org> Can you show an example API? I weakly preferred a stateful class instead of the objects myself in [#13](https://github.com/tc39/proposal-arraybuffer-base64/issues/13)

An example of a class-like API?

[12:04:32.0976] <shu>
wait what is "attach context" again?

[12:04:51.0213] <Justin Ridgewell>
Yah, how would you use it and how is it more efficient than the current API?

[12:05:19.0542] <Justin Ridgewell>
> <@shuyuguo:matrix.org> wait what is "attach context" again?

The module's base URL, and something else

[12:05:43.0748] <littledan>
> <@shuyuguo:matrix.org> wait what is "attach context" again?

This is attaching the global variable, and yes the current URL

[12:05:57.0365] <littledan>
for context, one of the compartments proposals was about user-supplied globals

[12:06:22.0713] <littledan>
module expressions don't have their global attached yet

[12:06:28.0221] <littledan>
> <@shuyuguo:matrix.org> wait what is "attach context" again?

 * This is attaching the global variable\

[12:06:54.0226] <shu>
i see

[12:07:25.0468] <shu>
thanks

[12:07:40.0953] <littledan>
https://docs.google.com/presentation/d/1mZrAHHimtM_z_8fM9L3DUXFz5bjlJPxx8VrwsC68hmk/edit#slide=id.g23e5197d83a_1_38

[12:07:57.0872] <littledan>
module expressions do *not* have a global variable attached yet, for example (but they do have a base URL)

[12:08:27.0464] <littledan>
or at least, module source doesn't... actually module expressions might have them attached and it just gets discarded during structured clone

[12:08:53.0349] <littledan>
(sorry ignore me here I got confused; nicolo-ribaudo can clarify better)

[12:10:37.0993] <nicolo-ribaudo>
Module expressions inherit the global object / realm from where the module expression is evaluated, but when structuredCloning them the idea is that the unserializable parts (such as, the global context) would be re-attached when deserializing them

[12:11:53.0213] <nicolo-ribaudo>
The "context" is currently attached when creating a Module Record (i.e. in ParseModule) that receives the _realm_ and _hostDefined_ params (where hostDefined includes the baseURL)

[12:12:02.0021] <nicolo-ribaudo>
 * The "context" is currently attached when creating a Module Record (i.e. in ParseModule) that receives the _realm_ and _hostDefined_ params (where hostDefined includes the baseURL when used in HTML)

[12:12:13.0329] <HE Shi-Jun>
when will it be structurecloned? send to a worker? 

[12:13:02.0766] <nicolo-ribaudo>
Or `structuredClone(module {})`, or `v8.deserialize`/`v8.serialize` in Node.js

[12:13:08.0877] <nicolo-ribaudo>
 * Yes, or `structuredClone(module {})`, or `v8.deserialize`/`v8.serialize` in Node.js

[12:13:25.0079] <nicolo-ribaudo>
 * Yes, or `structuredClone(aModuleObject)`, or `v8.deserialize`/`v8.serialize` in Node.js

[12:13:39.0571] <HE Shi-Jun>
So can i also structureclone module declaration?

[12:13:50.0005] <littledan>
anyway module source objects do not have context attached

[12:14:45.0880] <nicolo-ribaudo>
> <@haxjs:matrix.org> So can i also structureclone module declaration?

Yes, with a very big note that we currently don't have written down exactly how that works with module declarations importing module declarations (there have been concerns about the "scope capturing" between module declarations, so before proposing details for the HTML integration we want to solve the most fundamental concerns)

[12:15:03.0960] <Andreu Botella>
It seems like it would have to be a host hook requirement that there's no module source for JS imports, right?

[12:15:37.0253] <nicolo-ribaudo>
> <@abotella:igalia.com> It seems like it would have to be a host hook requirement that there's no module source for JS imports, right?

Well JavaScript Module Records are created within ECMA-262 (by the ParseModule AO), so the proposal directly encorces it

[12:15:59.0094] <littledan>
> <@abotella:igalia.com> It seems like it would have to be a host hook requirement that there's no module source for JS imports, right?

Concretely the throwing behavior is inherited from Cyclic Module Records

[12:16:37.0143] <littledan>
https://tc39.es/proposal-import-reflection/#sec-getmodulesource

[12:16:54.0561] <Michael Ficarra>
ljharb: I see where you're coming from, but IMO that would just add noise

[12:16:56.0105] <nicolo-ribaudo>
> <@littledan:matrix.org> Concretely the throwing behavior is inherited from Cyclic Module Records

(maybe it would make sense to move it to Source Text Module Record, since Wasm modules also are cyclic module records in the Wasm-ESM integration)

[12:17:15.0036] <ljharb>
> <@michaelficarra:matrix.org> ljharb: I see where you're coming from, but IMO that would just add noise

it indeed would add noide

[12:17:16.0447] <ljharb>
> <@michaelficarra:matrix.org> ljharb: I see where you're coming from, but IMO that would just add noise

 * it indeed would add noise

[12:17:30.0963] <littledan>
> <@nicolo-ribaudo:matrix.org> (maybe it would make sense to move it to Source Text Module Record, since Wasm modules also are cyclic module records in the Wasm-ESM integration)

well, arguably we should move this even further up, since it will apply to static module records as well

[12:24:24.0114] <shu>
i am not understanding the alternative ron is proposing

[12:29:34.0904] <littledan>
> <@shuyuguo:matrix.org> i am not understanding the alternative ron is proposing

me neither; maybe we should pause to clarify this?

[12:30:02.0323] <littledan>
I got the feeling he was suggesting that we only have the dynamic case, and use `import.source(x)` for that. Or maybe even just a function call.

[12:30:07.0256] <shu>
+1 let's get to other queue items if ron's particular alternative isn't actually on the table

[12:30:15.0581] <shu>
instead of getting in the weeds for a vague alternative

[12:30:23.0014] <shu>
but the current clarification sounds good

[12:31:46.0364] <littledan>
oh! this is a completely different alternative: that we use `with` for all of these instead

[12:32:07.0142] <shu>
okay then we should pause to clarify

[12:34:45.0959] <Luca Casonato>
Chris de Almeida: do we have time to overrun the timebox?

[12:34:55.0534] <ryzokuken>
yes

[12:35:09.0254] <Chris de Almeida>
we can go through the end of the hour

[12:35:10.0090] <ryzokuken>
you can run upto the top of the hour

[12:35:35.0431] <Chris de Almeida>
still need to be mindful of the queue

[12:42:26.0193] <Justin Ridgewell>
I've argued a few times that phase could be in the import attributes. Memo caching can be solved, early errors can be supported.

[12:43:00.0517] <Justin Ridgewell>
My reasoning is that phase is conceptually similar to an evaluator, meaning it changes the source text of the thing it imports (and this is how it's going to be implemented in bundlers)

[12:43:13.0310] <Justin Ridgewell>
Evaluators go in the import attributes bag.

[12:43:25.0630] <ljharb>
import attributes isn't exactly "evaluators" tho.

[12:44:42.0172] <ljharb>
 * import attributes isn't exactly "evaluators" tho - they can do that but that's not the purpose of them

[12:46:07.0295] <rbuckton>
I have a weak preference against `import <keyword>` for the static syntax.
I have a stronger preference for `import.<phase>()` for the dynamic syntax as the `import(url, { phase })` syntax either introduces unnecessary asynchrony for asset references, or it introduces a non-promise return value from `import` (for asset references). The `import(url, { phase })` syntax also introduces complexity for future proposals that may need to somehow navigate `phase` and `with` attributes on the object.

[12:46:09.0310] <HE Shi-Jun>
module from {}
import source from from

[12:47:02.0828] <Kris Kowal>
> <@jridgewell:matrix.org> My reasoning is that phase is conceptually similar to an evaluator, meaning it changes the source text of the thing it imports (and this is how it's going to be implemented in bundlers)

The intersection semantics with importHook would be quite bad in that case. The importHook is responsible for returning a Module irrespective of the phase, and the importHook will need to see the whole options bag, and the importHook is memoized according to the specifier + all attributes. You will get duplicate instances if you import with multiple phases.

[12:47:52.0584] <Michael Ficarra>
I don't really understand the syntax brittleness argument, all syntax is brittle to some degree

[12:48:19.0451] <Michael Ficarra>
we don't have like syntax checksums or ECC for syntax

[12:48:54.0197] <Justin Ridgewell>
I think you're relying on the engine to do the memoization, instead of letting the `importHook`?

[12:49:40.0379] <nicolo-ribaudo>
> <@kriskowal:matrix.org> The intersection semantics with importHook would be quite bad in that case. The importHook is responsible for returning a Module irrespective of the phase, and the importHook will need to see the whole options bag, and the importHook is memoized according to the specifier + all attributes. You will get duplicate instances if you import with multiple phases.

The only way this could work is to "hide" the phase attribute and not pass it to the importHook even if it's specified

[12:49:42.0616] <Kris Kowal>
The `Module` instance is relied upon to do the memoization, yes.

[12:50:32.0732] <Michael Ficarra>
if everything was S-expressions, I guess it would be less brittle, but also it would look like (()()()))()()()()(())())()()())))()()((()((())

[12:50:36.0421] <littledan>
> <@rbuckton:matrix.org> I have a weak preference against `import <keyword>` for the static syntax.
> I have a stronger preference for `import.<phase>()` for the dynamic syntax as the `import(url, { phase })` syntax either introduces unnecessary asynchrony for asset references, or it introduces a non-promise return value from `import` (for asset references). The `import(url, { phase })` syntax also introduces complexity for future proposals that may need to somehow navigate `phase` and `with` attributes on the object.

I can understand this argument, but also it seems really specific to asset references, which we really haven't worked out yet.

[12:50:42.0468] <rbuckton>
Its somewhat odd that we can `import asset ...` to resolve a url, and `import source ...` to fetch AND compile, but no way to just fetch via syntax.

[12:51:01.0509] <Justin Ridgewell>
> <@nicolo-ribaudo:matrix.org> The only way this could work is to "hide" the phase attribute and not pass it to the importHook even if it's specified

The `importHook`'s memo can handle that case pretty easily?

[12:51:21.0750] <nicolo-ribaudo>
> <@michaelficarra:matrix.org> if everything was S-expressions, I guess it would be less brittle, but also it would look like (()()()))()()()()(())())()()())))()()((()((())

Is uglily-js still used?

[12:51:26.0746] <rbuckton>
> <@littledan:matrix.org> I can understand this argument, but also it seems really specific to asset references, which we really haven't worked out yet.

I'm not a fan of turning `import` into an RPC call, i.e., specifying the operation via a property in an object as opposed to an imperative call.

[12:51:34.0580] <HE Shi-Jun>
 * module from {}
import source from from
"url"

[12:51:54.0420] <littledan>
> <@rbuckton:matrix.org> Its somewhat odd that we can `import asset ...` to resolve a url, and `import source ...` to fetch AND compile, but no way to just fetch via syntax.

Environments might add that through import attributes, but at the same time it's a little risky since you could never GC such a fetch result

[12:52:03.0444] <rbuckton>
It feels akin to asking someone to write `array.do({ action: "filter", callback: fn })`

[12:52:12.0724] <nicolo-ribaudo>
> <@jridgewell:matrix.org> The `importHook`'s memo can handle that case pretty easily?

You wouldn't want an user-defined hook to potentially load a different module depending on the specified phase

[12:52:40.0109] <littledan>
> <@rbuckton:matrix.org> It feels akin to asking someone to write `array.do({ action: "filter", callback: fn })`

it sounds like you're arguing against import assertions then?

[12:52:51.0117] <littledan>
> <@rbuckton:matrix.org> It feels akin to asking someone to write `array.do({ action: "filter", callback: fn })`

 * it sounds like you're arguing against import attributes then?

[12:53:06.0453] <HE Shi-Jun>
> <@haxjs:matrix.org> module from {}
> import source from from
> "url"

is this case cause syntax ambiguity ?

[12:53:13.0443] <Justin Ridgewell>
That's the responsibility of the code import hook code. If you use a power-use feature, you're expected to follow the rules

[12:53:21.0555] <Michael Ficarra>
why do SES folks have the time to burden every proposal with this requirement but they don't have the time to work on the `getIntrinsics` proposal or whatever it is?

[12:53:23.0256] <rbuckton>
> <@littledan:matrix.org> it sounds like you're arguing against import attributes then?

No, import attributes are a bit more esoteric. This is far more obviously an operation

[12:53:48.0643] <littledan>
> <@haxjs:matrix.org> is this case cause syntax ambiguity ?

Yeah, I think `from` should be banned in all these cases; it's good that you and Waldemar are pointing this out

[12:54:39.0953] <nicolo-ribaudo>
> <@haxjs:matrix.org> is this case cause syntax ambiguity ?

Yes this is probably what WH was worried about. It can be specced as unambiguous (and in parser it's a two tokens lookahead, or just "eat three identifiers and then decide if they are bindings or syntax").
It would still "read" as unambiguous, but how often would you import a `source` binding from a module declaration named `from`? (how many files do you have called `from.js`?)

[12:54:43.0976] <littledan>
> <@rbuckton:matrix.org> No, import attributes are a bit more esoteric. This is far more obviously an operation

oh, I see, we're back on `import.stage()` and not talking about the put-it-all-in-attributes side (which would be fine with phase:)

[12:54:47.0062] <nicolo-ribaudo>
> <@haxjs:matrix.org> is this case cause syntax ambiguity ?

 * Yes this is probably what WH was worried about. It can be specced as unambiguous (and in parser it's a two tokens lookahead, or just "eat three identifiers and then decide if they are bindings or syntax").
It would still "read" as unambiguous, but how often would you import a `source` binding from a module declaration named `from`? (how many files do you currently have called `from.js`?)

[12:54:57.0424] <nicolo-ribaudo>
 * Yes this is probably what WH was worried about. It can be specced as unambiguous (and in parser it's a two tokens lookahead, or just "eat three identifiers and then decide if they are bindings or syntax").
It would still "read" as ambiguous, but how often would you import a `source` binding from a module declaration named `from`? (how many files do you currently have called `from.js`?)

[12:55:17.0575] <nicolo-ribaudo>
 * Yes this is probably what WH was worried about. It can be specced as unambiguous (and in parser it's a two tokens lookahead, or just "eat three identifiers and then decide if they are bindings or syntax").
It would still "read" as ambiguous, but how often would you import a `source` binding from a module declaration named `from`? (how many files do currently exist have called `from.js` that export a `source` variable?)

[12:55:38.0955] <rbuckton>
> <@littledan:matrix.org> oh, I see, we're back on `import.stage()` and not talking about the put-it-all-in-attributes side (which would be fine with phase:)

Yes. I also brought up the cache-key concern internally, though the same argument was made that "such attributes don't need to be made part of the cache key"

[12:56:00.0401] <HE Shi-Jun>
> <@nicolo-ribaudo:matrix.org> Yes this is probably what WH was worried about. It can be specced as unambiguous (and in parser it's a two tokens lookahead, or just "eat three identifiers and then decide if they are bindings or syntax").
> It would still "read" as ambiguous, but how often would you import a `source` binding from a module declaration named `from`? (how many files do currently exist have called `from.js` that export a `source` variable?)

I don't worry about it in real world. Just try to find the edge case for parsers.

[12:56:12.0051] <littledan>
> <@rbuckton:matrix.org> Yes. I also brought up the cache-key concern internally, though the same argument was made that "such attributes don't need to be made part of the cache key"

yes I think this argument is valid--it just provides a guarantee; it wasn't impossible to meet otherwise

[13:00:57.0895] <HE Shi-Jun>
I also prefer `import.phase()` for similar reason.

[13:02:30.0254] <Michael Ficarra>
people don't mean literally `import.phase`, right? you mean `import.source()`?

[13:02:47.0079] <rbuckton>
I am ok with `import <phase>`, prefer `import.<phase>()` for dynamic unless there are strong objections. It seems like the champions had "no preference" when discussing it in slides.

[13:03:13.0271] <rbuckton>
> <@michaelficarra:matrix.org> people don't mean literally `import.phase`, right? you mean `import.source()`?

Yes. `import.<phase>()` is what I'd tried to use earlier in chat.

[13:04:38.0737] <ljharb>
> <@michaelficarra:matrix.org> why do SES folks have the time to burden every proposal with this requirement but they don't have the time to work on the `getIntrinsics` proposal or whatever it is?

fwiw i am working on it, and expect to bring it to the july plenary

[13:05:20.0923] <Michael Ficarra>
please let's not do conditional advancement

[13:05:53.0891] <Michael Ficarra>
I'm sorry, I missed part of the conversation because my power cut out, but I do not want to do conditional advancement

[13:06:11.0920] <HE Shi-Jun>
Agree with shu , I don't like such big syntax decision (not like simple case `await using` or `using await`) be conditional stage 3.

[13:06:13.0020] <bakkot>
we might have time at the end of the meeting anyway

[13:06:19.0554] <bakkot>
we could just come back to it

[13:06:29.0913] <bakkot>
we should not rush stuff

[13:06:41.0481] <nicolo-ribaudo>
> <@michaelficarra:matrix.org> I'm sorry, I missed part of the conversation because my power cut out, but I do not want to do conditional advancement

Do you want this in the notes?

[13:06:59.0037] <Michael Ficarra>
nicolo-ribaudo: no it's fine

[13:07:21.0744] <littledan>
sorry I'm also very happy to wait until the end of the meeting or a future meeting and not rush stuff

[13:07:26.0185] <littledan>
though I do think that, syntax-wise, this is actually easier than `using await`/`await using` since the technical aspects of grammar work out easier.

[13:08:16.0637] <shu>
littledan: conditional stage 3 might need to be renamed then. i think it's most useful as a "we have decided here are the set of things we don't want reopen discussion on", and in the past it's been mostly smallish things like a name or something, so it's also coincided with "let's start implementing it just like other stage 3 proposals"

[13:09:09.0303] <littledan>
Yeah anyway I sort of retract my comment

[13:09:36.0747] <littledan>
I don't think we've been using conditional stage 3 that way though

[13:09:43.0977] <shu>
hmm

[13:09:50.0771] <littledan>
but I've been surprised by the breadth of usage of conditional stage 3 and I'm happy to use less of it

[13:10:12.0449] <shu>
yes, that's probably closer to the root of my unease

[13:10:14.0497] <littledan>
the "conditional" aspect is just supposed to save us the two months of waiting for a perfunctory, meaningless signify to something we've already agreed on

[13:10:15.0853] <msaboff>
I also don't support "conditional" stage N, where N is ≥ 2.  We have time during this meeting for the champions to come back with the dynamic import.phase() change discussed.

[13:10:37.0525] <shu>
if we want to piecemeal decide "this topic is now closed and we have consensus", we should do that. i for one would like that

[13:10:54.0263] <bakkot>
I do wish we made more use of "consensus for this thing not being open for further discussion" outside of specific stage questions

[13:11:31.0000] <shu>
*i*'ve been thinking of conditional stage 3 as like, look, here're a few small things that a small set of stakeholders care about for small N, settle that async, i'll reload the issue in a month when i or someone on the team implement the feature

[13:11:37.0001] <rbuckton>
I know I'm guilty of using conditional advancement, but I've generally tried to keep it to small things that we usually have consensus on, but require some additional leg work outside of plenary to resolve.

[13:11:42.0870] <littledan>
> <@msaboff:matrix.org> I also don't support "conditional" stage N, where N is ≥ 2.  We have time during this meeting for the champions to come back with the dynamic import.phase() change discussed.

heh, conditional Stage 1 doesn't end up being so meaningful, we can just grant something Stage 1 and trust that a person will come back to it

[13:11:49.0909] <shu>
lol, sick

[13:11:52.0200] <shu>
if we had conditional stage 1

[13:11:56.0056] <rbuckton>
 * I know I'm guilty of using conditional advancement, but I've generally tried to keep it to small things that we usually have consensus on (or are close to consensus on), but require some additional leg work outside of plenary to resolve.

[13:12:45.0573] <littledan>
> <@shuyuguo:matrix.org> *i*'ve been thinking of conditional stage 3 as like, look, here're a few small things that a small set of stakeholders care about for small N, settle that async, i'll reload the issue in a month when i or someone on the team implement the feature

In theory, the point in time when something actually moves to the next stage should be when you should reload (but we don't have an easy way to trigger on that)

[13:13:15.0658] <msaboff>
I suspect some of this would depend what we are conditional on.  e.g. conditional on a spec review by XYZ is different than conditional on a syntax or semantic change.

[13:13:16.0968] <littledan>
anyway I think a good rule of thumb could be, "if it's controversial whether conditionality could be used here, it's probably not time yet"

[13:15:52.0796] <Luca Casonato>
> <@bakkot:matrix.org> I do wish we made more use of "consensus for this thing not being open for further discussion" outside of specific stage questions

This is a good idea. We can rephrase it as this when we resume the queue later in the meeting. We ask for consensus on everything except:
- dynamic import syntax
- `import source from ...` ambiguity

We can then come back next meeting (97th) to actually advance. We'd stay at stage 2 for now. I also don't want to make conditionallity overly complex.

If we have locked in the semantics for everything except those two, we can doing some preparatory implementation work already under the assumption that we will go to stage 3 next meeting.

[13:21:54.0551] <rbuckton>
guybedford, Luca Casonato: apologies this concern didn't come up earlier in stage 2. My preference for `import.<phase>()` is stronger than the "no preference" described by the champions, but not a deal breaker. If no one else strongly prefers that syntax, I certainly won't block advancement.

[13:22:29.0020] <HE Shi-Jun>
Does module declaration allow:

module x {}
import x;

? 


[13:22:35.0173] <Luca Casonato>
yes

[13:23:35.0836] <Luca Casonato>
> <@rbuckton:matrix.org> guybedford, Luca Casonato: apologies this concern didn't come up earlier in stage 2. My preference for `import.<phase>()` is stronger than the "no preference" described by the champions, but not a deal breaker. If no one else strongly prefers that syntax, I certainly won't block advancement.

no worries - i think your strong preference outweighs the "no to very light preference" from others here, so we can make the change for next meeting

[13:24:08.0676] <HE Shi-Jun>
If allow, i guess parser need to read many token in the case like:
module source {}
import source
x
from
"url"

[13:24:29.0693] <Luca Casonato>
> <@lucacasonato:matrix.org> no worries - i think your strong preference outweighs the "no to very light preference" from others here, so we can make the change for next meeting

and kris's brief argument that this could be used to grant the capability of importing sources, but not evaluating (ie providing inspection but not evaluation), purely through syntax seems good in general

[13:24:58.0170] <Luca Casonato>
> <@haxjs:matrix.org> If allow, i guess parser need to read many token in the case like:
> module source {}
> import source
> x
> from
> "url"

no, because `import source "specifier"` is not valid

[13:25:09.0805] <Luca Casonato>
unless I am misunderstanding what you mean

[13:25:38.0473] <Luca Casonato>
oh i see what you mean now - ok good catch

[13:26:33.0302] <Luca Casonato>
could we avoid this by banning module declarations that have import phases as names?

[13:27:39.0723] <HE Shi-Jun>
ban all phase names like source/instance/asset/defer ...?

[13:28:35.0274] <Luca Casonato>
or actually even easier, just ban `import <phase>;`

[13:28:56.0452] <nicolo-ribaudo>
HE Shi-Jun I'm curious, do you get these case by experience working on a JS parser? I would love to borrow some tests for Babel 👀

[13:29:12.0847] <nicolo-ribaudo>
 * HE Shi-Jun I'm curious, do you get these cases by experience working on a JS parser? I would love to borrow some tests for Babel 👀

[13:30:19.0911] <HE Shi-Jun>
> <@nicolo-ribaudo:matrix.org> HE Shi-Jun I'm curious, do you get these cases by experience working on a JS parser? I would love to borrow some tests for Babel 👀

just follow previous discussed `import source from from`, someone in my wechat group asked the question.

[13:31:21.0623] <HE Shi-Jun>
> <@lucacasonato:matrix.org> or actually even easier, just ban `import <phase>;`

We must make sure we will not introduce new phase in the future :)

[13:35:38.0258] <nicolo-ribaudo>
I will try to implement module declarations (at least the part for `import`) in Babel's to have a clearly understanding of hard it is to disambiguate.
Currently we implement only an old syntax of import reflection (`import module foo from "foo") without implementing also module declarations, and disambiguating `import module from from "x"` vs `import module from "x"` requires a 1-token lookahead. Another way to disambiguate is to keep eating identifiers until they represent possible valid syntax and then disambiguate based on the number of identifiers parser (and discard 0 to 2 "identifier" nodes created in the process)

[13:37:42.0504] <Luca Casonato>
> <@haxjs:matrix.org> If allow, i guess parser need to read many token in the case like:
> module source {}
> import source
> x
> from
> "url"

HE Shi-Jun: i think maybe the easiest possible fix is to disallow newlines between phase and identifier?

[13:51:55.0721] <Chris de Almeida>
 `Source Phase Imports for Stage 3 (cont’d from Day 1)` has been added to the schedule as the final item tomorrow

[13:52:22.0093] <Chris de Almeida>
limited to 20 minutes

[13:52:30.0829] <littledan>
What was the public calendar topic conclusion?

[13:52:39.0912] <littledan>
no conclusion is recorded in the notes. Are we going ahead with anything?

[13:52:40.0897] <Chris de Almeida>
I was going to update that

[13:52:56.0782] <littledan>
In general, a lot of the notes need significant edits and are incoherent

[13:53:08.0010] <Chris de Almeida>
 * I ~~was~~ am going to update that

[13:53:29.0507] <littledan>
(pro tip: use `<del>`)

[13:53:50.0117] <littledan>
also in general, we can delete comments in the notes that are just queue management, right?

[13:53:56.0879] <bakkot>
yes

[13:54:25.0333] <bakkot>
at least, I always do when I'm editing

[13:54:47.0359] <bakkot>
shu: re byo-buffer, thoughts on https://github.com/tc39/proposal-arraybuffer-base64/issues/21#issuecomment-1548418530?

[13:55:19.0987] <bakkot>
also: you know TextEncoder's `encodeInto`? thoughts on letting it grow a growable buffer? (possibly with an opt-in option) that would be handy in some cases

[13:55:24.0510] <bakkot>
(similarly here)

[13:55:37.0806] <littledan>
Reminder to everyone editing notes: we need a blank line between different speakers (this is Markdown)

[13:55:52.0683] <shu>
bakkot: won't have time to fully think it through until later, but first blush sgtm?

[13:56:08.0667] <shu>
it doesn't sound like a huge delta, and i appreciate not making the API even grosser

[13:57:00.0082] <littledan>
and should we delete the introductory comments by Ujjwal?

[14:01:22.0950] <littledan>
What is our conclusion on the ECMA-402 status update? Do we have consensus on the PR https://github.com/tc39/ecma402/pull/768 ? I share Jordan's concern that this should've been added to the agenda in advance so that folks could review.

[14:21:47.0578] <ljharb>
nobody objected, during or since, so i think it still has consensus. i brought it up as a procedural comment for the future


2023-05-16
[17:33:13.0098] <rbuckton>
> <@softwarechris:matrix.org>  `Source Phase Imports for Stage 3 (cont’d from Day 1)` has been added to the schedule as the final item tomorrow

I will not be available in the afternoon tomorfow, per my previously specified scheduling constraint. Given the only blocking concern is one I raised, it would be better if I'm able to be part of that discussion. 

[17:34:09.0012] <rbuckton>
* I will not be available in the afternoon tomorrow, per my previously specified scheduling constraint. Given the main concern is one I raised, it would be better if I'm able to be part of that discussion. 

[17:40:38.0237] <Chris de Almeida>
rbuckton: Understood.  I'm sorry, your constraint didn't mention source phase imports, and thus wasn't considered in the scheduling of the continuation.  The time slot for the continuation was the only possible time/day for this item.  I'll defer to guybedford and Luca Casonato for how they wish to proceed.

[23:31:38.0906] <ljharb>
littledan: it'd be great if we could ask the stenographer tomorrow to bump up their line length to as close to infinity as possible, and also to autocorrect any multiple spaces down into one, including after a period

[23:43:52.0121] <Ashley Claymore>
I've been running a regex on the notes post meeting to fix up the added line breaks and multiple spaces, we can keep doing this if they can't adjust their setting. (Just as an FYI)

[01:10:42.0947] <Luca Casonato>
Chris de Almeida: any chance we can proceed on thu (in the afternoon overflow)?

[04:19:54.0971] <littledan>
> <@ljharb:matrix.org> littledan: it'd be great if we could ask the stenographer tomorrow to bump up their line length to as close to infinity as possible, and also to autocorrect any multiple spaces down into one, including after a period

Yes they are working on this (we are in touch by email)

[05:22:50.0060] <Chris de Almeida>
> <@lucacasonato:matrix.org> Chris de Almeida: any chance we can proceed on thu (in the afternoon overflow)?

conflicts with KKL's constraint and JGT's constraint (although it appears JGT constraint is satisfied if it's the 13:00-13:30 slot)

[05:23:08.0890] <Chris de Almeida>
> <@lucacasonato:matrix.org> Chris de Almeida: any chance we can proceed on thu (in the afternoon overflow)?

 * conflicts with KKL's constraint (unavailable Thursday) and JGT's constraint (although it appears JGT constraint is satisfied if it's the 13:00-13:30 slot)

[07:54:28.0298] <Rob Palmer>
Plenary begins in 5 mins!!!

[07:54:41.0623] <bakkot>
chairs: I don't know why I put 45 minutes for float16array, 15 is probably plenty

[07:54:57.0957] <bakkot>
if we end up having 15 minutes somewhere I am happy to do it wheenever

[08:05:22.0565] <Michael Ficarra>
I think stage 4 is always "pending final integration tweaks"

[08:05:25.0948] <Chris de Almeida>
thanks -- I've updated it in the schedule at hackmd

[08:06:30.0576] <Michael Ficarra>
the PR is open, I've reviewed it, and only had minor editorial feedback, nothing that would prevent it from advancing

[08:07:02.0547] <littledan>
Sorry I need to drop due to a medical issue for my partner

[08:07:07.0580] <littledan>
if others could take notes that would be great

[08:10:14.0706] <rbuckton>
> <@softwarechris:matrix.org> conflicts with KKL's constraint (unavailable Thursday) and JGT's constraint (although it appears JGT constraint is satisfied if it's the 13:00-13:30 slot)

I'm reaching out to others on my team to see if someone can be present for the overflow topic this afternoon. Unfortunately, I'm giving a talk in the afternoon that couldn't be rescheduled.

[08:11:01.0489] <littledan>
OK, back

[08:13:45.0926] <Kris Kowal>
> <@rbuckton:matrix.org> I'm reaching out to others on my team to see if someone can be present for the overflow topic this afternoon. Unfortunately, I'm giving a talk in the afternoon that couldn't be rescheduled.

I do not think my presence is critical, though I would love to be present to support the champions. I do not contest the requested changes (or any of the considered options with regard to syntax). Chip will be present to represent Agoric in general.

[08:14:39.0925] <Chris de Almeida>
Luca Casonato: guybedford --- it appears the Thursday slot at 13:00 will work, per KKL's blessing there.  sound good?

[08:15:56.0704] <Justin Ridgewell>
/me merges https://github.com/tc39/proposal-array-grouping/pull/52 adding a warning to the README

[08:17:42.0706] <Francisco Tolmasky>
Is the best (only?) way to observer IsConstructor in client code to do IsConstructor = X => { try { class extends X { } } catch (e) { return e instanceof TypeError } return true } ?

[08:18:24.0081] <rbuckton>
I'll also state that https://github.com/tc39/proposal-import-reflection/pull/45 addresses my concern. While it is unfortunate that the `import.<phase>()` format doesn't use a verb for the method name, doing so would break symmetry with the `import <phase>` static syntax, so I'm not quite so concerned (for example, `import instance mod from "url"` could have a dynamic version named `import.instantiate(url)`, but that would break the symmetry that ljharb prefers).

[08:19:52.0127] <ljharb>
> <@tolmasky:matrix.org> Is the best (only?) way to observer IsConstructor in client code to do IsConstructor = X => { try { class extends X { } } catch (e) { return e instanceof TypeError } return true } ?

no, you have to use Reflect.construct i believe

[08:20:08.0731] <ljharb>
> <@tolmasky:matrix.org> Is the best (only?) way to observer IsConstructor in client code to do IsConstructor = X => { try { class extends X { } } catch (e) { return e instanceof TypeError } return true } ?

 * you have to use Reflect.construct i believe if you support pre-class syntax engines

[08:20:37.0517] <Francisco Tolmasky>
But that has side-effects, or can have side effects, right

[08:21:53.0435] <ryzokuken>
https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking#stage-3

[08:30:57.0082] <Michael Ficarra>
Francisco Tolmasky: yeah, there's no way to *just* test for `[[Construct]]`

[08:31:49.0089] <Francisco Tolmasky>
Michael Ficarra: Is that because class X extends Tested_Value { } also has side-effects (perhaps by having the prototype key be a getter or something)

[08:34:04.0396] <Michael Ficarra>
yeah, I think just the prototype getter

[08:37:33.0237] <Kris Kowal>
> <@softwarechris:matrix.org> Luca Casonato: guybedford --- it appears the Thursday slot at 13:00 will work, per KKL's blessing there.  sound good?

I also need to confirm that Chip is willing and able to stand in for me. Please stand by.

[08:39:51.0832] <littledan>
if we have a check mark, we might as well make that check link to the anchor where the urgent info is discussed

[08:40:54.0430] <Chris de Almeida>
prefer not to have a new col on the proposals table that is usually empty, but not a big deal if col is narrow

[08:43:53.0514] <bakkot>
I mildly prefer not to have this in the proposals table just so that there are not multiple sources of truth

[08:44:10.0187] <bakkot>
proposal links to the readme and readme documents seems like the right balance

[08:44:14.0416] <bakkot>
but I also don't care very much

[08:44:19.0893] <Chris de Almeida>
Kris Kowal: we may be able to move it to Wednesday though.  please hold.  apologies for the disarray -- tough shuffling with constraints 🙂

[08:44:28.0976] <bakkot>
 * proposals table links to the readme and readme documents seems like the right balance

[08:44:44.0544] <nicolo-ribaudo>
> <@bakkot:matrix.org> I mildly prefer not to have this in the proposals table just so that there are not multiple sources of truth

Is the proposals list currently auto-generated?

[08:44:55.0739] <Chris de Almeida>
no

[08:45:03.0265] <ryzokuken>
no

[08:45:17.0318] <Chris de Almeida>
no, and it's missing things as such

[08:45:23.0996] <ryzokuken>
oh, I think to some extent, yeah

[08:45:32.0432] <littledan>
for example the "last presentation" column is pretty outdated

[08:45:35.0102] <ryzokuken>
the website picks up the dataset from the dataset repo

[08:47:45.0482] <littledan>
The summary is for major points raised; people keep dictating the conclusion and calling it the summary. It's OK if we don't have summaries, if people don't want to capture this information.

[08:48:17.0520] <littledan>
the idea of the summary is to make a shorter version of the lengthy discussion above, so we capture more than just the conclusion

[08:48:26.0368] <littledan>
of course dictating the conclusion is a really good practice and we should keep doing it!

[08:48:42.0838] <Michael Ficarra>
Francisco Tolmasky: I did it, but you're not gonna like it

[08:49:14.0745] <Michael Ficarra>
`let isConstructor = (a) => { if (a == null) { return false; } try { Promise.prototype.finally.call({ constructor: { [Symbol.species]: a }, then(){} }, () => {}) } catch { return false; } return true; }`

[08:49:45.0878] <ljharb>
interesting

[08:49:52.0995] <Francisco Tolmasky>
Why wouldn't I like it? I love it!

[08:49:56.0472] <ljharb>
i assume that only works with a native finally tho?

[08:50:28.0524] <Kris Kowal>
> <@softwarechris:matrix.org> Kris Kowal: we may be able to move it to Wednesday though.  please hold.  apologies for the disarray -- tough shuffling with constraints 🙂

I’ve confirmed with Chip that you can ignore my constraint! Thanks.

[08:51:36.0128] <Chris de Almeida>
thanks Kris!  I think the Weds option may work better for all involved, but waiting on Luca + Guy to proceed

[08:53:23.0355] <Luca Casonato>
> <@softwarechris:matrix.org> Luca Casonato: guybedford --- it appears the Thursday slot at 13:00 will work, per KKL's blessing there.  sound good?

yes

[08:53:55.0464] <Luca Casonato>
sorry, responded to wrong message

[08:54:00.0627] <Luca Casonato>
yes to **wed**

[08:54:07.0149] <Chris de Almeida>
ok, perfect!  thank you!

[08:57:39.0369] <Chris de Almeida>
this has the added benefit of offering double the available time (40 mins now instead of 20m)

[08:59:12.0462] <Michael Ficarra>
 * `const isConstructor = (a) => { if (Object(a) !== a) { return false; } try { Promise.prototype.finally.call({ constructor: { [Symbol.species]: a }, then(){} }) } catch { return false; } return true; }`

[08:59:50.0871] <Chris de Almeida>
`Source Phase Imports for Stage 3 (cont'd from Day 1)` will be Weds afternoon

[09:02:52.0213] <nicolo-ribaudo>
waldemar I just tested this code with the _current_ proposal, and it alerts `5` as expected:
```js
function minusTwo({ set, get }) {
  return {
    set(v) {
      set.call(this, v - 2)
    },
    get() {
      return get.call(this) + 2;
    }
  }	
}

function timesFour({ set, get }) {
  return {
    set(v) {
      set.call(this, v * 4)
    },
    get() {
      return get.call(this) / 4;
    }
  }	
}

class Foo {
  @minusTwo @timesFour accessor bar = 5;
}

const foo = new Foo();

foo.bar = 5;	
alert(`Serializing and de-serializing 5 yields ${foo.bar}`)
```

[09:03:25.0037] <nicolo-ribaudo>
( https://babeljs.io/repl#?browsers=ie%2010&build=&builtIns=false&corejs=3.21&spec=false&loose=true&code_lz=GYVwdgxgLglg9mABAWxmEBnAKgdzgCgG9EMBTKAGkQHNzEBfASkUIChFEAnckTpNjhzJR8AN2YDBQ8gDoIAQwA2i_FAAWMDFVGIAtIgBMjdoPoUTHWiIkXB3KLyRW5Sles3MA1IYDct-ib0AJCsAaygkLAIiLDIpBgAYnC8RCTkVFYMNhz2jiy2wmLZUmlQLsqqGlqIOgBUiAAsxlJmtlb4xVK5fDSyChXuGMwA9I1-LYEhYRCK8hgYiElw-RwAAqjo2HiIq7HxSbyI8hAQ8RhwnIgARvKXALyIAKx-0wgYUIjAcMsPYKQ4i2-HT84W-Mhu9yePhCSlInBEAAMAMpwmBKGAALzQ1COYAAJog8aRdGROGjFJjsU9EABPGCkRR4hYAEkIXzg4Nu9ARjCAA&debug=false&forceAllTransforms=false&modules=commonjs&shippedProposals=false&circleciRepo=&evaluate=true&fileSize=false&timeTravel=false&sourceType=module&lineWrap=true&presets=env%2Cstage-2&prettier=false&targets=&version=7.21.8&externalPlugins=&assumptions=%7B%7D )

[09:03:32.0852] <Michael Ficarra>
 * `const isConstructor = (a) => { if (Object(a) !== a) { return false; } try { Promise.prototype.finally.call({ constructor: { [Symbol.species]: a }, then(){} }); } catch { return false; } return true; }`

[09:03:44.0186] <Michael Ficarra>
 * `const isConstructor = (a) => { if (Object(a) !== a) { return false; } try { Promise.prototype.finally.call({ constructor: { [Symbol.species]: a }, then(){} }); } catch { return false; } return true; };`

[09:07:35.0983] <littledan>
ljharb: Outermost to innermost feels counterintuitive but if you think about the setters as successively wrapping each other, this is the natural order to fall out

[09:07:59.0879] <littledan>
so the wrapping is what happens inner to outer

[09:09:52.0924] <Justin Ridgewell>
ljharb: it'd need a queue, which is a very different design

[09:10:21.0126] <shu>
yeah

[09:10:21.0238] <ljharb>
a different design for who? spec/implementations, decorator authors, or decorator users?

[09:10:25.0948] <shu>
for the proposal itself

[09:10:28.0939] <Justin Ridgewell>
I think the order of setters is correct, because this would be how it'd behave if you manually wrapped a class method

[09:10:44.0216] <shu>
for all stakeholders you list

[09:10:46.0884] <Justin Ridgewell>
Also, the order of getters is correct (as discussed earlier)

[09:11:13.0190] <HE Shi-Jun>
This issue is complex... I'm not sure I fully understand the issue and the consequences of each solution... 

[09:11:39.0265] <shu>
like, i don't think of any use case for multiple decorators, legacy or standard, is "accumulate into a list, which is evaluated (setters, getters, initializers) in order later"

[09:11:55.0232] <shu>
if that is the model you think it ought to be, that's a redesign

[09:13:09.0585] <ljharb>
`const timesTwo = x => x * 2; const minusFour = x => x - 4; const wrapped = x => minusFour(timesTwo(x));` is what i'd expect

[09:13:10.0704] <shu>
IOW, mental model of decorators is _replacement_, so if you want multiple decorators to apply, you need to make a new wrapper that calls the old one

[09:13:13.0713] <rbuckton>
As littldan said, decorators are like layers. You pass a value down through the layers when setting, and bring it back up through the layers when getting. So for `@A @B x`, setting traverses `-> A -> B -> x`, and getting traverses `<- A <- B <- x`.

[09:13:24.0493] <rbuckton>
 * Similar to what @littldan said, decorators are like layers. You pass a value down through the layers when setting, and bring it back up through the layers when getting. So for `@A @B x`, setting traverses `-> A -> B -> x`, and getting traverses `<- A <- B <- x`.

[09:13:36.0885] <shu>
it sounds like your mental model of decorators is _linear list of hooks_

[09:13:38.0960] <shu>
which is not what it is

[09:14:33.0778] <nicolo-ribaudo>
Note that the _order of operations_ is different from _order of function calls_. Setters change the value before passing it to the next setter, while getters replace it after that it has been received by the next getter

[09:14:45.0353] <rbuckton>
eemeli: yes, there are a lot of use cases for multiple decorators on an item. far too many to introduce this limitation, imo.

[09:14:54.0172] <rbuckton>
 * eemeli: yes, there are a lot of use cases for multiple decorators on an item. far too many to introduce that limitation, imo.

[09:15:14.0258] <nicolo-ribaudo>
Also chairs I'm travelling and I don't have a good connection, if when it's my turin in TCQ I don't reply please let other people go ahead

[09:15:40.0175] <nicolo-ribaudo>
 * Note that the _order of operations_ is different from _order of function calls_. Setters change the value before passing it to the next setter, while getters replace it after that it has been received by the next getter (so same order of function calls implies opposite order of transforms)

[09:15:56.0651] <nicolo-ribaudo>
 * Also chairs I'm travelling and I don't have a good connection, if when it's my turn in TCQ I don't reply please let other people go ahead

[09:16:50.0451] <Justin Ridgewell>
nicolo-ribaudo: Would an `init()` change the order of the calls?

[09:17:37.0437] <Justin Ridgewell>
Like, it seem the same as if we just `inits.reverse()` in the spec?

[09:18:04.0365] <nicolo-ribaudo>
> <@jridgewell:matrix.org> nicolo-ribaudo: Would an `init()` change the order of the calls?

Having
```js
init(v) {
  nextInit(v * 2)
}
```
would allow having the same order of function calls as `set()` _and_ the same order of transforms

[09:18:05.0298] <Justin Ridgewell>
We'd still have a queue of decorator inits that need to run in some order.

[09:18:13.0955] <nicolo-ribaudo>
Because it transforms the parameter rather than the return value

[09:18:19.0150] <nicolo-ribaudo>
 * Because it transforms the input parameter rather than the return value

[09:19:29.0134] <Justin Ridgewell>
I don't think that's the case?

[09:20:26.0583] <Justin Ridgewell>
The reason set order happens is because there's a defined starting point (the thing that's exposed to the user of the class)

[09:20:30.0460] <rbuckton>
> <@nicolo-ribaudo:matrix.org> Having
> ```js
> init(v) {
>   nextInit(v * 2)
> }
> ```
> would allow having the same order of function calls as `set()` _and_ the same order of transforms

You would need to be sure to call `nextInit` with `this`, or you'd end up with an error.

[09:20:47.0589] <nicolo-ribaudo>
Well you already have that requirement with `set` and `get`

[09:21:22.0578] <rbuckton>
Yes, but you don't with `init` currently.

[09:21:33.0711] <Justin Ridgewell>
The `init` isn't exposed to the user, so there's not a defined order

[09:22:07.0915] <rbuckton>
As I understand it, engines didn't want to thunkify the initializer.

[09:23:28.0951] <shu>
i don't quite remember the exact pushback

[09:24:08.0887] <shu>
oh, like, per-field, we don't want a per-field initializer function

[09:24:21.0126] <nicolo-ribaudo>
> <@shuyuguo:matrix.org> oh, like, per-field, we don't want a per-field initializer function

Yep, that's it

[09:24:40.0255] <nicolo-ribaudo>
Every decorated field would need to have its own initializer function with my proposal

[09:27:50.0867] <Bradford Smith>
Suggestion for fuller explanation: Decompose what happens into individual `Object.defineProperty()` calls in the order they would execute.

[09:30:21.0814] <rbuckton>
> <@bradfordcsmith:matrix.org> Suggestion for fuller explanation: Decompose what happens into individual `Object.defineProperty()` calls in the order they would execute.

IIRC, and from implementation, only a single defineProperty is called at the end. You need to show how the wrapping occurs, and step through the wrapped functions.

[09:40:24.0335] <rbuckton>
ljharb: only assigning due to dynamic evaluation seems the opposite of what implementers want. IIRC, for the class to have a stable shape resulting from its declaration, then `[Symbol.metadata]` must be defined due to syntax, not dynamic evaluation.

[09:40:37.0252] <bakkot>
shu:

```
class A {}

[09:40:52.0519] <bakkot>
 * shu:

```
class A {}
class B extends A {} // gets A[symbol.metadata], goes to F.prototype
```

[09:40:59.0054] <shu>
yes, okay, 

[09:41:00.0379] <ljharb>
> <@rbuckton:matrix.org> ljharb: only assigning due to dynamic evaluation seems the opposite of what implementers want. IIRC, for the class to have a stable shape resulting from its declaration, then `[Symbol.metadata]` must be defined due to syntax, not dynamic evaluation.

true, but that means that decorated classes *now* will suddenly start getting a metadata object

[09:41:01.0403] <shu>
thanks

[09:44:12.0165] <rbuckton>
> <@ljharb:matrix.org> true, but that means that decorated classes *now* will suddenly start getting a metadata object

Are there any shipping implementations of native decorators where that would be a problem? TS and Babel have downlevel implementations, but since this is only recently shipping I have less of a concern for this being a problem for our users.

[09:45:45.0951] <rbuckton>
> <@ljharb:matrix.org> true, but that means that decorated classes *now* will suddenly start getting a metadata object

 * Are there any shipping implementations of native decorators where that would be a problem? TS and Babel have downlevel implementations, but since this is only recently shipping I have less of a concern for this being a problem for our (TS) users.

[09:46:50.0407] <nicolo-ribaudo>
Babel's implementation requires users to explicitly specify the date of the TC39 meeting (YYYY-MM) that they want Babel to comply with (there were too many changes to do otherwise 😬), so I'm not concerned of this type of breaking changes

[10:55:10.0904] <littledan>
I think the error rate was particularly high in the second hour of the morning, and ljharb noted similarly. I contacted Duane, the owner of the captioning service, and the person who was on during that time block won’t end up repeating for the rest of this meeting; it will be shared by the same two people so they should be able to learn and improve over time. Please be like ljharb and send me any feedback about the notes so I can collect it and ensure it reaches the transcription service.

[10:58:35.0123] <littledan>
> <@ljharb:matrix.org> true, but that means that decorated classes *now* will suddenly start getting a metadata object

Honestly I've been thinking of the decorators proposal as work-in-progress until the metadata part is done. So to me this isn't as much of a case of changing what is already out there.

[10:59:44.0232] <Rob Palmer>
Plenary is restarting... now

[11:03:56.0582] <littledan>
About this presentation, I'd sort of like to discuss both topics together before drawing a conclusion

[11:04:15.0249] <littledan>
fine to discuss one first in between of course, just for concluding

[11:07:55.0066] <HE Shi-Jun>
It seems option 1 is more consistent to current iterator behavior?

[11:09:38.0173] <littledan>
I believe the transcription quality is higher this time than last time

[11:16:07.0446] <bakkot>
littledan: "with fallback only on undefined" - do you mean and _not_ null? Symbol.iterator uses undefined or null

[11:16:13.0823] <bakkot>
(because it goes via GetMethod)

[11:18:02.0638] <Bradford Smith>
Aren't iterators always supposed to meet the requirement that `myIterator[Symbol.iterator]() === myIterator` ? Doing this fallback at all seems weird to me.

[11:20:43.0765] <bakkot>
Bradford Smith: nothing in the language expresses that requirement today, and user-implemented iterators IME usually don't

[11:21:29.0384] <bakkot>
and the main place this fallback comes up is in `Iterator.from`, which is specifically for taking a userland iterator and getting something which inherits from Iterator.prototype; we want to accept the user iterators people are writing today

[11:21:56.0103] <littledan>
> <@bakkot:matrix.org> littledan: "with fallback only on undefined" - do you mean and _not_ null? Symbol.iterator uses undefined or null

Oops yeah my mistake for trying to correct notes and participate at the same time

[11:22:00.0320] <Bradford Smith>
Interesting. I'm pretty sure closure-compiler's transpilatoin of for-of and similar things relies on `myIterator[Symbol.iterator]() === myIterator`

[11:22:16.0967] <Bradford Smith>
I don't think we check for a `next()` method

[11:22:34.0992] <littledan>
> <@bradfordcsmith:matrix.org> Aren't iterators always supposed to meet the requirement that `myIterator[Symbol.iterator]() === myIterator` ? Doing this fallback at all seems weird to me.

well yeah we're talking about iterables (anyway that is more a convention than a requirement)

[11:22:57.0946] <bakkot>
Bradford Smith: for-of takes iterables, not iterators, so I don't think it comes up?

[11:23:16.0075] <bakkot>
like the way you work with iterators is always "call the Symbol.iterator method, and then call `next` on the result"

[11:23:19.0144] <Bradford Smith>
I thought it was a requirement that all iterators are also iterables

[11:23:42.0727] <bakkot>
nothing depends on or expresses that requirement

[11:25:25.0900] <HE Shi-Jun>
Michael Ficarra: Not sure I explained myself clear, I expect we can define a protocol which only have accessors which returns normal value, for example `obj[ProtocolA.x] // normal value`. 

[11:25:59.0886] <Bradford Smith>
So then `Iterator.from(x)` first tries to treat`x` as an iterable, then falls back to treating it as an iterator, which doesn

[11:26:16.0033] <Bradford Smith>
 * So then `Iterator.from(x)` first tries to treat`x` as an iterable, then falls back to treating it as an iterator, which doesn't happen to have a `Symbol.iterator`

[11:29:06.0514] <bakkot>
correct

[11:29:59.0438] <bakkot>
all the iterators _in the language_ (and the web platform / node, and those produced by generators) have the property that `myIterator[Symbol.iterator]() === myIterator`, so that should work for everything

[11:30:13.0564] <bakkot>
unless you go out of your way to make an iterator which _does_ have a `Symbol.iterator` which is not just `this`, in which case, that's on you

[11:33:51.0331] <HE Shi-Jun>
I will support failing early if we can "fix" `let [] = {[Symbol.iterator](){return {}} }` case...

[11:39:19.0404] <bakkot>
I think option 2 not closing is actually pretty bad

[11:39:42.0383] <bakkot>
well

[11:39:45.0303] <bakkot>
a little bad anyway

[11:43:36.0903] <Michael Ficarra>
bakkot: but it never "opens" either

[11:43:51.0513] <bakkot>
fair

[11:44:04.0014] <bakkot>
at least in the case that you're passing a multiple-shot-iterator

[11:44:09.0256] <bakkot>
 * at least in the case that you're passing a multiple-shot iterable

[11:45:31.0787] <bakkot>
but not in the case that you're passing an iterator:
```
function* gen(){ yield 0; }
let it = gen();
[] = it; // close gen
console.log(it.next().done); // true
```

[11:45:49.0156] <bakkot>
it is weird for the "close gen" thing to happen if you have `[x] = it` but not `[] = it`

[11:46:00.0896] <ljharb>
why? if it hasn't touched it why would it need to close it

[11:46:52.0536] <rbuckton>
> <@ljharb:matrix.org> why? if it hasn't touched it why would it need to close it

Consistency with pattern matching? 

[11:47:10.0256] <rbuckton>
A pattern like `[]` is exhaustive, thus will close the iterator.

[11:47:13.0945] <ljharb>
pattern matching is still stage 1 and i would assume it would just follow whatever is decided here

[11:47:15.0443] <rbuckton>
 * A match pattern like `[]` is exhaustive, thus will close the iterator.

[11:47:24.0354] <ljharb>
ah, hmm

[11:47:52.0386] <rbuckton>
> <@ljharb:matrix.org> pattern matching is still stage 1 and i would assume it would just follow whatever is decided here

It can't if array patterns are exhaustive

[11:48:11.0658] <littledan>
My main feeling is, it doesn't seem worth it to change existing things, and 3 and 4 both seem reasonable to me

[11:48:11.0793] <ljharb>
yeah that kind of falls out of the weirdness of having destructuring not be exhaustive by default, and pattern matching be by default

[11:48:28.0069] <rbuckton>
That said, a match pattern of `[]` will call `next()` at least once

[11:48:38.0006] <ljharb>
ah yes, that's true

[11:49:36.0584] <rbuckton>
Actually, I honestly don't know if pattern matching informs whether empty array destructuring patterns should close. There's enough of a difference that we could go either way.

[11:54:31.0918] <HE Shi-Jun>
Sorry, could anyone write a simple example to explain the observable diff between option 2 and 3?

[11:54:36.0794] <ljharb>
(fwiw i don't think the animal names are necessarily consistent across users)

[11:54:51.0748] <ljharb>
 * (fwiw i don't think the animal names are necessarily consistent across users, but i haven't tested thoroughly)

[11:54:58.0307] <shu>
principle: always be vibin'

[12:05:23.0892] <Michael Ficarra>
can someone who maintains TCQ make it so the reply / new topic / clarifying question / PoO buttons take effect immediately when pressed and then you can enter the topic later?

[12:05:35.0803] <Michael Ficarra>
I'm tired of writing out a topic in the reply just for us to move on :-(

[12:06:09.0756] <ljharb>
bakkot: https://github.com/search?q=language%3Ajavascript+grouptoobject&type=code

[12:06:49.0874] <bakkot>
sorry I meant as a property name specifically

[12:06:50.0623] <bakkot>
but yes

[12:06:56.0544] <bakkot>
I see one or two there

[12:07:01.0368] <bakkot>
 * I see one or two there which are properties

[12:07:17.0491] <Michael Ficarra>
someone claimed "group" was sufficiently obscure? what?

[12:07:42.0349] <HE Shi-Jun>
> <@ljharb:matrix.org> bakkot: https://github.com/search?q=language%3Ajavascript+grouptoobject&type=code

I see two or three obj.groupToObject and prototype.groupToObject ... 😅

[12:07:57.0267] <ljharb>
in there i see `Group.prototype.toObject` but no `prototype.groupToObject`?

[12:08:05.0298] <ljharb>
either way only 64 results on github is astonishingly rare

[12:08:56.0523] <shu>
yo i have an idea

[12:09:04.0218] <HE Shi-Jun>
What about the static methods? No need to worry the web compat issue.

[12:09:19.0487] <bakkot>
in this particular case I'm fine with static methods

[12:09:27.0581] <bakkot>
but I can imagine having other methods in the future

[12:09:33.0180] <bakkot>
e.g. I would really like a "sortBy"

[12:09:40.0477] <bakkot>
even though it unfortunately cannot be called that probably

[12:09:47.0746] <bakkot>
and it would be a huge shame for that to be static

[12:10:10.0547] <shu>
what if we change the identifier grammar such that there's some prefix of code units that doesn't parse for assignments and only parse for get (might need runtime errors too i guess)

[12:10:34.0795] <shu>
 * what if we change the <del>identifier</del> property name grammar such that there's some prefix of code units that doesn't parse for assignments and only parse for get (might need runtime errors too i guess)

[12:11:49.0663] <Willian Martins>
Would it be possible to add it inside iterable helpers?

[12:12:23.0823] <HE Shi-Jun>
> <@wmartins:matrix.org> Would it be possible to add it inside iterable helpers?

As I understand, it will be a different proposal, might have differnt semantic.

[12:12:25.0491] <Bradford Smith>
Wouldn't it be `Object.groupBy()` since it returns an object?

[12:12:43.0077] <ljharb>
yeah i actually was thinking that too

[12:13:06.0437] <Michael Ficarra>
Willian Martins: no, we cannot fit a possibly infinite structure into a finite structure

[12:13:16.0841] <bakkot>
https://github.com/tc39/proposal-array-grouping/issues/51#issuecomment-1372786948

[12:13:40.0768] <Willian Martins>
That makes sense. Thanks!

[12:13:42.0174] <bakkot>
> <@bradfordcsmith:matrix.org> Wouldn't it be `Object.groupBy()` since it returns an object?

that's what's in the PR, yeah: https://github.com/tc39/proposal-array-grouping/pull/47

[12:13:56.0594] <bakkot>
was something else proposed? I missed it if so

[12:16:52.0123] <ljharb>
i think a few of us just misspoke and said "Array.groupBy"

[12:17:02.0846] <bakkot>
ah cool

[12:17:04.0443] <HE Shi-Jun>
There are already some stage 1 proposals of Array.prototype methods. For example Array.prototype.unique

[12:18:55.0968] <Michael Ficarra>
the stage 3 proposal list isn't huge, it shouldn't take long to go through them

[12:19:09.0441] <Michael Ficarra>
https://github.com/tc39/proposals#stage-3

[12:22:12.0004] <littledan>
hey saminahusain !

[12:22:39.0807] <littledan>
Could someone with admin rights give Samina the Custom(10) rights to post here?

[12:24:16.0624] <saminahusain>
Ok, thanks

[12:25:36.0290] <ljharb>
fwiw the group PR has been rebased: https://github.com/tc39/proposal-array-grouping/pull/47 spec is here: https://raw.githack.com/tc39/proposal-array-grouping/static-method/index.html

[12:26:23.0840] <Justin Ridgewell>
> <@ljharb:matrix.org> i think a few of us just misspoke and said "Array.groupBy"

Yup, I meant `Object.groupBy`

[12:59:13.0269] <pzuraq>
does anyone know how to say "if a List has at least one item" in spec?

[12:59:19.0866] <pzuraq>
 * does anyone know how to say "if a List has at least one element" in spec?

[12:59:24.0092] <pzuraq>
does that statement work?

[13:00:18.0060] <ljharb>
"if a List is not empty"?

[13:01:01.0164] <ljharb>
we're at time so i need to hop off

[13:02:14.0408] <Michael Ficarra>
yeah you want "is not empty"

[13:02:40.0333] <Michael Ficarra>
pzuraq: might want to ask these questions in #tc39-editors:matrix.org next time

[13:03:57.0299] <shu>
what is happening

[13:04:14.0217] <shu>
are we, as tc39 delegates, able to confer IPR protection by forming a TG?

[13:04:20.0635] <bakkot>
I had to step away and did not capture speakers for the last few minutes

[13:04:21.0748] <shu>
like that's cool if we are

[13:04:27.0234] <bakkot>
please could people edit that into the notes

[13:04:29.0934] <bakkot>
if you remember who said what

[13:05:30.0094] <msaboff>
littledan: Since you fit this into a shorter time slot, you could bring this back as overflow later in this meeting for TG4 creation consensus.  

[13:05:58.0473] <Michael Ficarra>
littledan: we will also have to assign chairs and (when we get approval for a new document) assign an editor group

[13:06:07.0551] <msaboff>
> <@shuyuguo:matrix.org> are we, as tc39 delegates, able to confer IPR protection by forming a TG?

If we create the TG, I think we can.

[13:06:47.0188] <shu>
msaboff: how does the transfer of the existing source maps document work?

[13:07:22.0981] <shu>
or is the idea that we start with safeguarding newly produced IP by forming a new TG within which to produce new IP, then do the transfer and merge later with the existing doc?

[13:07:47.0613] <msaboff>
Not totolly sure, but if all the participants are Ecma members it should be straightforward .

[13:07:53.0650] <msaboff>
 * Not totally sure, but if all the participants are Ecma members it should be straightforward .

[13:08:08.0209] <littledan>
yeah the doc was written by Mozilla + Google so it should be fine

[13:08:08.0218] <shu>
huh, interesting

[13:08:16.0510] <shu>
that's cool

[13:09:32.0054] <littledan>
I'm vaguely sympathetic with the idea that we shouldn't jump straight into making a TG prematurely, but at the same time, adopting liberal IPR policy isn't the "too fast" part--it's really the only option for a modern open standard IMO.

[13:09:48.0409] <littledan>
> <@msaboff:matrix.org> littledan: Since you fit this into a shorter time slot, you could bring this back as overflow later in this meeting for TG4 creation consensus.

Thanks, yeah, I'd like to do this

[13:10:13.0577] <littledan>
> <@michaelficarra:matrix.org> littledan: we will also have to assign chairs and (when we get approval for a new document) assign an editor group

I'd like to nominate myself as chair :) I'm optimistic that we'll have volunteers for editor as soon as I raise it.

[13:11:37.0957] <littledan>
> <@msaboff:matrix.org> If we create the TG, I think we can.

I believe so too. At the same time, this IPR protection only really kicks in once we publish a standard (that's what the opt out period is for)

[13:13:42.0082] <msaboff>
littledan: I think just as long as those that participated in the current draft release any claim on IP.  If it is only Google and Mozilla, that shouldn't be an issue.

[13:15:14.0395] <littledan>
I think it should be fine for us to collaborate on a draft with all the same legal theories that we use to participate in drafting the ECMA-262 spec

[14:11:41.0461] <littledan>
also note that the current source map spec is CC-licensed

[14:31:52.0568] <Ashley Claymore>
> <@michaelficarra:matrix.org> `const isConstructor = (a) => { if (Object(a) !== a) { return false; } try { Promise.prototype.finally.call({ constructor: { [Symbol.species]: a }, then(){} }); } catch { return false; } return true; };`

are Proxies allowed?

```
function isConstructor(f) {
  let v = false;
  try {
    Reflect.construct(new Proxy(f, {
       construct() { v = true; }
    }), []);
  } catch() {};
  return v;
}
```

[14:43:27.0950] <pzuraq>
bakkot spec has been updated: https://github.com/pzuraq/ecma262/pull/10/files

[14:47:57.0861] <littledan>
> <@pzura:matrix.org> bakkot spec has been updated: https://github.com/pzuraq/ecma262/pull/10/files

I love how small this specification is. It makes me feel like we got it right.

[14:48:22.0498] <ljharb>
> <@aclaymore:matrix.org> are Proxies allowed?
> 
> ```
> function isConstructor(f) {
>   let v = false;
>   try {
>     Reflect.construct(new Proxy(f, {
>        construct() { v = true; }
>     }), []);
>   } catch() {};
>   return v;
> }
> ```

i still would love one that doesn't require ES6 but i don't think there is one :-/

[14:48:54.0368] <pzuraq>
> <@littledan:matrix.org> I love how small this specification is. It makes me feel like we got it right.

I should've listened to you in the beginning, we definitely over designed it at first 😅

[14:48:58.0284] <pzuraq>
but we got there eventually

[14:49:31.0807] <littledan>
the final design is simpler than what I initially proposed

[14:49:38.0195] <littledan>
a lot simpler

[15:05:44.0636] <Kris Kowal>
I’m wondering whether decorators for derived classes are likely to continue to function if the `Symbol.metadata` of the base class is frozen. But more importantly, hoping there’s somewhere I can putter to find out.

[15:20:31.0077] <Ashley Claymore>
> <@pzura:matrix.org> bakkot spec has been updated: https://github.com/pzuraq/ecma262/pull/10/files

I like how `Function prototype @@metadata` is `null`. Good hole to plug.

[15:21:54.0782] <Ashley Claymore>
(And non configurable)

[15:24:10.0199] <Ashley Claymore>
> <@kriskowal:matrix.org> I’m wondering whether decorators for derived classes are likely to continue to function if the `Symbol.metadata` of the base class is frozen. But more importantly, hoping there’s somewhere I can putter to find out.

Maybe we fix the overrride mistake but only for metadata objects? 😎

[15:25:36.0733] <Kris Kowal>
> <@aclaymore:matrix.org> Maybe we fix the overrride mistake but only for metadata objects? 😎

The derived metadata inherits prototypically from the base metadata?

[15:29:57.0880] <ljharb>
yes

[15:30:06.0052] <ljharb>
indeed i think it applies the same way here

[15:38:05.0420] <Kris Kowal>
That seems okay to me.

[15:38:45.0759] <Kris Kowal>
It’s the devil we know, any any case, and I imagine there will be herding behaviors to promote composition of unrelated decorators, favoring disjoint gensyms on metadata when possible.

[15:39:28.0938] <Kris Kowal>
 * It’s the devil we know, any any case, and I imagine there will emerging convergent behaviors to promote composition of unrelated decorators, favoring disjoint gensyms on metadata when possible.


2023-05-17
[08:01:04.0024] <bakkot>
morning all

[08:01:06.0933] <bakkot>
and/or whatever time it is

[08:01:08.0917] <Rob Palmer>
Plenary is starting now!

[08:01:24.0730] <Rob Palmer>
Please join to find out if TC39 will approve ES2023

[08:01:53.0731] <littledan>
I hope it gets approved 😬

[08:02:20.0562] <littledan>
please vote yes 🥺

[08:35:04.0178] <littledan>
Frank's comments are generally talking in terms of various absolutes which I think are too strong

[08:51:23.0992] <Chris de Almeida>
we need to clean up the notes for the conclusion of ZDT stage 1

[08:51:44.0221] <littledan>
I wrote a conclusion right under the heading; now writing main points

[08:51:49.0186] <littledan>
(not deleting the raw notes just yet)

[08:52:30.0849] <Kris Kowal>
ptomato: Is there any risk that zone date time formatting might require a temporal constructor to close over host data? At Agoric, we’ve enjoyed the separability of now() from temporal constructors and hope for that trend to continue.

[08:52:51.0502] <Chris de Almeida>
thanks for your hard work on the notes, Dan!  really appreciate it.  time at a premium today, so needed to  move

[08:56:21.0376] <ptomato>
> <@kriskowal:matrix.org> ptomato: Is there any risk that zone date time formatting might require a temporal constructor to close over host data? At Agoric, we’ve enjoyed the separability of now() from temporal constructors and hope for that trend to continue.

I think this is safe, Temporal constructors still don't close over any host data. FWIW you can currently already format `Temporal.ZonedDateTime` with its `toLocaleString` method; you just can't cache the expensive operations by creating a formatter object to format multiple `ZonedDateTime`, and you can't `formatRange` or `formatToParts`, so that's what this proposal is solving.

[08:56:30.0097] <ptomato>
`Intl.DateTimeFormat` does close over host data, because if you construct it without a `timeZone` parameter then it internally assumes the host's current time zone, but that's a long-preexisting problem and I'm assuming you're not referring to that

[08:57:35.0275] <ptomato>
my preferred solution would actually remove that closing over host data in the case of ZonedDateTime. (in other cases, it wouldn't be web-compatible to change that)

[09:08:04.0828] <bakkot>
I do not like "eliminates the need for developers to understand higher-order functions" as a motivation for design decisions

[09:08:08.0078] <bakkot>
I really really do not like it

[09:08:20.0021] <littledan>
I think we should avoid subclassing AsyncSnapshot... it's confusing for these examples

[09:08:31.0643] <littledan>
this is a has-a relation, not a is-a

[09:09:38.0161] <Justin Ridgewell>
```
const snapshot = new AsyncSnapshot();
snapshot.run(cb, arg1, arg2);
```

[09:09:45.0467] <Justin Ridgewell>
That's how I would normally use it.

[09:28:16.0056] <Willian Martins>
Do you have the Task attribution link? I don't know the scope of this api.

[09:28:28.0760] <Chris de Almeida>
https://docs.google.com/document/d/1_m-h9_KgDMddTS2OFP0CShr4zjU-C-up64DwCrCfBo4/edit#heading=h.pny1oyazzdg0

[09:29:03.0241] <Chris de Almeida>
https://bit.ly/task-attribution   friendly link

[09:30:48.0980] <Justin Ridgewell>
Termination is https://github.com/tc39/proposal-async-context/issues/52

[09:30:55.0333] <Justin Ridgewell>
It's still WIP, and not proposed to be added yet

[09:50:34.0224] <ryzokuken>
https://notes.igalia.com/p/TWx5MikWg

[09:50:59.0970] <Andreu Botella>
> <@usharma:igalia.com> https://notes.igalia.com/p/TWx5MikWg

I think that's not visible publicly

[10:24:02.0236] <ryzokuken>
> <@abotella:igalia.com> I think that's not visible publicly

Should be fixed now

[11:14:33.0797] <littledan>
There's a reason why the W3C broke off from IETF--to not deal with this bureaucracy. (And then WHATWG broke off from W3C for the same reason...)

[11:14:53.0810] <littledan>
We don't realize how lucky we are bureaucracy-wise!

[11:16:08.0117] <shu>
"You are now DAC, the do anything committee"

[11:17:58.0025] <Chris de Almeida>
it's oddly non-bureaucratic in certain ways as well.. IETF WGs are `mailing list all the things` and consensus, no voting, no memberships, etc

[11:18:12.0593] <Michael Ficarra>
the default state of being is no bureaucracy; these organisations do this to themselves

[11:18:22.0364] <Chris de Almeida>
but IESG gatekeeping...

[11:42:37.0265] <Kris Kowal>
chipmorningstar and I’ve been ruminating a procedural question regarding the staging process. It’s our understanding that a canonicalization proposal must be preceded by a beatification proposal. Did we miss something?

[11:44:26.0442] <ptomato>
the syntax of IANA time zone identifiers:
> Use only valid POSIX file name components (i.e., the parts of names other than `/`). Do not use the file name components `.` and `..`. Within a file name component, use only ASCII letters, `.`, `-` and `_`. Do not use digits, as that might create an ambiguity with POSIX TZ strings. A file name component must not exceed 14 characters or start with `-`.

[11:46:15.0137] <ptomato>
(but then there are a few legacy aliases in the TZDB that don't follow these rules)

[12:05:20.0860] <Michael Ficarra>
I like `Promise.create`!

[12:05:38.0986] <shu>
creat pls

[12:06:51.0050] <HE Shi-Jun>
But `Promise.create` will have very different api with `Object.create`?

[12:07:05.0187] <Michael Ficarra>
... so?

[12:07:29.0539] <Chris de Almeida>
`Promise.create` does have baked in anti-bikeshedding...

[12:07:37.0786] <HE Shi-Jun>
I expect the same method name would have similar api.

[12:08:05.0519] <shu>
i regret to inform you there are only a few good english words

[12:08:35.0258] <ptomato>
what. `Promise.embiggen` is a perfectly cromulent option

[12:08:37.0536] <nicolo-ribaudo>
Promise.deconstructed

[12:08:44.0051] <nicolo-ribaudo>
Promise.unpacked

[12:08:48.0776] <Michael Ficarra>
hey hey hey take it to TDZ

[12:08:59.0136] <Chris de Almeida>
> <@pchimento:igalia.com> what. `Promise.embiggen` is a perfectly cromulent option

winner right here

[12:08:59.0619] <HE Shi-Jun>
Personally I prefer Promise.deferred 

[12:10:28.0488] <Justin Ridgewell>
Ditto, I want `deferred`

[12:10:38.0649] <Kris Kowal>
Rejection is resolution.

[12:10:52.0665] <Chris de Almeida>
https://github.com/tc39/proposal-promise-with-resolvers/issues/2

[12:11:00.0427] <Chris de Almeida>
bikeshedding thread ☝️

[12:11:06.0759] <Justin Ridgewell>
The precedent is strong: https://github.com/tc39/proposal-promise-with-resolvers/issues/2#issuecomment-1483909052

[12:11:17.0702] <HE Shi-Jun>
It's always misunderstanding what "resolve" means in the community

[12:11:34.0423] <Kris Kowal>
ljharb: Indeed! Resolve can defer, fulfill, or reject!

[12:11:48.0260] <Chris de Almeida>
preference for `embiggen` but will settle for `deferred`

[12:11:53.0250] <ryzokuken>
we need to resolve the meaning of resolve

[12:12:06.0190] <ljharb>
lol i suppose it could be "fulfillers" or something

[12:12:10.0753] <Rob Palmer>
Resolve, fulfill and other promising terminology is clarified in [States and Fates.](https://github.com/domenic/promises-unwrapping/blob/master/docs/states-and-fates.md)

[12:12:34.0829] <ryzokuken>
`Promise.unwrap`

[12:13:02.0157] <Kris Kowal>
I’m not even sure how far back `Q.defer()` goes. It may have gone back to Q from Tyler Close’s Waterken, but it may have started with my work.

[12:13:23.0147] <Kris Kowal>
My reasoning was that `Q.defer() => Deferred`

[12:13:33.0147] <HE Shi-Jun>
> <@softwarechris:matrix.org> preference for `embiggen` but will settle for `deferred`

I guess many non-native speakers (like me) don't know the word...

[12:13:52.0136] <HE Shi-Jun>
> <@softwarechris:matrix.org> preference for `embiggen` but will settle for `deferred`

 * I guess many non-native speakers (like me) don't know the word `embiggen`...

[12:13:58.0387] <rbuckton>
IIRC, JQuery started with `defer` as well

[12:14:08.0747] <danielrosenwasser>
`Promise.withLifecycle`

[12:14:10.0747] <Andreu Botella>
(It's a joke from The Simpsons, it's not an actual English word)

[12:14:13.0632] <ljharb>
it's not a real word, it's a Simpsons reference (that's kind of become a real word)

[12:14:34.0896] <shu>
it is an actual english word _now_

[12:14:50.0584] <Kris Kowal>
It does indeed go back to Tyler Close’s Waterken ref_send/web_send library https://waterken.sourceforge.net/web_send/

[12:15:04.0964] <danielrosenwasser>
https://www.merriam-webster.com/dictionary/embiggen

:)

https://www.merriam-webster.com/dictionary/cromulent

:(

[12:15:33.0795] <HE Shi-Jun>
> <@robpalme:matrix.org> Resolve, fulfill and other promising terminology is clarified in [States and Fates.](https://github.com/domenic/promises-unwrapping/blob/master/docs/states-and-fates.md)

Unfortunately some libraries (like jQuery) not follow it many years

[12:16:00.0541] <ljharb>
i declare shenanigans

[12:16:02.0637] <rbuckton>
From the reading I've done, it seems like the ecosystem migration from `.defer()` to `new Promise` was due to the executor being safer as it could capture an unexpected exception and reject the promise. That meant that `new Promise` was a _better_ API for the more common use cases, not that `.defer()` in and of itself was a _bad_ API.

[12:16:30.0127] <Kris Kowal>
Waterken’s use of defer() goes back to 2004.

[12:16:33.0257] <bakkot>
I kinda liked `Promise.capability`, but possibly only because I'm familiar with that name from the spec using it

[12:16:34.0087] <rbuckton>
So it seems like this almost exactly matches how `.defer()` was used in Q and JQuery.

[12:17:27.0845] <bakkot>
(`Promise.withResolvers` also seems fine)

[12:17:30.0746] <ljharb>
in jquery the promise itself had resolve and reject methods on it

[12:17:34.0388] <bakkot>
(`Promise.defer` seems somewhat less fine)

[12:17:35.0864] <ljharb>
 * in jquery the promise itself had resolve and reject methods on it, so i don't think that's a match

[12:17:42.0447] <Michael Ficarra>
`defer` implies something time-based to me, akin to `setTimeout`

[12:17:45.0481] <Andreu Botella>
let's do `Promise.bikeshed`

[12:17:53.0388] <Kris Kowal>
@bakkot `Promise.caps` would be more apropos. The original idea is that the read-cap and write-cap could be distributed to different parties.

[12:18:07.0951] <ljharb>
"cap" reads to me as a hat, not short for "capability" :-p

[12:18:08.0219] <rbuckton>
And I'm probably not the only one that's called the same functionality `defer` or `deferred` in my own code and in npm packages (i.e., https://www.npmjs.com/package/@esfx/async-deferred though that exports a class called `Deferred`)

[12:18:18.0140] <bakkot>
`cap` means `lie` actually

[12:18:22.0155] <ljharb>
nope https://npmjs.com/promise-deferred

[12:18:23.0639] <danielrosenwasser>
> <@ljharb:matrix.org> "cap" reads to me as a hat, not short for "capability" :-p

no cap

[12:18:25.0281] <bakkot>
 * `cap` means "lie" actually

[12:18:28.0940] <Chris de Almeida>
FALSE.  it's a real word

[12:18:38.0303] <Kris Kowal>
> <@rbuckton:matrix.org> And I'm probably not the only one that's called the same functionality `defer` or `deferred` in my own code and in npm packages (i.e., https://www.npmjs.com/package/@esfx/async-deferred though that exports a class called `Deferred`)

Not the distinction I beg :-)

[12:18:38.0323] <Chris de Almeida>
stop gatekeeping

[12:18:48.0675] <Andreu Botella>
`Promise.gatekeep`

[12:19:05.0790] <nicolo-ribaudo>
If we end up going with defer, ideas for alternative names for https://github.com/tc39/proposal-defer-import-eval/ are welcome :P

[12:19:34.0171] <bakkot>
see that's the normal thing that `defer` means

[12:19:41.0128] <shu>
> <@danielrosenwasser:matrix.org> no cap

frfr

[12:19:46.0581] <Kris Kowal>
I am supportive of Promise.withResolvers(), and failing that, Promise.defer(). Of others I can be convinced. Really, just want the darn feature already.

[12:19:49.0397] <bakkot>
we should reserve the use of `defer` for its standard usage and find a different name here

[12:19:58.0735] <bakkot>
 * we should reserve the use of `defer` for its standard English usage and find a different name here

[12:20:18.0069] <Chris de Almeida>
NB: it was part of the ES promise proposal at one point, and was called `deferred`

[12:20:25.0202] <ryzokuken>
`Promise.deconstruct`

[12:20:46.0030] <ptomato>
that sounds like undoing what the Promise constructor does

[12:21:03.0733] <Bradford Smith>
Was I the only person who thought the plan was to have `import.source` for both static and dynamic import?

[12:21:10.0802] <Chris de Almeida>
well -- `Deferred` is the object returned from `Promise.defer()`

[12:21:28.0058] <Bradford Smith>
I thought part of the point was to fix syntax ambiguity.

[12:21:42.0480] <ljharb>
no, i thought the same

[12:22:19.0825] <ryzokuken>
> <@pchimento:igalia.com> that sounds like undoing what the Promise constructor does

well, that'd be `Promise.destruct` 😳

[12:22:33.0996] <ptomato>
true

[12:22:58.0815] <ljharb>
`Promise.gozer`

[12:24:04.0363] <ryzokuken>
> Derrida describes the task of deconstruction as the identification of metaphysics of presence. Metaphysics of presence is the desire for immediate access to meaning, the privileging of presence over absence.

half-joking here, but why not

[12:24:55.0413] <HE Shi-Jun>
I like meta method :)

[12:25:10.0181] <rbuckton>
Most `.withX` methods I've seen generally don't behave this way either. I normally expect it to mean "the same thing, but with something changed" or "this thing plus that other thing", such as `date.withCalendar` in Temporal: https://tc39.es/proposal-temporal/docs/plaindate.html#withCalendar

[12:25:29.0847] <Andreu Botella>
`Promise.meta.url`

[12:25:31.0691] <bakkot>
or `with` on Array.prototype for that matter

[12:26:47.0975] <Michael Ficarra>
ljharb: just do `import source a from 'b'; const from = a;`

[12:27:33.0373] <ljharb>
or `import source { default as from } from 'b';`, sure. but it's awkward

[12:27:51.0329] <Michael Ficarra>
wait what that shouldn't work

[12:27:58.0840] <Michael Ficarra>
the unicode escape should be the same

[12:27:59.0012] <ljharb>
no?

[12:28:03.0381] <Michael Ficarra>
I think Luca is wrong here

[12:28:15.0629] <nicolo-ribaudo>
The spec right now uses "source text matched by"

[12:28:22.0621] <nicolo-ribaudo>
For the restriction

[12:28:46.0925] <Michael Ficarra>
why?

[12:28:55.0934] <bakkot>
> <@bakkot:matrix.org> or `with` on Array.prototype for that matter

but I think this is only really true for instance methods

[12:28:59.0818] <bakkot>
static methods are a different beast

[12:29:06.0872] <bakkot>
I don't think it's likely to be confusing

[12:29:14.0490] <nicolo-ribaudo>
> <@michaelficarra:matrix.org> why?

Tbh the reason is that he asked me how to do it and I didn't think about a lookahead restriction 😅

[12:29:19.0226] <rbuckton>
Have we considered source phase imports and export declarations? i.e., do we have to do
```js
import source x from "y";
export { x };
```
but can't do
```js
export source x from "y";
```
?

[12:29:34.0917] <ljharb>
that seems reasonable to do

[12:29:40.0840] <Michael Ficarra>
nicolo-ribaudo: we should def change it, that is something I would bring up during editorial review

[12:29:52.0343] <nicolo-ribaudo>
> <@rbuckton:matrix.org> Have we considered source phase imports and export declarations? i.e., do we have to do
> ```js
> import source x from "y";
> export { x };
> ```
> but can't do
> ```js
> export source x from "y";
> ```
> ?

I think it should be supported, but `export x from "x"` is currently invalid too

[12:30:15.0801] <HE Shi-Jun>
precedent: await.all ?

[12:30:19.0561] <rbuckton>
> <@nicolo-ribaudo:matrix.org> I think it should be supported, but `export x from "x"` is currently invalid too

Yes, but you *can* do `export { default as x } from "x";`

[12:30:39.0668] <nicolo-ribaudo>
> <@haxjs:matrix.org> precedent: await.all ?

Well that proposal didn't go very well last time it was presented if I recall correctly 

[12:30:44.0117] <Michael Ficarra>
`super.foo` and `super.foo()` are unrelated

[12:30:51.0981] <Michael Ficarra>
to each other

[12:30:55.0957] <bakkot>
those are very related!

[12:31:12.0104] <rbuckton>
Which is why I brought up the topic, if we did want `export source { default as x } from "y"`, then wouldn't we want `import source { default as x } from "y"`?

[12:31:47.0744] <nicolo-ribaudo>
Yeah I agree we should support the export from, it was even included in some slides I presented at some point I think 

[12:31:49.0795] <HE Shi-Jun>
> <@nicolo-ribaudo:matrix.org> Well that proposal didn't go very well last time it was presented if I recall correctly

yeah, so it's not the precednet , just similar tries...

[12:31:57.0183] <nicolo-ribaudo>
Maybe in the slides I presented on Monday

[12:32:04.0588] <rbuckton>
 * Which is why I brought up the topic. If we did want `export source { default as x } from "y"`, then wouldn't we want `import source { default as x } from "y"`?

[12:32:21.0887] <shu>
i dislike `import.source` in static imports personally

[12:32:35.0473] <shu>
it's treating symmetry between static and dynamic forms as a goal, whereas that's just a "nice to have" constraint imo

[12:32:49.0482] <Kris Kowal>
Strongly favor the proposal as presented today.

[12:33:00.0986] <shu>
the goal, as Guy said, is to have something that's nice to type, so people will type it, and get the nice static analysis guarantees from bundlers and toolings

[12:33:04.0216] <shu>
 * the goal, as Guy said, is to have something that's nice to type, so people will type it, and get the nice static analysis guarantees from bundlers and tooling

[12:33:29.0173] <ljharb>
sure

[12:33:43.0312] <ljharb>
i'm not sure `import source` and `import.source` are meaningfully different to type tho, and they're identical for static analysis

[12:33:58.0208] <ljharb>
obv if folks just straight up find it icky then that matters

[12:34:14.0040] <Chris de Almeida>
it does give some ick, tbf

[12:34:17.0480] <Kris Kowal>
I do find the `.` as indicative of dynamic.

[12:34:19.0035] <Justin Ridgewell>
We discussed LR1 in https://github.com/tc39/notes/blob/ace580d512db32624bd74b843e0d9757278753cd/meetings/2017-11/nov-29.md?plain=1#L303

[12:34:19.0764] <shu>
yeah to be clear i'm purely talking about subjective ickiness

[12:34:25.0200] <nicolo-ribaudo>
I find it ugly, but I don't have any technical reason against it

[12:34:47.0147] <ljharb>
and i'm perfectly content to accept that a number of folks find it icky :-) i just want to be clear in that case that that's the rationale, nothing technical

[12:35:08.0219] <Justin Ridgewell>
> <@shuyuguo:matrix.org> it's treating symmetry between static and dynamic forms as a goal, whereas that's just a "nice to have" constraint imo

This is actually a huge improvement for bundlers

[12:35:25.0537] <Justin Ridgewell>
https://matrix.to/#/!RkpmGMjJtqLKXzByOT:matrix.org/$a5LIDdkHQL28xkgFoGx8emGNcVNOEI4BejJWms32dG8?via=matrix.org&via=igalia.com&via=mozilla.org

[12:35:27.0939] <shu>
> <@jridgewell:matrix.org> This is actually a huge improvement for bundlers

oh interesting, so you're pro `import.source` in the static form?

[12:35:33.0595] <nicolo-ribaudo>
> <@jridgewell:matrix.org> This is actually a huge improvement for bundlers

Why do bundlers prefer a dot over a space?

[12:35:55.0143] <shu>
likei understand `import.static` for the _dynamic_ change is a big improvement for bundlers

[12:35:58.0759] <Justin Ridgewell>
No preference on whether dot or space, just the syntatic requirement

[12:35:59.0189] <shu>
 * likei understand `import.static` for the _dynamic_ form is a big improvement for bundlers

[12:36:10.0465] <shu>
why is it an improvement in the static case?

[12:36:21.0989] <ljharb>
being syntactic is a huge improvement for linters too :-)

[12:36:23.0048] <Justin Ridgewell>
It prevents accidental deoptimizations

[12:36:30.0544] <shu>
what?

[12:36:48.0799] <shu>
how can a static `import` deopt?

[12:37:00.0831] <Justin Ridgewell>
Having a dynamic `import("foo.js", attributesComputedAtRuntime)` would cause us to add a lot of extra code to handle phase imports

[12:37:08.0573] <bakkot>
I think you're talking past each other

[12:37:11.0789] <shu>
yes, that's the... dynamic case

[12:37:22.0922] <shu>
i am asking, how does `import.source` help the _static_ case

[12:37:24.0662] <Justin Ridgewell>
Static import can't depot, only the dynamic case

[12:37:39.0811] <Justin Ridgewell>
Oh, I thought you were reference the static syntax in dynamic import

[12:37:46.0438] <shu>
yes, so... again, how does `import.source` help bundlers in the _static_ import case

[12:37:59.0504] <Justin Ridgewell>
It doesn't

[12:38:16.0572] <shu>
okay, that matches my intuition, thanks

[12:38:48.0585] <Michael Ficarra>
I don't think anybody has made a case for `import.source` in the decl form other than "it matches", which is not strong IMO

[12:39:17.0091] <littledan>
Who made the +1 reply that we just went through?

[12:39:47.0595] <bakkot>
> <@michaelficarra:matrix.org> I don't think anybody has made a case for `import.source` in the decl form other than "it matches", which is not strong IMO

it avoids an ambiguity here, is the other reason

[12:40:07.0948] <HE Shi-Jun>
Note `import.source` also help to solve `import source \n from` ambiguity for module declarations (`module source {}`). 

[12:40:24.0415] <Michael Ficarra>
bakkot: not an actual ambiguity, an imagined one

[12:41:43.0619] <Michael Ficarra>
I completely agree with Guy here, we don't need to worry about future syntax for this

[12:41:49.0296] <shu>
yeah

[12:41:50.0346] <littledan>
apologies for creating the confusion about `from`

[12:47:06.0701] <Kris Kowal>
> <@softwarechris:matrix.org> NB: it was part of the ES promise proposal at one point, and was called `deferred`

I’m not suggesting that `Promise.defer` should be preferred based on historical precedent, but Mark originally proposed `defer` https://web.archive.org/web/20160404122250/http://wiki.ecmascript.org/doku.php?id=strawman:concurrency#q.defer

[12:47:09.0875] <rbuckton>
If the concern around `import source from from` being ambiguous with module declarations, we could consider an alternate syntax for importing those declarations as well. i.e., `import x from <module_ref>` (with the literal `<>` characters), so there would be no ambiguity.

[12:47:24.0621] <rbuckton>
 * If the concern around `import source from from` is it being ambiguous with module declarations, we could consider an alternate syntax for importing those declarations as well. i.e., `import x from <module_ref>` (with the literal `<>` characters), so there would be no ambiguity.

[12:47:37.0171] <Michael Ficarra>
what? we already ban `let`

[12:49:38.0029] <Chris de Almeida>
> <@kriskowal:matrix.org> I’m not suggesting that `Promise.defer` should be preferred based on historical precedent, but Mark originally proposed `defer` https://web.archive.org/web/20160404122250/http://wiki.ecmascript.org/doku.php?id=strawman:concurrency#q.defer

right -- I clarified after this  Promise.defer() -> Object Deferred 

[12:49:59.0686] <rbuckton>
Not a huge fan of `import.source x from "y"`, to be honest. I understand its an option, but I'd rather not break that glass unless we need to.

[12:50:13.0825] <Kris Kowal>
And it seems we don’t need to.

[12:50:23.0611] <Bradford Smith>
Sorry, what would be the meaning of `export source ...`?

[12:50:36.0588] <littledan>
> <@rbuckton:matrix.org> Not a huge fan of `import.source x from "y"`, to be honest. I understand its an option, but I'd rather not break that glass unless we need to.

Yeah, I'm generally convinced that pseudo properties will be weird outside of expression context (exactly the reason why it's normal for dynamic import)

[12:50:48.0812] <ljharb>
> <@bradfordcsmith:matrix.org> Sorry, what would be the meaning of `export source ...`?

`export source foo from 'path'`

[12:50:54.0269] <littledan>
So I like the "break glass" mental model

[12:51:27.0045] <littledan>
let isn't reserved in *strict* mode either btw

[12:51:27.0182] <Bradford Smith>
> <@ljharb:matrix.org> `export source foo from 'path'`

So, it's a way to re-export the source of some other module?

[12:51:29.0815] <rbuckton>
I can see it now, someone writes a prettier or dprint rule to format code as `import .source x from "y"` so it looks less like an expression.

[12:51:43.0974] <HE Shi-Jun>
> <@michaelficarra:matrix.org> what? we already ban `let`

We really should also ban `from` as identifier in ES6 😅

[12:52:43.0004] <Michael Ficarra>
and `as`

[12:52:58.0235] <Michael Ficarra>
`import { as as as } ....`

[12:53:05.0700] <rbuckton>
> <@haxjs:matrix.org> We really should also ban `from` as identifier in ES6 😅

Nooo. I actually have a package that exports a function of that name.

[12:53:11.0944] <rbuckton>
> <@haxjs:matrix.org> We really should also ban `from` as identifier in ES6 😅

 * Nooo. I actually have a package that exports a function with that name.

[12:54:11.0247] <Chris de Almeida>
need stage 3 reviewers for `Promise.embiggen()` -- any volunteers?

[12:54:25.0540] <rbuckton>
e.g., 
```js
import { from } from "@esfx/iterable-query";

const res = from([a, b, c]).filter(predicate).groupBy(keySelector).toArray();
```

[12:54:39.0518] <Andreu Botella>
`Promise.source.from()`

[12:55:00.0319] <HE Shi-Jun>
> <@rbuckton:matrix.org> Nooo. I actually have a package that exports a function with that name.

I mean, `import {from} from module` might ok, but `import from from "from"` really a mess :P

[12:55:35.0863] <Michael Ficarra>
> <@softwarechris:matrix.org> need stage 3 reviewers for `Promise.embiggen()` -- any volunteers?

do a formal call after this topic

[12:56:03.0471] <Chris de Almeida>
yeah, might not have time do it tomorrow 

[12:56:11.0407] <Chris de Almeida>
 * yeah, might not have time -- can do it tomorrow 

[12:56:46.0740] <rbuckton>
I mean, `in` is a pseudo-keyword in `for-in` (and an actual keyword)

[13:01:15.0743] <Michael Ficarra>
I mean, you don't need quorum to assign stage 3 reviewers

[13:01:23.0665] <Michael Ficarra>
doesn't hurt to ask

[13:02:35.0187] <shu>
quorum is not even a concept we have

[13:02:51.0780] <Michael Ficarra>
eh, we kind of do

[13:03:19.0710] <Michael Ficarra>
on the last meeting day, when people are trickling in in the morning, we often delay the meeting a few minutes until we reach quorum

[13:03:22.0265] <nicolo-ribaudo>
"consensus by locking everyone else out of the room"

[13:03:33.0011] <Michael Ficarra>
everyone is always late on Thursday morning

[13:03:49.0251] <Michael Ficarra>
too much drinking Wednesday night

[13:04:51.0131] <shu>
fair, quorum is not a process formalism we have, but it is a norm we operate by where we kinda know who the core stakeholders are and don't pull a fast one when they aren't present

[13:12:18.0586] <littledan>
> <@shuyuguo:matrix.org> fair, quorum is not a process formalism we have, but it is a norm we operate by where we kinda know who the core stakeholders are and don't pull a fast one when they aren't present

and this norm is enforced by, if the stakeholder is present at the next meeting, they can say, "hey, you pulled a fast one!" and it's kinda undone. But this process is very infrequently applied and definitely has a 1-meeting time limit.

[13:13:17.0108] <Justin Ridgewell>
> <@softwarechris:matrix.org> need stage 3 reviewers for `Promise.embiggen()` -- any volunteers?

Happy to do it… because I already did it.

[13:32:50.0914] <littledan>
Can we add a continuation topic to the agenda for Array grouping?

[13:33:07.0859] <littledan>
I can be backup presenter if needed, but I thought ljharb was going to present

[14:00:43.0016] <ljharb>
ah good call, i thought the overflow item was already there. the PR has been rebased so i'd love to present it

[14:04:18.0794] <Rob Palmer>
How long do you need? We miscounted before so we may well run into the afternoon session. 

[14:09:09.0522] <littledan>
I think we should expect to go into the afternoon session. I don't want to be rushed in the source maps topic either.

[14:09:26.0149] <littledan>
is it an important goal for others to avoid the afternoon session tomorrow?

[14:25:19.0290] <ljharb>
> <@robpalme:matrix.org> How long do you need? We miscounted before so we may well run into the afternoon session.

ideally 2 minutes, realistically 15 is a good goal

[14:28:33.0701] <Rob Palmer>
Let's say 15mins then. 

[14:54:10.0768] <Chris de Almeida>
https://hackmd.io/d88UqzA8TFaKRdjY3t8vyQ
schedule updated. please take a look and lmk if any concerns

[14:55:20.0606] <Chris de Almeida>
it would also be helpful to be prepared to present in the earlier part of the day, if we breeze through quickly 

[14:57:20.0234] <littledan>
LGTM, yeah this is a good conservative approximation so we don’t rush too much, but we might get through it in the morning


2023-05-18
[06:17:27.0845] <dminor>
I have an appointment immediately before the meeting today, and Eemeli is out as well, so there'll be no Mozilla representative for the first half hour or so. From the agenda, I don't think there's anything that needs our feedback, but please ping me if something comes up.

[07:47:15.0596] <bakkot>
aww the decimal item got removed

[07:47:34.0995] <bakkot>
I would not have added my async iterators item if I'd thought it would be the only thing on the fourth day

[07:47:39.0351] <littledan>
the presenter is sick, unfortunately. I'm looking forward to it next meeting!

[07:47:39.0815] <bakkot>
I guess we have other stuff now though

[07:47:45.0868] <littledan>
also source maps overflow is today

[07:48:13.0804] <littledan>
if anyone has decimal feedback, it'd be good to take that asynchronously

[07:57:28.0512] <ryzokuken>
@room 3 mins to go!

[07:58:57.0409] <Rick Markins>
Morning conflict, be there after.

[08:12:50.0007] <Michael Ficarra>
`.bufferAhead(Infinity)` sounds like someone wanted `.toArray()`

[08:15:15.0008] <HE Shi-Jun>
> <@bakkot:matrix.org> aww the decimal item got removed

why removed? 

[08:15:29.0218] <littledan>
because the presenter is sick today

[08:15:35.0879] <HE Shi-Jun>
> <@littledan:matrix.org> the presenter is sick, unfortunately. I'm looking forward to it next meeting!

oh ...

[08:16:52.0403] <HE Shi-Jun>
> <@littledan:matrix.org> if anyone has decimal feedback, it'd be good to take that asynchronously

The current plan is decimal128 or bigdecimal?

[08:17:27.0025] <Michael Ficarra>
HE Shi-Jun: we don't have that decided yet

[08:17:56.0190] <littledan>
The champion proposed decimal128, and using objects with methods rather than primitives with operator overloading

[08:18:00.0077] <littledan>
(last meeting)

[08:18:02.0539] <littledan>
but nothing is decided

[08:18:24.0329] <littledan>
this choice was based on feedback from implementers about R&T

[08:18:36.0015] <littledan>
it'd be great to hear feedback on these decisions between now and the next meeting

[08:18:42.0967] <littledan>
 * it'd be great to hear feedback on these proposals between now and the next meeting

[08:20:14.0093] <HE Shi-Jun>
When we discussed it in wechat group, it seems people would prefer decimal128, with the assumption that it might have hardware support in the future. And if BigDecimal, some people might prefer Rational because it could cover more cases (at least theoretically? )

[08:20:44.0158] <littledan>
(I never understood why the conversation died down in the WeChat group I started for this outreach, and then there's this other group that I wasn't invited to...)

[08:21:28.0806] <littledan>
(when we make subgroups of TC39, the general principle is that they're open to anyone in the committee who wants to join them)

[08:22:14.0131] <HE Shi-Jun>
It's just my personal chat groups...

[08:22:21.0725] <littledan>
who is "we" then?

[08:22:31.0958] <littledan>
is it JSCIG or just your personal contacts?

[08:23:31.0977] <HE Shi-Jun>
Many chinese programmers , some are also in JSCIG group, but last JSCIG meeting we don't have enough time to cover decimal topic.

[08:23:45.0777] <Andreu Botella>
It seems like the transcriptionist is lagging far behind – and while the transcription seems accurate, it's far enough behind that it's very hard for me as a note-takers to keep track of what was said

[08:24:07.0972] <littledan>
yes I'm seeing that as well (I refreshed the notes a couple times to check if the error was on my side)

[08:24:18.0882] <littledan>
I wonder if it's that the presentation is too fast

[08:29:19.0567] <HE Shi-Jun>
> <@littledan:matrix.org> (when we make subgroups of TC39, the general principle is that they're open to anyone in the committee who wants to join them)

JSCIG meetings are open to anyone (check github.com/JSCIG/es-discuss/issues for meeting schedule). The only problem might be, we use only chinese in the meeting :-)

[08:29:53.0915] <littledan>
heh, I definitely won't be able to participate in a meeting, but I can participate in a text chat

[08:30:10.0036] <littledan>
but if it's a personal group that's fine, I don't need to be involved.

[08:32:46.0088] <HE Shi-Jun>
littledan: I don't think there is any official TC39 wechat group... do we have such wechat group?

[08:33:28.0394] <littledan>
well, I formed one in 2019 but I wasn't really able to generate much conversation (and now WeChat won't really let me log in). You were in it.

[08:34:05.0550] <littledan>
maybe because I was writing in English? but I would've been fine if people chatted in Chinese there

[08:35:53.0099] <HE Shi-Jun>
Oh, I find it. It's not have messages from March 2020.

[08:36:30.0585] <littledan>
Never mind, this isn't so important; we can discuss it after plenary

[08:37:25.0505] <Michael Ficarra>
I think that's just the ordered semantics that Kevin is proposing?

[08:37:50.0666] <Michael Ficarra>
we don't need some extra method to have these semantics

[08:40:06.0494] <peetk>
did i miss how you opt in/out of concurrency overall? is there an options bag or something?

[08:40:30.0091] <Michael Ficarra>
littledan: in response to your topic, yes, this is all going to have to abandon the async generator mental model

[08:40:50.0857] <littledan>
> <@michaelficarra:matrix.org> littledan: in response to your topic, yes, this is all going to have to abandon the async generator mental model

I do not see this as a bad thing for iterator helpers

[08:41:07.0742] <Michael Ficarra>
littledan: me either

[08:41:38.0795] <Michael Ficarra>
peetk: you just pull more than you need, and `bufferAhead` is a helper to do that for you

[08:48:19.0313] <Justin Ridgewell>
Maybe I'm not thinking of a complex enough test case, but I think something like `ints.map(subtractTwo).map(timesFour)`

[08:48:30.0561] <Michael Ficarra>
bakkot: yes it can, let me explain

[08:49:16.0687] <Justin Ridgewell>
If the returned promises settle in any order, we can add `cap` and `capOOO` methods to fix the settlement order, and rearrange the resolutions

[08:51:33.0890] <Michael Ficarra>
the queue doesn't seem to be advancing properly for me

[08:53:16.0707] <Michael Ficarra>
refreshing fixed it 🤷‍♂️

[08:55:15.0332] <peetk>
so -- just to clarify -- bufferAhead is the way to opt into concurrency?

[08:55:58.0630] <Michael Ficarra>
a limited for, yes

[08:56:19.0061] <Michael Ficarra>
the out-of-order bit is what we're talking about to enable it completely unrestricted

[08:56:29.0278] <Michael Ficarra>
 * a limited form, yes

[08:57:24.0919] <Michael Ficarra>
you can also just call `next` as much as you want for unlimited concurrency manually

[08:57:30.0658] <peetk>
right

[08:57:32.0621] <peetk>
ok thank you!

[08:57:39.0255] <Michael Ficarra>
no problem

[08:59:38.0746] <Michael Ficarra>
async iterators in particular really don't feel like they need to be sequential to me

[09:00:06.0350] <Michael Ficarra>
when people do async stuff, they know that the default state of things is out-of-order and that there needs to be explicit coordination to bring order back

[09:00:46.0189] <bakkot>
idk Promise.all() keeps order

[09:00:48.0368] <Justin Ridgewell>
I think it's a bit of a refactoring hazard if I have to change something to be async because I add a new call

[09:00:53.0619] <pipobscure>
@Michael That’s not really true though.

[09:02:46.0958] <Michael Ficarra>
yeah it's doing explicit coordination, that's its job

[09:02:57.0665] <Michael Ficarra>
 * yeah it's doing coordination, that's its job

[09:03:38.0973] <shu>
the "values being lost" thing is a core implication of anything concurrent _or_ parallel i think, don't think there's another choice

[09:06:13.0477] <shu>
like, you try to improve throughput or whatever by doing a larger-than-necessary amount of work at a time, so if you want to impose some kind of serialization of results after the fact you'll have to discard stuff

[09:08:05.0011] <Michael Ficarra>
yeah but we have effects and exceptions and you can't just roll those back

[09:11:23.0802] <Justin Ridgewell>
Happy to join an async-iterator call

[09:11:46.0660] <Michael Ficarra>
same

[09:12:00.0066] <Willian Martins>
I’m willing to be part of the call as well. 

[09:13:56.0750] <bakkot>
> <@shuyuguo:matrix.org> like, you try to improve throughput or whatever by doing a larger-than-necessary amount of work at a time, so if you want to impose some kind of serialization of results after the fact you'll have to discard stuff

only if you are going to stop consuming results conditionally - if you want to consume everything you don't have to lose anything, e.g. `let results = Promise.allSettled(array.map(asyncMapper))` doesn't lose anything

[09:14:45.0853] <shu>
bakkot: yes, right, but i thought your point was that `filter` and `reduce` are fundamentally conditional consumption

[09:15:20.0006] <shu>
which i agree with, we shouldn't just do the embarrassingly parallel things

[09:15:40.0188] <bakkot>
iterator helpers are fundamentally conditional yeah

[09:15:56.0377] <bakkot>
but we could decide that this problem is bad enough that iterator helpers should not be the place for concurrency, and just make these work like generators

[09:16:10.0264] <bakkot>
and say you have to do something else for concurrency so that you don't lose values

[09:16:15.0397] <shu>
right, fair, and that's not my position

[09:16:16.0187] <bakkot>
not my preferred option but it is an option

[09:16:32.0621] <shu>
because i think losing-values is just a core part of the bargain for general concurrency

[09:16:52.0461] <ljharb>
(in an exception case)

[09:30:17.0739] <bakkot>
to elaborate on why `filter` is weird:

let's say you do
```
let it = [1, 2].toAsync().filter(pred);
it.next().then(console.log);
it.next().then(console.log);
```

and let's sa your predicate returns `true` for the second call instantly, but takes a minute to finish for the first call.

if you are trying to preserve order at all, you can't resolve _either_ promise until the first call settles, because if the first call settles with `true` then the first promise needs to get `{ done: false, value: 1 }` and if it settles with `false` then the first promise needs to get `{ done: false, value: 2 }`.

the only way to get things earlier than that is to give up on order _entirely_, so that in the case your predicate returns `false` for `1` then the first line prints `{ done: true }` and the second prints `{ done: false, value: 2 }`.

[09:31:23.0146] <shu>
yes, good example, the done-ness signal further reinforces my mental model of iterators being inherently ordered things

[09:31:41.0763] <bakkot>
 * to elaborate on why `filter` is weird:

let's say you do

```
let it = [1, 2].toAsync().filter(pred);
it.next().then(console.log);
it.next().then(console.log);
```

and let's say your predicate returns `true` for the second call instantly, but takes a minute to finish for the first call.

if you are trying to preserve order at all, you can't resolve _either_ promise until the first call settles, because if the first call settles with `true` then the first promise needs to get `{ done: false, value: 1 }` and if it settles with `false` then the first promise needs to get `{ done: false, value: 2 }`.

the only way to get things earlier than that is to give up on order _entirely_, so that in the case your predicate returns `false` for `1` then the first line prints `{ done: true }` and the second prints `{ done: false, value: 2 }`.

[09:32:06.0461] <HE Shi-Jun>
It seems `done` should be also a promise 😅

[09:33:43.0059] <Michael Ficarra>
shu: I still don't think so. It doesn't mean that any iterator derived from this one will be done. It's just used as a signal to the consumer to not pull anymore.

[09:34:38.0948] <shu>
that strikes me as not the prevalent intuition

[09:35:01.0222] <shu>
and will be confusing for the majority programmer if we adopted it

[09:36:17.0559] <bakkot>
RxJS can make observables from async iterators, and also is async iterable

[09:36:32.0453] <bakkot>
and has `map` etc helpers which are obviously out of order

[09:36:42.0399] <bakkot>
 * and has `map` etc helpers which are out of order

[09:36:48.0051] <bakkot>
I wonder how they handle this case

[09:37:02.0133] <shu>
anyway my understanding of async iterator helpers right now is to provide "data concurrent" algorithms on generic collections, via the iterator interface

[09:37:29.0558] <shu>
but in general, data parallel algorithms require chunking and need to know the collection size ahead of time to chunk

[09:37:35.0552] <bakkot>
I'm kind of inclined to say that if you want to give up on preserving order you should switch to a different thing which is not inherently ordered, i.e. observables

[09:37:45.0313] <Michael Ficarra>
I think having two sets of methods with an opt-in that moves you from in-order to out-of-order is a fair compromise here

[09:37:55.0682] <shu>
thus my suggestion for bufferAheadOOO(N) method to recover the collection size

[09:38:05.0583] <shu>
and lets you do full OOO concurrency

[09:38:12.0341] <Michael Ficarra>
yeah I think we're in agreement

[09:38:44.0511] <bakkot>
If we're going to have to sets of methods I would be inclined to just have differently-named methods on the same prototype

[09:38:51.0323] <Michael Ficarra>
now question: should the OoO prototype have a similar-named method that's a no-op?

[09:39:07.0257] <bakkot>
I don't know how the proposed `bufferAheadOOO` would work

[09:39:42.0303] <Michael Ficarra>
bakkot: no, switching is better, since you don't have to add OOO to 10 method calls in a chain, and you don't accidentally in-order after some OOO method

[09:40:18.0759] <Michael Ficarra>
bakkot: we should pair on a prototype impl to see if it would work

[09:40:24.0551] <bakkot>
yeah but if you're reading it you have to notice the call at the the start of the chain to see that this `.filter` is unlike other `.filter`s

[09:40:31.0143] <bakkot>
and if it gets passed around first that might be lost entirely

[09:40:32.0163] <bakkot>
seems bad

[09:40:55.0394] <Michael Ficarra>
that's the case for all data structures?

[09:41:03.0932] <Michael Ficarra>
virtual dispatch baby

[09:41:25.0396] <bakkot>
"async iterator" and "async iterator but the methods are unordered" doesn't seem like really a different data structure

[09:41:35.0688] <bakkot>
hm. so. also, how do you consume one of these?

[09:41:39.0473] <bakkot>
like in my `filter` example

[09:41:42.0866] <bakkot>
what's the thing you actually do with it

[09:41:50.0824] <Michael Ficarra>
it's a different monad

[09:41:53.0207] <bakkot>
you can't for-await over it because for-await stops at the first `done`

[09:42:05.0919] <bakkot>
ditto `forEach` etc

[09:42:21.0253] <bakkot>
 * hm. so. also, how do you consume one of these out-of-order things?

[09:42:31.0506] <Rob Palmer>
Confidence in the ability to use the alternative license affects Ecma's ability to attract work and expand scope - even though we know informally it's highly likely to be approved. It's a matter for Ecma's organizational development.  I guess this is best discussed in the GA or ExeCom since it's not a TC39-specific thing.

[09:43:11.0213] <bakkot>
any explanation which requires the use of the word "monad" is inherently not suitable for actual users

[09:43:17.0401] <Ashley Claymore>
> <@bakkot:matrix.org> and has `map` etc helpers which are obviously out of order

For rxjs flatMap is out of order, concatMap preserves order 

[09:44:19.0901] <bakkot>
they renamed flatMap to mergeMap IIRC

[09:44:23.0709] <bakkot>
to make that clearer

[09:44:42.0080] <bakkot>
there is also switchMap

[09:45:20.0450] <Ashley Claymore>
Yeah which was flatMapLatest

[09:45:21.0628] <bakkot>
but yes there are several different notions of "out of order" for flatMap

[09:47:54.0662] <bakkot>
chairs: we need to revisit decorator metadata as well

[09:48:01.0972] <bakkot>
sorry I didn't notice it was not on the agenda

[09:48:06.0706] <bakkot>
 * sorry I didn't notice it was not on the draft schedule

[09:48:10.0828] <bakkot>
should only take 5 minutes

[09:48:18.0142] <ljharb>
https://github.com/tc39/proposal-array-grouping/pull/47/files

[09:48:56.0402] <Michael Ficarra>
hold back `done: true` until all underlying iterator yields settle?

[09:49:25.0475] <Michael Ficarra>
again, we should try to actually implement this to tease out these details

[09:52:23.0977] <bakkot>
peetk: https://github.com/tc39/proposal-array-grouping/issues/51#issuecomment-1372786948

[09:52:30.0338] <bakkot>
(sorry if that's the wrong handle to ping)

[09:52:57.0968] <Michael Ficarra>
(he means contiguous)

[09:58:15.0077] <bakkot>
you can't hold back anything without giving up on order entirely

[09:58:23.0532] <bakkot>
 * you can't hold back anything without giving up on out-of-order entirely

[09:58:48.0059] <bakkot>
well, maybe you can hold back `done` but not worry about exceptions?

[09:58:58.0510] <bakkot>
anyway yes we can pair on it

[10:00:09.0184] <bakkot>
wait the holding back doesn't fix anything in my example

[10:00:12.0692] <bakkot>
with `filter`

[10:01:15.0260] <bakkot>
giving up on order in that case means: that the first promise settles second, and it settles with `{ done: true }`. that means for-await is never going to see the second promise at all.

[10:01:25.0696] <bakkot>
i.e. in my example it's already settling last, so there's nothing to hold back

[10:03:53.0585] <littledan>
Who was the first Stage 3 reviewer?

[10:04:00.0952] <littledan>
We had someone who MS will recruit from Safari, and someone else

[10:05:34.0817] <Michael Ficarra>
littledan: shu

[10:05:50.0457] <shu>
yes?

[10:06:29.0345] <shu>
oh

[10:06:33.0154] <shu>
yes, i'm the first reviewer

[10:09:56.0755] <bakkot>
Justin Ridgewell: you should open an issue on the repo just in case though

[10:10:06.0569] <Justin Ridgewell>
Will do

[10:11:01.0492] <Michael Ficarra>
I read your comment like 10 times and I still don't get the issue. Did you mistype something?

[10:13:56.0044] <shu>
a question for practitioners who want to use decorators natively in browsers: do you want metadata to ship at the same time as the rest of the decorators proposal?

[10:14:22.0001] <bakkot>
pzuraq: metadata is now stage 3

[10:15:26.0540] <shu>
maybe a different question: who wants to use decorators natively in browsers?

[10:15:34.0649] <HE Shi-Jun>
Does creating a new metadata object really cause perf issue?

[10:16:04.0386] <bakkot>
HE Shi-Jun: doing it on every single class when most of them won't have any decorators seems like it would be a pretty high cost, yeah?

[10:16:27.0035] <bakkot>
I don't think it would be an actual perf issue by itself, but it wouldn't be free, and the benefit doesn't seem worth it

[10:16:30.0745] <littledan>
Someone clicked past queue items; who expressed support?

[10:16:35.0454] <littledan>
I think Shu was expressing support?

[10:16:40.0190] <littledan>
or maybe this was the previous commenter

[10:16:46.0313] <ryzokuken>
yeah

[10:16:46.0730] <littledan>
 * or maybe this was the previous topic

[10:16:49.0542] <ryzokuken>
it was for the last item

[10:16:53.0395] <littledan>
ah thanks

[10:17:04.0425] <ljharb>
> <@shuyuguo:matrix.org> a question for practitioners who want to use decorators natively in browsers: do you want metadata to ship at the same time as the rest of the decorators proposal?

in general, anything that minimizes the support matrix for any set of features is a nicety

[10:17:09.0883] <bakkot>
shu: : typescript can generate decorators with runttime type information and people write libraries which use that at runtime

[10:17:11.0211] <bakkot>
for some reason

[10:17:42.0684] <shu>
> <@bakkot:matrix.org> shu: : typescript can generate decorators with runttime type information and people write libraries which use that at runtime

not sure i follow

[10:17:53.0070] <bakkot>
oh

[10:17:54.0674] <bakkot>
sorry

[10:17:59.0740] <bakkot>
I did not read the question correctly

[10:18:00.0979] <bakkot>
ignore me

[10:18:03.0506] <shu>
ah

[10:19:22.0430] <Michael Ficarra>
I wish Natalie from Chrome security was still attending

[10:20:50.0693] <Justin Ridgewell>
https://github.com/tc39/proposal-decorator-metadata/issues/15

[10:31:39.0871] <littledan>
Great meeting everyone!

[10:33:04.0880] <bakkot>
```
let it = [1, 2].toAsync().ooo().filter(pred);
it.next().then(console.log);
it.next().then(console.log);
```
Suppose the first call to `pred` returns `false`, but takes longer than the second call, and the second call returns `true`. What behavior do you imagine for the two prints?

[10:38:32.0407] <Chris de Almeida>
https://github.com/tc39/Reflector/issues/450
looking for nominations for one or more individuals for TG3 Convenors/Chairs

[12:07:21.0734] <Michael Ficarra>
`{ done: false, value: 2 }` then `{ done: true, value: undefined }`? I don't see what's challenging about this case


2023-05-19
[12:28:44.0265] <ljharb>
fyi: updated tests for Array grouping: https://github.com/tc39/test262/pull/3830


2023-05-23
[17:04:01.0626] <littledan>
Hey, any comments on the TG4 scope before I send it off to Ecma? https://gist.github.com/littledan/5f3736a50a40c610d6e864f33a75dcad

[18:36:34.0924] <Chris de Almeida>
MLS had indicated that we should review this at the next plenary and IS echoed the same.  I didn't get the sense that it needed to be gated on plenary, but mentioning here in case I misunderstood.  Nonetheless, I don't see why it couldn't be updated later, whether at plenary or beyond.

[18:37:19.0768] <littledan>
Yeah, I will put it on the Reflector too

[18:37:20.0848] <Chris de Almeida>
I can't add comments to the gist -- how would you like to receive feedback ?

[18:37:31.0482] <littledan>
You can’t?

[18:37:35.0576] <Chris de Almeida>
thanks for writing this up, btw!

[18:37:41.0928] <littledan>
Anyway feedback here is good 

[18:37:54.0904] <Chris de Almeida>
oh sorry -- I can add comments -- I was hoping for line number comments

[18:38:07.0194] <Chris de Almeida>
didn't notice comment box at bottom

[04:10:49.0628] <eemeli>
littledan: Would the plan be for the source-map spec to ultimately follow the same procedures as we have for ECMA-262 and ECMA-402, or for more authority to be delegated to its TG to control the spec? Or is it too early for such considerations?

[04:23:25.0434] <littledan>
I’d like to discuss that among the group. I don’t know yet. I think source maps are a little more loosely connected to 262 than 402 and that could affect the process.


2023-05-26
[07:50:40.0135] <shu>
bakkot: https://github.com/tc39/proposal-set-methods/issues/98?

[09:17:32.0723] <bakkot>
shu: yeah you're probably right

[09:17:37.0169] <bakkot>
will bring it to the next meeting

[09:21:25.0431] <shu>
ah great thanks

[09:31:07.0620] <bakkot>
feel free to just implement it that way and ship

[09:31:16.0994] <bakkot>
don't think changing this after the fact will be a problem

[09:42:28.0071] <shu>
we'll be a while yet, need to think through the fast paths


2023-05-30
[02:02:39.0432] <Jesse (OoO, back May 31)>
I'm working on setting up an incubator call for the decimal proposal -- if you're interested in discussing things, please check out the Doodle: https://doodle.com/meeting/participate/id/dy9WKG6d I had initially set June 1 as the date of the call, but I've received some feedback saying this doesn't work. I added a bunch more dates to the Doodle, so hopefully we can find something that works for enough of us.

[12:57:25.0564] <ljharb>
these are all in the middle of the night for the west coast

[13:25:07.0317] <Chris de Almeida>
ljharb: there are some later options

[13:25:55.0569] <ljharb>
there's only 5 i see, ranging from 1am - 5am pacific

[13:26:27.0708] <littledan>
there's a "next" button

[13:26:53.0110] <ljharb>
ohhhh snap, ok, i could have sworn doodle showed them all with a horizontal scrollbar

[13:26:54.0304] <ljharb>
thanks

[13:28:34.0723] <littledan>
gotta change the UI to get promoted, right?

[13:29:46.0048] <shu>
i didn't know google bought doodle

[16:13:20.0201] <Michael Ficarra>
the 19th is a federal holiday in the US and the rest of that week is PLDI, so these options are not great...

[16:16:23.0285] <Michael Ficarra>
what was the reason for June 1 not working?


2023-05-31
[00:18:53.0181] <Jesse>
it could have worked but I got some private feedback from a few (and public feedback from one) that it wouldn't work out

[00:19:23.0974] <Jesse>
> <@michaelficarra:matrix.org> the 19th is a federal holiday in the US and the rest of that week is PLDI, so these options are not great...

I can add some more options.

[00:28:58.0239] <Jesse>
options added

[15:29:38.0385] <bakkot>
so if we were going to add a `Math.sum`, should it

1. take a single iterable argument and add its elements, or
2. take a variable number of arguments and add them all together?

keeping in mind that `Math.min`/`max` work like the second option

[15:30:10.0728] <bakkot>
 * so if we were going to add a `Math.sum`, should it

1. take a single iterable argument and add its elements, or
2. take a variable number of arguments and add them all together?
3. we should pick a different name to avoid this problem (`Math.sumFrom`?)

keeping in mind that `Math.min`/`max` work like the second option

plz vote with emojis

[15:30:17.0127] <bakkot>
 * so if we were going to add a `Math.sum`, should it

1. take a single iterable argument and add its elements, or
2. take a variable number of arguments and add them all together?
3. we should pick a different name to avoid this problem (`Math.sumFrom`?)

keeping in mind that `Math.min`/`max` work like the second option

plz vote with emoji reacts

[16:07:23.0096] <iain>
`Math.sum(...iterable)` seems like a reasonable way to implement 1 using 2. SpiderMonkey already has special handling for `Math.min(...array)`.

[16:07:30.0728] <iain>
 * `Math.sum(...iterable)` seems like a reasonable way to implement 1 using 2. SpiderMonkey already has special handling for `Math.min/max(...array)`.

[16:10:01.0544] <bakkot>
iain: unfortunately no engine I have on hand is able to handle `Math.max(...iterable)` when iterable has more than ~100k elements

[16:11:20.0799] <iain>
Ah, fair enough

[16:11:40.0220] <bakkot>
 * iain: unfortunately no engine I have on hand is able to handle `Math.max(...iterable)` when iterable has more than ~70k elements

[16:12:31.0923] <bakkot>
which, a.) sometimes I do in fact have arrays with more than 100k elements and b.) and because I don't know those limits offhand I would not be willing to use the `...iterable` version with any array whose length is not very strictly bounded

[16:12:41.0912] <bakkot>
 * which, a.) sometimes I do in fact have arrays with more than 100k elements and b.) because I don't know those limits offhand I would not be willing to use the `...iterable` version with any array whose length is not very strictly bounded

[16:13:19.0069] <bakkot>
 * so if we were going to add a `Math.sum`, should it

1. take a single iterable argument and add its elements, or
2. take a variable number of arguments and add them all together?
3. we should pick a different name to avoid this problem (`Math.sumFrom`?)

keeping in mind that `Math.min`/`max` work like the second option

plz vote with emoji reacts [note they may be out of order because Element displays the most popular ones first]

[16:37:10.0075] <TabAtkins>
Yeah I'm sad about that. I mean, I like both at the same time - take a variable number of numbers-or-iterators, and sum all of them

[16:37:26.0674] <TabAtkins>
aka flatten the arguments array and then sum the result

[16:38:46.0487] <Kris Kowal>
I’ve had the same problem with `splice`.

[16:39:27.0330] <Kris Kowal>
Not that I’m suggesting that we add `Array.prototype.swap` or `Array.prototype.patch`, but

[16:39:57.0299] <TabAtkins>
I'll say that in most cases I find it a little annoying if something *only* takes an iterable versus taking N arguments, because when I'm hand-authoring I have to remember to add a wrapper. But for sum() it's not really a deal; if I'm invoking on some varaibles directly I can just... add them together instead.

[16:40:52.0578] <TabAtkins>
The other issue with taking a single iterable is when you have two iterables. JS doesn't have built-in chain to make that work.

[16:40:54.0030] <bakkot>
if only we'd thought to make `Math.max` throw if you passed it something non-primitive with a `Symbol.iterator` property...

[16:41:02.0153] <TabAtkins>
While argument spread handles it automatically

[16:41:44.0658] <bakkot>
> JS doesn't have built-in chain to make that work

soon! `Iterator.from([iter1, iter2]).flatMap(x => x)`

[16:42:22.0927] <bakkot>
honestly that is making me want `Iterator.of`

[16:42:25.0229] <bakkot>
we should have that too

[16:44:50.0720] <bakkot>
really the problem here is coercing

[16:44:53.0454] <bakkot>
we should stop coercing things

[16:45:10.0782] <TabAtkins>
Ah, an `Iterator.from()` would do it, yeah

[16:45:19.0538] <TabAtkins>
and like it's trivial to write yourself, but still

[16:45:39.0553] <bakkot>
`Iterator.from` is in the stage 3 iterator helpers proposal

[16:45:45.0307] <TabAtkins>
nice

[16:50:39.0815] <TabAtkins>
I'm sure it's not web compatible, but I wonder how many authors we'd help by throwing for a max() argument with an iterator, letting them know they meant to spread it.

[16:51:21.0644] <bakkot>
yeah I'd love that

[16:51:35.0377] <bakkot>
but someone out there is relying on `Math.max([10])` giving them `10`

[16:52:21.0802] <TabAtkins>
i think coercing to string *or* to number is often fine, but our behavior where we'll coerce to string *then* to number is so weird and buggy

[16:53:46.0856] <bakkot>
I want to make a rule that we never coerce between primitives, at least

[16:54:10.0293] <bakkot>
also ideally never coerce Array

[16:54:15.0939] <TabAtkins>
yeah def

[16:54:18.0198] <bakkot>
 * also ideally never coerce Array instances

[16:54:30.0442] <bakkot>
I will probably have a bit on the agenda next meeting about this

[16:55:19.0657] <TabAtkins>
Having to call `str()` or `int()` in Python hasn't killed me yet.

[16:56:07.0916] <bakkot>
also like `['a', 'b', 'c'].at('start') // 'a'`

[16:56:10.0490] <bakkot>
I hate that

[16:56:12.0467] <bakkot>
I know why it happens

[16:56:16.0064] <bakkot>
and it's consistent

[16:56:18.0160] <bakkot>
but I hate it so much

[16:56:22.0395] <TabAtkins>
lol

[16:56:29.0456] <TabAtkins>
is that a NaN->0 coercion?

[16:56:32.0504] <bakkot>
yes

[16:56:35.0361] <TabAtkins>
bleh

[16:56:39.0190] <bakkot>
which is the worst of all coercions

[16:56:48.0597] <bakkot>
and which we are at least starting to move away from

[16:57:05.0706] <bakkot>
`take` and `drop` in the iterator helpers proposal guard on `NaN` explicitly