TC39 Delegates
2025-05-29
plaintext logs
prev next
source on github
08:00
<Rob Palmer>
We are now starting the meeting!
08:02
<Christian Ulbrich>
-> https://github.com/tc39/notes/blob/main/delegates.txt
08:04
<yulia>
I can't edit the doc
08:05
<yulia>
ah just needed to refresh
08:16
<Rob Palmer>
There's been minor schedule rearrangement, inserting TCQ & Decimal continuation after lunch, and bringing forward Tabs items to meet his constraint of avoiding the final hour.
08:24
<Michael Ficarra>
we need to advance the queue @Rob Palmer @ryzokuken
08:25
<ryzokuken>
done ty for the reminder
08:26
<Michael Ficarra>
why did my reply get moved to a new topic?
08:26
<ryzokuken>
because Yulia's reply came before yours
08:26
<ryzokuken>
but they're replies
08:26
<nicolo-ribaudo>
(my reply came before michael's too)
08:26
<ryzokuken>
TCQ just doesn't allow us to move stuff without turning them into topics
08:27
<ryzokuken>
oh right sorry I didn't even notice when it came in nicolo-ribaudo
08:27
<Michael Ficarra>
only because the queue wasn't advanced so there was no reply button @nicolo-ribaudo šŸ˜›
08:27
<ryzokuken>
yep sorry it's atleast half of TCQ's fault though
08:27
<Jesse (šŸ‡ŖšŸ‡ø)>
TCQ feature requests?
08:27
<ryzokuken>
we have a presentation coming up later!
08:35
<Michael Ficarra>
@yulia objecting to what?
08:35
<yulia>
objecting to the dual view
08:35
<yulia>
integration path 2
08:36
<Michael Ficarra>
if I want none of these options, does that count?
08:36
<yulia>
that also counts, but could you talk a bit about why?
08:36
<yulia>
esp. why not option 1 in that case
08:38
<Michael Ficarra>
it's more exceptional than not, there's already too much irregularity that needs to be dealt with in the language
08:39
<Michael Ficarra>
also I would like to hear from multiple implementations (or other constituents) that this would be useful
08:40
<Michael Ficarra>
@shu expressed in the editor call, where we talked about this at some length, that he didn't think V8 would find this useful
08:40
<Michael Ficarra>
I don't want to speak further for him though
08:40
<Michael Ficarra>
@TabAtkins this is almost certainly going to be the case, I don't see why it would not be
08:42
<Michael Ficarra>
what I mean is, any IDL is going to be full of exceptional cases because it's describing a language that is full of exceptional cases
08:53
<snek>
doesn't webidl's coercion for numeric arguments not match our current consensus for new apis in tc39
08:54
<Michael Ficarra>
@snek yes
08:54
<Michael Ficarra>
all new APIs will require attributes to that effect
08:54
<Michael Ficarra>
I feel like people haven't read arai's document
08:58
<snek>
i feel like having a declarative definition of all our stuff would be nice, especially if it reduces function entry/exit boilerplate. but it seems like webidl is a bit msimatched for us...
08:58
<snek>
i haven't read the full document though
08:59
<Michael Ficarra>
this conversation has not convinced me in the direction of WebIDL, if anything it has convinced me that a JS-specific IDL or no IDL would be better
09:00
<snek>
i guess in particular if the primary argument is reusing assumptions/code from existing webidl... all the extended attributes and special cases probably end up making it a moot point
09:01
<TabAtkins>
yulia: btw I'd like to help with this project
09:02
<yulia>
that would be brilliant
09:03
<danielrosenwasser>
It could be nice to generate TypeScript .d.ts files if TC39 published those, though I don't know if we would always generate them as a source of truth.
09:03
<danielrosenwasser>
I do wonder if an IDL for JS could also be used to generate the actual boilerplate of spec text under that dual approach.
09:03
<Michael Ficarra>
typescript types diverge enough from reality that it probably wouldn't make sense
09:04
<Andreu Botella>
DOM types in TypeScript are automatically generated from WebIDL
09:04
<Michael Ficarra>
what I mean is, typescript pretends certain complexity doesn't exist because that's how 99% of users use the built-in and it makes things nicer for them
09:05
<Duncan MacGregor>
I'm not sure I can officially help with the web IDL stuff, but we've been through a number of internal systems for exposing and describing core parts of our system, and I might well look at what we could do that would closely aligned with web IDL and could be automatically translated.
09:08
<rkirsling>
er wait, I'm participating in execom on behalf of an associate member
09:10
<rkirsling>
ah right this slide explains
09:10
<rkirsling>
a maximum of four people can be exceptions
09:11
<danielrosenwasser>
Right, this is why I don't think the output would be the source of truth. We would manually adjust the output periodically.
09:12
<danielrosenwasser>
Maybe? As we've talked about, we typically add more restrictions because we're following the spirit of the API rather than just assuming any everywhere.
09:13
<Michael Ficarra>
as you should (though I may disagree with a couple of them)
09:19
<eemeli>
Michael Ficarra: One should presumably read your "10 days > 3 weeks" to imply a transition, and not an inequality?
09:20
<eemeli>
(And I was just about to submit a similar topic)
09:20
<Michael Ficarra>
it's an inequality but on value, not duration
09:21
<yulia>
Duncan MacGregor: what is your github>
09:22
<Michael Ficarra>
why does this sound so threatening? lol
09:23
<yulia>
ha, probably because im in a rush and got a baby on me
09:23
<yulia>
*toddler
09:23
<yulia>
arguably harder
09:23
<snek>
what is the toddler's github?
09:24
<yulia>
she's hosting her own git instance
09:24
<ryzokuken>
she's more like a gitea person /s
09:26
<Andreu Botella>
for this particular plenary, 3 weeks ahead would've been basically right after the last one
09:31
<Michael Ficarra>
they do literally say "shall" though lol
09:31
<eemeli>
That perhaps tells us something about how often we have meetings more than anything else. As I recall, quite a few of the last few meetings have had an underflow of the agenda, and perhaps five meetings a year could be enough.
09:32
<Andreu Botella>
don't other meetings have overflow?
09:32
<Andreu Botella>
it seems there's an uneven distribution throughout the year
09:32
<Michael Ficarra>
yes we have had overflow quite often in the past
09:32
<Michael Ficarra>
the last 2 meetings having underflow is new and unusual
09:33
<ryzokuken>
yep it's a timing thing
09:33
<snek>
its not just a function of number of agenda items though, its also what overall latency we want to aim for. we can always have more meetings with fewer days, for example
09:34
<yulia>
we could potentally "bucket" work so that it is less cognative load to cover all of the topics
09:35
<yulia>
i think there are multiple approaches, but i think this is a very valid problem that is being raised
09:35
<yulia>
i think we should aim to fulfill the spirit of the 3 week requirement. maybe that means 3 weeks, maybe that means something else
09:37
<Rob Palmer>
What if we imposed the 3-week time only to requests for 2.7 advancement? (and keep it as 10 days for all other types of advancement)
09:38
<yulia>
i think that is potentially the most important stage (although its less "absolute" than stage 3 advancement)
09:38
<yulia>
either stage 2.7 or 3
09:40
<Michael Ficarra>
I am not as optimistic as Samina about how unlikely it would be for a bad actor to try to join and disrupt our process
09:40
<snek>
does javascript as an institution have enemies
09:40
<Michael Ficarra>
hopefully we don't have to deal with that, but we should be robust against such an occurrence
09:41
<Rob Palmer>
(I focus on 2.7 because that is where the primary decision-making happens, whereas advancement to stage 3 nowadays is when tests are complete which is something champions self-declare)
09:41
<Chengzhong Wu>
competitor languages?
09:42
<Michael Ficarra>
I don't think champions self-declare. They make the claim and try to convince the committee that it's true. Sometimes it's self-evident.
09:42
<yulia>
We've had angry users who have attempted blocking in various ways
09:42
<yulia>
usually we can resolve it
09:43
<yulia>
Right and stage 2.7 isn't a protected stage the same way as stage 3 iirc?
09:43
<Rob Palmer>
That is fair - the claim may turn out to be false.
09:43
<yulia>
the risk of moving to stage 3 is higher, because then you are basically on the train to shipping modulo very specific concerns
09:46
<snek>
14 minutes of tail calls
09:46
<ptomato>
one does not do just 14 minutes of tail calls
09:47
<Andreu Botella>
if you do tail calls, you gotta do infinite recursion
09:47
<Michael Ficarra>
I don't know what "protected stage" means. Is it a term of art or just colloquial usage?
09:47
<snek>
its an infinite topic but each iteration takes half the time of the last
09:48
<Michael Ficarra>
reminder that this is the delegates channel, not TDZ
09:49
<TabAtkins>
I think it would also be helpful in the future to have the attendees list in the notes doc separated into in-person and remote lists, to make searching for a name faster.
09:49
<Rob Palmer>
Umm - I'm happy to go back to when we defined Stage 2.7 to check, but my understanding is that your definition applies to 2.7. Meaning we were not introducing a new relitigation point at 3.0. 3.0 is simply the sign that tests are ready.
09:53
<Rob Palmer>
So it is critical that all design opinions are volunteered prior to achieving 2.7. People should not be holding back feedback in the hope of redirecting the proposal during 2.7.
09:53
<yulia>
If thatā€™s the case we should update the process doc
09:53
<yulia>
Currently:
09:53
<yulia>
Given that consensus on Stage 3 means "the solution is complete" (i.e., all open design issues have been resolved including anticipated implementation and ecosystem compatibility issues), all TC39 participants should validate the design of proposals they care about before granting Stage 3 consensus. Stage 3 proposals which have fulfilled the acceptance criteria for Stage 4 may not be withheld from advancement unless the issue raised is related to implementation experience or identifies a problem or information which has not previously been discussed by the committee. The goal is to enable implementers to invest in implementations, and preserve the significance of Stage 3 in the process.
09:54
<yulia>
Itā€™s a detail honestly, Iā€™m not saying one way or the other
09:54
<yulia>
Just we should align on it
09:55
<Rob Palmer>
I think that wording still holds. But maybe there's more we could say because I do wonder if the spririt (and words!) of the introduction of Stage 2.7 might get lost over time.
09:55
<yulia>
Stage 3 as a backstop is useful outside of stage 2.7 imo
09:56
<yulia>
Most of stage 3 is in 2.7
09:57
<yulia>
I don't know what "protected stage" means. Is it a term of art or just colloquial usage?
Protected stage is in reference to the paragraph that I just posted
09:57
<Rob Palmer>
The process doc is already pretty explicit about excluding relitigation after 2.7.
09:57
<Rob Palmer>
  • 2.7: No changes to the proposal will be requested by the committee aside from those elicited through testing, implementation, or usage experience.
  • 3.0: No changes to the proposal are expected, but some necessary changes may still occur due to web incompatibilities or feedback from production-grade implementations.
  • 4.0: No further changes will be made to the proposal.
09:59
<yulia>
Can you point me to where it says that in the process document? Iā€™m just not finding it
09:59
<yulia>
The only place where it says advancement to the next stage cannot be blocked is in reference to stage 3-4 advancement
10:00
<Rob Palmer>
I think we are saying the same thing: perhaps just slight different view on what a "very specific concern is"
10:01
<yulia>
Iā€™m perfectly happy if we added more guard rails here, but I donā€™t think we have. At least not to the degree that was done for stage 3. The stage 3 guard rail is explicitly stated in our process document
10:01
<yulia>
This isnā€™t about changes btw, itā€™s about appropriate blocks
10:02
<Rob Palmer>
There's no explicit statement saying advancement to 3 cannot be blocked. But there is scoping on the types of changes that can be requested. I'm not sure if we need to add the belt and braces as we have done for advancement to stage 4.
10:02
<yulia>
There is
10:02
<yulia>
Stage 3 proposals which have fulfilled the acceptance criteria for Stage 4 may not be withheld from advancement unless the issue raised is related to implementation experience or identifies a problem or information which has not previously been discussed by the committee.
10:03
<yulia>
This was very deeply discussed at committee
10:03
<Rob Palmer>
We are agreeing ;-)
10:03
<yulia>
That is why stage 3 is dangerous in a way stage 2.7 is not
10:03
<yulia>
ā€œMay not be withheld from advancementā€
10:03
<yulia>
At all other stages you can say no
10:04
<yulia>
We are not agreeing, this is not the same level.
10:05
<yulia>
If committee wants to change this, that is fine. However, at stage 2.7 you cannot elide someoneā€™s block
10:06
<yulia>
I also do not think applying this to stage 2.7 is wise
10:06
<yulia>
The flexibility provided by the other stages is important
10:11
<yulia>
This paragraph was introduced extremely deliberately
10:12
<Rob Palmer>
I'm in agreement on the super-power of 3->4. The reason I'm discussing this is in case folk apply a lower threshold of review when deciding whether to permit advancement, on the basis that they can change their mind later.
10:13
<yulia>
Right, regarding whether 3 weeks should be for 2.7 or 3 ā€” I think both have good arguments
10:13
<yulia>
2.7 is when the design work is really done, 3 is when ā€œif you didnā€™t review this and let it through, you are out of options because we are implementingā€
10:15
<yulia>
Obviously new info will be taken into account, but no one can just join the committee to block stage 4
10:23
<Rob Palmer>
This has been useful. I think there might be scope for additional wording.
11:03
<ryzokuken>
https://github.com/zalari/tcq/tree/feature/minimal-dockerized
11:09
<Michael Ficarra>
doesn't deno have a free tier?
11:10
<jkup>
also maybe cf pages/workers? (if we are rewriting)
11:20
<Christian Ulbrich>
We still need a persistent service for the socket.io/ websocket thing. Idea is to de-couple this and have the rest being serverless / cloud flare, etc ...
11:22
<canadahonk>
cf workers support websockets i think
11:22
<jkup>
could do with durable objects I think? (Not pushing for cf, just thinking of member companies that offer hosting)
11:22
<canadahonk>
https://developers.cloudflare.com/workers/examples/websockets/
11:23
<canadahonk>
not pushing either but has been nice in my experience
11:23
<canadahonk>
also they have a very generous free plan iirc
11:23
<Christian Ulbrich>
canadahonk: You are right! -> https://developers.cloudflare.com/workers/examples/websockets/ interesting!
11:23
<nicolo-ribaudo>
Who's chairing?
11:23
<canadahonk>
happy to help with dev btw :) maybe we should have a separate channel or something?
11:24
<nicolo-ribaudo>
Who's chairing?
(there is a point of order about people not following the queue)
11:28
<eemeli>
Rounding modes in Intl.NumberFormat: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/NumberFormat/NumberFormat#roundingmode
11:29
<nicolo-ribaudo>
In these docs "half even" only talks about integers, and not to "round to 1 fractional digit"
11:29
<nicolo-ribaudo>

