14:59
<ryzokuken ๐Ÿ‡ท๐Ÿ‡ธ>
Draft Schedule is up on the Reflector: https://github.com/tc39/Reflector/issues/545
16:58
<Rob Palmer>
The meeting begins in 1 minute!!!
17:00
<Michael Ficarra>
FYI we still don't have a TCQ link
17:03
<nicolo-ribaudo>
If Google meet is stuck on "Getting ready... You'll be able to join in just a moment", is it a problem on my side?
17:03
<ljharb>
https://tcq.app/meeting/RKti
17:03
<ljharb>
probably, there's a bunch of us in it
17:04
<nicolo-ribaudo>
Ok thanks, time to restart everything
17:12
<nicolo-ribaudo>
Chairs, last minute change. It seems like I will be the one presenting the TG4 status report
17:40
<littledan>
I like Saminaโ€™s idea to have a liaison from TC39 to IETF, analogous to our close relationship with W3C and Unicode. Is anyone interested in playing this role?
17:45
<saminahusain>
In the past, I think 2021, Mathew Miller was the liaison contact from tc39
17:49
<bakkot>
sorry, I forgot to add to the agenda constraints that I'm not available the first hour today
17:50
<bakkot>
hope we can get to my iterator closing topic after that
17:54
<nicolo-ribaudo>
Did Chris change which diff he's showing?
17:54
<Michael Ficarra>
yes
17:57
<Michael Ficarra>
whoever is doing notes right now, please refer to https://github.com/tc39/notes/blob/main/delegates.txt for abbreviations, don't just make something up
18:15
<Michael Ficarra>
@eemeli please add a link to the slides in the notes
18:22
<nicolo-ribaudo>
I always assumed the motivation for this proposal was about ergonomics and not really about performance
18:27
<eemeli>
@eemeli please add a link to the slides in the notes
There were no slides. The presented material was the readme of the proposal repo.
18:28
<eemeli>
https://github.com/eemeli/proposal-intl-currency-display-choices
18:29
<rbuckton>
We don't throw when you mutate a Map while iterating. I'd almost rather getOrInsertComputed just overwrites the key, whether it was set or deleted during the callback. If you want full locking, you can implement it yourself?
18:30
<shu>
rbuckton: that IS my understanding of the non-throwing approach
18:30
<shu>
is it not?
18:31
<bakkot>

the four options:

// common prefix
if (map.has(key)) return key;
let value = callback(key);

// option 1
if (map.has(key)) throw;
map.set(key, value);
return value;

// option 2
map.set(key, value);
return value;

// option 3 (not proposed)
if (map.has(key)) return map.get(key);
map.set(key, value);
return value;

// option 4 (not proposed): change `Map.prototype.set` to check if we're currently in a `getOrInsertComputed` for this map

