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 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 |
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. |
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!) |
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)
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)
|
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? |
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? |
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? |
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? |
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? |
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 |
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 |
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
|
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
|
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. |