Ties towards the nearest even integer

11:31
<nicolo-ribaudo>

Ok yes it looks at the 0.

new Intl.NumberFormat("en-US", { minimumFractionDigits: 1, maximumFractionDigits: 1, roundingMode: "halfEven" }).format(0.95)

returns "1.0"

11:34
<snek>
could someone with permission to do so create a TCQ development channel?
11:38
<Duncan MacGregor>
This is consistent with my understanding of rounding modes in IEEE-754 and Java's DecimalFormatter.
11:40
<Duncan MacGregor>
I thought I had found a bug in Decimal formatter once. Luckily I checked very carefully, and it turned out the my test vectors had a bug and Guy Steele wasn't wrong. :-)
11:54
<nicolo-ribaudo>
Steve Hicks I'd argue 1.1 does not exist in IEEE754, and instead when you try to get to thet number you get to 1.1000000009870432
11:56
<Michael Ficarra>
I would say all reals exist in IEEE754 binary64, they just share a single representation among many reals
11:56
<Michael Ficarra>
so each binary64 value is a range of reals
11:56
<Michael Ficarra>
there's one particular real associated with each of these ranges that we use to talk about that range
11:57
<Michael Ficarra>
(this is only in reference to finite binary64s)
11:57
<nicolo-ribaudo>
It's not used just to talk about it but also to do math on it
11:57
<Michael Ficarra>
yeah, that's right
12:04
<Michael Ficarra>
please advance the queue
12:04
<Michael Ficarra>
@Rob Palmer
12:05
<nicolo-ribaudo>
I can volunteer to take shared "queue advancing" responsibility
12:05
<Michael Ficarra>
we have no way to add a reply atm
12:08
<Jesse (šŸ‡ŖšŸ‡ø)>
I think I should prepare a diagram showing the different spaces here: digit strings, binary64 values, decimal128 values, real numbers
12:10
<snek>
tcq development room https://matrix.to/#/!FnKBZWyZXEOJHuOtWy:igalia.com?via=igalia.com&via=matrix.org
12:22
<rkirsling>
yeah it seems a bit weird to auto-object on somebody's behalf
12:24
<snek>
i feel like increasing the "strength" of stage 2 criteria based on the size of the proposal just needlessly slows down smaller proposals
12:25
<TabAtkins>
Yeah, this is definitely a Stage 2-compatible concern.
12:26
<TabAtkins>
(I say that as someone who definitely agrees with Waldemar on the merits.)
12:30
<waldemar>
No one was increasing the "strength" of stage 2 criteria. Stage 2 entrance requires the major semantics to be worked out. For something that's purely a math function the throwing behavior on valid input is major semantics.
12:59
<Rob Palmer>
Meeting resumes in one minute!
13:00
<Michael Ficarra>
when you consider how many binary64s don't throw, it's a very small set of inputs we're talking about
13:03
<snek>
i don't think the input domain or that the function only performs a single operation is really relevant in this case. but i guess there is contention here.
13:10
<canadahonk>
could someone else take over notes from me please? (need to work on clamp stuff)
13:10
<Duncan MacGregor>

