13:50
<Rob Palmer>
Another reminder: Plenary begins in 70mins!
14:50
<ryzokuken>
10 minutes!
14:59
<Rob Palmer>
1 minute until plenary!
15:02
<Rob Palmer>
We have 20 people attending so far
15:03
<yulia | PTO>
hey folks -- i am double booked this morning for the first hour
15:03
<yulia | PTO>
if there are any questions for mozilla, Dan Minor will be present from mozilla -- and I will join after
15:04
<littledan>
I'm going to be absent today and joining tomorrow. The schedule looks fine for me, but I'd like to be present during the second time discussing ShadowRealms. Sorry for this information coming late.
15:04
<littledan>
I'm excited to be back!
15:58
<mpcsh>
do we have a draft schedule hackmd?
15:59
<Rob Palmer>
it's linked in the Reflector post
15:59
<snek>
should i see something right now
15:59
<Rob Palmer>
(don't post here)
16:09
<mpcsh>
aha! had to refresh. thank you
16:20
<bakkot>
shu: can you capture the behavior which got consensus in the notes? not just "the pr" but a short summary, in case we find bugs in the PR or whatever
16:22
<shu>
yes, after this item
16:23
<Michael Ficarra>
I always love Justin's presentations, they are very clear
16:32
<bakkot>
snek: one of the possible solutions is to do the same thing as the await fast-path, which actually never gets .then at all
16:33
<bakkot>
(it just checks IsPromise and .constructor, and then assumes .then is the built-in Promise.p.then)
16:34
<snek>
did you mean to ping me
16:35
<Jack Works>
(it just checks IsPromise and .constructor, and then assumes .then is the built-in Promise.p.then)
can we really do that? I think there definitely someone overwriting then on the Promise instance...
16:35
<bakkot>
snek: this was re "my prediction is this will end up with us moving the Get("then") into the tick"
16:35
<snek>
oh
16:35
<bakkot>
Jack Works: that's how await works, yeah
16:35
<snek>
that's cuz of the security thing
16:38
<Jack Works>
This a bit surprise me. So does that mean Promise from another Realm will have 1 more tick to resolve?
16:38
<bakkot>
per spec, yeah
16:47
<ljharb>
yulia: https://blog.izs.me/2013/08/designing-apis-for-asynchrony/
16:56
<yulia>
my topic is also around this question that shu is asking
16:56
<ljharb>
to be clear: i intensely support making this change for builtins; justin's case for that was quite compelling and convincing
16:57
<shu>
understood, the subtext is i'm asking a "who's doing the work" question
16:58
<yulia>
understood, the subtext is i'm asking a "who's doing the work" question
which work specifically?
16:58
<shu>
i'm uncomfortable with an outcome that's like "convince me no userland stuff breaks" == "browsers should ship and see before stage 3 because we have no good procedure to figure out if something breaks"
16:58
<shu>
like i don't actually know how to be convinced, myself, that no userland stuff breaks
16:58
<shu>
without shipping and seeing
16:58
<yulia>
my feeling is similar
16:59
<yulia>
but we also have a preference for alternative 1, which would iiuc, side step the concerns around species
16:59
<yulia>
this would be appropriate as a normative pr imo, but requires a way to test this
16:59
<shu>
yeah i have no real preference for fast pathing natives or not
17:00
<ljharb>
the context of that comment was as a needs-consensus PR; doing it as a proposal means that "stage 3" is the time when we'd discover that
17:01
<shu>
i see, so explicitly you're supportive of stage 3 to find out if userland is broken, not blocking stage 3 before being convinced if userland is not broken
17:01
<ljharb>
correct
17:02
<ljharb>
but i would hope that the proposal can investigate both paths, so that if breakage is discovered, the "special-case builtins" path can be quickly shifted to
17:03
<shu>
thanks, sgtm
17:03
<bakkot>
I am imagining the thing mark wants is IsPromise(p) && GetOwnProperty(p, 'then') == undefined && GetPrototypeOf(p) == Promise.prototype, basically, which seems like an interesting alternative to the current constructor fast-path in await
17:04
<bakkot>
none of those checks are observable, which is nice
17:04
<bakkot>
(because the IsPromise check screens out proxies, specifically)
17:06
<yulia>
"Conditional Advancement" was the word
17:06
<ljharb>
Justin Ridgewell: please lmk when the repo's made and i'll update the proposals repo
17:07
<ljharb>
btw starting after lunch, i'm going to be sitting in one of the OpenJS rooms at the JW Marriott in Austin for plenary. whoever's in town is more than welcome to join; DM me for details.
17:57
<Rob Palmer>
Plenary resumes in 2 mins
18:11
<littledan>
+1 with a similar level of review/confidence as bakkot expressed
18:11
<littledan>
this change seems generally good but I didn't review all the details
18:11
<waldemar>
rbuckton: I have some comments on the RegExp Atomic Operators but won't be able to participate on Thursday. I reviewed all the proposals after the advancement deadline, and at that time I did not see the semantics. I see you added the semantics later but I was camping off-grid in the desert for the last week so I did not get a chance to review those. (Fun fact our group learned the hard way: covid can spread outdoors!)
18:13
<waldemar>
rbuckton: I'm ok with advancing to stage 1 but would prefer not doing the double-advance to stage 2 until I get a chance to review it in detail.
18:13
<shu>
seems like a scheduling conflict, Rob Palmer ^ possible to reschedule that item before Thurs?
18:14
<rbuckton>
rbuckton: I'm ok with advancing to stage 1 but would prefer not doing the double-advance to stage 2 until I get a chance to review it in detail.
That's fine. I may be able to bring it back in July assuming I'm able to attend (I'll be in the middle of a cross-country move so may not be present at the next meeting).
18:17
<rbuckton>
Also, I wrote up the spec text while reviewing the proposal internally with some folks who worked on the implementation in .NET. Fully understand on holding any possible double-advancement given the spec text was added after the deadline.
18:17
<ryzokuken>
rbuckton: I have some comments on the RegExp Atomic Operators but won't be able to participate on Thursday. I reviewed all the proposals after the advancement deadline, and at that time I did not see the semantics. I see you added the semantics later but I was camping off-grid in the desert for the last week so I did not get a chance to review those. (Fun fact our group learned the hard way: covid can spread outdoors!)
would it help if we moved it to another day?
18:18
<waldemar>
I'm available Mon-Thu this week. I have a conflict on Thursday.
18:18
<waldemar>
I'm availabler Mon-Wed this week. I have a conflict on Thursday.
18:20
<snek>
nobody is running sugarjs on tc53 devices right?
18:21
<littledan>
I think we can say here, let it be noted that there is a standing disagreement between Shu and Mark on this question of whether frozen environments should be considered
18:21
<ljharb>
not an old version, surely
18:22
<snek>
what were the bad names that sugarjs uses
18:24
<Mathieu Hofman>
I did not hear a disagreement. I heard the opposite: both agree frozen built-ins environments do exists and should be considered the same as other out in the wild code.
18:25
<shu>
no Mathieu Hofman there's disagreement. i agreed that frozen environments are a breakage to consider. i can generalize that disagreement more: the frozen environment breakage is a "second order" breakage to me in that it breaks the users of a library that mutates the environment to be different than the specced standard of 262. i don't want to weigh that very strongly
18:25
<shu>
i certainly do not consider it the same as other out in the wild code
18:25
<shu>
you're not saying your library breaks
18:25
<shu>
you're saying users of your library breaks
18:27
<Mathieu Hofman>
I wasn't asserting there'd be a breakage in user code running in those environments. I was just saying it may be one type of breakage we might witness in the wild
18:27
<littledan>
I think we should note in the minutes that this disagreement continues to exist (for clarity).
18:28
<shu>
but IIUC the only way you can witness that breakage is if another library mutates something that's by-default writable to be not writable
18:28
<Mathieu Hofman>
That it's a risk with a name which may be used as a named prop
18:29
<littledan>
This discussion seems to show that the disagreement continues to exist, as it has for as long as I've been in TC39
18:29
<shu>
+1 to dan's assessment
18:30
<Mathieu Hofman>
(still hopeful for a solution to the override mistake which would make these moot)
18:31
<littledan>
well, Caitlin Potter prototyped it and found web compat issues...
18:31
<littledan>
it's not clear to me what the solution should be, but I hope we can find one
18:32
<Mathieu Hofman>
What was prototyped exactly? I have an approach based on an explicit option bag to freeze which would set a slot on the frozen object, which would tweak the OrdinarySet step based on the presence of that slot.
18:33
<Mathieu Hofman>
I would love to see if there is prior experiments that would invalidate this idea
18:34
<littledan>
oh yeah what was prototyped was a more direct change of the Set behavior, we didn't try that tweak
18:35
<Richard Gibson>

bakkot: regarding "Where do you get your default time zone?", TL;DR is that we're covered.

More details:

The requirements are described in GetNamedTimeZoneEpochNanoseconds (which returns a List of nanoseconds since epoch for a specific time zone name and local time) similar to the current text in LocalTZA: https://arai-a.github.io/ecma262-compare/?pr=2781#sec-getnamedtimezoneepochnanoseconds (emphasis mine)

When the input represents a local time occurring more than once because of a negative time zone transition (e.g. when daylight saving time ends or the time zone offset is decreased due to a time zone rule change), the returned List will have more than one element and will be sorted by ascending numerical value. When the input represents a local time skipped because of a positive time zone transition (e.g. when daylight saving time begins or the time zone offset is increased due to a time zone rule change), the returned List will be empty. Otherwise, the returned List will have one element.

And specified more precisely in UTC (which interprets its input as a number representing local time and returns a single milliseconds since epoch): https://arai-a.github.io/ecma262-compare/?pr=2781#sec-utc-t (emphasis mine)

If possibleInstants is not empty, then… Let disambiguatedInstant be possibleInstants[0]. [i.e., the chronologically first matching local time]
Else [a local time skipped at a positive time zone transition], … Let possibleInstants be GetNamedTimeZoneEpochNanoseconds [corresponding with] tBefore is the largest integral Number < t for which possibleInstants is not empty (i.e., tBefore represents the last local time before the transition) … Let disambiguatedInstant be the last element of possibleInstants

t is interpreted using the time zone offset before the transition

18:35
<littledan>
if we do something with freeze, I guess we'd need to figure out the MOP implications. Maybe we could discuss this in an SES call?
18:36
<littledan>
or maybe you mean for preventExtensions in general?
18:36
<Mathieu Hofman>
if we do something with freeze, I guess we'd need to figure out the MOP implications. Maybe we could discuss this in an SES call?
We did a few weeks ago
18:36
<littledan>
oh oops! I'll try to catch up on notes
18:37
<snek>
today would anything break if we got rid of IsHTMLDDA
18:38
<bakkot>
yes
18:38
<ljharb>
i don't hear any audio at all
18:38
<ljharb>
is it just me?
18:39
<yulia>
yes, refresh
18:39
<yulia>
?
18:39
<ljharb>
k
18:40
<bakkot>
man sugar used all the cool names
18:40
<bakkot>
though I guess groupBy was uniquely bad because it made use of it during startup
18:40
<bakkot>
or something like that
18:40
<snek>
groupedBy?
18:41
<ljharb>
gimmeGroups
18:41
<bakkot>
we just decided to go with group I think
18:41
<snek>
so i hear
18:41
<HE Shi-Jun>
Have a question: is findLast/findLastIndex in ES2022 or ES2023?
18:41
<snek>
groupedBy would probably make more sense though if we consider the existence of r&t
18:41
<bakkot>
2023
18:41
<bakkot>
2022 is already cut
18:42
<HE Shi-Jun>
Ok. So we need to fix it in tc39/proposals page?
18:42
<ljharb>
yep, thanks, just fixed
18:48
<rbuckton>
would it help if we moved it to another day?
Is RegExp Atomic Operators going to stay in its current timeslot on Thursday or is it going to be moved up to accommodate Waldemar's schedule?
18:56
<ryzokuken>
rbuckton: working on it now
19:01
<snek>
my opinion continues to be that we should just remove the boundary from shadowrealms
19:02
<ryzokuken>
doesn't that just make them equivalent to contexts?
19:07
<littledan>
I have to leave due to a conflict; here are my queue items for reference: Copying the .message for non-callable objects seems like a useful and harmless convenience Note that the web makes errors opaque by design on the cross-origin throw case
19:11
<littledan>
(the web's cross-origin throw case is a little different, having more to do with source location than the origin of the realm)
19:24
<ljharb>
i mean, only a hanfdul of organizations implement ecmascript and it has a pretty big impact
19:25
<ryzokuken>
waldemar: I moved rbuckton's items around, please check out the schedule now
19:25
<ryzokuken>
also, could you please PR your schedule constraints?
19:26
<rbuckton>
ryzokuken: Is there now nothing scheduled tomorrow morning? The pre-lunch agenda is empty.
19:27
<ryzokuken>
I'll move items around, the schedule is in flux
19:28
<ryzokuken>
also, could you please PR your schedule constraints?
it helps immensely to do that ahead of time, btw
19:35
<Michael Ficarra>
I forgot you could refer to a named capture by its index
19:36
<Michael Ficarra>
I hope most people wouldn't ever intentionally use that capability
19:36
<snek>
i doubt that case happens very often
19:37
<littledan>
Michael Ficarra: yeah this was a sort of explicit design choice. IIRC it seemed like most other languages allowed that, and I didn't see a reason to diverge/skip those ones
19:37
<littledan>
I guess I could've been more clear in explaining that to the committee
19:37
<shu>
so wait what's the proposed behavior for the number references?
19:38
<shu>
they have globally unique numbers but aliased names?
19:38
<Michael Ficarra>
littledan: maybe it could be useful for compilers? but I'd hope a human would realise it's not the best way to express themselves
19:38
<littledan>
they have globally unique numbers but aliased names?
this is what I would expect
19:38
<shu>
yeah that seems fine to me
19:38
<shu>
global-to-the-RE
19:38
<shu>
would be funnier if it was actually globally unique
19:38
<littledan>
information leak!!!
19:40
<snek>
context? in my regex?
19:43
<snek>
conditional stage 2
19:56
<HE Shi-Jun>
Could the proposed decorator static initializers allow class member decorators change the shape of the class?
19:58
<bakkot>
they have globally unique numbers but aliased names?
yup, numbers continue to be counted as before
19:59
<ljharb>
if it helps, there's an eslint rule that pushes people to only use names and never numbers; it seems likely people won't be using both
19:59
<shu>
HE Shi-Jun: it shouldn't
19:59
<shu>
if it does that goes against the static redesign
20:00
<snek>
if it helps, there's an eslint rule that pushes people to only use names and never numbers; it seems likely people won't be using both
i like to mix it up randomly to keep my teammates on their toes
20:05
<rbuckton>
In general I agree, you usually don't see a mix of both. There are a few cases where this happens more often in other engines, such as when you can use a relative backreference (i.e., /(?<group>foo(bar|baz)quxx\k'-1'/) where a name wouldn't be relevant to the resulting captures.
20:06
<HE Shi-Jun>
HE Shi-Jun: it shouldn't
It seems if instance decorator could add class initializer, it could ... Maybe I misunderstand the proposal?
20:08
<rbuckton>
The existing addInitializer for a class decorator doesn't prevent changing the shape after the class is done, but there's far less reason to do so given the most common cases can be handled with something like accessor.
20:08
<shu>
HE Shi-Jun: ah right good point, i guess that goes back to the point i made that currently we have the statically analyzable guarantee that "no class decorators means no class initializers", which would be broken here
20:09
<shu>
so not really a fan thus far
20:10
<rbuckton>

Just as instance initializers don't prevent you from attaching a random this.foo = 1, and class fields don't prevent you from doing

function fn() {
  this.foo = 1;
}
class C { x = fn.call(this); }
20:13
<rbuckton>
If it came down to it, I'd be happy if you could only change the timing of an "extra" initializer from the default if the new timing was only "class" or "static" (i.e., non-static members can add "instance", "class", or "static" extra initializers, but static members could only add "class" or "static"), since the check to run "class" and "static" extra initializers is a one time cost.
20:15
<rbuckton>
Being able to add a per-instance initializer would be nice (per my topic in plenary), but isn't strictly necessary for the use cases I'm primarily concerned with.
20:17
<rbuckton>

i.e., we could possibly allow you to decorate a constructor declaration, where the decorator can only really add an instance extra initializer:

const dec = // something that just adds an instance extra initializer

class C {
  @dec constructor() { }
}
// is maybe better than
class C {
  @dec #unused;
}
20:20
<rbuckton>
But I still think @dec class C {} is better than either case. A class decorator can already do constructor replacement to inject an instance initalizer, but that requires rewiring the replacement function or subclassing, and wouldn't have the same timing.
21:10
<waldemar>
bakkot: I posted an issue in proposal-duplicate-named-capturing-groups with some minor spec issues. Stage 2 is fine if those are resolved.