Remote attendees:
| Name | Abbreviation | Organization |
|---|---|---|
| Luca Casonato | LCA | Deno Land |
| Ashley Claymore | ACE | Bloomberg |
| Jordan Harband | JHD | Coinbase |
| Bradford C. Smith | BSH | |
| Waldemar Horwat | WH | |
| Robin Ricard | RRD | Bloomberg |
| Caridy Patiño | CP | Salesforce |
| Jack Works | JWK | Sujitech |
| Istvan Sebestyen | IS | Ecma International |
| Michael Saboff | MLS | Apple |
Presenter: István Sebestyén (IS)
IS: Okay, so this is basically the usual type of agenda. I'm also looking at the, the clock here. You know, that I do not spend too much time on the report. So, first, I would go through very, very quickly, the list of new ECMA TC39 documents, and list of GA documents - those which are relevant. Then again, just to report on TC39 meeting participation numbers. That sounds like a very very quick one. Then the TC39 standards download- and access statistics. The next one, where we are with the ES 2022 approval and publication process. We are quite good. And then, there were some Ecma Bylaws and Rules changes proposed by the recent ExeCom meeting, and those are going to be approved or not approved at the June 2022 GA. I think it will be approved by the June 2020 GA and then last but not least, the next TC39 meetings, the GA and ExeCom meetings. There are some new information on those because we have received new dates for 2023 GA and ExeCom.
IS: Okay, so these are the TC39 document practically all of them, which I have not shown yet to you. So first of all on the opt-out period, as you know, we have already started during the last meeting. And then the timer for the two months had started. And then we had to publish, obviously, the full text of the two standards that we are going to approve, the new editions at the same time. So this is TC39/2022/14 and 15. Then the document 16 is the communication that was created by our management team regarding the TC39 nonviolent communication training funding requests to the ExeCom. So that was discussed at the ExeCom meeting but I understood it is still under discussion. So the 17 it is the collection of the slides for the last meeting. This is a duplication of info what we also offer over the GitHub. So only for those people who are only reading the official TC39 file server documents on the ECMA side, you know, this is all new information for them, but for you in in TC39 practically not so relevant because you know those from the Github. So then the minutes of the last meeting is is the say 18. So this is what we have approved, just five minutes ago. And then venue 19 for this meeting.
IS: Okay, and then the agenda for this meeting 20, and then last but not least, and this is the most important one for us, 21, so that the opt-out period has ended. Actually, it was, I think exactly on the 29th of May, so a couple of days ago and we have not received any comments. So everything is fine and everything should be prepared for the approval meeting on June 22. Okay. Let's go to the next slide, please.
IS: So these are those new GA documents that are relevant for us. Some of them are also duplications with TC39 documents, and you have also seen them in the TC39 set. So like the opt-out period, it was not only announced on TC39 level but generally on the GA level, this is the ga 2022/25. This document are the minutes of the debate at the special General Assembly when the new additional copyright policy was approved. Then the 027: This is for those folks who are interested in the Ecma financial figures of last year, what Ecma has produced. So this is the auditor's report. There was an important type hybrid Execom meeting on April 5th and 6th in Geneva. Actually, then later on in my sides, I have taken over some info from these minutes. Just the most important information for us. So you will see that later. Then 030 and 031: these are key documents which we have officially published for the approval, for the new edition (13th) of ECMA-262. So this will be approved at the next GA. This is also true for the document for the ECMA-402 9'th Edition. So this is going to be approved. And then in a separate document we have the table for all the drafts that have been submitted to the General Assembly. The 123rd General Assembly meeting in june 2022 will be in Geneva. It will also be a hybrid meeting. So, those who are interested in going. they should contact the ECMA Secretariat. And 36 is the GA presentation of the minutes of the last TC39 meeting. and we have a document on candidates of nominees for the vacant ExeCom and Ecma Management position. I think there are two positions, but we have only one candidate. Daniel Ehrenberg is a candidate for the for Ecma Vice President to be elected only for half a year. And then at the end of the year we have a full election for the entire next year 2023. The document 44 and 45: these are quite important. I would say, this is what would be the highlights. There are some minor changes on the Ecma bylaws and rules. Very modest. They are very good in my opinion, both from the substantial point of view and also from the editorial point of view, Etc. There is nothing really dramatic I have to point out to you. Everything is very very modest, but very good changes. Okay, the 46th document. So this is the agenda of our meeting, this is going up to be announced also at the GA level. and then the 052 document, this is what has been published last week by a Patrick and this says that the opt-out period which has been required by the Ecma IPR rules for royalty-free standards, you know, that passed without receiving any comments, everything is fine. So, please, Next document. And this was the end of the list.
IS: But why are these lists of interest to TC39 members? I already mentioned that in the past. Because some of the documents, the GitHub documents can only be seen by internal TC 39 people, but for instance usually not by a company GA representative Etc. So we have to do a sort of duplication for them. This is one of the Reasons the other reason is - for long-term, archival purposes - that if one day we stop working GitHub, like, I don't know, in five years time years, years, etc. Etc.then we have automatically a back-up for most important TC39 archived information. There is always danger that one needs that.
IS: Yeah, and this the recent history of TC-39 meeting participation. You can go to the next page because it's only the latest information that is new. So on the March 2022 meeting (remote) we had very high participation (92) and this was probably due to the fact that this was the last meeting before the freeze and before the approval of the ES2022 spec. So, the next slides again, slides, please.
IS: So this is the usual download of Ecma standards. The first line shows how many standards have been downloaded from the very beginning of the year in 2022. So, the first five months were 36,000, that's a little bit lower than usual, but not that much. This is the TC39 part of how many standards have been downloaded of the TC39 standards. And as it can be seen, more than half, so over 60% of all the downloads. So this is consistent with the trends, which we have seen over the years. Since 60 percent comes from us, the quality of the TC39 download standards is very important.
IS: Yeah, this is the usual breakdown for the two biggest TC39 standards in HTML format - regarding access. This is in the first in the second column, and then also regarding the download. Less logical are the access figures for ECMA-262 and ECMA-402 for the old Editions (6th and earlier). I have asked again to ECMA secretariat that we should try to look into more details. Unfortunately we could only go down to the country level but not into more details. The countries indicate that the vast majority of access is by bots and not by ES experts. I don't want to go into the list of those countries, but probably the first three numbers we can simply forget. And then starting from 2007, in my feeling it gets to be more realistic and the latest one is for the 12th edition with the 35,000 Etc. It's probably right. So you can see that the access number is significantly higher than the download number. But still with the download numbers are always said, if they are very good.
IS: So for ECMA-402, regarding the access number for the first edition and second that you see, it is also probably a fake number, so forget it. And then the rest, it should be okay and also for the download figures. Okay, and of course the ECMA-402 figures are significantly lower than the ES262. Okay, you can continue to the next page.
IS: So regarding the ES 2020 timeline approval. Nothing new, it will be approved at the June 2022 GA, exactly on June 22nd and 23rd. It will be on the agenda on the first day. Everything was OK, no comment received. However, still please note still no substance changes are allowed - not only already for two last months but also until the final approval. Only small editorial changes until the last minute are allowed. And we will publish the two standards as soon as possible. Usually Patrick puts them out immediately, even the pdf version if the pdf version may not be the final one because of the known formatting issues, etc. We will put out whatever we have, as it's good enough for that and then replace it when we have a better one.
IS: The rest of the TC39 plenary meeting planning: I am sure the chair group may give you more details if needed. So the next meeting it is open if that will be remote or hybrid. It is now in discussion. So we will see that works out from all points of view and the same is also true (marked with a question mark), what will happen with the September 2022 Tokyo meeting? Whether it will be remote-only meeting or a mixed meeting Etc. and preparation is also on the way. By the way the old date is still valid, discussion to move it is over.
IS: Yeah, so, the proposed change is by the Ecma by law to the Ecma bylaws. This is in GA/2022/44. So the ExeCom discussed this in the April meeting and some changes were proposed to be approved by the June general assembly. And some of the changes are editorial. Some were suggested by the Ecma legal counsel. I have just taken out the changes from the document 044, you know, see the list of the GA that I have presented. So the first change, for instance, what happens if the president and the vice president can not participate in the event to carry out their office and participate in the meetings Etc. So this is the par. 7.6 and then more explanation about Voting Rights. What happens exactly after there is a membership class change. etc. So this is a better specification 6.2 and 6.3 but nothing really dramatic. And the next one is that in the Rules also at the IPR policies are mentioned. They were not. So this I also would say it is an editorial change. The only bigger thing “in quotation marks change” is that now for the NFP members (not-for-profit organizations). As you know some of them are very large. They are often interested in more than one technical committees. So now they are able to participate - without any execom special requests - in all technical committees, if they want. So, this is the change for the NFP organizations. But the rights for the SPCs remain the same regarding participation in TCs. There is still the limitation for one technical committee participation only. So please go to the next slide.
IS: So this is now, the next one, the GA 45 document. And the reason is exactly the same. so why it has been done etc. Most of the of the changes are really editorial changes, for instance, here on the third bullet point, you know, identical text should be included for instance, in the patent policies Etc. Typical editorial change. The next one also, I would say. This is also a good me, just clarification, you know, if we have a not for profit membership organization, whose members could also be Ecma members, you know about those members what they are allowed to do and what they are not allowed to do. Then the term “chairman”. And now this is changed to “chairs”, So this is correct from the gender point of view. Okay, next one next slide, please.
IS: I have taken out from the April exocom report. Among many things I thought that TC39 was interested in the status of the Ecma Linux Foundation collaboration. Here: It is the exact text which I have copied out. So basically it is on ice from what I understood. The second point is this about the status of the nonviolent communication request, what we had. So basically, the message here is that, indeed, you know, it went to the ExeCom. They have discussed it and then what I have understood, it is not concluded yet because further information and further input was requested at. What I understood further input is going into the GA meeting in June. So the situation is, you know that it is in progress.
IS: Ecma recognition Awards. We don't have any TC39 candidate in this half a year and in general, the Execom will look into that and work out a more detailed operational procedure for the future, and we will see what comes out. Next one. Please.
IS: Okay. So here GA venues and dates. is new here? Yes, the GA and the Execom meeting also for 2023 are now included. I think that should be the end. Thank you very much.
Presenter: Kevin Gibbons (KG)
KG: So first, as IS mentioned, the 2022 spec is cut. It's just pending GA approval, but we don't expect any further changes. There might end up being some editorial fixes we backport for it, but I'm not aware of any we're expecting currently. There hasn't been very much in the way of changes, at least not changes worth calling out, since the previous meeting. There have been efforts to clean up regular expressions and make them more consistent with the rest of the spec. So this means mostly not having sort of floating aliases. There were a few aliases that were defined as like, these are just these aliases can be referred to without being passed in which is not how the rest of the spec works. So those are getting threaded through everywhere. And then there's a subsequent change to make it so that instead of having tuples we use records, which is again more consistent with the spec. At least, one of those PRs is still open. I know we have several in-flight changes to regular expressions, so I didn't want to land that PR until after this meeting because the existing proposals are of course, written as diffs against the current spec, but we probably will pull in that pull request after this meeting. If you have in-flight changes in a proposal or anything, I would be happy to take care of the rebase for you. I just don't want to delay it until we never have regex stuff in the pipeline because we will always have regex stuff in the pipeline.
KG: And of course, a variety of smaller editorial changes and improvements. So a small handful of changes. The first couple SYG brought up at the previous meeting. These are removing per iteration detached-ness checks in various TypedArray methods, and then getting rid of this kind of unusual use of Symbol.Species in InitializedTypedArrayFromTypedArray. And then #2670 was a pull request I presented at the previous meeting. Just reducing some of the information available to make CSP style determinations about whether you can run eval. And then these last two are just bug fixes. In 2729 we noticed that when named capture groups were added, or someone else pointed out I should say, that when named capture groups were added they were only added to the main grammar, but the actual grammar is this Annex B modification to the main grammar, and so were in this odd situation where annex B regexes didn't allow named capture groups. That was obviously wrong. So we fixed it without asking for plenary consensus for that change as we had understood that to be the consensus and that matched implementations. Similarly, 2779. When you add a regex flag. It needs to be added both in the grammar and then in a separate check, that makes sure that all of the regex flags are valid and we hadn't made the required modification in the second place. Again we understood this to be consensus and so we landed this without revisiting it in plenary. So, those last two, again, just bug fixes.
KG: And then this next is not a new change. This is just something I thought was worth calling out because apparently, a lot of people don't know about it. This has existed since well before my tenure. I believe Brian added this feature in 2016. For the specification, if you are jumping to certain sections very frequently, you should pin those. If you hover over a clause or definition or whatever, on the right hand side, you get this little pop-up and in the middle thing on that pop-up, it says pin. And if you click pin, it will show at the top of the table of contents on the left hand side, and all of the things that you pinned will be there. You can jump there from anywhere in the specification. And this will persist across reloads and so on. It's great. Highly recommend using it. So now you know!
KG: Again, fairly similar list of upcoming work as previously. #2744 I wanted to call out explicitly. So right now, when you evaluate something like the actual evaluate invocation, we have some prose along the lines of "let foo be the result of evaluating this expression" or whatever. And that's sort of a different call style than every other SDO. So the plan is to change this to "let foo be the result of Evaluation of this expression" or whatever, which is, it will just make evaluation work exactly like every other SDO. So there isn't this one-off dispatch style just for it. And then otherwise just general consistency and cleanups. And that's it, any questions?
Presenter: Ujjwal Sharma (USA)
USA: Welcome to the Ecma 402 update. As Kevin pointed out, the 2022 edition should be out soon. It's already cut. We put in all the editorial goodness in there. We talked about last time and should be good to go. Since the branch cut for that addition, we've done a bunch of editorial stuff. First off, we have essentially a bug fix, which is that IsWellFormedCurrencyCode. Something weird was happening. So normalized was being accessed before, it was never referenced. It was fixed by confluent. I mentioned this, especially because this comes from implementation over at Serenity-OS. Not sure if you know about this implementation, but it's certainly an interesting one, but go check it out. If you haven't.
USA: Next up, we have some more usual yet Super important editorial work by RGN. now get option which is one of our favorite operations, especially for both 402 as well as Temporal gets an upgrade. So now you get to have numbers in options, but from that there's a bunch of other interesting editorial improvements by RGN. Please check them out. We have things happening apart from that.
USA: There is no new normative changes. So so nothing on that front, but just to get it quickly updated on the status of the proposals, a bunch of new proposals, reached stage 4, and stage 3 in the As months, some of them don't have polyfills. So this is a request to everybody who's interested in writing polyfills or just interested in polyfills for some other reasons - if you want to help out, please get involved. You'd really appreciate any help around Polly filling. new 402 features. updates around the ongoing state three proposals. Is that local info and enumeration is shipping in implementations behind a flag. In some number format? We three is shipping in two implementations, but not in V8 at the moment, Duration format on the other hand is still work in progress. There's a Can I help you? So kind of biased towards the end of day two. so tomorrow and that's pretty much it. you. okay, and next up, have Ecma 404.
Presenter: Chip Morningstar (CM)
CM: Steady like a rock
Presenter: Sarah Groff Hennigh-Palermo (SHO)
SHO:. Okay, so, you'll recall Igalia recently joined test 262 project to take up some contract work. work. And that meant that we were in situation where we suddenly had three. We had maintainers that are now at three different companies and so it was a good time to formalize a lot of informal expectations and routines that had grown up around the project as this kind of stuff. Right? How the project is organized and why how to become a maintainer and the related responsibilities and decision making how to make requests for structural changes or communicate when the project's not working with you. And these discussions are still in progress, but since we sort of have broad agreement on the shape of them, we decided share our works of far at this update.
SHO: So if you Want to know things like why are there so many files? Why isn't this working? Like my favorite testing framework? You might be, you'll love how the Ejecting, organiz, organized. And why is there a little link to the pr their questions such as where do I put my tests? What do I put in them? And how do I actually run the darn things are answered in how to get started writing tests, then there's sort of organizational questions. Like, how do I become a maintainer? What our maintainers responsibilities and how does decision making within that group work. Work, some spoilers, there? You will, do maintainer training get approved. The responsibilities are both to rate and review the test. And we're taking a ‘consensus minus one’ model for things like maintainer approval and other group decision making. there's also other roles and responsibilities you may be shocked to discover. And so for instance test writers are going to be asked to read the cool guys that are being written. Proposal authors, who aren't aren't writing themselves will be asked to engage in review, tests will be establishing a priority of constituencies to outline things like who the project serves and how we will prioritize these conflicting needs and we're also outlining an RFC process. So that these constituents can make requests for structural changes or communicate when the project doesn't seem to be working for the community. and finally, to help make these decisions big and small in reviews and rfcs. We have plans to further outline. The values that are backing that project and those PRs are still to come. And so up next. You can expect to see an implementer survey. So we all have sort of assumptions about what implementers like and don't like and are getting from the project but getting a little data on that might be chill. Further discussions about the values as I mentioned. We will be reducing our meeting frequency. So to get a lot of this structure in place, we've been meeting weekly. Now, we're going to once every three weeks and eventually the goal will just basically be once per plenary to catch up on test262 business and then will be merging these PRs. If you want to talk to any of us, you can, of course, comment on the pr or in issues listed in the slides. They are linked on the agenda. There's a test 262 maintainers channel on Matrix and the group can be pinged on GitHub using this very cool. @tc39/test262-maintainers group, but now, thank you for listening.
Presenter: Jordan Harband (JHD)
JHD: There really aren't any updates. The new members have been attending meetings and have been briefed on all our workflows and there have not been any incidents reported since the last plenary.
Presenter: Shu-Yu Guo (SYG)
SYG: So this is something we got consensus for a while ago. When was this? I don't remember. It was a couple of years ago, and I don't think anyone implemented it and then I forgot what the consensus was. And then there's a new PR here. So, I'm trying to jog my own memory and then either affirm consensus or to get new consensus on some of the corners of this weirdness. So quick recap, the typed array stuff remains to have non-interoperable corners. It behaves strangely, when composed with other features. Namely, the strangeness here is what happens when you put a typed array on the Prototype chain of regular object. So if you see on this slide here, which is the old slides from from when I presented this originally, if you have a TypedArray on the Prototype, and then you assign to an index, what do we want to happen? And we're kind of bound by web reality here in that this NASA thing broke when we try to change this. So what is not up for discussion? I think, is that so, currently? I think the spec says something like, if you use a string key. And there is a TypedArray on the Proto chain, like it always goes through the integer, exotic index set for something like that. Meaning that you never go through OrdinarySet. Meaning like, the TypedArray. The TypedArray, implementation of bracket bracket set bracket bracket, kind overrides ordinary set as setters work, except this setter is like really broad. What's the proposed change? Last time? that to kind of keep the NASA thing working? And that was the main example that that we found that broke, but the I guess we consider that a Bellwether of other code on the web depending on the behavior, the proposed change last time. was that if a TypedArray exists on the Prototype and you assign a string keyed property to it. The setter for the TypedArray, would check if the receiver is the same as the target meaning: “Am I on the Prototype chain or Are you actually setting a TA?” if I'm I'm on the Prototype chain, meaning, the receiver and the target are not the same, then it falls through to ordinary set meaning that you would actually assign to, In this case. Not the Proto, what you you would actually assigned. And an actual property at one in this example, 20 instead of the TypedArray, the approaching. So that was the consensus that was gotten before I move forward with the rest of the presentation on the new PR from Alexei from Apple. Are there any questions here? Does anyone disagree with this? I'm just recapping what I think is to the consensus from a few years ago.
(silence)
SYG: Okay, taking silence as a no questions. Let me now move on to the current question. The current question is what happens for? Inbounds versus out of bounds indices. So, in this example, this int32 array is of length, 10 and one is in bounds of 10 and so, all I presented last time was this example of well, if the indices are inbound, then it falls through and end the receiver and the target don't match, then it falls through to ordinary set. There's a question now, for what happens if it is out of bounds, for example, this were like 12. Does it fall through to ordinary set? Meaning, Does it set a property an own property on O? Or does it not set a new property on O? So I'm going to switch tabs now to the PR from ASH. What is that? This is the pr from ASH and the proposed normative change from ASH is that, if? It is. An inbounds in deck if If it's an inbound index, then it falls through to ordinary set. If it is not an inbound index then it does not fall through the ordinary set and it does nothing. So basically, basically, this is as far as I understand the kind of minimum delta to web compat and changing this Behavior. I think this is fine. Like don't put typed arrays on the prototype and expect reasonable Behavior. So we should really just decide on something again, and then remember to actually try to implement it this time. Do I did it? I characterize the your change correctly ASH, if you're on the call,
ASH: sorry, I've just missed for the last seconds. Yeah, so, let me just make it go ahead. Yeah, every cop so. We've got consensus for. Inbounds indices, you know, to call ordinary set for them. We got confesses to call ordinary set which is like now for non-canonical indices numbers, but the original presentation kind of missed this detail for out of bounds and here. I argue we should not traverse prototype further just to stop the recursion. Do not invoke Setters on the prototype chain the same as we do for typed arrays, get like to align this Edge internal method with get internal method like we are this exact line that you are highlighting, and it is known to be web comfortable because we age implement this? Yeah. Yeah, the other way would be like not to have this line to align with SpiderMonkey, like to go, for example type chain, which is also web compatible, but I pursue like this option here.
SYG: Cool. Cool. Thanks. So. yeah, to the extent that any TypedArray of this gazers have opinions here. I'm we're going ask consensus for Lexi's PR, which is to not fall through to ordinary set and not call setters if the index is out of bounds, we will continue to call setters for Proto Typed arrays if the index is inbounds, and we're bound to do that. We're constrained to do that, because of web compat issues that we found last time. any questions or disagreement or agreement or people don't care. In which case we'll just try to do this. all right,
(silence)
SYG: I'll take the silence as a people. Agree / /, don't care. So I will consider ASH’s PR to have consensus which due to reiterate. Again means that for out of bound indices they do not fall through to ordinary sets for typed arrays that are on the Proto chain. All right, that's it.
MAH: I was actually I put something on a little late. I'm confused. Yeah, what I was reading from the PR is that it ends up, if you If typed array is on the Prototype, it ends up as in own property of set in down ends up as an own property on the receiver, which basically behaves pretty much like the ordinary set. If so, you're saying, if you're out of bounds, it wouldn't that. And the set would end up setting nothing. Is there a reason for the discrepancy between what is the reason for the discrepancy between inbound and out of bounds? Or and why not? Just I mean it's weird, but why have more weirdness? Why not make the weirdness consistent?
SYG: consistent in which direction?
MAH: in the direction that any if you reach TypedArray and you do a set. So, I guess I need one more clarifications. All right, out of bound being non integer or any string or property, right? If you do foo instead of something numeric you, what is the behavior currently? Sorry
SYG: The behavior currently is currently spec. I guess, you mean. Yeah, the let's see. Where is this set?
ASH: Currently, this typical calls ordinary sets, right? And we are not changing that for properties. That are not canonical, not Marik Industries, right?
MAH: Okay, so it would results in a new own property on the receiver.
ASH: That's right. I'll call in etc from a about type chain.
MAH: Yeah, so we're saying that if it is numeric, but it is out of bounds. Then it it just would end up nowhere.
ASH: Yeah. Yeah, the whole set will be suppressed the same for get. Yeah, just draw lines them. They weirdness to Alliance. That's the goal here.
MAH: Okay, it just feels weird. It feels weird. F for inbound. and for non integers, it would end up on as a known property. property. But for Adam, Bound numeric. It wouldn't.
SYG: So, currently the spec says, for all canonical numerics, basically suppress it. and we can't do. So it's consistent now, quote, unquote, but we cann’t do it because people don't implement this behavior and when we try to it broke NASA. So we did this carve out here to have it fall through to ordinary set. And the current question is there's non interruptive you if we go, let me go back to the convo. There is non-interop. Where's the comment? This one. I have a comment replying to something. There's interopnon-interop among engines between in bounds and out of bounds. In SpiderMonkey difference
Gap in notes: recap All engines differ May be web compatible but some engines have a larger user base Some engines may be very slow to implement this
MAH: I think my response would be that it's so you're saying the minimal change here is minimal and implementation, but it is not exactly a minimal in minimizing the weirdness Like yeah, I think from the conceptual point of view. I would prefer to have the same behavior throughout if you which is instant the same behavior throughout what axis throughout what axis like this is the same. behavior throughout the type of properties, if it's whether it's it's numeric in them. You're out of bounds or non-numeric old shouldn't end up setting on the receiver.
SYG: Okay, that's a final opinion to have. What if I told you this kind of corner is so low priority that if we got that consensus to change the current V8 behavior, and we don't we're not going to do it for a few years. Does that change your opinion?
MAH:I think there's a lot of other. I mean, it's it's currently engines. Don't agree in the first place. So I don't think there is any any risk in maybe engines catching up to the spec, at some point there.
SYG: There. Is it that the risk I is nobody content like everybody continues to, not care. And then, like, this continues to get to. The second is not reflect reality in reality in this corner. I'm fine with the other Behavior to be clear. It's just like more work, which then probably gets the deprioritized as it's not very important. I don't have, you know, that part.
USA: We are we have only 10 minutes left, I think on the Queue Dan has a common that might useful.
DLM: Yeah, sure. We've discussed this internally and SpiderMonkey glands to change our Behavior to match, what's being proposed here?
SYG: Thanks. So, okay. So I'll take that as a spider monkey being +1 on, ASH’s change here. And since it, like C is at Apple, I assume JSC is is on this change as well.
USA: Yeah, right also on the queue had JHD who was +1 on the confusion aspect.
YSV: So, I think I'm also on the queue. It's all right. Yeah, so I joined late. Sorry about that, but I understand that we were talking about confusion in terms of how consistent this is, with other types said behavior. Is that right? II.
SYG: Guess MAH’s confusion, confusion, binders and correctly. Is it's weird with respect to type Fitness. Like, if your mental model is that you get the same set Behavior. If the type of the of the of the property key is one type versus another, than this makes it more weird in Discerning distinguishing boundedness in bands or out of bands. account.
YSV: Okay? Okay, I see. So when I was thinking through this, I was looking at it from a different. perspective like in what case would you actually want to have this kind of behavior in, which you would want to set something out of bounds for an object? And I like so we're proposing to change our behavior and my thinking here was it makes sense for SpiderMonkey tow line with the other engines here because from my perspective and correct me if I'm wrong. I would only see the out of bounds set. Actually falling through in the case that I just don't see a use case for the out of Bounce said following through. So I agree with the proposed change. I don't know if that helps with the confusion thing. I think not. But yeah, our thinking that our behavior is a little funny here and there's no obvious use case for this, whereas we have issue with aligning with both JSC and V8. That's all.
SYG: Thanks. So a last effort from myself to to pitch the consistent to consistency here. if you kind of look at it, zoomed in on, like we're distinguishing boundedness, then. Yes, it's weird and yes it's inconsistent. But as YSV has brought up, if you look at it from a use case perspective suppose you want so suppose actually had a use case where you want out of bounds stuff to set on own property such that they look like they exist. To the user. What does that mean? Like now should you also be overriding lengths because now you have this other weirdness where if you have a TypedArray, Proto chain, presumably you're using it mostly like a TypedArray and then you're having length ball through to the to the prochain look. Now at the override that as well to reflect that it is. I don't know, like I don't know what that means. You have a TypedArray with holes now, as well, if you allow these, get something that looks like a typed array with holes with maybe an inconsistent length. But yeah it like it doesn't seem to make a lot of sense from a use case perspective and it could make the mental model of it. TypedArray on the on the pro chain more inconsistent, if out of bounds were allowed. Does that change anybody's Minds.
MAH: I think my answer here is if you have something on the prochain. Doing a set. Never changes the Prototype object unless that property your set is using a Setter, you will always end up with an own prop, on the receiver, unless you find a Setter since we don't have Setters. We can't have it behaved like a setter because of web compat. Then in my hou,
SYG: This is an exotic object by the way like this. Like a blanket, setter. This is that's the behavior we're talking about. Right? This is not an ordinary object in ordinary object. agree with your take, but this is explicitly. Not an ordinary object.
MAH: Right. I was just saying, let's make it behave like ordinary for old types of props.
SYG: We cannot really. How do we make it behave?
MAH: What are we saying here is that we're never changing the typed array? If it's in the if it's the receiver.
SYG: That's right. Currently it doesn't either currently the spec doesn't either, right? Currently, the spec just like drops the sets on the floor.
MAH: Right. So what I'm saying is that you end up doing a receiver check and if you're not the receiver you fall back through ordinary.
SYG: okay, that's but that's not what ordinary objects on the Proto chain. Do they like they don't do that?
MAH: Sorry, I should have looked into this more earlier, but I got confused by your explanation. And so now I'm trying to catch up. Yeah, I think I expressed my preference for to be consistent for between props, but I don't want to keep litigating this. It’s fine either way.
SYG: Okay. Is there anything more on the queue?
USA: Nope.
SYG: So we have as far as I understand three explicit supports from the engine folks, one and a very reluctant don't care either way, but would prefer not this change but nevertheless. seems okay, too. Looking love this through. I heard an opinion from JHD as well to +1 the confusion. Is there a blocking concern JHD?
JHD: No, I have a very, very mild preference for what MAH’s talking about, but this is such a niche edge case. That, and as you said, it's an exotic object, so “it's fine, with the room on fire behind me”. No big deal.
SYG: All right, then. Okay, so with that, I hope we can stop thinking about typed arrays for a while and I'll ask for a consensus again and now calling any concerns with getting consensus, for ASH’s, PR here. What it? One something #1556.
YSV: so in for us and since we're going be infected by changing it, we are happy to change.
USA: There's nothing on the queue and I hear explicit consensus from the engines. Okay, I think you're good to go.
All right. Thank you
- Approval of PR, specifically: for IIEO
[[Set]], if receiver != target, in-bounds numeric property keys fall through to OrdinarySet, and out-of-bounds numeric property keys do not (i.e. no proto chain walk). If receiver != target, non-numeric keys fall through to OrdinarySet.
Presenter: Justin Ridgewell (JRL)
JRL: I'm talking about removing a job from adoption of thenable. So I'm going to start off with the little question. First off pretend ticks here is going to increment every single tick, every micro task. Every time it's going to increment by one. I want you to think about when do the particular log statements actually logged in which tick. Hopefully we all agree that the tick for the console A log will happen immediately. It'll be in the exact same tick as the executing code. That's because the executor is called synchronously by the promise constructor. We are resolving this Promise with a primitive value. And so, the promise itself is immediately settled with the primitive value, then callbacks happen after a single tick after the promise itself is settled. If the original promise settled in tick 0, then the callbacks would be called in tick one. And so, the B statement here is going to be called in tick 1. We're now returning a primitive value B. And then the that promise that was created by the then will be settled in that same tick in, tick one. And so the console log for statement C, it's going to happen in tick 2 because it again happens after a single tick after previous promise is settled. In C, we are now returning a promise, we're not returning a primitive value anymore, it is now a promise for a primitive value. I want you to think about when does D log and it's going to be a little surprising.
JRL: Why is it surprising requires you to have a lot of context. And I'm sorry, but this is going to be a bunch of very code heavy slides that are coming up back-to-back. Essentially the way that the promise Constructor works in the spec is it calls the executor the function that you pass to new promise constructor. It calls it immediately with resolve and reject. Now resolve is an internal function that we create in the spec and its name Promised Resolve Functions. I've implemented the the important parts of the spec in the code slide here, but I want to note that the function that we pass to a promise constructor is the executor and the resolve parameter is the excutor's resolve. I'm going to call it the executor’s resolve so that we don't get it confused with Promise.resolve. So, in the executors resolve, there are a couple of checks. Is the value that I'm resolving with, is it an object? If it's not, then we can immediately fulfill the promise with the inner value. If it is an object, we get its then property synchronously right now, in the same tick as the executor is called. So if the then property is not a function, then we immediately fulfill the promise with the inner value. And now if then is a function, we call then after a single microtick. Once we have the then function, we know it's a Thenable. We wait one tick before we call the then with the inner value and a spec function that will allow us to settle the outer promise.
JRL: What does then itself do? Well, it's complicated again, but then gets the symbol species of the promise. It's hard to describe because of the way the spec is written, but essentially what it does is it constructs a brand-new promise out of the symbol species. The new promise that we're creating waits a tick before it resolves with the result of the onFulfilled callback's return value. So when you call then it takes that onFulfilled callback, it waits a tick, and it resolves the newly constructed promise.
JRL: Linearizing that, if you're piecing this all together what has happened here? What we're doing is creating a new promise that's line 7 and 8 here, we are immediately calling the function, the executors resolve, with the inner value, which is the constructed promised a that I create on line 2 now, the inner value. That function becomes line 10 and 11, because the inner value is itself, a promise. We wait one tick before we call the the inners then with the function that will settle the outer promise. Then itself waits one tick before it calls, the setterOuter function. So before we can even settle the outer, we have to wait two ticks. And then finally, on line 16 and 17. We are waiting one tick after the outer has settled to call the logging function. So essentially there are two ticks that are required to adopt an inner thenable and then there's one tick to fire a chained callbacks on the outer promise. So, essentially three ticks for the next action to happen.
JRL: And so if you were to follow that in our question, original question, when does D log? It logs in tick five. We have to wait three whole ticks in order for this to happen. I want to change this because it affects the way that we do async await. All async functions are just really fancy spec machinery for a promise chain. And so if you were to run these for async functions, you have to think about when it actually logs the results.
JRL: On line 4 and 5, what I'm doing is creating an async function and then immediately returning a primitive value so that async function is settled in the first tick and so the then callback can be fired on the next tick, tick one. In the next example, I'm awaiting a value and then returning the awaited value. And so when does that happen? Well, we wait one tick because we're awaiting and then immediately settled the promise with the awaited value. And so here logs on tick 2. Line 11 through 13. This is where it gets tricky. What happens if you were to return a promise inside the async function? This is a native promise, which is also a thenable, and it could have been a fetch or any other API that returned in native promise. If you were to return a native promise what happens? Well, it has to adopt the state, which is two ticks and then it has to fire its chained then callbacks which is anothertick. So C here can't fire until tick 3. And finally, we have 15 through 17. What I'm doing here is awaiting a native promise. We're returning the awaited value and then chaining off of that D here, actually fires in tick two because we don't have to adopt the state of the promise here. await has special magic that allows you to quickly get the value of the Native promise. So I want you to pay attention to line 12 and line 16 here. It's faster to await a native promise and then return that value, then it is to directly return a native promise. It takes an extra tick, just for the adoption. So it's faster to do an await, then return than it is to just return a promise directly.
JRL: This bites us all over the place. So, what I want to do is remove the only tick that we can. The tick that happens when you're trying to settle a promise with a Thenable actually doesn't need to be there. According to the promises a plus spec, it's not supposed to be there. We created it I don't know how many years ago to get around a security issue, but we did it really, really badly. Unfortunately, we're paying for the security fix, not getting any of the security benefits. So I kind of just want to remove the tick entirely.
JRL: What will happen with that is now the D will log in tick four instead of five. It takes one tick to adopt and then one tick to fire chained callbacks. The next Thenable, and in every other log statement that I had talked about originally will be exactly the same if you Thing that changes is the adoption state of the promise afterwards. What will change if we have a async functions? Well, the only thing will change is line C. C will log here will happen in tick two, instead three, which means it's the exactly the same as log B and log D, which are awaiting a value, or awaiting a promise and returning that value. So they all become equivalent essentially and they're not one is not slower than the other.
JRL: So what else will change? Well, this is the only one that's easily observable. The Promise.resolve function, essentially checks to see if you are a thenable, and If you are actually a promise with a thenable, and if it is then special cases, but if you're not, it goes through the promise adoption logic. Here, log B and C are going to change. A is going to stay the same. So then if you remember when you call Promise.resolve you get a thenable with what you resolved, when you adopt the thenables then Is not on the pole anymore.
bot dropped. summary: There is an alternative proposal if this one does not get consensus.
JRL: Okay. So this is the initial proposal. I want to remove a tick that happens when you try to adopt a thenable instead of waiting a tick on line 9. This used wait 1 micro tick before calling line 10, we can just call it synchronously. And if this, we can get consensus on this, it'll fix all of the things that I want to fix. So, let's discuss this one first.
MAH: Hi.. basically we would not be in favor of shortcutting calling dot-then synchronously for everything. We would potentially be in favor of the alternative, which is to recognize a native promise and fast path them. However, I actually had missed the symbol species look up on then and I thought we would we were considering for alternative going straight for promised result then. If this would involve a single species look up, this brings other concerns, so let me clarify exactly what the concerns are. The security concern here is synchronous reentrancy: code modifying providing a thenable or in Native promise with the modified then or getter on the constructor. And apparently if we do this a getter for Symbol.species would be able to synchronously execute when the promise is adopted, or when the object is being adopted. So I agree the original solution here was half-baked, and we didn't prevent it with the constructor check and gets there in the alternative path. So, unfortunately, we never got to have safe promises that do not allow re-entrancy. So at the end of the day, we would like to find a way to actually get there. This either alternatives here seem to involve new synchronous interleaving points through symbol species that we are not comfortable with and maybe this should actually be moved to a stage one proposal so we can figure out how to fix this mess.
JRL: So, the real intrinsic problem you have here already exists, then is accessed synchronously, constructor is accessed synchronously. I don't see accessing species as being an issue. We're already insecure.
MAH: We have code that attempts to recognize promises and does own checks for Structure and then Getters and so on. So now you would be adding a synchronous call to species, which wasn't the case before. and which are code and some other clue that there, I'm sure doesn't guard against
JRL: You are already vulnerable to constructor. .constructors is already accessed synchronously.
MAH: yeah, so Yes, you can you can get it to do a known check and recognize the promise as not being a proxy in which case you are sure that Constructor you're not triggering anything by doing a known property Check for Constructor ahead of time.
JRL: How can you tell if a promise isn't a proxy by the checks? As in, how can user code determine?
MAH: by replacing the proxy Constructor and branding internally. All the proxies.
JR: This means the thing which owns all proxies has to be the thing that checks the the promise.
MAH:. If your code is in a privileged way, to know if something is a proxy or not, once, you know, it's not a proxy, you can do an own check property, check for Constructor. And if there is nothing, you know, nothing will synchronously execute.
JRL: Okay.
MAH: And now by introducing a Symbol.species synchronously, you’ve broken that assumption. I know this is very edgy and like, we've been trying to tame synchronous asynchronous execution during adoption, and we would actually really love to find a way to solve this problem as it was intended to originally, and which is why we would be in favor of working on a stage one proposal that addresses all the concerns of everyone.
JRL: Okay.
MAH: Too many changes for a symbol normally PR here.
JRL: Okay, there is no solution that will not face reentrancy.. Unfortunately the way that all this works, we would have change the way that properties are accessed in order to avoid this. There is no way to avoid at least 1 access. We could just settle with the constructor check. So as long as you're okay with a single constructor check, which already happens, but there does have to be some property look up in order to test if the thenable is a native promise.
MAH: I will admit I'm not sure how we can solve the Symbol.species and constructor look up to build the right kind of capability, but that's something I would like to explore solutions and how we can make promises resolved and promise, adoption safe.
JRL: Okay.
JHD: I share some of the same concerns. I just kind of feel like As you know, separate from that some of them were niche things that MAH talking about. I think that it makes sense to do this for built in things like the fast path approach, but I'm vaguely worried about problems caused by doing this for userland promises or subclasses. And since at this point basically nobody uses anything except native Promises because of async/await, I feel like that would cover everything. So I would prefer to just start with the fast path approach, and then if it turns out there is still a need for non-native Promises to get this extra behavior, then that seems like something we could explore further.
JRL:. So the to clarify here, the normal user land promised implementations already do the proposed change because that is the way it was specified in promises A-plus. In particular, Bluebird, which is as far as I'm aware the most popular alternative promise implementation follows promises A-plus. All we are doing is making the native promises behave.
JHD: In core-js and es-shims, they do what the spec does. I think that perhaps independently, and certainly combined, they definitely dwarf bluebird’s usage, but either way, I personally don't really care about A+. I think it was an amazingly useful transition plan, and now, the only thing I care about is the JavaScript spec. It's nice to know that A+ says this, and that's a good argument in favor of the change, but to me, that doesn't assuage my concerns about the non built-ins because, like you said in one of your examples, you’re using a well-behaved then implementation there, that resolves in the next tick. I don't want to have to worry about that good behavior.
JRL: That will not change the behavior of the then call back. It does not depend on the behavior of the inner thenable's then. So you could have synchronously called the resolve function with a value and the outer promise will still behave exactly the same, nothing about that changes.
JHD: Previously, if my then callback synchronously resolved, then that call would happen in another tick and with this change that synchronous call in other words is forced to be asynchronous - the bad behavior is corrected.
JRL: You do not need to fix your behavior. Your behavior will not affect the result, the outer promise just becomes settled. The settled outer promise will not fire the chained then until a microtick happens. Even if you call the resolve sync, or async, the outer always waits another tick after the outer is settled. This won't release Zalgo. Everything chained on the outer promise will still be called properly.
JHD: I clearly don't have a concrete example or anything. I'll have to think more about it. I think you've made an amazingly compelling case for making this change for built-ins, and I'm very motivated to see it happen for built-ins. I am vaguely concerned about non built-ins, but I also think that doing the fast path is fine because most people won't care about the non built-ins.
JRL: To show you the exact example that we're talking about here, if we remove the next tick on line nine, line 15 does not change. It will still happen after one tick. So zalgo in this specific case is not released. The outer still behaves as a correct promise. Even if you were to remove the tick on line 9.
JHD: I hear what you're saying. It's why I'm using the word vague. It's a very undefined sense of dread about that change for non built-ins and you're making good counter arguments that, maybe it's fine. You know, I just have this foreboding.
YSV: What does release Zalgo mean? I'm not familiar.
JRL: Oh, this is all in a blog post from 2013. Issac from npm wrote the blog post, describing the behavior of asynchronous functions. And essentially if you were to boil down his blog post, it says that if a callback passed to a function can be called asynchronously, then it must always be called asynchronously and if a callback to a function can be called synchronously, it must always be called synchronously. You cannot call a callback asynchronous and synchronous without releasing zalgo. And you should not look up what zalgo is besides his blog post because it is not work appropriate.
YSV: Gotcha.
JHD: I just posted the link on matrix: https://blog.izs.me/2013/08/designing-apis-for-asynchrony/
MAH: I just want to quickly say something. So core-js. implementation does follow the ES spec and so it doesn't synchronously call then and so it's not promises a plus for that and the author of that Library. Claims that until it did, did it that there were breakages that were observed. So this is definitely one of the concern to JHD point that non-native promises might break. Something would break break.
JRL: So to correct that I look through the bugs for his implementation. It was not this particular behavior that was causing the breakage. He incorrectly did promise adoption. But another part of Promise adoption, not the fact that then was called sync/async.
SYG: Hello. I wanted to clarify something about both the re-entrancy concern and JHD concern about username promises. So if I understood the re-entrancy sequence correctly, the concern that you presently have is not that we are we are like adding synchronous re-entrance e issue where there was none before but that you have patched the existing ones and that you're worried about a compact problem. In that there will remain users of your old library. That only past that Constructor and something else, I guess. Instead of also, instead of immediately upgrading to the new library that also patches the species re-entrancy of see, is Is that the concern
MAH: Roughly, I think we believe there is a way to make this safe and we would like to actually get there so that we don't have to chase around new places like this and I let MM talk more about this, but yes, the concern is this is adding a new point of re-entrance.
SYG: But not the point is sorry, about the point. I was trying to make is that you are not adding a new point where there was none before you're adding like plus 1. Instead of whereas there was like two before.
MM: I'll jump in at this point. The there is genuine problem. Here. We did screw up. JRL is completely right in pointing out that that we screwed up. You're completely right that the unsafety currently exists. What this proposal is proposing is to make it change which is not technically backwards compatible, we believe with high probability won't break anything. We believe that there is an alternate change that addresses JRL’s concerns and fixes the unsafety that we screwed up on and is also technically not backwards compatible in a different way, but we also believe with high probability doesn't break anything. And in any case and I can I can say a few words about it, but it right now our thinking about it is frankly half-baked. We want to investigate it but the basic thing is that you can internally check whether something is a promise, the brand check on promise synchronously. synchronously, without introducing a re-entrancy hazard, of course, and then once you know that it is a promise, then you know that it cannot be a proxy. You don't need a brand check for proxy. If you know, it's a promise, you know, it cannot be a proxy. And at that point, you know, you can do get own property checks on it without trigger without a re-entrance a hazard when you can check for other properties with get own property rather than get. So that's the that's the basic perspective. I don't want to argue about that perspective. The point is we want to investigate it. We believe that there is a solution on this path that has the virtues JRL’s proposal and fixes the original re-entrancy hazard we tried to protect against the screwed up. And in any case this whole topic is big enough that it needs to be a proposal going through the staging process. It certainly cannot proceed as a, as a PR that gets approved or disapproved as a PR, so we definitely vote no on this proceeding as a PR - as a proposal we would be willing to co-champion. It going We certainly would support to stage 1 and for investigating the topic.
JRL: Okay. That would be okay with me. I think. As long as we eventually fix for Native promises. I'm open to figuring out how to make it work for everyone. Great.
SYG: And to finish up my before we get to Kevin's reply to finish up my items. So thank you clarification. That helps me to JHD point. Now. Is that same? Like that because your concerns about userland promises where as you said vague, that's I guess this a different fast path. No matter what the sorry. Okay. Let me rephrase the question. How strongly do you feel that proposals in this space? Going forward, it must not touch the user land paths and we should only touch the native paths
JHD: I'm not sure. I think it's a little early to decide how strongly I feel about it. What I would hope is that this proposal investigates both paths in parallel. And if a compelling enough case can be presented, that there are no concerns then, maybe it's fine and we should do it for everything. But with what MM is talking about if you're doing a brand check, you've already filtered out anything except a subclass, so like I think that's the job of the proposal to investigate these possible paths and make a compelling case, one way or the other.
SYG: sure, but like your concerns of userland promises breaking depends on what exactly?
JHD: Let me rephrase: I would like to be convinced that commonly used promise implementations and thenables will not do anything unexpected with this change and going through the staging process is a good way to determine that.
SYG: Okay. Okay, I think that clears it up. YSV said in chat, something it's related to this.
YSV: You were first to, did you already cover your topic?
KG: MM, you wanted to have a whole proposal for this, would you consider changing the behavior of await to be in scope for that proposal?
MM: await delegates to the internal promise resolve function. I think the right place to the right place that we want to change the place that we want to add, you know, phrasing. It in stage one compatible ways, a place that we want to investigate as the place to change in the spec is the internal promise resolve function because all of the things because that has the best Leverag and the best consistency in changing, the things that depend on.
KG: Well, the point of JRL’s presentation is that there's currently a difference between await and returning a promise without awaiting it because returning a promise without awaiting does not go through the promises resolve machinery. It has its own path.
MAH: The awaiting does have await, does have the similar synchronous, re-entrance, you concerns, and so it would need as MM said, the by focusing on the promise resolve algorithm. It would solve it for both for all cases where this is, this happens, including awaiting.
KG: It would not solve it for returning a promise from an async function because returning a promise from an async function does not go through the promise resolve machinery.
MM: returning a promise from an async function is So, the it goes,
JRL: It goes through promise capability and it calls resolve with the promise capability. So I think KG is incorrect here. I think it does go through promise resolve functions. It just does it in a funny way.
KG: It doesn't go through PromiseResolve, which is where the fast path is right now.
JRL: Yes, await currently does Promise.resolve, essentially. If you were to return a promise in an async function, it does not use Promise.resolve, it uses executor's resolve to adopt the value.
MAH: So maybe to clarify, maybe saying promise, then algorithm was wrong, We want to holistically look at everywhere something is adopted, whether that is, as a return value of a nesting function, whether that is awaiting, or whether that is an explicit resolve
YSV:, right? So I've mentioned this in chat, but I'll also say it out loud. We have a preference, a very gentle preference for alternative one. Reducing the number of ticks we think is a good, a good goal and if it's possible we would like to do this globally but this of course brings up the web compatibility issue, but it has the added. I think if I understood correctly, it has the added impact that we don't have to touch on species questions and the discussion around how to fix promises. In fact be separated into a proposal that is dedicated to that space and we could potentially go with in a hypothetical world, We could have alternative one and all promises are sped up but this would require a form of testing and that's either that a browser implements and sees if this will work or it requires that we have a testing procedure. So I just wanted to mention that our preference is alternative one. And that I think that we can get away from a couple of the issues that have been raised here if that is largely web compatible.
JRL: On the testing front, the Google internal folks have said that if we implement this in Chrome will be able to run the full Google test suite against it. If any of our current internal tests would break because of it. Apparently they went through a similar change when we changed await to use a fast path.
YSV: Okay, that's actually very interesting. It would be very interesting to actually validate the web compared concern that's leading us down the path of alternative to before we make a decision based on it, if it's possible. So if Chrome is willing to do that work, then that's an investigation. I would much support.
SYG:I don't want to promise that we're going to do the work. I don't think that was what was not only that agreement with these, but yeah, do some change in Chrome.
JRL: We should be able to figure out if it's compatible least. with the millions of tests that Google runs.
YSV: Right, but I think what go ahead you could. We also just do like some kind of a smoke test to see what happens on the web, like running the top. 100 sites do something like this.
SYG: This is the general problem, right? Like given that we're changing. The number of ticks here we can do says, suppose we had the rollout procedure to do that. We pick some stuff, some number of sites, to run it. How do we know it? Things are broken?
YSV: Yeah, this is this is a problem we've hit before. I mean, this is an issue with any changes. We make to JavaScript, right? If we add anything to the Prototype, but we don't have a procedure for this. I suppose that this is a, this is a more general question about how we make decisions around, what possibly risks web compatibility and what actually, just misses our radar because it doesn't get reported on any of the major browsers as a breakage. So maybe that's an interesting topic for us to discuss another time. I two more Suppose I can just finish with saying that alternative one is interesting to us
USA: and our preference if it's possible minutes. I possible to test. hear that folks like to explore this as a proposal. So maybe for next steps we could talk about what a stage one proposal would look like.
JRL: If I understand all the comments, we will be going for stage 1 proposal looking into how we can change promise resolve functions, which is the executors resolve, and possibly await, so that we fast path native promises as the main goal. And if we can make non-native promises (thenables) fast without causing issues, then maybe we'll also approach that.
MM: That all sounds compatible with our desires for stage 1. And as I mentioned, we would be willing to co-champion if you're so inclined. And certainly if we were co-champion and in any case, we would want investigation of the re-entrancy hazard as an explicit part of the problem statement of what we are investigating in stage 1. and first for stage 1, I think that's, I think that's, you know, unquestionably appropriate since some of us are concerned specifically to fix that.
JRL: Okay. Is it okay to ask for stage 1 now? And then we can flush out the actual like the repo for it and everything else. After this meeting?
MM: we be supportive. I was I was wondering whether I should raise that we would be supportive of this going to stage one. Technically, one could argue that it's process violation, but the content of what and accounts for this is sufficiently presented that I think we can wave, I can. I think we can say that the spirit of the process has been satisfied by your presentation and then go for stage one.
JHD: I've also done conditional stage advancement. So we could say it's stage one pending repo creation. Pretty straight, right?
USA: Yeah, I think there's a lot of agreement on stage one. We just need a repo. So just when we could pass, I guess you could ask for consensus and spin up a repo next.
YSV: Yeah, just so just to mention, we do have a, we do have a mechanism for this in the process, which is the advancement, pending depending advancement. So it wasn't a complete.
JRL: Yes. I'm officially asking for pending advancement to stage one and then I will create the repo and everything necessary. After this meeting.
USA: On the queue SYG has suggested a problem statement. What do you think about that?
JRL: I mean, yeah, that's exactly what I want. The problem statement that is to reduce one tick from promise state adoption, which is my goal, I think is compatible, but we may have to differentiate whether that's native promises or user land promises.
USA: Okay, I don't see anything on the Queue. I think you have stage 1. Okay. Thank you. Additional on the, on the repo.
JRL: Yeah, then MM is bringing up that we're specifically investigating the re-entered. See which yes will be part of the stage one mission statement. Okay, great.
MM: Great.
USA: We're a minute over but we have stage 1. Congratulations Justin and thank you.
- Stage 1 proposal investigating removing 1 tick from promise adoption, without causing reentrancy hazards.
Presenter: Richard Gibson (RGN)
RGN: I'm going to try to power through but there's a high risk of background noise. This is a question that came up in the context of Temporal and there's an open pull request, which I can pull up at the end of the presentation if we want. But the summary of the issue is that we have a situation where it's possible per spec for the left hand to not to know what the right hand is doing. The Ecma-262 Date object has a concept of host time zone that shows up in the strings when serializing. And the Ecma-402 DateTimeFormat has something similar, but there's no connection between the two. So the code we're seeing on screen now is actually a valid combination of the two specs... Ecma-262 Date can report US Eastern Time in the same implementation for which Ecma-402 DateTimeFormat reports US Pacific. This seems undesirable, and we would like instead to refactor the relevant operations. We've got in 262 LocalTZA and in 402 DefaultTimeZone. And even though no engine takes advantage of this bizarre behavior, we'd like to preclude it entirely. The approach is to move the DefaultTimeZone operation from 402 into 262, but still maintain an override in Ecma-402 to remain editorial in terms of what time zones are allowed to any given implementation. Ecma-402 is limited to the IANA time zone database. Although there’s a follow-up that we can discuss later if we want to further refine that, and in fact I do want to but it's not on the agenda for this meeting. Bottom line, having done this Ecma-402 will remain as constrained as it is now and Ecma-262 will remain as open as it is now, but they will both be using the same fundamental operations so that any implementation supporting both has this mandatory agreement between Date and DateTimeFormat. Also in the pull request are some editorial improvements from Temporal so that it's kind of like laying the foundation for that. And it means that the ultimate Temporal pull request comes out smaller than it otherwise would. As noted, this does not include changes to any implementation we know about. Because as far as we know, no one exhibits this discrepancy. And it does not actually remove DefaultTimeZone from Ecma 402. That's the work that I mentioned would probably come as a follow-up to this. So I think that actually covers it. I’m ready for questions.
KG: Yeah, so can you explain the complexity around handling times which occurred during the Spring Forward because there's complexity there that I don't entirely remember. Like local tza doesn't have to deal with so much because it just says the implementation should return a time whereas actually using a time zone you have to explain how to translate the time which didn't exist, like 2:30 a.m. during spring forward to UTC; you have to specify how that gets handled.
RGN: Yes, the short summary of required behavior is that when the local time doesn't exist because it was skipped by a transition, we essentially extend the offset that existed before transition. So if there is no 2:30 because of springing forward, then 3:30 it is. We've made an effort to preserve that and I think we succeeded. Let me open up the PR. Yeah, all that text is still in here. Yeah, so what you see is in the operations that use LocalTZA, or the operations that replace them, they have requirements for when a local time occurs more than once or is skipped. The returned list will be empty or will have more than one element. That is currently a little ambiguous in local tza moves into this new operation. Based on this minimum implementation, we're definitely not making a change here. But I don't remember how much we specified in 262 versus 402.
KG: Okay. Well, as long as it's definitely not making a change, I'm not worried about it. I was worried there was - there's like a lot of complexity in this pull request which is around like getting the time out of the time zone and a lot of that has to do with the daylight savings transitions, but if you are confident that it is preserving the already required behavior, that's good enough for me.
RGN: Yes, I remember specifically paying attention to that. Should be. Oh yeah, so tBefore represents the last local time before the transition. t is interpreted using the time zone offset before the transition. So what’s here is a little bit more algorithmic than was previously present, but there's still a bit of hand waving that I'm expecting Temporal to clean up more fully.
RPR: Okay, there's no one else in the queue. JHD is a +1. Any other voices of support? Or disagreement? Plus ones are always welcome. USA is a plus one.
RGN: Okay. Thanks. I'll make a final pass through to verify before landing it. But assuming I remembered correctly, I think we're good to go.
RPR: Perfect. Okay. Yeah. Thank you Richard. I Knew You Got consensus just before your kitchen is running out for whatever.
RGN: Appreciate it. Thank you.
- consensus for TODO details
Presenter: Justin Ridgewell (JRL)
JRL: In last meeting we discussed the web incompatibility of the name groupBy. Essentially, there are so many websites that depend on the broken version of sugar JS that it's infeasible for us to update all of them to work with our chosen name of groupBy. So I'm proposing that we rename it to group and groupToMap. So group would be the normal returns a prototype list object for you and groupToMap would return the Map variant. When we did the similar rename with flatten to flat. We chose the normal adjective word flat, and not past tense flatten. So I think the name group makes sense with the precedent we set with flat. That's all I have. We can jump straight to the queue.
YSV: So I have a lot of sympathy for this renaming situation. The only concern I have is that group actually feels a little riskier than groupBy and I'm worried about the web compatibility that. groupToMap seems fine. I think probably that's not used. But did we do any validation of if group has been used anywhere?
JRL: I did not, no.
YSV: Well, we just be sad offering through it again. Is that the plan?
JRL: possibly? Yes. I mean, is it my intuition here is that there's probably not a method group. It might be that there is a data property called group, and you won't be able to access it. If you were to override it on your array, it might break, but I don't think it would be terrible.
YSV: Okay
JRL: I don't know of any library that implements a method ‘group’. I think everything that I'm aware of implements groupBy.
YSV: Okay. All right, so I guess we can try to implement this but I guess this is going to. We're going probably just test and see if anything breaks. But yeah, I think this is another spot where I'm just wondering how we can make this better.
JRL: I have no idea.
MAH: on the topic of a group, maybe a data property exists. I'm wondering we risk triggering the override mistake here in the sense that if we add group and somehow that is use an array is used on the Prototype chain. Are we risking now somebody trying to set group on there and it wouldn't be able to set it because array prototype is Frozen.
JRL: We had a similar issue with Array.prototype.at where someone was using an array as a hash map object with arbitrary non-integer keys. There was only a single site that we were able to find. So I think using arrays as hashmaps is uncommon. I think we could be okay.
MAH: I mean, so basically we're fine with this. As long as there is no web whip compatibility issues.
JRL: Yeah, so I think that's the way it has to go.
YSV: So I think yeah, I think what we need is to is we need to validate that. It's that it's what compatible change. I don't know if we want to do that before, like committing to this name. But yeah, I'm not sure how best to do this. We do have a full implementation in Firefox. What we can do is we can change the name there and see what breaks, but I will turn off the feature immediately as soon as something does break. So that's one option. But yeah, I'm really thinking that this isn't the best way to gather this information. I'm just wondering how we can do differently. I don't don't have any ideas.
RPR: SYG, asks about the override mistake issuing
MAH: this would be in an environment where the built-ins are frozen.
SYG: Okay, you're okay. So there's other user code you load before that freezes them.
MAH: And in environment of breaks. Yeah, or node, Frozen intrinsic. You know. It went node. freezes, array.prototype. I know there's an option to start with a frozen industry. Intrinsics.
SYG: Okay, I understand the concern. I am. I have my own concern that we take that kind of environment as a concern basically, but okay, I understand.
MM: That's also the environment that TC53 takes those normative and that and that excess multiple ships with
SYG: But it is not the normative. Thing, right? Like it's user code that can do it. But the thing we ship is that these things are writable what they think the spec says.
MM: Yes, the TC 53 device environment assumes that certain actions have been taking in the within that JavaScript engine before cutting the ROM and one of those actions that's assumed before cutting, the ROM is to all the primordial zayi to configure things like an SES environment.
SYG: I understand. I am saying I would like that too. It's my understanding that the currently the normative constrains of these 39 and 262 is that we considered that these things are writable like Like we will be designing like the web component placement, very different. If we also assume that they're not writable.
MM: I understand that is standardized using a system in which the the initial state is. Everything right appointed. There's I completely understand that the point is that we're a pushback on a particular proposal, is always what does it break and things have broken for really bizarre reasons because other user code did other things. First there is enough use of frozen primordials between all the cases that we mentioned. that whether something breaks in an environment in which the frozen the primordials are frozen is breakage to take into account. The way we take other breakage into account.
SYG: Agreed, that it is a breakage to take into account.
MM: Great. Great. That's all I was saying.
RPR: JRL, do have any more?
JRL: That's it. This is just a status update. I would say I'm going to merge this PR afterwards and hopefully we'll find out that is web compatible.
RPR: Okay, so just to check here what we're saying, effectively. We have a consensus to merge this PR but we know that there'll need to be some checks, web-compatibility checks to follow.
JRL: Yeah.
RPR: Okay, so let's just check on that consensus any objections to merge. Okay, no objections. You have consensus. Thank you.
- Merge PR, attempt using ‘group’
Presenter: Daniel Rosenwasser (DRR)
DRR: Great. Okay. I'm here on behalf of both me and KWL to present five last and final stage. Good for this Or when you can. presentation. So driving, most of his hard work. So the most part, have everything that we need for stage 4 where I have links here if necessary got suspect ex stage four criteria as a tracking issue where we link out to more things and a list track of implementations that have already gotten, you know something implemented in shipping or are on track to being implemented. Since we last presented, the only thing is this a minor typo? So no major changes just if we need it. I have the specific spec text in the slides as a refresher. much of this is kind a mash-up mash-up of like lastOf, and find and findLast and findIndex, right? And so, I don't think we're going to try to spend too much time on these steps, but if you need them, they're here. These are new sections and then, the only modified section this section on the on scope. So, we have test 262 tests. We have spec text as a PR ready to be merged and we have multiple implementations shipping. Or pretty close to being shipped. So we should have stage for qualifications. And so with that, I would like to ask for stage 4.
RPR: All right, any objections to set the stage for? Right. Any any plus ones? We have one +1 from JHD? And as a bit more, yeah, LCA with a plus one. All right. I think we can call it. Congratulations. You have stage 4.
DRR: Thank you very much. All right. Thanks everyone. Thank you, Daniel with earned time back.
- Stage 4
Presenter: Leo Balter (LEO)
LEO: Okay. Yeah, I don't have many contents here. This is a part. 1 of 1. Let me share my screen quickly. hmm, don't have anything like such as big slides on your thing, huh? so yeah, this is just like status updates on the stage, three couple, couple slides. I guess you can see my screen, right? Yes. Okay. So this is a part 1 of 3 for shadow realm. So we also have like a item that was headed by SYG which is we can consider this part two they not done. Did they? Follow specific order. And we have a part three, which is regarding the html integration, which might need more time. And it's also like a sad for extra discussion. Implementation status. We have Webkit. Actually Safari technology prefer already showing up, initial implementation of ShadowRealms. There are still details being discussed. We are aware of that and I as I believe like the Apple team is as well. We're so we have like a few details but like mostly, we are using these ShadowRealms implementation to also test things internally which are running great with good performance. I know there's a lot of ongoing implementation on Firefox. A lot notifications coming from Mozilla and we have ongoing implementation going on in Chrome. So things are still like, active. I think this is the best status to report right now, still active, but there isn't anything like really new to test on other than small normative PRs for the work here one. Is that one of them mostly reporting. The HTML GGA which was just an issue raised for regarding when we move a document.all across Shadow realms. because they're, they're just awful and I can get like weird results. The problem with document.all with, We've all the problems It has. It's not excuse me. It's to somehow callable. So they have an internal ‘call’, call, but they have different. results, if you give different arguments, and so, yeah, you can, there's wrapped the cross or Realms. I understand. There is no. We want to give no special treatment here in. So let me remember because this is not Amazing. Okay. Yeah, so for the behaviors that we might predict it. GG ayy is actually wrapped as call callable. This is the status quo like that means. If you try to transfer document.all, like it's just gonna be wrapped across the other realm with whatever results they have a cross and we could actually see the other options. I think the number three here, isn't it dda as an argument throws with type error? we consider you to just be an object or exactly callable that would actually require some extra work in the steps, like special treatments for something. is in annex B. The for my understanding. I think we should just keep this out of scope. But let everyone know that we are like we get we are given intentionally giving those special treatment to treatment to DDA crossrealms if they do. Have an internal call know regardless like how awful they can be status quo is just like the way to give them. I think this gives good path the way they on You're going the future on how to be moved and modernized. If we do, we can add things to the queue to discuss this, but my vote is just like to keep on static School, unless someone has any requirement. We can discuss it. I will move on for now to the other part,
JHD: Yeah, Yeah, just means document.all is already getting special treatment and it depends on which perspective you have, right? If you're looking at spec text, special casing things for document.all might be seen as special treatment, but I think the more important model is that document.all being callable is the weird thing - we can’t get rid of it because of web compatibility.
(audio issue)
JHD: That's perspective because you're just saying, well, it got a call slot. So we're going to wrap it and option. Three is the one that's similar in my opinion from a user perspective. It's I don't know how far I got, but between those three options Option 1 is the current behavior where the spec is simpler because document.all has a call slot. And so it just says it's callable wrap it. Option, 3 to me is much simpler from the user perspective because this thing that really isn't a function Like, not really can't be passed across the shadow realm option, two would be just bizarre to me. So I would really prefer to go with option three so that we don't add more places where document.all is, this kind of weird quasi function?
LEO: yeah, just an observation as like the the option three In my opinion. He's kind like, as I mentioned already, give special treatment to DDA if we move on such tree, we extend a special treatments like kind of reverting it back and Shadow Realms. I am kind of neutral to this. I just like preferred a shortest path for me, me, but like neutral. in general, maybe we can see like, like, how the The room prefers. I don't have a specific. Yeah, I agree on the like the option 2, as like, not go. Let's not go through that path. This is not weird what we are proposing here. we have other comments on that.
MM: Okay, I do. Yeah, it's I think it should be a quick question. It does not affect my opinion on this, but it might affect somebody's so it's at least possible golovin. There are various pure JavaScript emulations of the DOM that run for example node. I'm wondering has pure JavaScript. Have to choose one of the way possible ways to emulate what the document.all is. Does anybody happen to know what choice they make about how to emulate document.all on the server side. Wow, okay. any case I'm good with either one or three. so I so plus 1 from it from me for either of those choices. I slightly prefer three, but I don't not to the degree that it should sway the decision.
LCA: A quick follow-up on that, MM, from everything that I've seen that people do. You know, I don't think anybody has any special handling with document.all its Like, it doesn't seem used enough that people care about it.
MM: Thanks. Yeah. Is there JHD just make sure like? as a champion, I might actually make sure proposal is just like continue the status code, you have an objection on that or you have a preference for preference for number three? We might have lost JHD’s audio.
DE: So I'm not sure if this is what you're saying. LEO, that that we would propose one is the conclusion of no special handling. Are you proposing? Three? Is that conclusion?
LEO: I am proposing. Number one, the status code, No change to the shadow realm API regarding gradiate.
DE: I support that conclusion. I think that's, this is simpler option and it's nice to go with the grain of the logic of not giving special handling. So what would propose like a call for consensus on that so that we could close this? Issue and move on to the next topic. I'm not going. Just not sure if we have JHD connected.
RPR: YSV suspects JHD has lost audio. I think he has, I think he moved from his hotel room to a conference room.
LEO: Yeah, let me move to the other item and then we can just bring that back to the conclusion as like famous last words. It should be fast. yeah, this is a thing returning from the previous meeting, where we had some, we were of get function realm throwing revoked proxies. This has been reviewed since March with no further comments, and this is the, the change proposed by CZW, which I don't have any opposition for that. If we, as we do, Apart, like are two and three coming up. I think we can use a part 3 as long as anyone needs to take a like final look to it from my perspective. It looks good from as CP reviewed it, It looks good, but I we've seen no objection so far for me. Does anyone need more time for this PR?
RPR: Nothing on the queue. No one is asking for more for the time on this.
LEO: very issue and the call and make sure she was comfortable with us moving these ahead and asking consensus relays.
SYG: I'm here and this seems fine to me.
LEO: Okay, good. Yeah, so I'm asking for consensus on Sundays.
RPR: No objections. I think you have a consensus.
LEO: Sounds good. Yeah, I'll finish this later for now. These are fine. I'm not sure if JHD’s back. Asked, again about DDA you one. Yeah, I was able to ask. Okay, So JHD, I was telling and with support from DE. as a champion. I am proposing. The number one. Lucien, I understand like the number three would be ideal for some sort of like user perspective, But we, Our intention is to give no extension of the special treatment for DDA in. I think it's fine as this, my question for you was if you actually have my question for you is, if you do have objections for number one,
JHD: not in this case, but I don't want this to be a precedent. I would push towards banning document.all from new places, where conceptually a function is expected. But I don't have to push for that change here.
LEO: Okay, that does it mean can we close this issue or? Considering like spec will remain I says for now.
MM: I heard JHD agree. So yes, yes. Y
JHD: Unless there's someone else feel strongly with option three.
RPR: So it's yes. It sounded like one was acceptable to all. There was not any objections to one, so it sounds like that is the conclusion.
LEO: Okay. In a, just a trying to sort of summarize. What is coming next? We have the topic for a second part from sure. I think it's following up Now this SYG is driving and we have topics about HTML integration, which is for another part that we should see discuss this for tomorrow within 60 Minutes, anything that we need to revisit. We can. can be my find time tomorrow, but yeah, and we have things coming forward to meeting in July. We I just needed more time. I didn't have time prepare anything for this. call regarding the following PRs. And with that, I end my screen sharing.
RPR: Thank you LEO.
Presenter: Ujjwal Sharma (USA)
USA: Perfect. Thank you. Okay. Okay. Hello folks. Hello again, for the third time today. today. temporal now. So sorry, just one moment. Thank you. Okay, so, what's up? For example, you might ask. Well this. If you've attended last few meetings, might find this familiar. This is similar to what we asked for consensus on the last meeting. This is mostly several minor normative changes. They can be in two categories. There is on the one hand, there's changes suggested by implementers essentially implementer feedback. We call them adjustments. Or changes that we need to make the spectators more accurately reflect the decisions. Essentially uncovering old spec bugs. Well, one thing that I'd like to point out is that there's nothing major, this time. It's just tiny fixes. So if anything that helps. We will convey the game plan, which is that you'll continue to turn implementer feedback into presentations. It's like this hopefully Islam until we reach stage for but the number of normative PR's between two. plenary meetings are still decreasing. So perhaps we would not need them in the next few months. The ITF update from my side is that we're only on the last few legs. I feel this relief for the final reading. Buddies are however, there are some bikesheds that are bothersome but should be fixed. There's broad consensus within the working group on the syntactic details and the RFC should be published soon, but it's hard to hard to say when. Regarding the adjustments that we've made to the spec. First of all, there were some concerns regarding non for two, implementations with calendars. So currently an implementation that does not have a support internationalization is constrained to support, Only the iso 8601 calendar, but we remove that because well, for instance, a internationalization fitted in implementation might want to support. So for example calendars, like the Gregorian calendar for instance, but it does require that any supported calendars are from the said that are supported by Angel. So, you cannot confirm arbitrary calendars, you can selectively support. calendars and implementation becoming too capable should not remove functionality either, so they're still constraints, but we're relaxed some of the requirements that did in sort of match the understanding of the implementers. Next up, we have the next PR which is the order of operations in date, from fuels. the changes in the order of thrown exceptions in a really sort of case are, maybe the example would make it clear. So if you call calendar dot date from Fields with this together, it throws the Site before and in the type Ever After. So we fix that. It makes the spec nicer to read and it somehow wasn't uncovered in the stage 3 reviews. Sorry for that regarding the We removed and errors. Sorry. I can't speak with her new and earnest run check. So there was a faulty rain, check in Temporal. Pull in from it is fixed now. So some valid strings were previously invalid, now, that's that's fixed. We also changed the time zone name grammar. So time zone strings with UTC offset. were not in the grammar. Now. More invalid strings, that would have been valid. So like if you check out this the current spec throws, the intended outcome of the Champions group was that it could be valid. Just the same way, Beyond the time zones, Develop. So that's X now. there's also, we also fixed a mistake in the exact time rounding. And so the rounding method on instant was buggy, that's that's fixed now. We start using null Proto objects in more places. So if you yeah, sorry, it guards against some of the odd cases where you can put in all sorts of objects.And now go it's It does the same sort of probably property look up. They are also fixed. Yeah, we validate the Overflow option in the from method now. So this is basically similar to the previous one, but it helps with consistency with property bags. and yeah, so those are all the changes. Please let me know what you think about them
YSV: I'm going to the queue. It looks like it's empty at the moment. If anyone has any comments, please feel free to add yourself there. … I'm not seeing anything you want to ask for consensus?
USA: Yeah.
YSV: All right. YSV: Looks like you have it. Wait.
- Consensus
Presenter: Shu-yu Guo (SYG)
SYG: If you're there with errors, across the ShadowRealm. Yes, I am. Okay. So I have no slides here. It's fair. I don't think the solution space is probably simple. I think I think of the problem, the motivation, for the problem. The solution we're trying to solve is fairly simple and note that there is no concrete, normative change being applied for here, but I want to kind of get the discussion going on. what the actual invariants are that we are trying to preserve and and get some clarity on that and then the plan is to come back later with actual normative change. So, the problem at hand is that shadow Realms have this callable boundary? And the whole idea is that we build in a boundary? Into the API. So that you cannot accidentally intermingle the object graphs of things in the shadow realm with things in the outside realm. This is done by the callable boundary, where the only things that are allowed to pass through the boundary, are primitives, and callables with callable objects being automatically wrapped. All other objects throw when you do when they try to cross the boundary.
SYG: So, what does that mean for throwing errors? So currently the spec says something like, if the shadow realm code evaluation throws an error, we should re-throw a type error in the call learn. So like the caller. Calls into the shadow realm to do something. And this example calls this evaluate function, but it could also be an import value in case, you know, CSP is on or something. And if this, if the thing that is being evaluated itself throws, then the shadowRealm machinery. All the spec says, is the shadow realm Machinery, should a type error in the caller realm. So in this case with the caller of Shadow Realm .evaluate, the problem with that is that this makes Shadow Realms basically impossible to debug. We ran into this pretty quickly in the Prototype Tests implementation in Chrome where we were writing tests for import value, cause I wrote The implementation. And the tests were failing with just, this cannot import are and we're chasing it down. It turns out, it was just a stupid mistake. We forgot to upload some support files onto the test Runners And the error, the inner error was just “not found”, but the outer area was just generic, cannot evaluate or cannot import values. Value or something and the inner area was completely lost and took longer to debug and fix than it should have. You should have been like, a one minute thing. The file is not found. We can forget to update. So it's a, it's a, it's a major ergonomics pain point right now that the air is just kind of getting dropped. So the discussion is, How should we make this more ergonomic and actually debuggable during development. We should not obviously define the callable boundaries such that, you know, the error itself is passed through, but how do we preserve the actionable information when we rethrow the error in the outside realm is the general question. I know that the SES folks have opinions here. What should or should not be? Allowed to cross what should or should not be reproduced I guess. There's some difficulties. Let me see if I can find the right one. The right comment here. So, here are some questions to ask at least. Can we do things like, should we prohibit stacks from being preserved across the boundary stack serve continue, you do not be standardized and it seems to be desirable by all parties. It seems to be desired by all parties, rather that don't work across the boundary. that if the shadow realm either, we throw an error. It does not work. Stack that the kind of exposes the inner workings of the show around code. Another question is, how do we preserve the messages? Is this like eagerly reading the message property on the, the inner exception, the inner error and then copying it that you know, has observable normative effects. like it calls the public cost possible Getters on the inner error. Should we somehow take a fast path and check only for Native errors, the last question is something that has been raised that I have a pretty strong opinion on personally. And that question is whether we should just stick to which user thrown and platform thrown media platform, thrown errors to distinguish. The idea that user thrown errors errors caused by user code should just be kind of dropped but platform throws are just maybe getting their messages copied something. I feel that we should not. Wish users thrown in platforms rather than areas. Mechanically. I'm not sure how to deepen it, But just practically that, if we start distinguishing that, I think that has such large knock-on effects on the web ecosystem, all the downstream specs that it's just not a good idea to do for now. But anyway, these are some questions to see the discussion. And with that, let's open up. The floor for discussion.
MAH: Yeah, so I think my concern with passing messages through or anything that has a probing of the value being thrown seems incompatible with what we're trying to with the with, what the callable boundaries is currently doing. Currently the correct called boundary is just introspecting the type and letting it through or not, doesn't affect. the value through at all, here, you would have to start automatically probing the object itself, which, which seems like too much. And Regarding the point on user thrown versus platform throw error. The way I see it. There's it's, I wouldn't frame it like that. I would frame it. as is their user codes in the context inside the realm, where the or if is thrown or not. If there is no user code on the stack. There is no way for the user code to handle this exception at all. And so yes, there is a concern there and as far as I know that concern only ever happens during an import and the host is throwing an exception because it cannot resolve a part of the module graph. As far as I know. This is the only case where that can actually happen. And really the context here is Shadow realm is an advanced low-level API code. That executes it has to be at least the entry point, the, the first layer of across the callable boundary, as to be aware of the existence of the callable boundary and at that layer can catch all exceptions and report them as appropriate for that system. And so really this is, if the code executing inside the coal burner, he has no opportunity to do that. For example, as in the case of the module graph in exception being thrown away. unreasonable, when during the resolution of the module graph,
SYG: So concretely, are you saying that maybe we just special case errors thrown during import value during the module machinery?
MAH: I don't know how mechanically that would work. What I'm saying. In my mind, the operating guideline here should be, is their code executing in user code, executing inside, the shadow realm, that would be able to catch and handle the exception or not.
SYG: I see so so you're thinking that it is by design that errors kind of become opaque. Should they cross the boundary boundary? And that it is acceptable to be un-ergonomic in this case because that's, that's I mean,
MAH: ShadowRealm is a low-level API. And un-ergonomic in the first place. You can't really do much without having agreed code, especially aware of its existence.
RPR: Right, there is three minutes left on this time box. And the queue is quite deep.
KM: I guess, I guess I could start. I guess my question sort of was answered to some degree. one thing. thing. I don't understand what it's like talking about, I guess it's sort of a continuation of the last topic to some degree. Why is it like, isn't there or isn't it already possible for the creator of the realm to muck around with the internals, by just forcing Imports of its own files? What does it create? We shouldn't be overly worried about the outer realm seeing data from inside the realm. Like, like a, but I could imagine something where, like, the stack Trace is truncated inside the realm like and like to include or exclude frames from inside your realm. But that once you exit the realm like the outer context is allowed to look at the whole thing. Of course, thank you. I could imagine something like that. If that makes sense because I wouldn't guess you're eating. Yeah, group, debug abilities.
CP: I have a couple of comments on that very quickly. The problem with errors goes both ways because they can occur not only when you try to import something, but also, when you try to call something that might be a wrapped function, so we have to be careful about it. We just generalized the mechanism when an error occurs to shadow the error, so you don't see what's going on the other side. In the case of the importValue, we know who the caller is.
KM: just wanted the realm itself to be totally exposed to the creator of the realm.
CP: Yeah, with the importValue we know who the initiator is, in this case, and it's the outer realm. And you're right, that should not be a problem for the incubator realm to see what’s going on inside the shadow realm. In that case, we might be able to expose that actual error into the incubator realm. We call the module resolution mechanics when importValue is invoked, and it should not be that difficult to propagate the details of the error because you're doing a module graph initialization. I believe we could that problem first, and then look at the other problem. I think these three bullet points that SYG has on the screen are important. So we should look into this but not in the context of the importValue mechanism, especially because we're doing that with the evaluate method already. So we might be able to accommodate that, we already accommodate that for parsing when you calling evaluate and the error is a parse error. You're going to get the details of the parse error on the side of the incubator realm. They seem analogous.
KM: in general, like period. It doesn't seem like if you can imagine something on the realm that's like you have an opaque realm error and then the creator of the realm is allowed to like access properties on that be like some realm.dot. Get my information and it returns to you an error that It's all the stuff from your Realm. I guess it's sort of what I'm saying, if that helps ergonomics, that's one possibility. Anyway, that was kind of what I was thinking. Does that make sense to anybody else? Or am I just saying things.
SYG: I think it makes sense to me. I don't see how it works yet. It seems that might be a bit involved. So I want to make sure that the carve-outs there actually are totally fine.
LCA: yeah, so I just want to +1 the not distinguishing platform user errors. That seems very technically challenging and also very difficult to understand for users, and it also makes a bunch of things like polyfills or other things which Implement platform features in common and much more difficult because they would work with this. Like what were these? Like special platform areas that do get passed over the boundary?
MAH: Quick reply to that, I think yeah, you would have probably had to shim the shadow realm on the API at the same time. I suppose. I mean anything that would be special passing through the callable boundary would require The callable boundary to be shimmed.
KM: Right. It's just kind of questionable, If that's something that we should be encouraging because polyfills are relatively common like a relatively common thing, right? And also there are runtimes which Implement a lot of platform-like APIs technically code. Like I would order, already know.
MAH: I mean, you're talking about the module graph resolution, which is not some wholly fillable, and
LCA: I'm not talking about the module graphic solution. I don't think I'm just talking about generally platform versus user areas that she would bring up.
MAH: Right. I didn't just make what I mentioned earlier, like, defining guidelines. Is there any? User code on the stack. and so if it's an error, that is raised without user code being evaluated, it is By definition. I don't believe it can be anything that wouldn't involve the shadow. Realm, being polyfilled as well.
LCA: Sure, right. But like that, it only solves the errors coming from module import. much of the solution areas. It does not solve the general debugging use case, which maybe is fine if Shredder wants a low-level API here. Not this is not something that you meant
CP: All right. So why don't we focus on the module graph solution specifically, because this is the pain point. If you go into your debugger and you break on all errors. You're not gonna get an error in a particular line during module linkage where something happened and this is the main issue. On the other hand, if you throw a regular error during execution, you should get the debugger to catch the error on a particular line. You can always get your browser (in this case) in the mode, and break at the error, and you will be able to debug it even when code is running inside a shadow Realm, we will see whatever is happening there. But in the case of the importValue, it is really where you have no choices. You're not going to get that error, instead, you are going to get a shadowed error where you don't see anything. I think solving this will solve a big chunk of the problem from the ergonomics point of view. So in order to solve that, as I was saying before, I was looking at the spec and what we have in there is that the importValue triggers the resolution process for the module and evaluation and so on. And if there's an error during that process, we have all the information at hand. It's just a matter of throwing the error in the incubator realm rather than the actual shadow realm. I think we have all the information already. They might be able to surface that. But, if that's not the case, then we'll have to do a little bit of gymnastics on the spec, to be able to capture the proper information about the actual error, and then get it down to importValue to surface that to the incubator realm. I think it is not going to be that difficult. But the point I'm trying to make is that importValue covers a lot of ground in terms of ergonomics. So we can do that. The rest is not a big deal. We can definitely look into how to improve, especially with the work on the error stack and so on in the future, but I think focusing on the importValue will get us very far.
SYG: I Thank You CP. I also agree with that. I do think it'll go pretty far the, the, your point you made earlier about. We already special case parse errors. That's a pretty Salient one. And this extends that symmetry well. Let's drain the queue. And then I have one more thing before asking for any concrete consensus.
YSV: I'm having some trouble with my audio. So I lost about half of the conversation, that just happened. Sorry, if I repeat anything. So I have a couple of concerns that we're sacrificing ergonomics by saying that this is a low-level API for experts and this has been used as an argument for a number of the design decisions, including for example, passing null to the host import module dynamically, host hook. So I have concerns because I'm not sure that we're not just making things more difficult without adding a genuine benefit by making things more difficult and in addition to that, I would hate to see us introduce this API, so that it is inaccessible to developers when it doesn’t need to be, and requiring spec knowledge, or end up benefiting a smaller set of organizations than it otherwise might due to its poor ergonomics which could have been fixed. To that end. I do think it's valuable to actually surface errors. They are a very valuable debugging tool in some form and that we can discuss, what form that might be. So there are maybe a couple of ways we can do this. I just wanted to express that I believe ergonomics are important also, for low-level APIs, and I don't think that the argument that this is just a low-level API. It doesn't need to be ergonomic. It is one that we should be making design decisions around and to further that I just To propose maybe one way we could do. This is by introducing a hook like processError and maybe that would be something that helps you. That's all.
CP: Yeah, we have discussed that in the past! In this sense, we intentionally reduce API to the minimums. But we definitely can do that. This is an interesting point because it also potentially solves another problem that we have which is unhandled promise rejections. Since we don't know what to do with that. So we don't have a model right now where the shadow realm itself can handle those promises, those errors related to promises and so on. It might be a good opportunity to move this up one layer to the incubator realm. A developer can have all the information about the error and then decide what to do with that error, maybe propagating the error into the incubator realm or just simply doing some app specific behavior, like sending a beacon back to the server, or something like that in production. it might be that this solves multiple areas that are still not very clear. I'm up for looking into some sort of hook mechanism for errors. We removed all the hooks just because we wanted to have a very small and concise solution.
YSV: Yeah, I can, I can definitely see the point that you wanted to keep things smaller and more concise and I'm open to how this is addressed. Like, Like, maybe we discuss this. So DE also raised a very similar point that marshaling, or reifying it into a field. Might also be a solution. I think there's a couple of ways we can solve this. My main emphasis here is I would really hate to see us developing low level APIs and intentionally making them un-ergonomic because the idea is that the people here will be experts in JavaScript. I think we should be as accessible as possible even unless we are introducing something that's dangerous, dangerous, which is intentionally unaccessible. And my understanding is that shadow Realms is intended to be a dangerous API.
SYG: So, I want to clarify that, which I think is important. Okay, so the callable boundary exists. What's taken to the very fact that ocado battery exists is very honest to God, right? And the whole point of that was because the argument there was that it is dangerous to, to mix the object graphs, not in the browser security sense, but it is dangerous in the kind of use cases that folks wanted to use Shadow realms for. We might as well build in this. We believe there's a right trade-off. You don't have to build in a callable boundary that was itself ergonomic, That was known on Earth as an honor. This is maybe a Fallout of that on ergonomics, nasaan. How can we kind of round out the edges a little bit? But, but yes, it is true that like we did make a trade off against something that we thought was dangerous to allow like, this could have been as the original proposal. Loud. The object graphs proposal. No callable boundary. to Interior intertwine, but that was deemed. Not a good thing to allow by default,
YSV: Yeah maybe I'll clarify what my distinction is. I consider something like finalization, and weak references to be like a dangerous API that we introduced for the use of experts. And there are aspects of it that are unergonomic that we intentionally had as blockades because this is an API that if you use it incorrectly, you will run into trouble. think with the introduction of the callable boundaries. To the Shadow realm. So we actually introduced a safety mechanism, but I'm afraid that we're now using this argument that it doesn't need to be ergonomic because it’s low level to make other decisions that aren't that may not necessarily have this dangerous element to them where we want to discourage users from using Shadow Realms. Maybe I'm getting this wrong. Also, maybe we want to discourage users from using ShadowRealms.
MAH: I have a reply, some on the queue. I think that it addresses some of this. You? Yeah, you mentioned that this API only being used by a handful of organizations would be kinder to the goal here and it wouldn't really have an impact and I disagree with that. Like I think if a few organizations build libraries that can be used by the broader community, it can have a huge impact and the broader Community doesn't need to be concerned with the complexity and the are going to make nests of this API, if they can benefit from it, and I think that the important part is right now, the callable boundary is not their ergonomic by design for for the security foot guns, that SYG and CP mentioned. And because of that, you have to write specialized schools that run in it. My hope is still that we can have follow on, proposals that can make it built in more usable More usable to use, Shadow Realm. So, maybe they have built in membranes, or maybe have built-in mechanisms that allow it to make it more seamless, right? But this would be just a building block here.
YSV: Yeah. I worded my comment poorly. What I was worried about was that I didn't want to see a situation where this wasn't being used and that it became one of these mysterious parts of the JavaScript surface. For example, I think that one issue is that proxies are poorly understood. I think they're easier to use than what this API is shaping up to be. But I would like to see us be very careful when introducing things that are difficult for people to understand and make those choices. Really carefully, I think finalization groups and weak references was a good choice in that direction where we intentionally dropped economics as a goal from that. But I do think So, the reason that I bring this up is because there is this other issue, which is around how modules are imported into a shadow realm, and I don't understand why we're making it more difficult for users to do that import. And then I'm seeing a connection here where this is also. When hiding information from the user that we might surface, that may make it easier for them to understand why an error is occurring. So I'm questioning why we are not adding certain things easily. Ergonomic blocks for the user to use. Maybe this is just that I'm not fully. I follow Shadow Realms at a surface level. So I may simply not have the in-depth View.
CP: I'm very sympathetic with that position.
SYG: Can I have like one minute to ask for them to say some concrete next steps and try to get agreement on that?
SYG: so. the immediate issue is, I would like, I would guess like to that that this discussion that general issue of how to make errors more, ergonomic should the shipping of this, this proposal, which is already stage at three more scoped, I would like to block shipping on, hopefully the Champions are up for this, you doing something out with surfacing of the Module resolution errors, which will address the short term development pains. As it's pretty, it has been identified. And then independently work, They follow a proposal to tackle. tackle the error problem. At large and there are problems at large. I am now also, punting on like should be copied at the top message or should there be a process hook. I don't want to. draw any conclusions in haste there, but I think it made sense General agreement that we should solve the model, resolution is a surfacing problem and that it is a problem. We can solve without affecting the rest of the error solution. So concretely, I'm asking. Can we get the champion, the shadow realm, Champions to commit, to come up with a PR that is normative PR, they will come back later to surface, module resolution errors and to have that with the understanding that have that PR block shipping, that we don't ship Shadow realm. So until we can adequately surface those errors and then we can deal with the rest of the errors that are her own pace.
CP: I can commit to that.
YSV: Yeah, I'm also happy to hear that. There's some willingness to make things a little bit easier for developers and sorry earlier. I spoke poorly and I'm sorry about that. I'll be editing the notes to make the language a bit better.
KM: Sorry, I won't say but I do think this is something. We can probably consider it more strongly. I mean, I heard a lot of times, if people were like certain features couldn't ship, because they impact people's abilities to debug their webpages, that one that in specific example. I'm thinking of it for the like WH topic of, you know, proper tail calls, but things like that, bye-bye. Make sure that we do this, right? That said I don't know if this is like a few clouds, probably talk to people that work with me.
SYG: But if you want to chat with your Dev tools, folks, KM is good to hear their Insight. I think the thing I'm trying to strike is a balance in how to debug. Like I do believe the debug-ability ought to be a block or two shipping and what I'm conquering we saying is what I've heard in this discussion, that module resolution gets us most of the way there and I kind of agree with that intuition. So that's what I'm rolling with right now. Other browsers, devtools and DX folks have Different thoughts here. Let's bring it back.
KM: Yeah. Okay. I think I think that's a fine thing when I think we have to solve that no matter what. Like I think we will be able to ship without having module graph errors up for you both. I just don't know about the other parts. Like, that's the question. I have to ask them. Here.
RPR: All right. We have four minutes over. Are there any last words SYG?
SYG: I think I have what I need. Thank you. Thank you. CP and other shadowRealm, champions.
RPR: Thank you for clarifying the way of putting things.
YSV: Yeah sorry about that. I, it was, I realized after I came out of my mouth, that it was sort of accusatory and I'm really sorry about that. That wasn't intentional. I just wanted to say that if we are making something unergonomic, it should be very intentional. Sorry.
RPR: That's alright. This is an example of how we can fix things. It's good to correct things.
Presenter: Kevin Gibbons (KG)
KG: Great. So, I don't have slides for this. It's a small change. I wasn't entirely sure if I wanted to do it through the proposal process or through a needs consensus PR, but the proposal process is, I think, easier to track things. Basically, we have named capture groups in regexes. Named groups are great. There is a restriction that they must be globally unique throughout the regular expression and sometimes that's a little annoying because you are trying to match something that can be written in two different ways. So, for example, here you might be trying to match something that is either a four digit year followed by a two digit month or a two digit month followed by a four-digit year, and the natural way that you would want to write this if you don't actually care which style it is written in is /(?<year>[0-9]{4})-[0-9]{2}|[0-9]{2}-(?<year>[0-9]{4})/. And then if you just want to extract the year you want to use the "year" name in both groups. But this regular expression is illegal in the current specifications, because "year" is duplicated. So this proposal is to relax restrictions specifically so that you can use capturing group names as long as they are in different alternatives.
KG: That there's other ways than "different alternatives" that you can statically prevent things from being reused, with lookahead and so on, but those are all very complicated whereas this is a very simple rule that says if two things are in different alternatives then they definitely can't both participate, or I should say they can't both participate except in repetition groups, but repetition groups, it is already established that only the last instance of the group controls.
KG: There's some details about how back references work. But again because only one of the two groups for the given name can have participated, the proposal says that the backreference just refers to whichever of the two actually participated. Of course, if neither participated it matches the empty string, which is how it works currently.
KG: And then there's the "groups" object. The proposal is that the capturing group name on the "groups" object is again whichever actually participated in the match. There's a final open question, which I will get to if we have a little bit of time at the end, but I wanted to see how receptive the committee was to this proposal in general and potentially moving it through the stage process. So, do we have any questions or anything on the queue?
WH: Now you have a situation where capturing groups with the same name might have different numbers. That can cause a bit of strife since you’d have a many-to-one mapping between numbers and names.
KG: I agree this is true. It doesn't seem like it would actually be an issue. I mean, it's true that it allows you to determine which of the groups with a given name matched if you really want to, but otherwise, I don't know, it just doesn't seem like a problem to me. Especially given that in my experience people tend to use one or the other - like once you start naming capture groups, you are unlikely to be referring to groups by number in any case. Is that like a specific way you think that might trip people up?
WH: I haven’t thought through all the implications of this. I don't know if this introduces any new problems. I just can’t tell at this point.
KG: I do, incidentally, have spec text written. It probably needs a rebase at this point. So, if you'd like to see how it's written down in more detail, the spec text is available.
MPC: Yeah, this is just pure clarifying question except not sure how it works currently, but what so what happens if you were to try to use this regex today, do you get an early error?
KG: Yes, it's an early error.
KG: If we have nothing else, I do have a last sort of detail here. Now, this regular expression (/(?<a>x)|\k<a>/) is legal, where you have a backreference to a capturing group in a different alternative. And I wrote spec text that just made it illegal kind of by accident, just because I was already working on making that backreferences map to something. If I were making named capture groups from scratch I would definitely have made this illegal. Since it's already legal, maybe we should leave it as such. There's not really much benefit to making it illegal. So I'm kind of neutral on making this illegal. With this proposal it will kind of stop being legal by accident and it will be legal on purpose. There will have to be spec text that handles this explicitly, which is fine if we want to say this should stay legal because we're worried about breaking changes and it's not worth risking it. But I did want to point that out as a sort of edge case.
KG: And I see we have things on the queue - plus one for any stage advancement. Thanks. I will be getting to that momentarily.
JHD: Yeah, this thing you're discussing seems like an omission from the named capture groups proposal and assuming it's web compatible it seems like something we might want to do, so could we just make it a separate needs consensus PR?
KG: Yeah, that doesn't need to be paired with this proposal. It sort of was related to the proposal because of how the spec text worked, but you're right, semantically it doesn't need to be related. WH says [on the queue] they're incompatible. Can you say more?
WH: I don't want to diverge between numbers and names. Backreferences to numbers allow references to another alternative; names should do as well, especially since you're trying to relax names so that you can define a name in multiple alternatives.
KG: Yeah, the point about numbers is well taken. So I will close this out as yes, you can. And it just unconditionally matches the empty string. Just like if you have a number-style back reference across alternatives.
KG: Okay. With that done, I think the semantics are all fairly straightforward. I'd prefer to go through the staging process rather than a needs-consensus PR for this just because it's easier to keep track of things. I do have spec text, but I haven't asked for reviews and so on. So I guess I would like to ask if I can go to Stage 2 with potentially a very quick stage 3 at the following meeting after it’s had time to be reviewed. I realize that this is the first time I am presenting it and I'm already asking for stage 2, but given the relative lack of possible design points in the proposal I thought it was warranted. Does anyone have objections or support of this?
WH: I’m fine with advancing to stage 1. I wasn't expecting this to go to Stage 2.
KG: Okay, that's fine by me. Okay, so can we say stage 1?
RPR: You've got two people in the queue comfortable with Stage 2. But if you're happy just for stage 1, then that seems safe.
KG: yes - fine by me, especially if WH wants to - actually, can we say stage one? And then if WH says on the Matrix chat that the spec text is okay for stage 2. Then we can call it stage 2 at that point without revisiting in plenary..
WH: Sure, that's okay. Just to double-check: Only the portion about using the same name in different alternatives will remain?
KG: Yes. I will remove this part which is currently in the spec text. I will remove it after this. And then I would also like to ask for reviewers for stage 3. Hopefully at the July meeting. Would anyone like to volunteer?
(WH to review)
KG: Personally, I am comfortable with just having the one review, given the relative simplicity of the proposal, but if we'd like to have another, that's fine, of course.
RGN: I'm willing.
KG: All right, RGN and WH to review, great. It''s stage one, potentially stage two pending review from WH. Is there anyone else who'd like to wait for a chance to review at this meeting?
RPR: All right, then what we have here is conditional stage 2, just waiting on WH to confirm that tomorrow, and it will become stage one if what WH does not confirm.
KG: Yes.
RPR: All right then. Thank you, KG.
- Stage 1, or 2 pending WH spec review
Presenter: Kristen Hewell Garrett (KHG)
KHG: Okay, it's okay. Sharing my screen. And so yeah, so today we just have a kind of normative update that were considering for the proposal that I wanted to bring to the committee. It was suggested RBN after the proposal, made it into stage three and basically it would change the way that initializers currently work to a little bit more flexible by allowing. users to specify when they're initializer should run from any decorator. So today, when you add an additional initializer, using the app at initializer method on the context of a decorator, that adds the initializer function to one of three possible stages of initialization, if it's an instance field or method then that initializer runs. The beginning of class, instance, initialization. So when a new instance is created, if it is static it runs. Prior to class static class field assignment. So, when the class itself is initialized and if it's a class decorator that it runs after the class has been fully initialized. So all static Fields have been assigned. This code example, kind of shows the different areas where these run essentially. So for instance. Initializers, they run before, the first class field is assigned. This is literally very close to how we transpile it actually in the Babel plugin. For instance or static fields and static initializers. They run prior to the first static bill being signed, and then for class initializes, they run right after the class is defined. so, the proposal would change it so that you could specify the three placements as the first option to add an initializer. You would be required to specify one of the displacements actually. And that would allow it to be placed, you know, in one of those three locations the main two reasons to do this. The first one is that it provides more flexibility overall. There are a number of use cases where you have for instance, and instance method or field that wants to provide do some setup on the class itself wants to initialize the class in some way. An example of this is like props on web components or event listeners on web components as well. So that flexibility to be able to have like an instance and an instance elements be able to add an initialization for the class as a whole would be very useful. But another motivating example motivate action, here would be that this could become a way to add metadata. So previously we broke out the metadata portion of the decorators proposal into a separate proposal and that proposal is currently at stage 2 with this change. We would be able to instance elements and static elements. They would all be able to add their metadata via initializers in the via static initializers, or class initializers. They would do this much like the same way that they currently add metadata by currently meeting like the previous, you know, stage 1 and stage, two proposals added metadata. Meaning, they would just get a reference to the class itself, static initializers and class initilisers get that and they would be able to WeakMap the metadata to the class or just a sign it as a property on the class and expose it that way. So this wouldn't mean that we would still potentially explore the metadata proposal because there would be other benefits to having a shared standard for metadata, but it would also make that proposal not as Necessary for a lot of common use cases. So we would need some of that metadata. And any of the other additional APIs, so that's that's pretty much it. Any questions?
MAH: So we are supportive of this change as it really increases the flexibility. However, I think there's still benefits to explore. a solution that empowers metadata and also multiple decorators working together as it's very ergonomic to do with just initializers. and so just to increase, the ergonomics of decorators going to make these of the Creator's. It would be great to continue exploring, In addition, an opaque context were direct that data API.
SYG: I'm kind of uneasy about this. But before I say my piece. The title of this was update, but are you proposing this as a post stage 3 change to the proposal?
KHG: Yes. I'm proposing this as a change. Yes.
SYG: Okay, so I'm kind of uneasy because part of the redesign ethos was that things that look. Declarative ought to behave declaratively and the idea was that you could syntactically kind of look at the static parts of the decorator and tell the shape changes that would be necessary. And if I understand correctly here, I can no longer tell, for example, that if there are So currently, it's my understanding that. For example, if there are no class decorators than there, no class initialization. Is that correct?
KHG: Yes, that's correct.
SYG: Okay, so did this increase flexibility means that the presence of any decorators mean that we have we now have to kind of dynamically determine if we need call these three hooking points because any decorator can we can add to these three hooking points? That makes me uneasy. It feels Contra to the original redesign, ethos that we had set out to do, Try to fix from the previous iterations. Maybe this is ok in that it's just like one of three well, understood hooking points, but so far, like the thing that's most compelling to me about this is, does this obviate the need for additional complexity by a simple, meta data and the metadata proposal? If it does not, then I am not in really in favor of this change, but if a little bit more flexibility here, a little bit more complexity here, here, lets us obviate more complexity elsewhere, then. I would be on board. But as it stands right now, I'm somewhat uneasy about this to to be accepted as a stage three change. If it were a follow-up proposal to add the flexibility. if we ship, the current behavior does it preclude. Do you have a path to get to this world?
KHG: Yes. I mean we could either add another method, you know, onto the context object or accept an additional parameter to the add initializer function in the future there that I could imagine ways to get to this world additively for sure but to address the other part of what you were saying. I see it that way as well. Essentially, you know, I think that this would personally like not - it would mean that we wouldn't really need the additional complexity of the metadata proposal. And personally, I've already let others in kind of the decorators meetings know that I would not continue to Champion that proposal just with my time constraints and everything. I feel like this would cover all of the needs that we really have but others have expressed that they would still want to explore it. So and, you know, not going to like, oh, we can't but I yeah, I'm 100% in with what you're saying there.
SYG: Then as it stands now, I think am not in favor of accepting this as a post stage 3 change, but I am in favor of a small proposal here to tack on to explore afterwards. All right. I still want more implementation experience under my belt, to be for kind of going against the original redesign, ethos of more statically analyzable.
KHG: Yeah, that's completely reasonable. A big part of the reason to bring it up now, as well was just, you know, the proposal is still fresh and I wanted to make sure that we had considered all the different possible ways to address metadata. Since that is still an ongoing concern and another proposal. So I realized also that it was kind of last minute that's going to be one of the next topics coming up but I just felt that, you know, it would, it would make sense to bring this to the committee as early as possible just to see what the thoughts were. And yeah, get some feedback.
MAH: So yeah, I just want to say really quick. I think they're complimentary, they're not. There are cases that can that can benefit from both. Yeah, that's all I got. I don't think it's one or the other. There are benefits from having both.
YSV: Yeah, I actually echo a lot of the thoughts that SYG had. I think that the main problem is that this came as a surprise and I haven't had a chance to review this or think about it at all. And so I can't accept it because I can't think on the spot, but I echo SYG’s thoughts about if this is potentially something that can more easily solve the same problem space as the metadata proposal, or it gives us another way to think about these problems. I think that this is a benefit. I also think that his suggestion of introducing this as a separate proposal as an add-on is a good idea and it will also give us some time to review. Just one comment. I think, in general, we want to avoid making such a large addition at stage 3. I think there have been a couple of cases, but probably it's best to split it out into a separate proposal if it comes late. And also, if it does happen, my working method is, and it's similar to others in the community. I gather all of the proposals on Friday and create a breakdown for my team and we review them together. So this completely got missed because it came up after the deadline. If you do something big, adding it before the deadline will make sure that it gets a review.
RPR: That's all. Thank you. I'll let go that just on the on the timing. We have the 10-day cut off in the agenda rules. Please read them on the agenda. It's totally legit for this one to be pushed back on just for the deadline alone. Thank you.
RBN: All right. One thing that I think is kind of interesting with this. Is that the current proposal for decorators, you can add a static initializer. which runs before extra initializer. Which runs before are met static fields and a class initializer extradition laser, which runs after all the static Fields have been initialized. Of those give you the ability to run Dynamic code during the static definition of the class, for instance decorators. There's the only way that you can add something that adds a instance extra initializer is to decorate a method or a field which requires introducing a method or a field if you wanted to do something at through the instance, whereas something like a class decorator, you don’t actually have to write a declaration if you want to run something that happens during just the static definition, the class. So there is an interesting value that this provides that you could have a decorator that wants to do something per instance, but doesn't necessarily need that declaration to attach to and there's currently no way to do that with the decorators proposal without this.
JHD: It be reasonable to require this string but like, throw an error if you try to add an instance initializer and you're not an instance thing and so on, so that we leave the design space open? Because if we ship now with that initializer, just taking a function argument, we would then be forced to add a string later and that may or may not be something we want. Like for me, I do think that's a second argument.
KHG: Yeah, I do think that would be possible. I also think adding the string as a second argument also wouldn't be that much worse ergonomically though. I'm open to possibilities here.
JHD: So yeah, and then that's a real exercise that we're going to add it as a second argument, then it would probably be wise to add it now as an optional second argument, and if it's not undefined it has to be the correct string. Similarly. So that people don't, you know, start passing things and we have a web compat issue.
KHG: I think that would probably be the best way to approach it because that way we don't incur a permanent issue like DX. It if we don't go this direction.
SYG: Sorry, I did not understand the second suggestion of the second argument.
JHD: My suggestion SYG was that the current API, addInitializer() takes a function. The change would be that we add an optional second argument and it can either be undefined, or it can be a string of the correct placement. And so instance for instance, static for class, and that's it - anything else would throw and that would preserve our ability to allow the other two placements in the future if we so desired.
SYG: Right.
RPR: We are a good five minutes over and it's the end of the session. KHG. Did you want to just say a few words to wrap up to say?
KHG: Yeah, absolutely. thank you everybody, for the feedback and definitely understand this was a bit late. So sorry about that again. Just wanted to make sure we got that feedback as soon as possible. So, thanks again.
RPR: Thanks to the note takers!