So, I think I should clarify what I was saying about the rounding of 0.15, and why I say that rounding to 0.1 is a bug. 0.15 translates to a float 64 with the following raw bits: 0x3fc3333333333333. This number is not quite 0.15, but is shortest decimal representation of a decimal number that is closer to the float 64 value than any other float 64 value. The raw bits 0x3fc3333333333332 are closest to 0.14999999999999997 and the raw bits 0x3fc3333333333334 are closest to 0.15000000000000002.

So the first stage of rounding a floating point number to a number of decimal digits (or significant figures) is to convert it to a stream of digits because we are inherently working in the decimal domain, and then rounding should occur using whichever rounding rule you are using.

So in our example the decimal digits produced are 0.15, and then it is rounded by half even rule to 0.2. Anything else is a bug.

13:16
<bakkot>
incidentally, cite for chacha being a CSPRNG: https://www.johndcook.com/blog/2020/02/22/chacha-rng-with-fewer-rounds/
13:17
<snek>

But the results of the simple poker test are harder to understand. What is it about simulating poker that makes ChaCha(3) fail spectacularly?

13:18
<eemeli>
I didn't really understand the relevance of rounding in the Decimal discussion, given that new Decimal(n) will implicitly first convert its input into a string, and so n === Number(new Decimal(n).toString()) for all typeof n === 'number'.
13:20
<Michael Ficarra>
We're not using Chacha3 lol, we're using Chacha12
13:20
<Michael Ficarra>
well, well over the bar for a CSPRNG
13:21
<snek>
yeah for sure
13:21
<Michael Ficarra>
Chacha20 is only used in TLS because we didn't have as much confidence in it at the time
13:22
<bakkot>
https://eprint.iacr.org/2019/1492.pdf
13:23
<bakkot>
"Too Much Crypto" is a fun title
13:24
<snek>
especially from the swiss
13:27
<Duncan MacGregor>
waldemar might be able to clarify the root of the example he was asking about. I know that various other languages have attempted to offer rounding functions that give and return float 64s, and try to avoid real conversion to the decimal domain. I know Ruby has such a function, and it has a number of issues which will never be fixed because there is code out there that depends on its bugs. Various string formatting implementations have also had bugs.
13:28
<Michael Ficarra>
this is why I use 2DES, 3DES is too many
13:31
<eemeli>
Ok, but how does any of that impact anything around the Decimal proposal?
13:32
<Duncan MacGregor>
Sadly, in the case of 3DES, too much is never enough.
13:33
<bakkot>
if I never have to write fischer-yates again I'll be happy
13:36
<Duncan MacGregor>
I think it's thoroughly in the weeds. We seem to end up circling back to rounding questions whenever Decimal is discussed and I'd far rather we write this stuff down and avoid retreading the same ground repeatedly.
13:37
<bakkot>
I appreciate tab's repeated nods towards directing people to the crypto API so they are not misled
13:37
<bakkot>
I wish the crypto API had as much care for not misleading people
13:37
<bakkot>
what a terrible API
13:37
<bakkot>
also it still only offers pbkdf2
13:38
<bakkot>
sidebar, any implementers in the room please direct your attention to https://github.com/twiss/webcrypto-modern-algos
13:38
<Christian Ulbrich>
x-posting from TDZ, but I found -> https://medium.com/@betable/tifu-by-using-math-random-f1c308c4fd9d a very good intro, into the topic of good randomness...
13:45
<snek>
pretty banger ideas from mark here
13:46
<Michael Ficarra>
there's a reason MM has his reputation
13:54
<bakkot>
static and prototype methods of the same name on the same class! let's do it
13:54
<Michael Ficarra>
so I guess we're doing Random.Seeded now
14:11
<bakkot>
Michael Ficarra and I came up with a reasonably comprehensive test plan for Iterator.zip, incidentally https://github.com/tc39/test262/issues/4112#issuecomment-2415235086
14:11
<bakkot>
not quite as nice as this one
14:11
<bakkot>
it's a very useful exercise though
14:11
<bakkot>
if anyone wants to help .zip advance, PRs implementing these tests welcome
14:12
<Michael Ficarra>
šŸ™ someone please write these tests
14:34
<ljharb>
what would be the difference between chunks and windows if windows does option 3? (nvm, put it on the queue)
14:35
<nicolo-ribaudo>
Chunks slides by the chunk size, window by (by default) 1
14:36
<ljharb>
ah ok
14:36
<ljharb>
and chunks has no default size?
14:36
<nicolo-ribaudo>
No, you need to specify how big you want the chunks
14:36
<ljharb>
ok so with option 3, windows is just chunks of 1?
14:36
<nicolo-ribaudo>
Like you have to specify how big you want the windows
14:37
<nicolo-ribaudo>

