TC39 Delegates
2026-03-10
plaintext logs
prev next
source on github
13:32
<dminor>
I think an update is still useful, based on activity in the proposal repo it looks like it's been five years or so since it's been discussed.
13:48
<Rob Palmer>
The video link for the plenary meeting is now available via the sign in form.
13:49
<Rob Palmer>
Please can someone confirm that it works.
13:50
<eemeli>
I see a brick wall.
13:51
<eemeli>
Also, might be good to remove the Google Meet link from the TC39 calendar event, esp. as it's not the right one.
13:57
<nicolo-ribaudo>
Can you update the template to also have the sign-in form at the top? It's quite difficult to find every time, especially because it does not actually say "form" so I always forget what to search for 😅
14:01
<Michael Ficarra>
I just had the same issue
14:01
<Michael Ficarra>
proper Ctrl+F is "video"
14:02
<waldemar>
Folks, when going for stage advancement, please post the correct links to the specs by the deadline. A long spec going for stage 2 was posted just 3 hours ago. That's not enough time to review it.
14:03
<waldemar>
I reviewed the spec that was posted by the deadline, only to find out just now that the wrong link was posted.
14:05
<Michael Ficarra>
@waldemar I don't understand, the agenda hasn't changed at all today: https://github.com/tc39/agendas/commits/main/2026/03.md
14:06
<waldemar>
The document behind the link was replaced.
14:06
<Michael Ficarra>
also, we have rules that allow anyone to block based on that criterion alone, and delegates should have no reservations about exercising that rule
14:07
<waldemar>
This is the 3rd time this happened in the last 3 meetings.
14:08
<bakkot>
bot is using a new service which is capable of diariazation so it is a better experience than previously
14:10
<Aki>
Book your hotels for Amsterdam now bc it's a busy season to start with and also Harry Styles is performing stadium shows every night of the meeting
14:12
<nicolo-ribaudo>
Can we get a group discount for that?
14:17
<Michael Ficarra>
my merch is already on the way
14:18
<Chris de Almeida>
sign-in link for the meeting has been added to the top of the reflector post
14:20
<jkup>
Aki: aware
14:20
<Michael Ficarra>
working on it
14:22
<nicolo-ribaudo>
Folks put a hoodie on the mic
14:24
<bakkot>
the transcription is at least capable of handling the echo
14:24
<nicolo-ribaudo>
Other than notes volounteers we need a mic volounteer
14:29
<nicolo-ribaudo>
Wait, we don't have human transcribers anymore?
14:29
<Michael Ficarra>
we missed like 5 minutes of transcription
14:32
<nicolo-ribaudo>
bye bye
14:37
<Chris de Almeida>
nicolo-ribaudo: please rejoin
14:37
<bakkot>
I feel like we should not announce when these things are unanimous because that gives information about everyone's votes
14:40
<nicolo-ribaudo>
The re-export PR was actually Kevin's :)
14:43
<eemeli>
Audio dropped.
14:44
<bakkot>
came back at least for me
14:46
<ptomato>
if you are interested in joining the test262 reviewers, we could use some extra hands!
14:56
<bakkot>
oh no do I not transcribe myself
14:56
<bakkot>
that makes sense but is silly
15:04
<mgaudet>
(Can we mute the room?)
15:04
<mgaudet>
(echo is pretty bad)
15:04
<eemeli>
If we agree on the problem statement, how is this different from Stage 1?
15:05
<nicolo-ribaudo>
Rob Palmer: / Chris de Almeida I went ahead and muted the room, since Mark speaks in long paragraphs anyway so it's not a quick back and forth
15:05
<nicolo-ribaudo>
Remember to unmute when he's done
15:05
<mgaudet>
(thank you!)
15:16
<nicolo-ribaudo>
If we are just defining the protocol and not the object that implements it, we could just not expect the callback called by the implementation to be called synchronously, right? Similarly to how for thenables we assume that the callback could be called asynchronously, but custom thenables can still call it synchronously
15:17
<ljharb>
bakkot: lol maybe "task cancellation"?
15:20
<bakkot>
In the design I was envisioning, we'd be specifying it fully, but in principle we could leave it up to implementations I guess
15:21
<bakkot>
but, given that all existing implementations do call it synchronously, I think that would end up being a de-facto requirement anyway, so it seems silly not to write it down
15:27
<nicolo-ribaudo>
One reason is that promises have two possible "done" states while abort signals only have one
15:28
<nicolo-ribaudo>
So the only two that could even make sense are .any and .all, and not the rest
15:29
<bakkot>
I could imagine .all being useful in some scenarios (e.g. a multiplayer system, where you want to cancel a request only when every requester cancels) but I also have never encountered one in real life
16:10
<James M Snell>
abort signals have two states... possibly three: Pending and Aborted/Triggered are the two definite states... Never is potentially a third.
16:11
<James M Snell>
Never can, in some cases, be considered a second "done" state... only reason I mention
16:11
<Justin Ridgewell>
Is there an API exposed that makes it differentiable from pending?
16:16
<ljharb>
https://github.com/tc39/proposal-error-stack-accessor/issues/9
16:16
<danielrosenwasser>
Re <details>: do they really not render tables even if you add 2-3 leading/trailing newlines?
16:25
<Michael Ficarra>
I think the problem is you can't include HTML tags in a GFM table
16:26
<Michael Ficarra>
so the whole thing would have to be rewritten as HTML, which isn't the worst thing ever
16:27
<rbuckton>
This sounds more like a CountdownEvent (C#)/CountDownLatch (Java)/countdown_latch (Rust)/etc. and is maybe a bit outside of the purview of cancellation and more aligned with general async and/or thread coordination primitives.
16:28
<bakkot>
certainly you could build it on top of a semaphore, yes
16:43
<rbuckton>
Semaphore is a slightly different concept. Semaphore lets up to n actors in until all spots are filled. Countdown keeps up to n actors out until all spots are filled.
16:58
<dminor>
Adding something late to the agenda does not mean we'll drop our current work to prioritize reviewing it.
17:55
<Rob Palmer>
Delegates!!! We resume in 5 minutes. Please return from the lunch room!
18:01
<Aki>
Should we be able to hear you?
18:02
<Rob Palmer>
yes, now
18:03
<Rob Palmer>
you haven't missed anything
18:03
<Rob Palmer>
we were just getting sorted
18:47
<Justin Ridgewell>
Converting 1.50miles to cm is 241401.6 cm (if infinite precision). But really, it's 241000cm when keeping sig figs. Certainly not 241000.00 or 241401.60 and keeping the number of fractional digits.
18:49
<Olivier Flückiger>
I think regardless how you define what the supplied precision is and how it is transformed across conversions and roundings, it will always be confusing in some of the usecases.
18:50
<Olivier Flückiger>
Personally I think less is more here, since the interpretation will be super domain specific.
18:50
<waldemar>
How about the other example of converting 1 1/16 inches (1.0625 in) to mm?
18:51
<Justin Ridgewell>
How precise is 1/16th?
18:52
<waldemar>
That's the question. The point I'm making is that the answer to that question is not apparent from the numerical values themselves.
18:53
<Justin Ridgewell>
But the precision is specified when creating the amount? I agree that it should be specified when constructing the amount directly, because our fp numbers don't carry real precision.
18:53
<ptomato>
I would say 2.41e5 cm? I always learned trailing zeroes are sigfigs
18:53
<Justin Ridgewell>
This would be ok with me
18:54
<Justin Ridgewell>
I'd rather see 0s than scientific, but they interpretation is the same to me.
18:55
<Justin Ridgewell>
(My teachers would say to specify . if the non-fraction digits were precise, eg 241000 is different than 241000.)
19:00
<Jesse>
some juggling can be done with a poor man's rational arithmetic -- even staying in Number land -- that can solve some of these issues
19:00
<Jesse>
but even that presumably has its limits
19:02
<Jesse>
we can store the conversion factors in CLDR's units.xml in the amount spec and define a ConvertTo AO that would give exact answers in many cases, all with Numbers
19:03
<Jesse>
e.g. (x/12)*12 would give x, exactly
19:04
<Rob Palmer>
Just outside the meeting room is cheese. Dmitry brought it from Amsterdam.
19:04
<Rob Palmer>
One of the waffles contains honey
19:06
<bakkot>
I need to step away from my computer; I have set the bot to restart in 500 seconds but if it doesn't, sorry, I'll be back asap
19:20
<jkup>
This is such a nice treat. Thank you Dmitry!
19:30
<Ashley Claymore>
+1 thank you Dmitry, all 3 cheeses were really tasty!
19:36
<nicolo-ribaudo>
The most intuitive behavior would be to consider zeros as significant for small magnitudes and not for large magnitudes
19:36
<nicolo-ribaudo>
Not saying we should do it
19:37
<nicolo-ribaudo>
I'm very curious to hear waldemar's point about "0.0 being a misunderstanding of significant digits"
19:38
<nicolo-ribaudo>
Hopefully we have enough time in the timebox for it
19:41
<Richard Gibson>
to add context while it's still fresh, the above was a comment about new Intl.NumberFormat("en", { maximumFractionDigits: 5 }).format("1.2e-10") returning "0.0" rather than "0" or "0.00000". And I agree with the comment; it seems to be conflating "significant digits" with "fraction digits".
19:47
<Michael Ficarra>
would we want the frozen objects created by this to have a null prototype?
19:48
<ljharb>
that'd be nice, but i don't think they need to
19:48
<bakkot>

Object.getPrototypeOf(Composite({})); // Object.prototype

per the readme

19:48
<bakkot>
dunno if this is intended
19:48
<bakkot>
dunno how I feel about it
19:48
<bakkot>
anyway cross-realm considerations are probably not the high order bit
19:48
<Andreu Botella>
bakkot: The bot doesn't seem to be transcribing you in particular
19:48
<bakkot>
yup
19:48
<bakkot>
sorry
19:49
<bakkot>
artifact of how it's wired
19:49
<bakkot>
I will go back and add myself
19:49
<eemeli>

Yeah, the proposal's current behaviour is a somewhat accidental result of how significant digits are accounted for, and the way that zero as a whole is a bit of a corner case. I'm pretty sure that we'll also need to do this:

let nf = new Intl.NumberFormat("en", { maximumFractionDigits: 5 })
nf.format('1.2e-10') // '0.00000' (currently '0.0')
nf.format('0.00000000012') // '0.00000' (currently '0.0')
19:49
<bakkot>
I'll get a second computer for my presentation if I get to do my presentation
19:49
<eemeli>
Yes, because Object.prototype isn't immutable.
19:50
<Michael Ficarra>
but it's after lunch time
19:50
<bakkot>
I ended up having other things to do over lunch
19:51
<bakkot>
also because this lets you avoid the .constructor and .__proto__ footguns! at least partly
19:51
<rbuckton>
I assume Arrays created wouldn't have a null prototype?
19:51
<bakkot>
yeah Arrays are more problematic
19:52
<bakkot>
it's probably not worth omitting Object.prototype if we can't omit Array.prototype
19:52
<bakkot>
... I guess we could make a cross-realm immutable ArrayLikePrototype...
19:53
<rbuckton>
IMO, it's inconsistent, not necessarily bad.
19:53
<bakkot>
there's just no point in it really
19:53
<bakkot>
if you can't do both
19:53
<bakkot>
(or, very little point anyway)
19:54
<eemeli>
Object.assign(Object.create(null), ['foo', 'bar'])
19:54
<ljharb>
Array.isArray(that) => false
19:55
<rbuckton>
So, no .map or .filter on the result then?
19:57
<Chengzhong Wu>
does Kevin's bot transcribe for himself?
19:57
<rbuckton>
We could just add an ImmutableArray prototype that is itself frozen, unlike Array, where instances are also an Array Exotic Object.
19:57
<Michael Ficarra>
@Chengzhong Wu not yet
19:57
<Michael Ficarra>
at some point in the future, it may
20:00
<bakkot>
(more precisely, it is transcribing my audio out, and when I talk it doesn't go into my own audio out)
20:01
<rbuckton>
You could use something like Voicemeeter to map your audio in and out to a virtual output and transcribe that.
20:01
<bakkot>
yeah I just haven't had time to mess around with it during the meeting
20:17
<bakkot>
Olivier Flückiger: I am pretty sure SABs do not make the algorithm observable, because the lookups aren't observbable or synchronizing
20:19
<Olivier Flückiger>
I think you can observe the order of writes
20:19
<keith_miller>
bakkot: Oh, also with an iterable wouldn't the engine effectively have to copy the iteration results into a buffer anyway? There could be arbitrarily many things in the iterable and an engine can't (and probably wouldn't want to anyway) drive it twice
20:19
<bakkot>
writes from another thread? only if the reads are synchronizing, I would think?
20:20
<keith_miller>
Yeah, the memory model says the reads/writes can happen in any order unless there's a synchronizing event
20:21
<bakkot>
yes but that's no worse than making the user do that manually, except for (as you point out) the iteration protocol objects themselves, which I was kind of assuming would not be realized in the normal case
20:29
<Olivier Flückiger>
Atomics.store() is seq consistent. So two collaborating threads can find out if the search is left-to-right or the reverse.
20:29
<Olivier Flückiger>
which means a right-to-left search would violate the spec (if the spec is written in a way that it searches left-to-right)
20:31
<keith_miller>
Yeah, I thought I replied in a thread about that, sorry. Yeah, I agree.
20:31
<keith_miller>
I was commenting on a different thing and missed the point
20:31
<ptomato>
do we have anything else in the language that would potentially have weird results with SharedArrayBuffer if the programmer doesn't implement synchronization properly?
20:31
<ptomato>
or is this the first?
20:31
<keith_miller>
But I don't think the left-to-right search is all that meaningful. The needle being SAB is more of an optimization inhibitor though
20:32
<keith_miller>
Maybe there's no way to observe that the engine cached your needle though?
20:32
<Andreu Botella>
I'll have to stop transcribing, can we have some volunteer?
20:32
<Olivier Flückiger>
agreed. I don't see a problem yet. just noting that it's kinda strange that you can probe what the implementation does internally.
20:33
<keith_miller>
i.e. there's a valid ordering such that even if the other thread does Atomics.write it can't distinguish that from the needle being cached
20:33
<waldemar>
The spec doesn't actually say whether a search is left-to-right or right-to-left. It just comes up with a location that satisfies a condition without specifying the algorithm that finds it.
20:34
<Olivier Flückiger>
(although now I am not sure anymore. I guess Atmoics.store is only seq consistent with respect to Atomics.read. So if searching uses non sequential reads, then it's again ok to implement any access order)
20:34
<Richard Gibson>
yes, I think at least half of the functions at https://tc39.es/ecma262/multipage/indexed-collections.html#sec-properties-of-the-%typedarrayprototype%-object
20:34
<rbuckton>
James M Snell: I mentioned -1 being fine, but if we are dropping iterables (and thus Array) and restricting this to only matching when the content types of the arrays match, then I lean more towards throwing to align with .set.
20:34
<Richard Gibson>
I feel the same way
20:34
<waldemar>
The spec uses SEQ-CST operations in some places but doesn't say what the synchronization mode of the reads is.
20:34
<rbuckton>
Then again, .set allows array-likes and throws
20:35
<keith_miller>
Well you could see a subsequent Atomics.store with a relaxed read in an ordering that's inconsistent.
20:36
<waldemar>
(In both cases above I was referring to the proposal's spec language as it is today)
20:36
<rbuckton>
for .set it looks like it uses SEQ-CST to read the length but UNORDERED for reads and writes.
20:36
<Olivier Flückiger>
if the read is relaxed yes.
20:36
<Olivier Flückiger>
if it's unordered then I think anything can happen
20:37
<Ashley Claymore>
well for Map you would do map.has :D
20:37
<rbuckton>
23.2.3.26.2 SetTypedArrayFromTypedArray, steps 23.b.i, 23.b.ii, 24.a.i, and 24.a.ii specify UNORDERED
20:38
<keith_miller>
Well relaxed read is unordered w.r.t. any other reads/writes?
20:38
<ljharb>
i really don't like calling it "includes on iterables" - imo it's more like, "incudes on iterators provides a generic mechanism that iterables can leverage and/or define". we spent a ton of time during the iterator helpers proposal debating whether the helpers should be on iterables or iterators, and i think that framing revives that confusion.
20:38
<keith_miller>
But actually I take it back
20:38
<waldemar>
I was referring to the proposal's spec language, not the current ES standard.
20:39
<keith_miller>
Because the ordering can happen on the non-barriering thread
20:39
<rbuckton>
Ah, my bad
20:40
<keith_miller>
So the first thread could have completed the load for the second atomic before the first atomic ever retired on the writer thread
20:40
<rbuckton>
Correction, it only throws if there is a content type mismatch (number vs bigint)
20:50
<ljharb>
i mean also, x in iterator specifically already means something ("does iterator[x] exist"), so that wouldn't make any sense anyways?
20:51
<eemeli>
And because the question currently does not make sense, I was kinda hoping we could find a way to make it make sense.
20:52
<ptomato>
function isIterator(object) { return 'next' in object; } 😛
20:52
<rbuckton>
iter.includes(x, -n) is theoretically possible, though it would mean holding onto a sliding window of n elements until the iterator is done before peforming the search.
20:52
<ljharb>
either way we'd need a non-syntax way to do it too. so it's not something that would replace the proposal, just augment it
20:52
<ljharb>
there are very few things that require syntax to do, and only a subset of those are appropriate to be in that bucket
20:54
<eemeli>
iterator[Symbol.iteratorIncludes](needle)
20:54
<ljharb>
ok, an ergonomic way :-p
20:54
<eemeli>
Ah, well, that's an entirely different question.
20:55
<eemeli>
I also don't really see why an ergonomic non-syntax way is actually needed.
20:56
<hax (HE Shi-Jun)>
Theoretically, as double-ended iterator proposal, iter.includes(x, -n) could consume n elements from the end.
20:58
<ptomato>
re. iterating more than once, I sometimes do arr.includes('one thing') || arr.includes('another') in quickly written code where performance isn't a concern
21:03
<rbuckton>
Also, before an iter.findIndex(pred) I'd love to see a more primitive operation like .takeWhile or .takeUntil, which could be used to build a .findIndex, e.g. iter.takeUntil(pred).reduce((a, b) => a + b, 0)
21:04
<rbuckton>
I've found myself frequently using some variation of .takeWhile/.skipWhile
21:06
<ljharb>
https://mrshu.github.io/github-statuses/ for those interested
21:06
<bakkot>
I don't think we intend to do findIndex
21:06
<bakkot>
it's not very useful without the ability to access by index, which is mostly just on arrays and TAs
21:06
<bakkot>
(and NodeList, I guess)
21:11
<bakkot>
sidebar: if anyone who was editing the notes has feedback, now's a good time
21:12
<bakkot>
I am especially interested in feedback from anyone who remembers doing it the last time we had automated transcription. my subjective impression is that this is much better than the previous service? not necessarily more accurate but faster and the diarization is nice. but I'm not sure if that's colored by my own expectations
22:27
<Ashley Claymore>
I thought it did an excellent job.  Not perfect but damn close. 
22:28
<Ashley Claymore>
There were a few times it fell behind and then got a bigger chunk. Hard to know in those situations if to point of order or just wait a few more moments 
22:28
<Ashley Claymore>
Do you still do your own chunking or is it fully streamed now?
22:31
<bakkot>
it's streamed; I'm waiting to get finalized tokens (it sends low-confident guesses initially) and for word boundaries but otherwise it's just passthrough as fast as I get stuff
22:32
<bakkot>
I suspect the delay might actually be on the google docs end; if I get more stuff from the transcription before my previous doc update has completed I buffer internally
22:32
<bakkot>
and the docs API like all google APIs is kind of garbage