TC39 Delegates
2024-06-11
plaintext logs
prev next
source on github
01:05
<rkirsling>
Promise.try too
I guess I won't complain that they featured my work like this ๐Ÿ˜†
06:27
<Rob Palmer>
The Zoom is up and the Sign-in form is posted on the Reflector. https://github.com/tc39/Reflector/issues/527
07:11
<Duncan MacGregor>
Is it the same sign in form for remote and in person?
07:16
<eemeli>
Yes.
07:18
<ryzokuken (TC39 ๐Ÿ‡ซ๐Ÿ‡ฎ)>
have a smooth recovery saminahusain
07:20
<Aki>
recommendation to presenters: write your summary for notes ahead of time. edit on the fly as needed.
07:23
<littledan>
top quality transcription today
07:28
<littledan>
FYI: Google Docs works badly when many people are in the doc. Please close the doc if you just have it in the background, if you're not reading or editing the notes.
07:32
<Michael Ficarra>
@littledan the recurring work was only due to Paged.js failing to break (or not break) according to the breaking rules that we wrote
07:32
<Michael Ficarra>
if a tool supports those rules, we don't need to do that work by hand
07:33
<Michael Ficarra>
for any browser vendors in the room, that tool could be your browser if you implement CSS Paged Media btw
07:34
<ryzokuken (TC39 ๐Ÿ‡ซ๐Ÿ‡ฎ)>
^ nicolo-ribaudo ๐Ÿ‘€
07:37
<littledan>
Is ryzokuken audible from remote?
07:37
<Aki>
yes
07:41
<Michael Ficarra>
@littledan in-room audio appears to be modulated separately from zoom audio
07:41
<Michael Ficarra>
if something sounds off to you, ask @eemeli to adjust it
07:42
<Michael Ficarra>
FYI 402 editors: here is the in-progress editorial conventions document that @bakkot mentioned in the 262 update: https://github.com/tc39/ecma262/wiki/Editorial-Conventions
07:42
<eemeli>
Yeah, in-room and remote audio are routed separately. The speakers on the wall are delivering sound from Zoom, while in-room is from the screen at the other end.
07:42
<littledan>
great bullets bakkot, thanks
07:50
<littledan>
sffc: I would prefer that we not add Gemini-produced summaries in the notes. Let's use our human intelligence to understand what the important points are.
07:51
<littledan>
everyone who wants AI-produced summaries can make them themselves
07:51
<nicolo-ribaudo>
Is the << Software identified by reference to the Ecma Standard* ("Software)">> in https://github.com/tc39/test262/blob/main/LICENSE#L1 a placeholder, or is it expected to be written like that?
07:54
<Michael Ficarra>
everyone who wants AI-produced summaries can make them themselves
you're so close
07:54
<littledan>
(I don't want to read an AI summary of anything)
07:55
<littledan>
(and it is confusing if they're included in our docs because it looks authoritative)
07:55
<Michael Ficarra>
I agree with both of those statements
07:55
<Aki>
holy shit toronto and montreal were merged?
07:56
<Aki>
politically not insignificant
07:56
<Chris de Almeida>
it's Torontreal now
07:56
<Chris de Almeida>
whoops, this isn't TDZ
07:56
<Rob Palmer>
Montronto surely
07:57
<Michael Ficarra>
๐Ÿ‘ฎ โžก๏ธ #Temporal Dead Zone
07:59
<hax (HE Shi-Jun)>
typo๏ผš chongquing should be chongqing
07:59
<littledan>
typo๏ผš chongquing should be chongqing
This is a historical entry in TZDB; there are a lot of outdated latinizations there
08:00
<littledan>
(several of the other forwardings discussed were examples of the same)
08:02
<hax (HE Shi-Jun)>
I never see "asia/chongquing" spelling, google shows nothing...
08:02
<rkirsling>
yeah that's an interesting typo that only an English speaker could make
08:02
<littledan>
oh I stand corrected
08:03
<Michael Ficarra>
I thought the whole point of the slide was that some of the timezones were being renamed due to historical misspellings
08:03
<hax (HE Shi-Jun)>
Anyway, "asia/chongqing" -> "asia/shanghai" is a mistake IMO, always cause confusion and accidentaly cause bug ๐Ÿ˜‚
08:03
<rkirsling>
(the outdated romanization would be chungking, fwiw)
08:04
<hax (HE Shi-Jun)>
Though it's not the bug of JS, but the bug of TZDB.
08:06
<littledan>
Anyway, "asia/chongqing" -> "asia/shanghai" is a mistake IMO, always cause confusion and accidentaly cause bug ๐Ÿ˜‚
why is that? is there a chance that China will split into multiple timezones?
08:08
<Richard Gibson>

https://github.com/eggert/tz/blob/d56ae6ee85d496ef67f0428e81060341ec70cec2/backward#L311

Link Asia/Shanghai Asia/Chungking #= Asia/Chongqing

08:08
<Chris de Almeida>
why is that? is there a chance that China will split into multiple timezones?
bit of a misconception there is only one
08:08
<Chris de Almeida>
Asia/Urumqi
08:09
<Chris de Almeida>
also different TZ for HK and Macau
08:09
<Chris de Almeida>
although those are UTC+8 same as CST
08:11
<hax (HE Shi-Jun)>
why is that? is there a chance that China will split into multiple timezones?
It's irrelevant to possible multiple timezones. Asia/Chongqing is a BUG due to misunderstanding of historical timezones in World War II. It never be used broadly in practice in the history. Or if it was been used, it already have no usage from 1950. So keep Asia/chongqing in the TZDB always cause confusion to Chinese programmers and users, especially some users might change the timezone to it and in edge cases it cause weird bugs in the historical dates.
08:12
<littledan>
It's irrelevant to possible multiple timezones. Asia/Chongqing is a BUG due to misunderstanding of historical timezones in World War II. It never be used broadly in practice in the history. Or if it was been used, it already have no usage from 1950. So keep Asia/chongqing in the TZDB always cause confusion to Chinese programmers and users, especially some users might change the timezone to it and in edge cases it cause weird bugs in the historical dates.
Great, so sounds like the merge is what should happen
08:13
<JaseW>
TCQ Revolutions
08:13
<hax (HE Shi-Jun)>
Great, so sounds like the merge is what should happen
Well I think it should be deleted, not merged.. but It might be the deep design philosophy of TZDB which I don't fully agree with.
08:13
<littledan>
Meta: Please link your slides from the agenda so it's easier for folks to follow along (and link the slides from the notes)
08:14
<littledan>
Well I think it should be deleted, not merged.. but It might be the deep design philosophy of TZDB which I don't fully agree with.
so if someone uses it, an exception should be thrown, rather than redirecting them to CST?
08:14
<littledan>
Christian Ulbrich: After the presentation, please paste your slide link in the notes
08:16
<ryzokuken (TC39 ๐Ÿ‡ซ๐Ÿ‡ฎ)>
Well I think it should be deleted, not merged.. but It might be the deep design philosophy of TZDB which I don't fully agree with.
unfortunately that's not how TZDB is managed, yeah ๐Ÿ˜•
08:16
<ryzokuken (TC39 ๐Ÿ‡ซ๐Ÿ‡ฎ)>
so all historic or just incorrect timezones need to stay forever although they could be linked to a more relevant zone
08:16
<hax (HE Shi-Jun)>
so if someone uses it, an exception should be thrown, rather than redirecting them to CST?
If it's really "merged", I think it's ok. But in fact it will report differently in old dates in 194x ~ 195x. As I understand, TZDB never ensure correctness before 1970, but most OS still use TZDB history part, which IMO is bad, and cause problems.
08:21
<hax (HE Shi-Jun)>
If it's really "merged", I think it's ok. But in fact it will report differently in old dates in 194x ~ 195x. As I understand, TZDB never ensure correctness before 1970, but most OS still use TZDB history part, which IMO is bad, and cause problems.
Note "Asia/chongqing" is especially bad case , because in some old version TZDB it even report different time to CST in 198x dates.
08:27
<hax (HE Shi-Jun)>
so all historic or just incorrect timezones need to stay forever although they could be linked to a more relevant zone
But there were another three China historical timezones in old TZDB and have been deleted, only Asia/Chongqing is merged, not sure why they keep it, IMO they are just from same misunderstand.
08:28
<ryzokuken (TC39 ๐Ÿ‡ซ๐Ÿ‡ฎ)>
But there were another three China historical timezones in old TZDB and have been deleted, only Asia/Chongqing is merged, not sure why they keep it, IMO they are just from same misunderstand.
interesting! yeah I have no clue but I'm curious so I'd try to dig around to see why
08:29
<littledan>
If it's really "merged", I think it's ok. But in fact it will report differently in old dates in 194x ~ 195x. As I understand, TZDB never ensure correctness before 1970, but most OS still use TZDB history part, which IMO is bad, and cause problems.
Yes, ICU and JS implementations tend to implement this historical part
08:39
<nicolo-ribaudo>
bakkot A few weeks ago I was writing my own source maps decoder, which use base64 but in a weird way: 6-bit-bytes should not be rearranged in 8-bit-bytes, but left as they are (or padded with a leading 00): ABCD is not [0, 16, 131] but [0, 1, 2, 3].
The proposals does not support doing anything like this, right? (it's a quite niche use case so I'm not expecting it to, but I'm wondering if I missed something)
08:39
<bakkot>
correct
08:40
<bakkot>
but Michael Ficarra's iterator chunking proposal + flatMap would get you there!
08:40
<bakkot>
actually no it wouldn't, reading closer
08:41
<bakkot>
I guess that's just [...string].map(x => Uint8Array.fromBase64(x + 'AAA')[0] >> 2)
08:42
<bakkot>
or... something like that anyway
08:42
<nicolo-ribaudo>
Oh yes that would work
08:44
<hax (HE Shi-Jun)>
Yes, ICU and JS implementations tend to implement this historical part
Yeah, even Asia/Shanghai have some weird historical part. So in current js/web application, there is no easy way to represent CST (China standard time) for old dates (just like proleptic Gregorian calendar). It seems the design flaw of TZDB?
08:45
<littledan>
has this feedback been raised to the tzdb mailing list? (we're not really in a position to manage a better tzdb here in TC39)
08:49
<sffc>
On the topic of time zones: TZDB and CLDR have both fairly explicitly decided to not prioritize pre-1970 transitions (and especially not pre-WWII transitions) because they were kind of a mess and documentation is kind-of lacking.
08:50
<sffc>
My understanding is that some of the merges are from time zones that had historic differences but have been the same since 1970
08:52
<bakkot>
re: Symbol.isConcatSpreadable, not only does no one use it, but also if you do use it then all uses of Array.p.concat anywhere on your page get slower in V8: https://www.tines.com/blog/understanding-why-our-build-got-15x-slower-with-webpack-5
08:57
<hax (HE Shi-Jun)>
Is it also get slower in FF/Webkit? Isn't that the bug of v8?
08:58
<bakkot>
it's not a bug, it's an intentional design decision
08:58
<bakkot>
FF and Webkit have similar things though I don't know if they have this specific thing
09:01
<Duncan MacGregor>
There is always going to be a trade off when deoptimising for things likes isConcatSpreadable. Just deopting at the particular sites you'll likely use more resources than just noting that the possibility exists everywhere.
10:20
<Luca Casonato>
The AsyncIterator.propotype.split thing looks nice
10:24
<Luca Casonato>

I wonder if we can combine the ideas from split, but still not require combining a split, map and merge. For example:

const parallel = iter.parallelMap(5, (iter) => {
  return iter.map(mapFn).filter(filterFn)
});

Would be the same as

const parallel = AsyncIterator.merge(
  iter.split(5).map((iter) => {
    return iter.map(mapFn).filter(filterFn);
  })
);
10:35
<Michael Ficarra>
@Ashley Claymore that's what semaphores are for
10:44
<bakkot>
very pleased to have used 44minutes 30 seconds of a 45 minute timebox
10:45
<bakkot>
@Ashley Claymore that's what semaphores are for
which we also don't have
10:45
<ryzokuken (TC39 ๐Ÿ‡ซ๐Ÿ‡ฎ)>
like a pro
10:46
<Michael Ficarra>
@bakkot yes but I would prefer the concurrency-limiting function helper anyway
10:56
<bakkot>

yeah I was thinking about something like this. it's a very weird signature but once you learn to use it I think it does exactly what you want in many cases. a cute thing is that you can pass an async generator as the second argument:

iter.parallelMap(5, async function* (vals) { for await (let item of vals) { yield item + 2 } })

or whatever

10:58
<bakkot>
it does not immediately resolve the question of consuming without producing a new iterator, but I think that could just be a second function; iter.concurrentForEach or something
10:59
<Michael Ficarra>
the note-taker is double-spacing sentences again, are we just gonna fix that up in post?
10:59
<bakkot>
let vals = iter.concurrentMap(5, async_generator_taking_iterator);

for await (let item of vals) ...

and

let promise = iter.concurrentForEach(5, async_function_taking_iterator);

await promise;
11:00
<bakkot>
though maybe concurrentForEach would take a T => void rather than an Iterator<T> => void? unclear
11:00
<bakkot>
(which would make that a bad choice of names)
11:01
<Aki>
the note-taker is double-spacing sentences again, are we just gonna fix that up in post?
absolutely
11:01
<Aki>
i have a regex for it
11:03
<Michael Ficarra>
k good then we don't need to bug them about it
11:17
<Ashley Claymore>

Option 6 (a-la acorn):

const errors = [];
...format(..., { onError: errors });
if (errors.length) { ...}

to avoid inline callbacks

11:23
<bakkot>
i can no longer stay awake, but my bot will continue being in the meeting. please don't be misled by its presence, it is just a computer and cannot (yet?) represent my opinions for me
11:25
<bakkot>
for Error.isError, I'm not objecting to stage 2, but I still have reservations about whether it is motivated. i would like it to have strong from other delegates, and the reasons they want it to be captured, before it advances. also I do want to say that it absolutely must consider dom exceptions to be errors; users should not be exposed to that distinction.
11:34
<Luca Casonato>
straw person proposal: https://github.com/lucacasonato/proposal-semaphore
11:35
<Michael Ficarra>
@Luca Casonato lol noooo why?
11:35
<Michael Ficarra>
@bakkot yes but I would prefer the concurrency-limiting function helper anyway
11:35
<Luca Casonato>
Michael Ficarra: It actually does that too - semaphore.wait() is this (minus the wrapping itself)
11:36
<Michael Ficarra>
@Luca Casonato that's backwards though
11:36
<mgaudet>
(Do we have a test262 dashboard that has v8 and sm on it? I have https://test262.fyi/ in my history, but this seems incomplete at the moment)
11:37
<Luca Casonato>
(Do we have a test262 dashboard that has v8 and sm on it? I have https://test262.fyi/ in my history, but this seems incomplete at the moment)
It's just bugged at the moment - it has V8 and SM usually
11:37
<Michael Ficarra>
let limitedFunction = fn.limitConcurrency(5) and then pass limitedFunction around in place of fn
11:37
<Michael Ficarra>
(Do we have a test262 dashboard that has v8 and sm on it? I have https://test262.fyi/ in my history, but this seems incomplete at the moment)
https://github.com/CanadaHonk/test262.fyi/issues/56
11:38
<ptomato>
(Do we have a test262 dashboard that has v8 and sm on it? I have https://test262.fyi/ in my history, but this seems incomplete at the moment)
Was just wondering that as well, since I based my remark about implementation status on it ๐Ÿ˜…
11:38
<Luca Casonato>
@Luca Casonato that's backwards though
const semaphore = new Semaphore(12)
function wrap(cb) {
  return (...args) => semaphore.wait(cb);
}

I'll add this helper as an open question to the doc :)

11:39
<Michael Ficarra>
yeah but that allows you to wait on the semaphore with multiple functions, right?
11:39
<Luca Casonato>
Yes - I mean isn't that what you want?
11:40
<Luca Casonato>
let limitedFunction = fn.limitConcurrency(5) and then pass limitedFunction around in place of fn
This lacks flex
11:40
<Michael Ficarra>
no, it's inverted
11:40
<Michael Ficarra>
I want consumers to not have to even know that there's limiting going on
11:40
<Michael Ficarra>
think about it this way: if I am currently passing a function to someone, I want to swap it out with a concurrency-limited one without them changing their implementation
11:41
<Michael Ficarra>
yes I could do that with your wrap helper, and in fact that's how I will always do it
11:41
<Michael Ficarra>
so if I always do it that way, there's no reason to expose the semaphore directly
11:46
<Luca Casonato>

Sure - that makes sense. But there are use cases where this doesn't work - for example if you have execute and query functions that both operate on the same database, and you want to limit both together.

Another common case for this is when you want to limit the number of FS ops, but there are many different ops. For example you want to limit the number of stat(), realpath() etc all with the same limiter

Another use case that wrapping is not expressive enough for is if you want to limit the number of open files. Because you "acquire" at every open call, but only release once a file handle is explicitly closed.

Also one could propose that we make Semaphore sharable across agents :)

11:49
<Luca Casonato>

added a wrap method:

const semaphore = new Semaphore(5);

const wrappedFunction = semaphore.wrap(async () => {
  // Do some work
});

async function doWork() {
  await wrappedFunction();
}
11:51
<Michael Ficarra>

Sure - that makes sense. But there are use cases where this doesn't work - for example if you have execute and query functions that both operate on the same database, and you want to limit both together.

Another common case for this is when you want to limit the number of FS ops, but there are many different ops. For example you want to limit the number of stat(), realpath() etc all with the same limiter

Another use case that wrapping is not expressive enough for is if you want to limit the number of open files. Because you "acquire" at every open call, but only release once a file handle is explicitly closed.

Also one could propose that we make Semaphore sharable across agents :)

it does if you virtualise the database through these
11:52
<Luca Casonato>
yeah, but that seems rather unergonomic?
11:55
<Luca Casonato>
You can always do it by creating a function like const call = ((cb, ...args) => cb(args)).limitConcurrency(5) - but i mean that is very messy and it also does not layer well with using - also it's very unergonomic when you are limiting a resource, not a single call
11:55
<Michael Ficarra>
not really, it moves the limiting further inward into like a "kernel"
11:55
<Michael Ficarra>
we should talk over snack break
11:55
<Michael Ficarra>
I want a snack
11:56
<Luca Casonato>
sure :)
12:02
<hax (HE Shi-Jun)>

littledan:

Regarding function.sent, we have discussed use cases and possible solutions in several past meetings. However, there is no consensus on whether the use cases are strong enough to support introducing a syntactic solution. Although I generally still believe this is a problem worth addressing, perhaps solving it through a more general feature like function decorators in the form of an API is more promising than introducing entirely new syntax. Therefore, I hope to revisit this proposal after the function decorator proposal advances to the next stage.

12:07
<ljharb>
good morning. to be clear about Iterator.concat, the behavior I think users will expect has nothing to do with Symbol.isConcatSpreadable (which is regrettable and nobody should expect it), it's that array concat takes both arrays or scalars, and anything with the name concat should do the same (take both containers or things contained).
12:15
<ljharb>
link to present for Promise.try: https://github.com/tc39/proposal-promise-try/issues/15
12:17
<littledan>
good morning. to be clear about Iterator.concat, the behavior I think users will expect has nothing to do with Symbol.isConcatSpreadable (which is regrettable and nobody should expect it), it's that array concat takes both arrays or scalars, and anything with the name concat should do the same (take both containers or things contained).
ah, sorry for any confusion caused by my misinterpretation
12:19
<Luca Casonato>
test262.fyi is sorta back ^^
12:19
<Michael Ficarra>
it's gradually filling
12:19
<ljharb>

links to present for RegExp.escape:

12:20
<littledan>
Congrats ljharb
12:20
<littledan>
they wouldn't let me clap...
12:21
<littledan>
BTW volunteers welcome for doing the next proposal scrub
12:32
<Michael Ficarra>
I think we should retro the proposal scrub because I value it but it felt unproductive for some parts
12:32
<Ashley Claymore>

littledan:

Regarding function.sent, we have discussed use cases and possible solutions in several past meetings. However, there is no consensus on whether the use cases are strong enough to support introducing a syntactic solution. Although I generally still believe this is a problem worth addressing, perhaps solving it through a more general feature like function decorators in the form of an API is more promising than introducing entirely new syntax. Therefore, I hope to revisit this proposal after the function decorator proposal advances to the next stage.

thanks! I've copied this into the notes in the appropriate section.
12:34
<hax (HE Shi-Jun)>
If do temp check, could we have a simple example to show the difference of two escape solutions ?
12:34
<Rob Palmer>
https://docs.google.com/document/d/19PqeLeKjdy9zTn4OAQEhQVI2zmAxUvZ7eCmnNrKQHeI/edit
12:34
<Rob Palmer>
Nicolo, can you share this on-screen
12:35
<Michael Ficarra>
If do temp check, could we have a simple example to show the difference of two escape solutions ?
\x40 vs \@
12:36
<Michael Ficarra>
for RegExp.escape('@')
12:36
<Richard Gibson>
If do temp check, could we have a simple example to show the difference of two escape solutions ?
if we don't change, RegExp.escape("$") === "\\$". If we do change, RegExp.escape("$") === "\\x24"
12:39
<ljharb>

links to present for Error.isError:

12:43
<Rob Palmer>

I made a mistake of not stating Shu's comments on RegExp.escape so will read it out at the next break:

V8 has no concerns for Stage 2.7.

As for character vs hex code escapes, V8 can live with either outcome but weakly prefers character escapes. The future stability argument AFAIU is that choosing character escapes makes changing the behavior of character escapes in the future even harder. But it is already very hard to change non-throwing behavior to new non-throwing behavior. We don't understand why this would make it meaningfully harder.

12:49
<Michael Ficarra>

I made a mistake of not stating Shu's comments on RegExp.escape so will read it out at the next break:

V8 has no concerns for Stage 2.7.

As for character vs hex code escapes, V8 can live with either outcome but weakly prefers character escapes. The future stability argument AFAIU is that choosing character escapes makes changing the behavior of character escapes in the future even harder. But it is already very hard to change non-throwing behavior to new non-throwing behavior. We don't understand why this would make it meaningfully harder.

that was exactly my opinion
12:50
<littledan>
doesn't it throw an exception if you forget to call super(), unless you take the extreme step of returning something other than this/undefined?
12:51
<Richard Gibson>
that was exactly my opinion
I think that's a misunderstanding; the changes would not be from non-throwing to throwing but rather the other way around (such that e.g. /\@/u becomes valid)
12:52
<ryzokuken (TC39 ๐Ÿ‡ซ๐Ÿ‡ฎ)>
(possible) hot take: brand checking is orders of magnitude more important (and less icky) than type checking
12:52
<littledan>
(possible) hot take: brand checking is orders of magnitude more important (and less icky) than type checking
why contrast them? they are both important and just do different things.
12:52
<ryzokuken (TC39 ๐Ÿ‡ซ๐Ÿ‡ฎ)>
oh
12:52
<ryzokuken (TC39 ๐Ÿ‡ซ๐Ÿ‡ฎ)>
true
12:53
<ryzokuken (TC39 ๐Ÿ‡ซ๐Ÿ‡ฎ)>
I guess more accurately: runtime brand checks are important to complement type checks
12:54
<nicolo-ribaudo>
Chris de Almeida (TCQ) Because it's a revoked proxy, so you should not be able to inspect its state
12:55
<nicolo-ribaudo>
Array.isArray does the same
12:56
<Michael Ficarra>
@ryzokuken (TC39 ๐Ÿ‡ซ๐Ÿ‡ฎ) give me one reason for brand checks
12:56
<ryzokuken (TC39 ๐Ÿ‡ซ๐Ÿ‡ฎ)>
well, you might want to check the "type" of something on runtime? I use code that uses Array.isArray all the time?
12:57
<ryzokuken (TC39 ๐Ÿ‡ซ๐Ÿ‡ฎ)>
as do many others I believe
12:57
<littledan>
we're in quite violent agreement about Error.isError returning true for DOMException.
12:58
<Michael Ficarra>
@ryzokuken (TC39 ๐Ÿ‡ซ๐Ÿ‡ฎ) you should be duck typing, though maybe you need to know whether the object has a magic length property for some reason?
12:59
<ryzokuken (TC39 ๐Ÿ‡ซ๐Ÿ‡ฎ)>
I can give a more specific example from a recent function I wrote but in general when dealing with heterogeneous objects and collections like we do in JS, it's quite useful
12:59
<Michael Ficarra>
like I can see testing for Arrays due to the magic length property and mapped arguments objects because of their magic assignment behaviour
12:59
<Michael Ficarra>
in general, you definitely shouldn't be brand checking
12:59
<Michael Ficarra>
those two cases are accounting for language magic
13:00
<ryzokuken (TC39 ๐Ÿ‡ซ๐Ÿ‡ฎ)>
idk what to say... I disagree?
13:00
<ryzokuken (TC39 ๐Ÿ‡ซ๐Ÿ‡ฎ)>
I don't think the stuff I'm writing would be better handled without brand checks
13:04
<Richard Gibson>
like I can see testing for Arrays due to the magic length property and mapped arguments objects because of their magic assignment behaviour
is there a way to identify a mapped arguments object?
13:05
<ljharb>
no, this is indeed another missing brand check i seem to always forget about. see https://npmjs.com/is-arguments
13:05
<Michael Ficarra>
@ljharb don't you dare
13:05
<nicolo-ribaudo>
is there a way to identify a mapped arguments object?
He said "all instances except for error have a brand check", I found the wording to be carefully chosen :)
13:05
<nicolo-ribaudo>
Can I stop screen sharing?
13:05
<ljharb>
sure, thanks
13:08
<ryzokuken (TC39 ๐Ÿ‡ซ๐Ÿ‡ฎ)>
Michael Ficarra can you expand a bit on "icky"? What's specifically wrong with explicit brand checks apart from just the added cost of an additional static method?
13:12
<Michael Ficarra>
@littledan I think you hit on the key point there: the opposition is to brand checks that are not otherwise justified. Like all features we consider, we should require them to have a good reason to exist.
13:14
<Michael Ficarra>
@ryzokuken (TC39 ๐Ÿ‡ซ๐Ÿ‡ฎ) this is basically "nominal typing > structural typing" but at the term level
13:24
<littledan>
@littledan I think you hit on the key point there: the opposition is to brand checks that are not otherwise justified. Like all features we consider, we should require them to have a good reason to exist.
so the action item is for supporters and opponents to come together and make a shared set of guidelines. I'd prefer an answer which is not, "make sure you sneak in an operation that does a brand check without being just a brand check operation."
13:25
<littledan>
because this is what proposal champions currently have to do! it just papers over the disagreement about whether the brand check is justified.
13:25
<Michael Ficarra>
@littledan how is that a bad situation if that operation has been independently sufficiently justified?
13:26
<Michael Ficarra>
wanting the same thing for different reasons is how dispute resolution happens all the time, and it's fine
13:26
<littledan>
it is super confusing; if the objection from person A is "this can't move forward unless it adds a brand check" and person B is simultaneously saying "a brand check is not justified" then the champion ends up finding an excuse for a brand check by shaping the API such that it's "natural" to include one, such that independent motivation can be argued for. It's super confusing!
13:27
<littledan>
this is a particularly weird set of disagreements, among the various ones we have. It doesn't amount to a coherent design principle.
13:27
<littledan>
it seems like you have a different set of things you're looking for in "what makes a brand check justified" than ljharb does. Maybe you can work together on a common set of criteria.
13:28
<littledan>
the answer does not need to be that everything has a brand check; we should just find a common answer one way or another
13:28
<Michael Ficarra>
I think the majority of the committee agrees that brand checks are harmful for "normal" code
13:29
<Michael Ficarra>
this Error check was justified for like dev tooling
13:29
<ljharb>
i don't think that's actually true anymore
13:29
<Michael Ficarra>
it would be ideal if it was less ergonomic to discourage its use
13:29
<ljharb>
it was certainly true when the committee was 20 people, but we're much larger and have a much more "anchored in userland" set of experience represented than in the past
13:30
<littledan>
so, yes, if we can get consensus among the committee that brand checks are not required when making a new type of object with internal slots, then yeah that's a way through
13:30
<littledan>
if
13:31
<Michael Ficarra>
@nicolo-ribaudo to be clear, I didn't actually have time to complete my review, but from the review I did do, it was fine
13:32
<littledan>
(not sure why Shu's question was directed specifically at implementers)
13:40
<hax (HE Shi-Jun)>
question: are defer namespace and normal namespace object always distinct? or only distinct when error?
13:43
<Richard Gibson>
question: are defer namespace and normal namespace object always distinct? or only distinct when error?
hax (HE Shi-Jun): can you get that on the queue?
13:44
<nicolo-ribaudo>
@nicolo-ribaudo to be clear, I didn't actually have time to complete my review, but from the review I did do, it was fine
2.7 would be conditinal on editorial reviews
13:45
<nicolo-ribaudo>
question: are defer namespace and normal namespace object always distinct? or only distinct when error?
Always distinct because when you create them you don't know yet if the module will error or not
13:45
<hax (HE Shi-Jun)>
hax (HE Shi-Jun): can you get that on the queue?
Added.
13:46
<hax (HE Shi-Jun)>
Always distinct because when you create them you don't know yet if the module will error or not
Seems reasonable. Thank u!
13:46
<JaseW>
(Do we have a test262 dashboard that has v8 and sm on it? I have https://test262.fyi/ in my history, but this seems incomplete at the moment)
It's back up fully now https://test262.fyi
13:47
<mgaudet>
:) Still waiting for legacy regexp results tho
13:50
<ptomato>
:) Still waiting for legacy regexp results tho
a bit weird. this is what it looked like when I loaded it a couple of hours ago:
13:51
<ptomato>
now it's not showing v8 anymore
13:51
<mgaudet>
... huh. (kudos to Canadahonk for building this tho -- its a bit weird it's become load bearing?)
13:58
<Jack Works>
if the fake module namespace object is created, it will be created each import
13:59
<Jack Works>
this usually happens in getting the ES namespace object of a CommonJS module
14:01
<Jack Works>
for real ES Modules, webpack just returns the internal module namespace object. for non-strict semantics, (that import * as ns is equal to ns = require()), it's the same
14:08
<nicolo-ribaudo>
Thanks for investigating!
14:08
<nicolo-ribaudo>
Babel does indeed the same for CJS imports
14:57
<shu>
littledan: sorry wasn't there for the proposal scrub thing. you can always check chromestatus when in doubt
14:57
<shu>
that's usually kept up to date
15:07
<bakkot>

Sure - that makes sense. But there are use cases where this doesn't work - for example if you have execute and query functions that both operate on the same database, and you want to limit both together.

Another common case for this is when you want to limit the number of FS ops, but there are many different ops. For example you want to limit the number of stat(), realpath() etc all with the same limiter

Another use case that wrapping is not expressive enough for is if you want to limit the number of open files. Because you "acquire" at every open call, but only release once a file handle is explicitly closed.

Also one could propose that we make Semaphore sharable across agents :)

you can have a "wrap" which takes a set of functions and limits concurrency across all of them. prior art: https://www.npmjs.com/package/throat
15:12
<Luca Casonato>
you can have a "wrap" which takes a set of functions and limits concurrency across all of them. prior art: https://www.npmjs.com/package/throat
https://matrix.to/#/!WgJwmjBNZEXhJnXHXw:matrix.org/$jBz5BAYiJ6u9yymLBwDZTutvHhDE7LZooG0Q36NMxxo?via=mozilla.org&via=matrix.org
15:13
<bakkot>
I don't know what your snippet is supposed to be doing
15:15
<bakkot>

the wrap thing I'm suggesting would be like

let [limitedExecute, limitedQuery] = AsyncFunction.limitConcurrency(5, [execute, query])

or something like that

15:17
<bakkot>

or the api in throat gives you a limiter you can call repeatedly to draw on the same lock, as in

let limiter = limitConcurrency(2);
let limitedExecute = limiter(execute);
let limitedQuery = limiter(query);

which also works and is more flexible

15:34
<shu>
I think that's a misunderstanding; the changes would not be from non-throwing to throwing but rather the other way around (such that e.g. /\@/u becomes valid)
i meant non-throwing to non-throwing, because \@ already is a literal escape that doesn't throw
15:35
<shu>
or was the scenario you were thinking of in u and v modes only?
15:42
<bakkot>
ljharb: re: isError, another thing I forgot to mention is that I am not OK having any more places that replicate Array.isArray's proxy-piercing behavior
15:42
<bakkot>
that may mean that having a static method for this is incompatible with the SES folks' goal of practical membrane transparency
15:48
<shu>
bakkot: say more? is the rationale in the notes?
15:48
<bakkot>
from the last time this was discussed, I think, yes
15:49
<bakkot>
the SES goal is that a membrane for a thing "works like" that thing, as long as you're using the normal interface and not bypassing the object by doing e.g. Map.prototype.call(membrane)
15:50
<bakkot>
the way a membrane for a Map works is, its methods are themselves proxied so that they are able to reach into the underlying data structure of the proxy
15:50
<bakkot>
but that doesn't work for static methods, since those come from outside of the membrane
15:50
<shu>
but why aren't you okay with having more places that pierce Proxies?
15:50
<bakkot>
oh
15:50
<bakkot>
couple of things
15:50
<bakkot>
first is just that it's conceptually gross
15:50
<bakkot>
second is that it makes any use of proxies harder
15:51
<bakkot>
for most of the proxy invariants, you can uphold them as you go by imposing them on your target object when they come up
15:51
<bakkot>
but for specifically "is it a function, an object, or an array", you have to decide that up-front
15:51
<bakkot>
the reason "array" is on that list is because isArray pierces proxies
15:51
<bakkot>
I don't want to expand that list
15:52
<bakkot>
from the point of view of proxies, there are three kinds of thing in the world; we shouldn't add a forth, especially a fourth which is just some random thing and not as fundamental as the existing three
15:52
<shu>
right, it is just true that it makes use of proxies harder. i'm trying to understand if that's now a general goal you have, or a concrete use case, or that since we have Proxies, we shouldn't go out of our way to make them harder to use
15:53
<shu>
but also this seems like a pretty fundamental disagreement that should've blocked stage 2?
15:53
<bakkot>
I am reluctantly OK with this going forward without the proxy-piercing behavior
15:53
<bakkot>
so I don't think it needs to block stage 2
15:54
<bakkot>
unless someone else says that they are OK with it going forward only with the proxy-piercing behavior, in which case that's unreconcilable
15:54
<shu>
ah, i missed that last part
15:54
<shu>
okay, sg
15:55
<bakkot>
re: goals, I am OK with making proxies harder to use for the benefit of other more frequently used features, since I think proxies are a power-user feature already. but the "should it pierce proxies" question is about proxies, so it makes sense to evaluate that question from the perspective of how it affects users of proxies
15:55
<shu>
yes, that sounds reasonable
15:56
<bakkot>
unless someone else says that they are OK with it going forward only with the proxy-piercing behavior, in which case that's unreconcilable
my understanding is that the SES people might not be ok with this going forward as a static method without the proxy-piercing behavior but this has not yet been hashed out. also they might not be OK with it going forward as a static method with either proxy-piercing or not-proxy-piercing for different reasons. but I can't speak for them.
16:06
<ljharb>
right - proxy piercing is def something to resolve in stage 2. Your constraint is noted, thanks :-)
16:45
<littledan>
littledan: sorry wasn't there for the proposal scrub thing. you can always check chromestatus when in doubt
Sorry I should have skipped asking about implementation status anywayโ€”those proposals were already too current. Next scrub we will focus on Stage 2 and, if time allows, Stage 1 proposals which havenโ€™t been discussed in a while.
17:30
<ljharb>
seems like it'd be more effective to start at oldest and move to newer?
19:58
<littledan>
This is what we did within the stage. Probably I should have skipped the more recent ones. But I do think we have more of a responsibility to keep things up to date for higher stage things
19:59
<littledan>
Also I donโ€™t want to own scrubs; if someone else wants to run this topic next time, that would be great
20:01
<littledan>
And then other facilitators could try their own prioritization schemes
20:01
<ljharb>
i should be fully at the next two plenaries so i could do one
20:33
<Chris de Almeida>
Also I donโ€™t want to own scrubs; if someone else wants to run this topic next time, that would be great
is this a topic that we should just include by default at every plenary?