[1, 2, 3, 4, 5]

  • windows (size 2): 12, 23, 34, 45
  • chunks (size 2): 12, 34, 5
14:37
<ljharb>
ahhh right
14:37
<ljharb>
thank you
14:37
<ljharb>
(my realization is that windows "repeats" values by sliding, chunks does not)
14:38
<Richard Gibson>
neither has a default size, but they differ in how results overlap (slide 3 and slide 4 visualize this well)
14:40
<kriskowal>
(iā€™m on my way to go camping but) in case it gets missed, iā€™m recommending that the windows() algorithm return an array with any iteration values that were consumed but not produced in any window, so they can be disposed of properly, which only occurs if the producer does not have enough values to fill a single window.
14:40
<TabAtkins>
I'm no longer in the meeting because I'm busy cooking, but big +1 from me for stage advancement
14:41
<kriskowal>
(and also would like to see concrete uses of windows(). I know of at least two sliding window algorithms, but canā€™t imagine doing TCP or gzip this way.)
14:42
<nicolo-ribaudo>
Probably 80% of the times I use the "index" parameter in .map&friends is because I need to access the previous or next item
14:42
<nicolo-ribaudo>
Which means I need .windows(2)
14:42
<TabAtkins>
I'd hang to go track down where, but I've definitely written windows by hand (and chunks)
14:42
<bakkot>
ljharb yes, returning from a generator is the case that populates the value of the { done: true, value: _ } object
14:43
<ljharb>
thanks, glad i remembered right
14:43
<bakkot>
I wonder how many people in the world know that fact
14:43
<bakkot>
mid double digits, probably? at most?
14:44
<kriskowal>
In those cases, I assume you also want length-1 iterations and can tolerate 0 iterations when thereā€™s only one value?
14:44
<nicolo-ribaudo>
Hold on let me find an example
14:45
<kriskowal>
(I have definitely used index to get at a neighbor before, so this answer is on the right track.)
14:47
<nicolo-ribaudo>