sounds like people like option 2 (which I'm also happy with)

18:32
<nicolo-ribaudo>
I dislike these names but I have no constructive suggestion
18:32
<rbuckton>
I personally prefer getOrAdd/getOrCreate, but I've been too busy over the last few weeks to comment on the issue :/
18:33
<ljharb>
bakkot: option 3 would basically be "actual upsert"? or is that something else
18:33
<bakkot>
no
18:33
<bakkot>
we're accounting for mutation during the callback
18:33
<bakkot>
not passing new values to the callback
18:33
<ljharb>
ah k
18:35
<rbuckton>
Regarding the naming, neither of these methods are actually an "upsert", which normally consists of either "updating an existing value" or "inserting a new value", hence the portmanteau of "update" and "insert".
18:45
<Mikhail Barash>
University of Bergen's students have written a tutorial on upsert proposal prototype implementations in SpiderMonkey and V8. The current preliminary (rough) draft is available here: https://github.com/bldl/emplace-spidermonkey . It currently lacks the description of the implementation in V8; this will be added soon.
18:47
<ljharb>
https://github.com/tc39/proposal-is-error/issues/7
18:47
<bakkot>
chairs: can you make sure my "iterator helpers close receiver on argument validation failure (10m, Kevin Gibbons)" topic doesn't get lost? currently it's up with the already-presented items on the agenda
19:00
<Aki>
ljharb: reminder to record your summary/conclusion
19:00
<Aki>
bakkot: see ๐Ÿ‘†๐Ÿป
19:01
<nicolo-ribaudo>
You can get an AsyncContext candy
19:58
<Rob Palmer>
Plenary resumes in one minute!
20:08
<nicolo-ribaudo>
Can we get the transcriptioner to disable automatic-newline?
20:09
<ryzokuken ๐Ÿ‡ท๐Ÿ‡ธ>
how bad is it? should I file a POO?
20:09
<nicolo-ribaudo>
It's just annoying
20:09
<nicolo-ribaudo>
Because if I add a newline anywhere then the line is too short and looks bad
20:09
<ljharb>
(also more than one space after a period)
20:20
<nicolo-ribaudo>
This note taker is very good
20:20
<nicolo-ribaudo>
They are even adding parentheses in function calls
20:43
<nicolo-ribaudo>
The results of the temp check are "we should flip a coin"
20:45
<bakkot>
I can't speak but note:
20:45
<rbuckton>
My concern is that reuse promotes weird corner cases
20:45
<bakkot>
this means you can't implement concat with a generator
20:45
<rbuckton>
i.e., accessors, proxies, etc.
20:46
<shu>
yeah i'm confused by the flipped polarity
20:46
<shu>
why are agoric folks okay with concat doing reuse?
20:46
<nicolo-ribaudo>
this means you can't implement concat with a generator
function* concat(...iterators) {
  for (const it of iterators) yield* it;
}
20:46
<nicolo-ribaudo>
Since yield* re-uses
20:46
<bakkot>
ah, true
20:46
<shu>
oh i see
20:46
<bakkot>
ok then i am indifferent
20:46
<rbuckton>
this means you can't implement concat with a generator
If we don't reuse, we can use a generator but not yield*
20:47
<bakkot>
though return is a little trickier
20:47
<rbuckton>
function* concat(...iterators) {
  for (const it of iterators) 
    for (const el of it)
      yield el;
}
21:00
<Michael Ficarra>
Since yield* re-uses
(except in JSC and LibJS)
21:02
<Chris de Almeida>
https://github.com/tc39/proposal-shadowrealm/issues/393
21:17
<nicolo-ribaudo>
waldemar There is also random which is technically I. I guess the actual principle is "web APIs don't expose I/O other than what is already exposed by ECMAScript itself"
21:28
<shu>
brother i don't know of any API that doesn't allocate memory
21:30
<Richard Gibson>
brother i don't know of any API that doesn't allocate memory
destroy()
21:31
<shu>
where do you think the stack space needed to push the frames to make the call comes from?
21:31
<Richard Gibson>
lol
21:33
<Chris de Almeida>
should we consider elaborating on stage 3 acceptance criteria re: tests being merged?
21:33
<shu>
Chris de Almeida: i honestly thought that was already the case
21:33
<Chris de Almeida>
it's hand-wavy
21:33
<shu>
like what's the point of having tests that are floating out there but not merged
21:33
<Chris de Almeida>

The feature has sufficient testing and appropriate pre-implementation experience

21:34
<shu>
sorry, i meant i thought it was the case that being merged is a necessary condition for being considered "sufficient testing"
21:34
<shu>
not just that some tests were written, somewhere
21:34
<Chris de Almeida>
I understand; the question is, would it help to make the text more explicit?
21:34
<ljharb>
i think we've generally considered merging a requirement
21:35
<ljharb>
but we also don't usually block advancements on procedural things whose completion is unambiguous - we usually grant conditional advancement pending that thing (a PR review, a PR merge, resolving an open question between known stakeholders, etc)
21:40
<Chris de Almeida>
generally speaking, is the status quo that tests have been merged before asking for stage 3?
21:40
<ljharb>
for non-large proposals, yes, i believe so
21:42
<shu>
i think how much leniency we give definitely will vary case-by-case. in the particular case of ShadowRealms, it got to stage 3 the first time on that promise that the integration work will be done, and the ball got dropped
21:52
<bakkot>
ptomato I am happy to open an issue about crypto.subtle somewhere if you'd like. is the shadowrealm proposal the right place for that kind of bikeshedding issue? also if you want to just look at it without bothering with an issue that's fine
22:10
<ptomato>
ptomato I am happy to open an issue about crypto.subtle somewhere if you'd like. is the shadowrealm proposal the right place for that kind of bikeshedding issue? also if you want to just look at it without bothering with an issue that's fine
thanks! in proposal-shadowrealm is fine, but if you don't want to bother with an issue that's also fine; I've got it on my todo list
22:13
<bakkot>
dminor: mozilla doesn't usually bother with standards-positions on TC39 proposals, yeah? https://github.com/mozilla/standards-positions/issues/1133
23:04
<Michael Ficarra>
sorry, i meant i thought it was the case that being merged is a necessary condition for being considered "sufficient testing"
IMO, the (significantly) more important bit is just that someone has done the elaboration of all of the edge cases and confirmed that we are indeed specifying the thing we want to specify
23:07
<Michael Ficarra>
and if someone has reviewed and said "yes, these look both correct and exhaustive to me", then it has met that criterion
23:15
<shu>
i'm hoping the delta between that last bit, where someone has reviewed and +1'd it, and merging it into a test suite, is trivial
23:15
<shu>
if it isn't then we should rework the test suite workflow
23:29
<Michael Ficarra>
well atm the test262 maintainers group holds those keys and they may have additional criteria that they need to review for before it gets merged
23:37
<dminor>
dminor: mozilla doesn't usually bother with standards-positions on TC39 proposals, yeah? https://github.com/mozilla/standards-positions/issues/1133
Correct, we don't normally do this