Ok one example from the Babel codebase is

nums.forEach((num, i) => {
  if (i > 0 && nums[i] <= nums[i - 1]) throw new Error()
});
14:47
<nicolo-ribaudo>
Where I need to explicitly skip the first iteration to only actually work on pairs
14:47
<kriskowal>
Itā€™s useful. I think that using it for the remainder is good because it hides the remainder in the common case, but gives the tiny minority a place to stand if they need it.
14:48
<bakkot>
it does also make it more expensive for everyone just for the benefit of the tiny minority, though
14:48
<bakkot>
which seems bad
14:48
<kriskowal>
how so? you have to accumulate the window array regardless
14:49
<bakkot>
you don't have to allocate an actual array
14:49
<bakkot>
it's strictly internal
14:50
<kriskowal>
itā€™s allocated in something. you mean that you avoid the reĆÆfication of the internal array?
14:51
<bakkot>
yes
14:51
<sffc>
Call sites of windows in the icu4x codebase: https://github.com/search?q=repo%3Aunicode-org%2Ficu4x+%22.windows%28%22&type=code
14:51
<bakkot>
doing allocations in C++ is cheap
14:51
<bakkot>
allocating JS objects is expensive
14:51
<bakkot>
relatively speaking
14:51
<kriskowal>
i think that cost will vanish in comparison to the cost of the happy path for this algorithm
14:52
<jkup>
Can someone advance the queue?
14:52
<bakkot>
there is no reason for this algorithm to have any allocations on the happy path unless you are doing manual iteration
14:52
<bakkot>
( https://docs.google.com/document/d/1M5S-u3N3vQkVBGFCoaYt_ABPGl0EW16QQrvDBaY2FiE/edit )
14:52
<kriskowal>
windows() allocates iteration results and an array for the value of each iteration result, no?
14:52
<ljharb>
well, it'd have an array per window/chunk, surely, but no more than that
14:53
<bakkot>
see my link
14:53
<ljharb>
that's about the iteration result
14:53
<kriskowal>
Cool, so merely a window length array for each iteration.
14:53
<bakkot>
ah yes it does of course have to allocate the chunk
14:53
<ljharb>
the value is an allocation too
14:53
<ljharb>
btw luca ty for doing the github search, i thought about it but am too tired
14:54
<Richard Gibson>
sffc do any of those speak to the question of what to do when there aren't enough elements to fill a window?
14:54
<kriskowal>
The champions arguably could propose a variant of this algorithm that allocates a single array up front and reuses it by shifting and pushing. Then theyā€™d just return the thing at the end at no extra cost. Thatā€™s the optimized case.
14:54
<ljharb>
that proposal would not be considered acceptable by some :-)
14:55
<kriskowal>
But shifting and pushing is a different performance character for large windows. Probably not the majority case.
14:56
<kriskowal>
Also, my recommendation does not require reĆÆfying the final chunk array unless there were too few elements to send a single iteration. Otherwise, the final value should be undefined.
14:57
<jkup>
this is inside a rust codebase, so that means empty returns?
14:57
<bakkot>
ah, that's fair
14:57
<bakkot>
I was imagining always having an array
14:59
<Michael Ficarra>
I didn't give a summary but I guess we're moving on
14:59
<nicolo-ribaudo>
Michael Ficarra
Steve Hicks left a comment that a whole separate method just because we cannot agree on an edge case seems overkill. I tend to agree
14:59
<Michael Ficarra>
I'll add it to the notes later I guess
14:59
<Michael Ficarra>
I'll create an issue where people can leave feedback and post it here
15:01
<Richard Gibson>
the uses mostly seem like .windows(2) verification that the inputs are sorted and/or unique, for which the best-aligned behavior is to not yield an incomplete window (e.g., every single-element iteration is sorted and duplicate-free)
15:09
<bakkot>
Michael Ficarra speaking of summaries, one of the bullet points in your summary of yesterday's iterator sequencing item is just "* Pull request #1923, access .value on the final IteratorResult object"
15:09
<bakkot>
it does not say any things about this pull request
15:09
<Michael Ficarra>
šŸ¤·ā€ā™‚ļø I haven't opened the notes doc at all yet this meeting
15:10
<Michael Ficarra>
I will review the summaries when I review the notes after the meeting
15:10
<bakkot>
I just wanted to know what the decision was
15:10
<bakkot>
we're backing out all the yield* stuff?
15:16
<Michael Ficarra>
yep
15:16
<Michael Ficarra>
all of it
15:30
<kriskowal>
Iā€™m adding ā€œdeltas and deltas of deltasā€ to the pot for motivating use cases for windows(2) specifically. For those algorithms, thereā€™s an expectation of quantity-1 total iterations, with no desired recourse for a remainder.
15:54
<Michael Ficarra>
yeah I think we gave more than enough justification to keep windows
16:06
<ljharb>
SeededPRNG got stage 2 today, and was on the agenda as already being stage 1, but i can't find anywhere in the notes indicating it ever had stage 1 before. can someone help me find that? (cc TabAtkins)
16:47
<TabAtkins>
ljharb: The Stage 1 request was discussed back in Jan 2018 https://github.com/tc39/agendas/blob/main/2018/01.md, but I can't find the actual notes (links are broken in https://github.com/tc39/Reflector/issues/116)
16:48
<ljharb>
https://github.com/tc39/notes/blob/main/meetings/2018-01/jan-23.md#13iif-mathseededrandoms-for-stage-1 ?
16:49
<TabAtkins>
that looks right. It ends with "Conclusion: stage 1 acceptance"
16:49
<ljharb>
perfect, thanks!
16:49
<TabAtkins>
(I can't believe it's been 7 years, but hey, COVID fucked everything.)
16:51
<ljharb>
did we select reviewers for stage 2.7?
16:53
<ljharb>
if not, we should do that tomorrow morning first thing
17:11
<bakkot>
I am not going to be in the room tomorrow morning but will volunteer as a reviewer
17:35
<eemeli>
I transferred the https://github.com/tc39/proposal-intl-keep-trailing-zeros repo to the tc39 org earlier today. Could I also be granted admin rights on that repo?
17:37
<ljharb>
i set you to "maintain" but can set you to "admin" if there's something you need that level for?
17:44
<eemeli>
The current level doesn't appear to let me e.g. set the repo's URL or description, which would be quite nice.
17:46
<ljharb>
ah oops, you were set to "write" - try now? i'll bump it higher if that doesn't do it
17:46
<eemeli>
Thanks, looks good now!