Remote and in person attendees:
| Name | Abbreviation | Organization | Location |
| -------------------- | -------------- | ------------------ | --------- |
| Waldemar Horwat | WH | Google | Remote |
| Bradford C. Smith | BSH | Google | Remote |
| Frank Yung-Fong Tang | FYT | Google | Remote |
| Shu-yu Guo | SYG | Google | Remote |
| Shane Carr | SFC | Google | In-person |
| Justin Ridgewell | JRL | Vercel | Remote |
| Michael Saboff | MLS | Apple | Remote |
| Kevin Gibbons | KG | F5 | Remote |
| Ross Kirsling | RKG | Sony | Remote |
| Sergey Rubanov | SRV | Invited Expert | Remote |
| Chip Morningstar | CM | Agoric | Remote |
| Mathieu Hofman | MAH | Agoric | In-person |
| Kris Kowal | KKL | Agoric | Remote |
| Richard Gibson | RGN | Agoric | Remote |
| Robin Ricard | RRD | Bloomberg | Remote |
| Daniel Ehrenberg | DE | Bloomberg | Remote |
| Ashley Claymore | ACE | Bloomberg | In-person |
| Robert Pamely | RPY | Bloomberg | In-person |
| Rob Palmer | RPR | Bloomberg | In-person |
| Philipp Dunkel | PDL | Bloomberg | In-person |
| Jason Williams | JWS | Bloomberg | In-person |
| Luca Casonato | LCA | Deno | In-person |
| Andreu Botella | ABO | Igalia | In-person |
| Nicolò Ribaudo | NRO | Igalia | In-person |
| Romulo Cintra | RCA | Igalia | In-person |
| Ujjwal Sharma | USA | Igalia | In-person |
| Linus Groh | LGH | SerenityOS | In-person |
| Yulia Startsev | YSV | Mozilla | In-person |
| Eemeli Aro | EAO | Mozilla | In-person |
| Daniel Minor | DLM | Mozilla | In-person |
| Tom Kopp | TKP | Zalari | In-person |
| Christian Ulbrich | CHU | Zalari | In-person |
| Patrick Soquet | PST | Moddable | In-person |
| Richard Gibson | RGN | Agoric | Remote |
| Caridy Patiño | CP | Salesforce | Remote |
| Philip Chimento | PFC | Igalia | Remote |
| Alex Vincent | AVT | es-membrane | Remote |
| Daniel Rosenwasser | DRR | Microsoft | Remote |
| Istvan Sebestyen | IS | Ecma | Remote |
USA: [standard housekeeping stuff]
USA: So first up we need to approve the last meetings minutes assuming that you've gone through the last meeting’s minutes. Please let us know if you object to publishing them. Otherwise, they will be posted. [no objections] Okay. that sounds like consensus to me.
USA: Next up we need to adopt the current agenda. Please let us know if you have any objections to the current agenda. [no objections] Perfect.
Presenter: Istvan Sebestyen (IS)
IS: I will be very careful in order not to go over the 15 minutes. So what happened lately? Yes, so we had the last meeting in September. and I will very quickly show the list of the documents for TC39 and the actual GA documents and then if there were any membership movements since the September meeting and then status of the TC39 meeting participation; and this TC39 standard downloads and access statistics. Tthere is one point which this time I would like to talk about a little bit in more details about the ISO/IEC JTC1 periodic review of the fast tracked TC39 standards - because it already started to come up but also next year we will have one and it is rather important for TC39 if we want to be presented with our standardization work also in the ISO/IEC JTC1. It is very important that we take some action. Then the list of the next TC39, GA and ExeCom meetings. Then I have taken out some of the results from the October 2022 Execom meeting which are relevant for us and then I have also some news related to the upcoming ECMA GA meeting.
IS: So these are the TC39 documents that were published since the September TC39 meeting and actually these are the usual documents. There were not so not so many: one of the documents were for instance the chair group’s report to the ECMA Execom….
IS: The next set of new documents are the ECMA GA documents. We have a lot of them at the moment. And the reason for that is that we are going to have the GA at the beginning of December and all the documents are already out, so that's the reason why we have so many documents. It is very important to know that automatically you don't have access to these documents, but if you are interested, and some of them are definitely interesting for TC39 members, then ask your GA Representative that either he or she gives you the documents or gets them access to. a so this is the first page of the documents. Is the second page for instance the suggested officers for the Ecma Management for 2023. So this is for instance interesting one. Then some on the ecma tc39 ongoing businesses with the GA - like the TC 39 stenography request. So that was entered by Bloomberg, what is the status of that, etc? And obviously there's also the usual presentation from the ECMA secretariat like membership, financial report to the GA, Agenda, list of the members of the not-for-profit members… I go here to the next document as you can see as I said, we have a lot of documents for the GA and I am not going to go through. What is important is for instance the voting intentions here the voting at the ecma GA is being prepared this time. We are going to have a lot of new standards in ECMA, but none from TC39, but from the other TCs.
IS: Okay. The next point here is, what kind of movements regarding TC39 membership have happened since September. There is one withdrawal, Coinbase, and then there are two downgrades to associate members and this will take in effect at the beginning of the 2023, so starting from 1st of January. We have downgrade from two ordinary members, one is Microsoft and the other one is Hitachi.
IS: Okay. now TC39 meetings participation: This is a continuous table. I started with July 1990 and now we are here the last one it was the September 2022 meeting. It was a remote only meeting because in Japan we couldn't have it because of the Japanese Visa specialties, etc. We had to decide to have a remote meeting. Now you can see that after the approval of ES 2022 and this is also normal the participation it was lower. So 44 there was zero local participants, remote participants were everybody from 20 companies. So a little bit lower than it was at the July San Francisco meeting which was already a mixed meeting. So those local participants you can see that are there were much higher. so this is still a good participation and I would not be worried at all about the lower participation we had. By the way here you can see what we had a year ago, and then you can see the October 2021 remote participation it was also 54 - so 10 less now. So these are about the meeting participation.
IS: Now regarding the ECMA standards downloads. I can already say you know that nothing has changed in terms of the tendency. So the latest status is 16th November and at this point in time we had a download of 75,000 for all Ecma standards and these are below the TC39 download statistics and I have calculated that 56% of all of the downloads are coming from TC39. So still TC39 is the absolute champion in terms of downloads statistics, and obviously the ECMA 262 is here the champion. JSON has dramatically improved over the years. So now it is second here with 11000 and and this is good and here ECMA-402 is much less and then the ECMA specifications which we have transferred also for fast track to JTC1. ECMA-414: this is rather important on the ISO side and we have to actually renew it next year within the 5 years reconfirmation procedure. So we have to be very careful that this actually gets a reconfirmation next year in ISO because that's the way how we are presenting our self to ISO. Now the next one is here the usually the html access statistics. I would say that here the last three years’ figures are which I would consider that this are true figures and not made by bots. So here the latest one at the moment is 34,000 and and 12th edition 50,000 Etc. So these are here the last three. is is is 31,000.
This is what was mentioned earlier we have the TC39 meeting schedule for 2023. So here you can just copied it from the TC39 GitHub Etc.
Just for reading at home: There is a requirement that every five years there is a periodic review of the faster extent that takes place and and this involves us. Two important standards: one is the JSON standard and then here you find the number for iso a number for the JSON and the other one which comes up next year, and this is the ECMA-414 Ecmascript suite. So we have to be very careful that the JTC1 SC22 P member national member bodies approve it. So if you have any chance to influence your National member bodies that they give a positive reconfirmation vote for both the JSON standard, which is up until next march (2023) and then we will have a similar one for the ECMA-414 and reconfirmation of that would be very very important. One point is for the Ecma-404, which is the JSON standard, which is very stable to get in ISO the “stabilized” status. Rex Jaeschke - out SC22 liaison - has pointed out this possibility and I fully agree with him and which means that it will after that it can never be changed in JTC1. ECMA-414, this is just a preparation for next year. it contains automatically all the “undated” (latest) normative references to ECMA-262 and 402. So that's the reason why this exercise is very important, unfortunately we cannot influence that JTC1 here from TC39, you have to do it within your National SC22 Body. As I see it SC22 does not have a working group dealing directly with the ECMA standards and this is a little bit dangerous in my opinion. So we have to make it sure that the fast-tracked TC39 standards get reconfirmed.
IS: now here the GA venues and dates They have not changed. The ExeCom meeting venues and dates have also not changed. and I think now I am just over my time, so please just read my remaining slides.
Presenter: Kevin Gibbons (KG)
KG: Okay. So as this says, no particularly notable editorial changes. We've been doing our usual minor tweaks and fixes, but nothing worth calling out here. And only a couple of normative changes that we've landed. Both of these were discussed - well, the first of these was discussed in previous meeting, which is a tweak to the handling of Date.now which basically requires it to use the same operation as Intl uses for getting the local time zone; previously Date.now wasn't actually required to match anything in Intl and now those share the underlying time zone getting logic so that they're required to be consistent. This was a change from the Temporal champions. And the second one wasn't something that we asked for consensus for because we have consensus that every release of Unicode is automatically pulled in, so this is just an informative update that Unicode 15 has been released and with it there a corresponding handful of changes that are automatically implied for implementations because they are required to use the latest latest version of unicode.
KG: A couple of meta changes. This first one, as you may be aware ecmarkup has a built-in formatter. It's not super aggressive, but it handles a few minor stylistic nit pics just so that documents are consistent. We had previously not been entirely consistent about whether we used HTML entities or the actual Unicode code points that they represented for stuff like the fancy brackets that we use for lists. We decided that we did want to be consistent and in particular we wanted to consistently use the actual code points instead of the HTML entities. But you don't actually have to remember that because whichever style you write, if you run the formatter it will translate the entities into the code points for you. This is kind of annoying if you have open PRs to rebase and so in the next slide, I'll talk about how you can rebase automatically. Then the second one is something we've been working towards for a long time, which is that KAIST, the Korean researchers who presented a few meetings ago, have an automatic type checker for ecma262 and it can catch a number of errors. It is now integrated into CI. It has a list of operations that it's not able to check so if your PR fails you might be able to just exempt it if you think that the type checker has a bug, but also you can just talk to the editors and we can figure out what's going on. And then here is a slide for your reference. It's also mentioned in the pull request that made the formatting change. This is how you can rebase onto a commit that has a formatter applied without needing to manually handle the git conflicts with the format of yourself. Basically you just rebase onto the commit before the formatter and then we rebase on the formatting commit and discard the upstream changes and then rerun the formatter and then continue to the rebase. And that will prevent you from needing to resolve merge conflicts manually. And then a very similar although somewhat shorter list of upcoming work now that we have the esmeta type checker integrated. I'm not going to go. through all of these again because I don't think there's anything new or especially notable here. And that's it. Thanks for your time. Any questions or anything from the queue?
WH: I'm curious about what the slide point about “making RegExp consistent with the rest of Ecma 262” is referring to. What is inconsistent that you’re trying to change here?
KG: Yeah; this refers to a couple of things. One of them is that a few of the algorithms in the RegExp section basically refer to variables that are not passed in — they're just said to be ambiently available for the current execution of RegExp matching. I think we actually changed that one and now thread all of the state through the parameters. The others are pretty minor things — RegExp matching currently uses internal data structures such as pairs or tuples. Nowhere else in the spec do we use pairs and tuples; we use records with named fields. So I'd like to replace pairs and tuples with records with named fields. There are no other large inconsistencies at this point, it's that sort of minor thing.
WH: Thank you.
Presenter: Ujjwal Sharma (USA)
USA: Hello. and welcome to the Ecma 402 status update. There is a number of normative changes that I'll quickly go over. not to take too much period of time. first up we just know we talked about a new version of Unicode this has deeper implications for Intl, specifically there's new numbering systems that have been added. so Andre made up a request based on ICU 72 and has been approved by the TG2, but it adds these new numbering systems to the spec at the moment. We're working on a long term solution to periodically do this automatically so that the lists are updated because since this is uncontroversial and needs to be done periodically anyway. But at the moment this is an individual, normative pull request.
USA: next one we have 715 this pull request is by RCA. It updates the fractional seconds digits in date-time format in preparation for Temporal. So at the moment date-time format accepts only zero till three in order to format sub second values when formatting. Temporal allows greater precision, so this PR would allow the formatter to accept values from 4 till 9 fractional digits, which is the end of the limit when it comes to Temporal. But at the moment it behaves like those additional digits were all set to zero. This is also been approved by TG2.
USA: Next we have. a PR by ABL this is canonicalizing GMT to UTC. at the moment UTC. / GMT is canonicalized to UTC in the 402 spec. After the new edition in the TZ data now one of the other possible values is GMT. So we're essentially expanding that behavior to both of them since they're semantically equivalent. This is also been approved by the TG2.
USA: next we have this pull request 729 by RGN it corrects buggy math in Gregorian calendar date-time era formatting to compute the right value here. This is fairly recent and has not yet been presented to TG2. So if we get consensus here today, this will be approved after it is approved by that group.
USA: So, that's all. I would like to ask for consensus.
FYT: Yes, I have to point out PR 715 have never reached consensus is clearly stay in the meeting notes. I have a question and it says we will discuss offline. if you look at October and November meeting and I strongly oppose this for technical reason. This is not implementable and we think we should not do this.
USA: All right. I’ll take it that you objected to this particular PR.
FYT: Yes.
USA: All right. Okay. is there anything else on the queue? [no] All right, so that's all in the queue. I take it that 715 does not have consensus within this group. So I would like to ask for consensus on the rest of the PRs: 714, 724, 729. Any objections to those?
DE: the explanations you gave all will make sense to me and I support. support consensus on these changes.
USA: Thank you, Daniel.
FYT: It’s too early to talk about 729. I haven’t had a chance to review. The first time I loaded your slide like one minute before the meeting you don't even have the thing. Nobody have chance to look at the PR. I don't feel comfortable to read consensus about this one.
DE: All right. I agree with Frank. We should probably just come back to this next meeting after TGT reviews it that's been the pattern so far, right? the 729 Yeah, the one that you said. you haven't reviewed in TG2 yet.
USA: Oh, yeah. well this would. this would be presented to TG2 to but I take it that you. don't consent to this PR being merged.
DE: I like the way that you've been giving summaries explaining why the PRs make sense? and so it'll be great if you can give that next meeting.
?: you know the ordering of it goes to TG2 TG2 and then it goes to TG1. I like that better.
>>>>> gd2md-html alert: Definition term(s) ↑↑ missing definition?
(Back to top)(Next alert)
>>>>>
USA: Okay. Okay, then I guess I would like to ask for consensus on two of the PRs 714 and 24. so 714 and seven. Oh. example 724 so these have already gone through TG2. and so asking for do we do we have any supporters for those specifically those two? I'd Daniel does your your previous support -
DE: I support those.
FYT: I support 714 and 724.
RPR: We have two two active supporters. Are there any objectors for those? No. okay, then those two PRs have consensus then. Thank you very much. I think you SFC as well on the the queue. Right. Does that conclude the 402 status update?
- Consensus on 714 and 724
- No consensus on 729 at this point
Presenter: Chip Morningstar (CM)
CM: The status of ECMA-404 remains very boring, which is exactly how we like it.
Presenter: Ujjwal Sharma (USA)
USA: Hello. the test 262 maintainers unfortunately weren't able to attend this call, but they have sent us a summary. So I'll quickly read that:
- The ESMeta team approached us about integrating their tools with test262's continuous integration. (As a reminder, ESMeta is the ECMAScript interpreter generated directly from the specification.) We had a productive discussion and identified some next steps towards running new tests with the ESMeta interpreter in CI. We also identified some difficulties around integrating the text of Stage 3 proposals into ESMeta.
- There's an RFC (our first, as a trial of the new process) about adding some facilities to test262 for improving the experience of writing asynchronous tests. We'd love to have some feedback from the perspective of implementers maintaining a test262 runner, and from (potential) test writers.
- There are now tests for several more stage 3 proposals: change Array by copy, Symbols as WeakMap keys, RegExp duplicate named capture groups.
SYG: What were you looking for feedback on from implementors? I missed it.
USA: They have defined an RFC process for test 262 for discussing improvements to the infrastructure itself. They are looking for feedback on their first RFC which is around improving test262 in order to better write async tests. So they're seeking feedback from implementers from test runners as well as from test writers.
SYG: not on the RFC process but on the RFC itself of writing async tests.
USA: Yes on that particular RFC.
SYG: Thanks.
RPR: and then Dan has a comment.
DE: I think that governance model for test262 been a bit too conservative. it looks like that RFC is for comments on a small support Library that would be used to write tests that it wouldn't take changes by test all by just getting better by implementers to use. Then I see a lot of negative comments from somebody there. there kind of. on not liking the form of that I think people who write tests should be. encouraged to commit tests and also commit support files without this kind of without this kind of gatekeeping and I worry that the RFC process and the governance discussions have led to a kind of impasse here that's not helpful.
USA: I'm not sure if I can answer that question. Maybe you can raise this to the maintenance directly in Matrix
DE: Sorry. I'll follow up with them and get up.
USA: Thank you. That's all. Right
Presenter: Firstname Lastname (FLE)
RPR: next we have JHD. with updates from the code of conduct committee. JHD are you online? Maybe not. Is there anyone? else from the code of conduct committee that would like to give an update? Okay. looks not.
RPR: I will say. related to this topic and something that istvan mentioned in his section. is that we still have the NVC funding requests. So that's non-violent communication training, and that is an active request from TC39. that has been discussed at execom. I think most recently at the well and first in well I said this this dates back about something like 2018. I think the original request came up, but it was discussed more recently this year. The current status is that we have feedback from execon that they wanted us to investigate more about the reasons and like the fundamentals of why this is needed. as well as also like reviewing the CoC as itself see it that could be improved. at the moment, I think that the chairs are looking for who can champion this. CoC side originally it was the inclusion group that were pushing this forwards the most. but I know that obviously not everyone has everyone has the time for that at the moment. So if you would like to be the champion for this and help us to kind of do it do the full due-diligence on this please say. Otherwise, I think that this request has kind of been in a stasis for quite some time now, for years, so if we don't get an active champion by February time, I think that we will probably withdraw this request. so yeah if you would like to help out with NVC funding, please contact the chair group.
RPR: Okay. that is the COC update.
Presenter: Shu-yu Guo (SYG)
SYG: So some background here on what I'm trying to accomplish. So there's this framework called Lit that depends on this property of template objects, of these array objects. It depends on them being basically not being garbage collected as long as the template site, like I guess the static Source text location can still be evaluated in the future. the way we spec this guarantee today, which I believe they are correct in interpreting the intention of the spec is to provide that guarantee, but the way we spec that guarantee today is kind of confusing and not entirely coherent in my opinion. So the way we spec that site today is this note that basically says that - this is a note under the description of the of each realm records template map. template map field the template map field is this associative array that stores all the pairs of sites and array It stores the an associative array of pairs of sites and arrays. and the intention is basically that so long as a parse node is "reachable". So there's this note that basically says once a parse node becomes unreachable the corresponding array object is also unreachable and it would be unobservable if an implementation removed the pair from the template map list. The intention here I believe is to to guarantee this stable identity thing, but also to give implementations leeway to you know, not make this map Eternal and everything and it live forever. The problem is we don't define reachability in any way and this note I think was written before WeakRefs. So, one, we don't Define anything about what "reachability" means and two, it is now totally observable to remove stuff from this list because if you have the array object in a weakref, that is observable. So that the note is just kind of not coherent.
SYG: So we should tighten this up, but I kind of want to do the thing of I guess reaffirming the intention of the spec is to preserve the identity of these template objects. And I struggle a bit with how to define this. The way we talk about. whether something can be removed or not, whether something can be cleared or not in the context of weak stuff is in terms of liveness. Liveness is entirely defined today on JavaScript language values. Parse nodes are not JavaScript language values and the initial attempt by myself here to define it was buggy as WH found in a review. So the current attempt Is this very narrow thing that basically says a parse node is considered live as a template object site. if there exists a valid feature execution where this AO is called. so basically just directly defines a parse node as live if at some point that parse node can be used as a as a template map key. And this is really just about clearing up this confusion for when we can remove entries from this template map. Then this is paired with - so that this section here for these steps. This is the section where we have this thing today where when we speced weakrefs, when you can clear weak refs, and we have this non-deterministic step that basically says that "any point in evaluation you can do this if some objects are not live". These are additional steps in that thing because as a during any event during at any point in evaluation if a template entry site key is not live as a template object site according to the definition above, which is directly just do you ever can you ever call GetTemplateObject with that parse node as a key. If it's not. live then you can clear out that entry so instead of depending on note which doesn't make too much sense today. Anyway, this PR intends to directly specify when we can remove things.
SYG: Practically what this means is that engines must keep template array objects alive until the script that contains that template site is no longer reachable. So that's like after the top level has been executed and there are no references anywhere to any closures that may refer to that site. But until then it can't clear those template sites.
SYG: Okay, so that's about it. It's kind of rambly. this concerns this corner of the spec that is not that well understood. Because it talks in terms of constraints instead of steps to perform. but yeah. Hopefully that made some sense.
DE: This formalization looks really great to me. You know, I previously made the change to template literals where you know in es6 they were keyed by strings so they were eternal. and the goal was to make it so that code would generally be collectible except in modules of course. so this change seems like a very natural way to connect that to the WeakRef formalism and I'm happy that SYG has written this out. I'm curious whether you expect. whether whether this change was motivated at all by possible changes in implementations or tests, or if it was purely. to make sure that the text was sort of all in order. you know a from that looks good to me and I support this Lending.
SYG: Thanks, DE. This was motivated by V8 realizing the current implementation was incorrectly collecting some things earlier or more frequently than the spec actually required thus breaking Lit in some rare cases of heavy memory usage and triggering GC, and then V8 engineers trying to fix it and misinterpreting that note and making matters worse. So this is some normative clarity.
DE: Should there be a note?
SYG: That's a good point. I should probably. expand this particular note on. kind of with implementation guidelines on what is the conservative thing that you can do here? I will. add some and I can see see. you for review. or any other interested folk.
DE: Okay sounds great.
MAH: So I was just thinking about this a little bit more now that I’m awake, and I'm wondering why this is actually needed. From what I remember from discussions of liveness, something can be stored in a slot, but as long as there is no execution path for the content of that slot to be observed by the JavaScript program, it doesn't matter that it's actually stored in a slot and can be collected. So I don't understand why we need to actively clear out these slots for the templates. The reason we do it for weak sets and WeakMap is well, obviously if we didn't the program would be able to get those values but there is no way to get at the template objects through those slots by any call the JavaScript program can make. So I guess my question is why is a note clarifying when the implementation is allowed to collect these based on the current definition of liveness, why is that not sufficient?
SYG: The current definition of liveness talks about JavaScript language values only which parse node is not one.
MAH: Why do we need to define when a parse node is collected? That's not something that can be observed.
SYG: I mean it can be. because it affects the template object, the template array object.
MAH: the template literal object can be observed only if there is an execution where that template object is going to be given to JavaScript program.
SYG: Yes. and this directly defines that. like right now we don't really talk abou parse nodes as things that have. some lifetime or liveness today. So - okay. it's my my strict reading of the current spec text.
MAH: If the parse node is unreachable -
SYG: but what is unreachable mean? That's just a note, right.
MAH: Yeah, if the program is never going to execute that template literal tag, the program is never going to be able to observe the Frozen array.
SYG: That's right. But if for example you're implementation implementation does something like bytecode flushing and it blows away the compiled byte code on memory pressure because it can reparse the source code that suddenly affects that implementation choice on certain interpretations of what that note means can affect. the lifetime of these template objects.
DE: So I’m on the queue next. I have to agree with MAH actually thinking about this. We definitely need to clarify things somehow in the text for implementers, but you know, the definition of liveness threads through all the spec internal constructs. It's about whether JavaScript code will be able to access that frozen array again and in the case of bytecode flushing it's pretty clear that if it gets reparsed it should be able to access that. That array again.
SYG: so why is that clear to you if it gets re-parsed ?because it talks about parse nodes not the parse nodes corresponding to a site.
DE: in some way. It would be a Fool's errand to start tracking all sorts of different spec internal constructs. because there are lots of them and we could think about liveness for lots of them. But it's a question of whether there's an execution path that can lead to what should return the same frozen array. and it clearly should cross the operation of you know, clearing out the byte code and then reparsing it. because it's the same it's the same considered the same parse node.
SYG: Where in the spec does it do you draw that conclusion, I guess like I agree. That's yeah, but that was that's exactly the confusion
DE: because when you do and eval you parse it, just once in the spec, there's no part in the spec where it says. Oh, yeah, it's fine to throw away the parse node and reparse it. Let's so it's the same person in that and then that would be the key in that, you know. Association lists that we have for the template template map. so you know by the logic of what was there before? It would be. unreachable at the point when? You know that particular result of the eval is never being used anymore. and it would still be reachable across blowing away and reparsing the cache. I mean, it's it's very obscure logic. I don't think it's the best way to express it to implementers, but I think it implies the same semantics.
SYG: I don't know if I agree right now a strict reading of the current spec as is. implies the semantics. What is the harm in doing this? Do you see a downside in doing this? Is it this slippery slope thing that there are other things that we might want to talk about liveness where we don’t want to?
DE: Yeah, I think it's an editorial decision whether we make this change or not. The note is clearly incorrect because it is observable via via WeakRefs but I think the current spec implies the same the same semantics
SYG: Okay. it's clear to you WH.
WH: I disagree with the DE’s conclusion that this change is not observable. Consider what happens if you use template objects as keys in a WeakMap — depending on what we decide here, these keys may or may not cease to be live, which means that the values of that WeakMap may or may not be garbage collected.
DE: Could you clarify what you? mean? I'm not sure if any of us are disagreeing about what the semantics actually should be.
WH: What I'm saying is that this is not a transparent change. Whether we garbage collect parse nodes or not is observable.
DE: can you walk through that a little more concretely?
WH: Yes. Let's say you build yourself a weak map with template objects as keys. And then use weak references to see if any of the bindings in the weak map ever get garbage collected. If they did then you know that a template object has gone away.
DE: I don't think we're disagreeing about whether the template objects go away or like when they should go away. but just about whether the current spec text implies the same thing. At least that's what MAH and SYG and I were talking about. can you elaborate on what you mean?
WH: Yes, and I disagree with the conclusion you made that this is just an editorial change — whether we do this change or not is not observable. I produced a counterexample to that conclusion.
DE: Hmm I don't understand yet. Sorry. SYG. I guess this was addressed you. Do you have any thoughts here?
SYG: I think we already disagree DE. I disagree with you, DE and MAH about a strict reading is the collection of parse nodes that we the intended collection of partners that we all agree on Is that covered by the strict reading of its back and I already disagree because I don't really see. that for reasons I said I already understand. I still don't really understand why why you think it is. covered by the strict reading so I'm I mean like I think this is normative which is why I put it on here.
USA: Just a reminder SYG. The queue is quite big.
SYG: It is? Okay.
MAH: Yeah. I just want to clarify there is already a note Note 5 in the liveness that says “presence of an object in internal slots or property does not imply that the object is live”.
SYG: That talks about language values. Parse nodes are not language values.
MAH: But it's an internal concept. That is not observed anywhere, and I think it's a level of indirection to the template object. To answer WH, yes, you can observe that the template objects might be collected through WeakRef or finalization registry. So, yes, we do need to remove that current note because it's not correct anymore. However I don't think we need to do anything further than clarifying when those can be collected because that parseNode is never evaluated anymore.
SYG: My understanding of your disagreement MAH and where I disagree, is that on a strict reading of the liveness section it talks about objects that can be referenced to weak refs. parseNodes are not language values and cannot be referenced to weak refs. It is very natural to read a generalization of the liveness section to cover parse notes. Which are strictly speaking is not what it says currently is my contention. therefore it's a normative change that we need to extend it to cover parse nodes in this scoped way. Does that make sense or you disagree with that characterization?
MAH: I disagree. It seems that you're saying that because it's indirect we need to do some more work. I think the level of indirection within the spec doesn't matter.
SYG: The level of indirection matters here because we can collect - we can clear this this entry in the template map. Even when the array object is alive. like you could have saved the array object object somewhere. but that site is no longer reachable. at that point the engine is free to collect that entry. even if the object is still alive. the liveness is tied to the parse node.
MAH: again that's internal. It's implementation details. That is not observable.
SYG: What? it is observable.
DE: I want to see if we could draw a - like I think MAH and I agree with you on what the semantics should be and we're just disagreeing editorially how to State it. So I think here in in plenary what we need to draw strong consensus on is what the semantics should be and then we can work out the editorial details offline about how how to merge that into the specification Is that is that a fair Yeah happy. way to go forward?
SYG: Yeah, I guess
MAH: Happy to work on this offline.
BFS: I was I think on the same vein. I was just gonna I was just gonna sort of Wonder aloud if this would if it would help anything to just clearly state that the the guarantee is supposed to be that every time a template literal a specific template literal is executed the the array the static array that is passed to the tag function must be exactly the same one as every other time. That's that's the intended behavior and maybe we could maybe it's enough to just say what that observable Behavior must be and you don't have to get too much into the details of exactly how that is made to work. Just a suggestion.
YSV: So my question is, I tried to test this behavior on Firefox with what I could understand was the STR [steps to reproduce] from the bug using the lit framework with the repeat directive and calling that multiple times under different circumstances, but I'm not 100% sure that I got the STR correctly. I'm wondering does V8 have - I didn't notice it in the bug - does V8 have a test related to this that other implementations could use to verify their behavior.
SYG: Not a reliable reproducible one because it like as far as I understand It depends on memory pressure. and the triggers for that area different from engine to engine.
YSV: Yeah. I'm wondering because the project that raised the bug to V8, they have a couple of example PRs that I wasn't quite able to get working. None of that's available right now, right?
SYG: Sorry PRs to what are available?
YSV: Um, there are a couple of diffs on the V8 that demonstrate the behavior, but I wasn't able to get those working and are those available anywhere?
SYG: Not that I'm aware of for non-V8 runtimes. \
YSV: Okay. So for now I guess the status on our side is that we haven't been able to reproduce behavior in our engine. and I'm checking with our GC folks if they think that this might also exist as a misunderstanding within Firefox because that might be interesting in terms of if other implementers misunderstood the specification here as well. \
SYG: Yeah. I think check. your life check the lifetime of the keys to this actual map.
YSV: I’ll pass that on.
BFS: I think YSV covered everything. I was just concerned. whether this is anything that is known to happen and other engines or you just happened to discover that this happened in v8 and it don't know if it happens anywhere else. Maybe I was just gonna suggest more communication to other engines might be needed than just fixing the spec. That's all.
SYG: Well, I mean I hope like right now is the communication to other engines.
JRL: Earlier you mentioned that the confusion came from bytecode flushing and trying to determine if that kept the template object alive. I'm not sure how the proposed change actually fixes that because we don't mention that a particular site maps to a parse node (or maybe we do and I'm not aware of it).
SYG: That's a good point. I mean, I don't think it's very clear currently in the state of things on. the lifetime of parse nodes at all. I suppose other folks might disagree, but I actually agree with that point.
JRL: Yeah, I think the change is fine and we could merge depending whatever editorial changes, but I don't think it solves the actual problem that V8 was having.
SYG: There were multiple problems. The example I gave with byte code flushing there was the misinterpretation of the current note caused an even implementation that that kept the template objects just in an even weaker way because they thought it could be done that way and it broke things even more so that's what that was One of the things that prompted this needs to be cleared up in some way.
USA: We have two minutes left and two items in the queue.
WH: I agree with SYG’s intent, but the formalism here is broken, specifically there are issues about what “a valid future execution” actually means. I can come up with examples where a parse node keeps itself alive, or a parse node keeps other objects alive which then keep the parse node alive. The property I would want with garbage collection is that if there are cycles of objects which keep themselves alive but you can't get to the cycle then you can collect all of them. The “valid future execution” kind of definition doesn't currently work if template objects are part of such a cycle.
SYG: I think I see where you're getting at. Um, this is why we ended up with a non-maximal set of things for the current definition of liveness. and to yeah, Okay. Yeah, but I don't quite see I think I see where you intend to cycle to be. But there seems to be resistance to having formalism here more formalism here. anyway, but I want to I guess okay, so let's clear the queue and then I want to have some. next steps.
JHX: Okay. so, could we have a note to describe the high high level? intention of the templates array objects, I mean it's it's a frozen array and from the developer. perspective I'm not sure. if they have other use case but it seems the only use case of it is to use it as a key. to cache the cache for the results of the tag function. So I think I think if we can have a note to make it a much clearer it might help as my helpful for the incrementer too. not only implementors but also developers to understand what it's for and what what the desired behavior and also are I mention this because actually I don't see many tags using this use it as you use the cache. that the for example the the Dedent proposal also We also have a topic about the dedent. cache problem and actually all the all the dedent implementations I have seen never use the cache. Maybe it's not important important in the dedent case because it do not it do not have a big performances but I really hope the spec could have a note to clear. say what what it's for.
SYG: Thank you for your thoughts. I take it there is disagreement what it is collectible designed the for. So the current the disagreement both is increments and is whether it is editorial or normative, but I guess that particular question is moved because we agree on what the semantics are supposed to be but we the disagreement with MAH and DE and myself and WH is whether it falls out from the current definition and we will work offline to resolve that and find a wording. I guess. Does that sound accurate?
WH: Yeah, I wonder if, rather than trying to make parse nodes be live or not live, there is instead a way to change the way that we access those template objects such that GC falls out of traditional object GC semantics.
SYG: Maybe. That sounds interesting if we can do that editorially I know we reached this current point of like using parse nodes as sites to get. to as a fix as DE said in the beginning around the earlier issue where we accidentally made the whole thing Eternal.
WH: I'm hand-waving a lot here, and this might not work, but suppose each parse node has an invisible unique internal symbol which is used as a key to look up the template object in an internal weak map…
SYG: Yeah, I like what that direction's going. I might kill two birds with one stone to clear up Justin's. thing earlier too on like what exactly is the lifetime of parse nodes is it you know is is reparsing allowed that kind of thing. So Okay. That's enough concrete next steps for me. Thank you everybody.
- Normative semantics have agreement (can’t collect template objects if the code which produced them might get evaluated)
- Discussion of how to specify normative semantics to continue offline
Presenter: Justin Ridgewell (JRL)
JRL: All right, so we have another webcompat issue with the array grouping proposal. and it's not just a single site. It's actually three separate sites that are apparently using arrays as hash maps with arbitrary key values. because we've added a new group property It appears that they are using that same key group and now the code is failing because they're doing a lookup, the lookup passes because it now returns a function object instead of their key value. This happened in the last pass browser extension, which is a little surprising. And two separate websites, one from IBM and one from something that I don't really know.
JRL: So we have a couple of paths forward that I can see. We can try to rename again. Something that is not generic like the name group. We have a couple of proposals called groupToObject, groupToMap which just changes group to groupToObject We could use a different tense of the word. So grouping groupingToMap or any of these others. We can continue on this path and add this to the array prototype. And reminder we can't use groupBy because that already has a problem with the library ecosystem.
JRL: Another possible path forward that I had mentioned in GitHub issues maybe a year ago was instead of defining a prototype method we define a static method on the particular objects that you want the result to turn into. So we could have Object.groupBy, we could have Map.groupBy which would return a new map. We can have WeakMap.groupBy which would return a new weak map. We could have Record.groupBy. So essentially instead of placing it on to the prototype which has all these issues for people using instances of arrays as hashmaps, we place it on the resultant object constructor, so that you get back the constructor instance that you want, sidestepping the issue entirely.
JRL: The three options that I can see is 1) we continue with group / groupTo Map and try and get these three sites to update but I have no idea if they'll actually do it or what time frame that they will actually try to do that. 2) We can rename again to something more obscure. 3) Or we could switch to the static method definitions instead.
JHX: I have a quick question. What’s the difference between Array groupBy and Tuple.groupBy.
JRL: Array group by would return an object. which which contains Array instances and Tuple groupBy would return either an object or a record that contains Tuple instances. I haven't clearly specced out what this would mean for everything. I just want to get a direction before I actually Define what all of the the semantics for the static method would be. I actually think this is a typo, we’d just have Object, Map/WeakMap, and Record static methods.
JHX: Oh. okay. Thank you. I just I have a question because it's the first class. I'm not not gathered because I suppose it should be Object.groupBy.
JRL: Yeah, I typo’d my my slides.
JHX: Thank you.
YSV: I don't think it'll be realistic for us to wait for sites to update. because in particular. it took us about five to six months to get these bug reports. A lot of people just thought Firefox is broken and I didn't act on it. This is in particular the error messages for this. and for this web compatibility issue. makes it difficult to identify that it's related to a new feature. With groupBy we immediately had, within a month or so, a web compatibility issue. I think it's too dangerous to, first of all, only think that it's these three sites that have this problem. I think the problem is much more widespread so I don't think that the current name is something we can go ahead with, especially not given the type and scale breakage that we saw on those sites.
JRL: Okay. So that would eliminate option 1. We still have either rename or static method as options then.
SYG: Yeah, plus one to YSV. After these breakages came up. I searched for them in the Chrome issue tracker and chrome Canary had the same bugs and which are reproducible. We didn't even get any bug reports. So I'm kind of worried. um that if we rename to be pretty hard to figure out the words.
RPY: Yes, so we discussed this with in Bloomberg and our feeling was the we don't really like to static methods just because of being consistency with the other grouping prototype methods. regarding the renaming I guess our preference was groupedBy was our consensus. But
JRL: we cannot use groupBy. that has library inconsistencies with sugar.js particularly, but we could use Group by two object or one of the other variations. It's just it has to unfortunately be a very very obscure name.
RPY: I think you had a suggestion of past tense “groupedBy”. That was just a slight preference.
JRL: Ohhhh. That was option 3 in this list. groupedBy and groupedByToMa.p. I don't want to waste any time with bike shedding the actual naming. I just wanted direction that we should rename instead of using a static method. We can go into GitHub issues for particular what the preferred name is and I can come back next meeting with with the rename.
RPY: yeah, I think we would prefer the rename option instead of setting methods.
JRL: If possible, can I get tcq to do the the temperature check just to see if renaming is the direction we want to go in?
USA: Just to confirm you want a temperature check on renaming?
JRL: Yah, any possible renaming. it just kind of like a smiley face or a frown face is all I really need to see if renaming is the direction we want to take.
YSV: there arguments in favor of the static methods. Do you want to hear those first?
JRL: Sure, Sorry. I didn't realize, is there something else in tcq?
EAO: If we go with static methods we end up doing the same thing that we're already doing with Object.fromEntries and Array.from, so there is consistency there that we would be matching.
RPY: I did actually yes. so I think because and object helpers don't live on the Prototype whereas array ones do I think that's a slight difference. so help us for a raise typically live on the array prototype, right like
EAO: But those prototype helper methods modify that instance, while here we're creating new instances.
SYG: I was swayed when we discussed this internally to the consistency thing for the same reason that was previously.. I'm in favor of the static methods for the same reason that was just mentioned.
YSV: I prefer static methods to groupByToMap on the prototype. I think it's actually kind of nice because then we are creating new objects of different types. So we are doing map.groupBy and then passing in an array and there's a common pattern there, similar for object. and then possibly for other types, I think there's something nice to specifying the target via the constructor, rather than putting each one explicitly on Array.prototype. So that's a nice benefit.
JRL: I guess, can we do a temperature. Check with three options and I can come back. next time with either a rename or formalize spec for the static methods?
USA: So you mean the temperature check on naming not naming whether or not we choose renaming or the static method. method. Unfortunately that's that's too wide perhaps you could limit it to something more specific, okay? Could we get a temperature check on, just the static methods,
JRL: All right? So I suppose we will do a temperature check on static methods versus instance. Okay.
[discussion of how temperature check should work]
JRL: I mean it's there's only Option 2 and 3 now. I think we’ve ruled out Option 1 to begin with. So there's only 2 and 3, another rename or static method. I think the way that we phrase this will give us the same result anyway. If you're positive on using static methods, then I would come back with a definition for static methods. if you're unconvinced by static methods I would come back next time with a rename. Or if you're indifferent then I would choose what happens, I guess. Whatever has more positive results or negative results. So the question, the temperature check question is, are we happy with a static method definition?
Strong Positive: 3
Positive: 11
Indifferent: 7
Unconvinced: 5
JRL: Because we only have a 15-minute time box, I’m going to call it here. It looks like we're mostly positive on using a static method and only a couple people who would like to see a rename.
YSV: I think also given that we aren't 100% one way or the other, it may make sense for us to give this some time to bake ith the community. So that they also can give input, and let it socialize for a period of time before going ahead with the decision,
JRL: Do you think we should go back to Stage 2 since I'm going to be vastly changing the specification?
YSV: So, stage 2 to stage 3 the advancement means that we agree with the shape of the proposal and the problem space, that is solving problems based on is valid. It's the solution shape, that is changing. I still think that this is a strong proposal so I'm not opposed to the staying in stage 3, but I can move into Stage 2 given what the stage two to three transition means is also valid.
JRL: I was so specifically if this would allow time to bake with the community. If we signal that going back to stage two, that we have to rethink the solution because the naming doesn't work out. Well, maybe that would - I don't know. I can't think very well, it’s too early. Maybe that would allow us more time to bake instead of stage 3, essentially their next meeting or the following to see if this would be implemented already in browsers. And if we could Advance the stage for I guess if we go back to stage two than just means more time that we'd have to wait before if this actually lands in browsers.
USA: You. have a queue but you're on time. I request you to be quick. if we have Daniel.
DE: I, think we should in general avoid demoting, things to stages, especially if it's something so minor as a naming issue, as long as we're clear in documenting that this isn't ready to ship until we have we allowed this time to bake as YSV said.
SYG: What do you mean by massively?
JRL: essentially this shape of the proposal is prototype methods. Changing from prototype methods to a static method, seems like a large change.
SYG: Okay.
JRL: Especially because I haven’t specced the static Methods at all. I don't know how they'll actually work or what the semantics would be. The confusion about whether this was array.groupBy or object.groupBy was because I haven't through through it fully - but I can just come back next meeting with a formalized spec, but not actually ask for advancements until we get community feedback.
SYG: Okay, I'll wait for Bradford's saying, I guess I was the massively was - like is the spirit of the behavior normatively changing? Because now the more things are in play.
YSV: Yeah, my thinking is just thinking a little bit more about the stage to think. First, we don't know yet for sure that the API is changing. We want to give it time with the community to sort of see how people react. It might be that they really push us towards a prototype method in spite of what we internally think is best there might be a large discussion there. Secondly, this came up as implementer feedback due to web compatibility concerns and if we need to test this then that needs to be done. Probably as an implementation. We probably won't be able to touch that outside of this. Unless we do, for example, a big data query. and even that it's not entirely clear of will get exactly the information that we need in order to make good decisions. So I think it's, I think what might make sense is like have a back pocket proposal which is the static methods that if we come to the Inclusion that yes, this is the corrected shape of the proposal. Then we advance that to stage three and move ahead with that rather than doing a demotion right now, okay?
JRL: Okay. that's fine to me.
JHX: Yeah, I think if we do renaming, I think there's no need to go back to stage two, But if we change to the static method, I support go back to Stage 2, because we've not only it's actually not, not only. instant methods, for example, we may have Record groupBy so yes \
BSH: Just briefly one of the in favor of static methods is if is a static method, then the argument can be any iterable, not just an array, which seems like a more generally useful structure so that might be feature creep for this proposal. I realize, but it could be with this
JRL: Because iterables could be infinite, they’re a bit different. Here you're only taking a fixed amount, the behavior will collates all keys. I would say like if you have a span of 1, 2,1,1 those all 1s get grouped into the same key. But in an iterable, if you have 1, 2, 1,1 you have 3 separate groups, [1], [2], [1, 1]. The behavior for iterator groupBy has to return itself an iterator which does not have all keys collated together, only contiguous runs collated.
BSH: Okay, thanks.
USA: All right. That concludes this topic. I would like to reaffirm that this proposal stays stays at stage 3.
JRL: Yeah. so I would like to remain at stage 3. I'm going to come back next meeting with a formalized spec for static methods and we can agree on that point if we want to approach, if we want to switch to the static method approach, we could either demote to stage two and let it bake with the community at state stage 3.
- Proposal stays at stage 3
- Tentatively going for static methods on Object/Map
Presenter: Shu-yu Guo (SYG)
SYG: OK. This is a pedantic thing that I don't think has any real world impact one way or another currently, but it'd be good to to get clarified in the spec. So RGN here filed an issue a while back currently. Atomics.wait is one of those things where we hand wave some stuff about what time actually is and the way that it does the blocking. It is a blocking call that suspends the thread of execution until it is notified. This cannot be called on the main thread because it blocks execution. And the way it does this, it can have a timeout that goes to this AO called SuspendAgent, and it just says like, wait for that time. The issue is that we don't really put any normative guidance around what exactly that ‘wait for that time’ means. Does it mean a compliant implementation must wait exactly that time? Does it mean it can wait at a coarser granularity of time? We don't say. So I think we should say something about that. Specifically, RGN brings up the point of fractional milliseconds, and you observe different things on different implementations. As he shows in this. example here. So, what should we do?
SYG: My preference here - So, the choices here, I think are: one, we say something like when the spec says wait for n milliseconds implementations can be considered compliant and wait for any finite length of time. That is greater than N milliseconds. Meaning it can coarsen. the timer resolution as much as it wants. This is basically what HTML does. So when you do a set timeout for example it says wait that amount of time and then there's another step that says then wait and implementation defined amount of time. So if for whatever reason, the host or the implementation, Besides, that needs to course and timers do to Enter security. implementation. constraints or anything. It can choose to do. So and still be considered compliant. or we can say in the JavaScript spec that compliant implementations must have some granularity. some resolution Like if we say Ms you cannot question Beyond milliseconds. Beyond whole milliseconds or something. I don't think I think that's the thing that we can say but that is I contend that it's not a thing we should say because it binds Implementations hands too much both current and future. So, That's basically it. My preference is +1 from DLM. What's the last? The question. What exactly it means and I think my preference is something like this, it basically means that if someone calls atomics that weight X for any finite X, the implementation can choose any possibly different actual point of the time and still be considered compliant. so long as the weights at least X. The. have done on the queue.
DLM: We have discussed this internally SpiderMonkey team. and we explicitly support option. One. Six. up,
MAH: Yeah, how is that? I didn't really go through this. How, how is the time observed. Is it just a simple Date look up?
SYG: In the current spec?
MAH: How would a program observe the time that was actually spent waiting? As far as I know, the only way to do that with Ecma 262 defined operations is through Date.
SYG: With 262, Yes. the host can of course, choose to inject other things, like monotonic clocks or something.
MM: I think I'm just confused. number two, what I thought I understood you to say. was that the number two suggestion, which is would be that you would imply that you can't before sin Beyond milliseconds but course but But what it would mean to course in Beyond Ms, would simply be that the wake up happened sometime later. sometime more later than you asked for. and it's already the case that the the You know that? there's there's no there's no upper bound on the time that anything in the language takes So in the absence of an upper bound on, when you can see that an atomic woke up, how can it mean anything to constrain and implementation from further coarsening?:
SYG: So, I agree but I think so that that is exactly what I seek to clear up pedantically. I think because the current language is so imprecise. It just says, like wait for n ms. One could naively read that to constrain implementations in this unrealistic way, but I agree in general with you.
MM: Okay, good.
USA: That's all. of the queue.
SYG: Cool. Thanks. All right. Sounds like we have consensus for option one. and, so, I guess that means - Is this an issue or a PR? just an issue. So then I need to write a PR and then but we have consensus and that just needs editorial review.
DE (on queue): Looks good.
SYG: All right. that's it.
- Consensus to allow any finite amount of waiting which is longer than the specified time
Presenter: Daniel Ehrenberg (DE)
- slides
DE: So this topic is about intellectual property rights patents and copyrights around the specification. So this is not a fun topic. You can go next slide. Sorry to talk about it but next slide. so, the goal is that we don't run into a situation where some people claim ownership over the specification. So, we have detailed intellectual property agreements license agreements that members sign on to and the key is to make sure that everyone who contributes to the specification has signed these agreements or is somehow under these agreements. So this needs some tracking.
DE: All patches to the specification or two proposals. that eventually land need to have people sign on to these agreements. One path is for people being a delegate. of an organization that implies that all of its delegates. sign on to these agreements This includes most companies but excludes organizations. Like open JSF. Which doesn't employ its delegates. for any invited Experts people in these exceptional organizations like open JSF or people who are not attending meetings but just submitting PRs. It's important for people to sign the contributor agreement. It's necessary. So excited. So JHD did a lot of really good work in enforcing this. he made a script in our in our CI, the checks that all the commits have. come from people who are either delegates in. JHD cleaned up the categorization of delegates or people have signed the IPR form or at least of exceptions. This is really bad that we have a list of exceptions because you know, in the limit, if we can't, you know, we can't either ascertain that everyone in that list of exceptions is covered by the IPR agreements or that they or get them to sign the form Then we should figure out how to back out those those commits.
DE: So, there's a few steps that I want to take in improving the situation. We have to eliminate the exception list. we have to apply this contributor checking back to all proposal. Repose to make sure that we don't get things in a bad state earlier. If we can't trace a paper trail, we have to unfortunately remove past contributions. I really don't expect this to happen. Last time. Ecma, lost all the IPR history. history for for contributors and I had to go around and re-signing the form. This was in like, 2016. almost everyone agreed to sign it. and so it should be good. We should probably have a license file as a defense in depth. So next slide. If anyone wants to work on this with me, there's a number of different work items and please get in touch with me offline. offline. so, as I mentioned, the first step will probably be contacting the people on the exceptions list. if anybody has any concerns with this, like, we're talking about it further in an admin and business issue. If you have any ideas for Alternatives, that would be less kind of spammy for people. great. But otherwise this is kind of my plan. Yeah. Any thoughts.
RPR: This seems really important. Thank you for following up on this.
DE: SYG. Do you express? concern in the admin and business repo? Do you have any thoughts? now that I've explained the motivation and things.
SYG: Let me page it back in. I think my concerns were, I don't want any delegate to be in the business of tracking down. exact employment dates of past employees of any company.
DE: Well if you don't want to do that, that's okay. But I think, as a committee we have to put in this effort because the past employment dates imply, whether the contribution was licensed under the IPR are agreements. so, you know there's some current googlers and some former googlers on the IPR exceptions list. So someone will have to track down whether their contributions were under the agreement. Did you have any idea how we could avoid that? that?
SYG: I do not.
DE: Okay, So what is it like is it is that is that supposed to be be public info? You know. really editors shouldn't merge Patches from people who they aren't sure. our licensing. Their things According to I, the IPR paintings. So what I was what I was vice chair, I was checking for this stuff all the time and then I expressed to other people that they should check for this stuff. Now, we generated in exceptions list over time. because it wasn't being checked for. So I want to I want to go back and fix the situation. Like someone. so one of these items here is, maybe we should make lighter weight processes for noting the status of people. but in the w3c there's all these Bots and tools that the W3C produces to enforce exactly this thing. Just because we don't have that infrastructure in place fully doesn't mean that the motivation for it doesn't apply to us.
SYG: Well, I'm confused. My concern is about I thought we were talking about past contributors trying to attribute and trying to see if IPR cover them for crew for emerging current contributions. That is not in question, right?
DE: The hole we have for current contributions around proposal repos where we're not really checking that these only come from Members or people who signed the forms. For past contributors, many patches were merged where we haven't yet traced, what the, what The agreement status is. But those are equally important, I think. you know, these are recent past contributions. They're like in the past five years
USA: One thing that I wanted to note was that was quickly scanning through the list. I found out that a number of names on the list I could recognize as node.js contributors, if you like this idea I could post on their internal GitHub Discussions list. I guess is the is the thing, but get a movement
DE: Yes it would be really great if you did encourage those people. to go and sign the form. then we can remove them from the exceptions list. Also, I believe that a number of the people on the exceptions list are employed or were employed by member organizations. And so if you can take the time to look and kind of note those people, then we can you know, including in the, in the issue. That's linked from the the Agenda item. then we can put them in the appropriate category either delegate or or Emeritus, We might want to improve processes for this. And so that's kind of a work item here listed. That would be really helpful. Arguably nobody should be responsible for this, like whose job is it? But well, we have to make sure it gets done.
SFC: It looks like I'm next on the queue. I'll just note that the Unicode Consortium we went through a fairly large revamp of all of our IP policies involving specs and especially our libraries this summer. The thing that we largely landed on was just using the Apache CLA and using the CLA assistant for all of all contributions to Unicode repositories. It's been a fairly smooth roll overall. Just speaking from, you know, some other experience working with the standards body, that's what they landed on. So I don't know if that's relevant or not but I thought I'd point that out since their topic is here.
DE: Yeah, I think it's an interesting idea. Yes, CLAs are very complicated. Yeah, if someone wants to work on instituting a CLA then let's be in touch. but I guess they don't see an exact need for one right now. Please get in touch about some parts of this topic or offline with me, like on Matrix. If you're interested in this topic, I would really appreciate your help.
Presenter: Kris Kowal (KKL)
KKL: All right. so today I wanted to give a brief update on module Harmony and it's motivating use cases. This is largely the same presentation I gave last time I spoke except transposed to emphasize the motivating use cases and then tracing them back to the layers and other proposals regarding modules. By the end of this presentation I'm hoping that you will have an a better appreciation for the coherence of all of the proposals that are involved in this and and be better prepared to understand the the four proposals touching on modules presented this week, so this is highly abbreviated and emphasizes the use cases.
KKL: so the first up is bundling. Again, I’m also emphasizing all of these use cases are already done in the wild and the proposals that we're talking about today largely improve the developer and user experience and possibly performance in some cases. So the purpose of bundling for example is a performance improvement large implemented by many large web applications that amortizes the cost of the TCP handshake and eliminates the chattiness of going back and forth between static analysis of the import graph and obtaining more dependencies. So basically everything can be sent in one shot. This has been done for years. Having a Module constructor, module Source, bindings reflection, and module expressions or a ModuleSource constructor make this easier and better. Notably module expressions, né blocks do so and also preserve CSPs so you can avoid eval.
KKL: Hot module replacement, like bundling, benefits from a lot of the same the same cross section of proposals: the purpose of a hot module replacement is to auto-reload modules as they're changing during development or during testing or automated testing. This is pervasively shimmed but requires user space equivalents of all of these layers. So one of the things that we have with ESM is support for JavaScript modules,
KKL: That's that's a good place to start. Let's go on. We can also do non-JavaScript modules as long as they're host-provided, like JSON and Wasm but this puts hosts in a position where they get to gatekeep what languages are supported, for a coherent with the language ecosystem. So what if we wanted to do non-host-defined or non-JavaScript modules and some of the examples of this would be JSON when the host doesn't provide it (which presumably won't be long for any of them), but there are holdouts. Wasm when it's not host defined. and then the biggest win of having a solution for non host defined non-JavaScript modules also provides us an opportunity to solve the assets and modules in the ecosystem and without adding other things that to the language. we that we can't And then of course. anticipate today the largely and then also I specifically say scoped experiments because I think it's also important to note that these kind what what kinds of modules and are involved in a module graph can be very application-specific and need not be generalized to the host.
KKL: And yes in order to do this you need a minimal virtual module source protocol, as opposed to a maximal on. I'm striking a distinction here between what's easy and what's difficult. Easy that unlocks most use cases and difficult one that unlocks everything up to and including virtualization of JavaScript itself.
KKL: CommonJS: one of the motivating use cases for module proposals to improve the participation of CommonJS and these and module and there are a number of ways to do this and I'm expecting them to evolve in our heuristics to evolve, and in fact for those heuristics the necessarily be application specific in some cases. I do not believe that CommonJS participation in esm generalizes well enough that it will ever make it to 262. I don't wish to try.
KKL: Mocking. Don't do it. In order to unlock the ability to participate at runtime to [notes cut out for ~10 seconds] Supported by a. particular module through static analysis, which source and also. the maximal module Source protocol. We would be able to create in user code. a proxy for any module and that would allow us to do things like telemetry analysis of its methods that are exported etcetera. As the champions of the import reflection proposal have stated in the past, Wasm content security policy, support is one of the benefits that is improved by, in fact in this case I think unlocked by, both having a static import reflection syntax to obtain a module source, having a standard for what the module source is, pointing that at the existing definition of WebAssembly.Modules, and then having support for module instances from layer 0 of the compartments proposal. These collectively allow us to incorporate webassembly modules in the ESM module graph in a way that is compatible with a content security policy that disallows eval.
KKL: Inter-agent module transfer as well, as previously mentioned. You might recall from the presentation, uses module blocks, which we are now calling module expressions, are improved by having a module expression in the, having the source property, specifically on the module object revealed by module expression. Being able to instantiate those modules, and that having some host-defined mechanism for transferring the modules and their module source, allows us to amortize the cost of parsing and loading between workers. And this can be made cheek because the module source can close over immutable data that can be safely shared between threads, or agents within an aging cluster, as it were
KKL: Domain-specific languages benefit from the final layer of evaluators. I mean specifically, it's stuff like Jasmine or Jest where they inject globals into the global scope of the realm in order to allow these kinds of expressive language to be embedded within JavaScript. And the disadvantage of the approaches available to us today are that it makes these available literally, and every realm in every script in module of the realm and it's only really necessary to have these globals available in the entry point of a particular module graph. But then, worse than that, it's not possible with this current approach within the same realm to have multiple of these DSLs asynchronously running to completion. Because they need to be able to use dynamic scope in order to determine the context in which they're running. So, for example, it needs to be able to know that it's running within described which it. The only way to do that currently is through dynamic scope and that is fragile, and composes poorly If you have multiple of these running asynchronously. We can solve that by having it be possible to inject closures into a specific module or script. So this is one of the things that's in improved by adding evaluators to the language from layer, 3 of the compartments proposal, which is of course, the primitives that we had built originally for doing things like supplied in supply chain confinement, which is very much like bundling except that you provide dedicated evaluators to packages and individual to each of your third party dependencies.
KKL: And so with that, that's a course overview of what I've put together at the behest of other delegates to lay out. More clear and concise explanation of what the motivating use cases are for each of the layers. and how they, how they relate to other module proposals and I think that may have been very quick but I'm sure you all appreciate having seen the same material before. And I hope that this paves the way for the upcoming presentations today. I put a link at the end of the slides to the long boring version of this conversation. And He's, please enjoy.
KKL: That's my presentation. Thank you, Chris, at the moment. There's no one on the key. Does anyone have questions or comments? See. not. So thank you, Chris. All right. Next up.
SYG: Seems like this is just an overview. So thank you for that KKL. Unsurprisingly to KKL, I imagine, as I disagree with some of the virtualization use cases, but I'm happy to discuss in these particular proposals.
RPR: All right. nothing more in the queue. so, we shall advance.
Presenter: Richard Gibson (RGN)
RGN: So, what we are looking at is an issue that came up in the context of Temporal. Just a little bit of background for it. There are a number of properties on the prototypes of various Temporal classes such as PlainDateTime and ZonedDateTime and YearMonth that are necessary for the ISO 8601 calendar: things like year, month, monthCode, daysInYear, and so on. Temporal also defines non-ISO 8601 calendars in ECMA-402, some of which have aspects to them that lack analogs in the 8601 calendar. And in particular, some of those calendars have the concept of eras. The most familiar example to people is probably going to be the Gregorian calendar, where you might have learned about BC and AD or BCE and CE. You know, how are years counted before year one? And because such calendars are required for an ECMA-402 implementation, the current state of the Temporal proposal is that property accessors for that data are defined in 402 rather than 262. An issue was raised regarding whether or not that is acceptable. In general, ECMA-402 extensions take the form of a subgraph of properties and objects that are accessible from the Intl object, or of methods that are explicitly called out into 262 as being overridden in 402 such as toLocaleString. So, even though hosts in general are allowed this kind of arbitrary extension, it's not something that currently exists inside of our specification cluster itself. And this being unusual, an issue was raised in Temporal, it was discussed a little bit in TG2 and a decision was made to bring it to TG1 plenary, which is why I'm here today.
RGN: So, the slide itself (thank you very much SFC) has a couple of specification excerpts, one in 262 allowing hosts to extend objects in arbitrary ways and the other in 402 describing its own scope and what generally can be expected. I think at this point I'm ready to open up discussion. Hopefully everyone has enough background but if not, please put yourself on the queue and I will answer questions as appropriate. But to reiterate, the goal here is to provide an answer to the question on the following slide: is this kind of extension relationship between 262 and 402 acceptable, or should we instead constrain it and instruct Temporal to define all properties for all calendars strictly inside of 262?
DE: So, in this thread I was pretty sympathetic with the argument that JHD raised that these should be defined in 262. Could you explain again, because I didn't quite catch it, what the downside of defining the era in 262 would be?
RGN: To the extent that there is a downside, I think it would be that the property itself is not really meaningful for the only calendar that is required of a pure 262 implementation.
DE: Because you were so careful to permit 262 implementations to have multiple calendars, that might use the era. That it's hard for me to make much sense of that. It's really hard for me to see the downside of era. I'm not opposed to having certain things defined in 262 and revising over time what things are defined there, but I don't see the case here in in I think the your this discussion about about calendars and like, which extra fields might come over time, is a bit excessively elaborate and we should focus concretely on what we know today. We know that era is a thing, so let's just define it in 262 and then, if there's some other field, and we can and we can add that later.
RGN: Okay. I think what you're getting at one of what it looks like three broad outcomes of this discussion. One of which would be (1) this kind of extension in 402 we consider acceptable; another would be (2) we don't consider it acceptable, and then the third path which I think you’re supporting is (3) we don't need to decide right now if Temporal defines the specific properties in 262 and we kick this question down the road. Would that be accurate?
DE: I guess. It's (3) with some elements of (2) or maybe I'm mixing up the order. But it's kind of nice just stick with the existing trend that you described of where things are defined and most the higher order bit for me is that in this case, I'm concerned about over-engineering, the different Temporal field to finally parse them, when we have a simple kind of possibility and on the table. I'm not willing to make a blanket statement that we could never add anything like this to 402. So, or we should always add these things. So I guess I kind of rules out one and two.
RGN: Thank you.
DE: Presumably, the 402 group had some reason for wanting it to be otherwise. So be good to hear from that. Because I think, what I'm talking about is pretty, pretty simple option. next up, we have shape. Hello, I have a lot of thoughts on this topic. Let's see.
SFC: So first regarding Dan's question for the era. Eras are an internationalization concept. They're not a 262 concept. They are in scope of 402, and I don't think there's any disputing that eras are a concept that are their unique to specific calendars that are introduced in the 402 to part of the Temporal specification. And it's not just eras, I posted in the issue, some examples of for example, the Chinese calendar uses cycles here instead of eras and year, which is just an example of how eras are not a universal concept either. The only calendar that's defined in 262 is the ISO 8601 calendar, which does not have eras. Eras are introduced as an international concept there. So eras don't belong in 262. The one reason that I think that we added this topic to the agenda as a standalone topic is not to debate eras, whether eras belong in one place or the other reason, we brought this to the agenda, of the of this meeting of flubbed of teaching of TG1, plenary is to talk about, whether it's okay for 402 to to define these types of entries on the 262 prototype? Like is this like if we were if 402 were to define that it wants to add the era property and potentially in the future of the cycle or cycle your property too. Temporal plain date or whatever like is it allowed to do that Editorially in the specification is that something that we're OK with, like are we okay saying that if you're a pro to complain implementation, then you have to add these properties to a non 402. Intrinsic basically like that? That that's the question that were asking the committee and that's why it's like not, that's why we're talking about this separately not inside of the Temporal like presentation. This is a separate presentation to answer. The answer is either yes or no. If the answer is no then we have several options to move forward. If the answer is yes then we also have options to move forward. So yeah I'll let the queue move forward.
MM: So SFC thanks for focusing on what the question is. My answer to that question is a strong no, that extensions and especially extensions like 402 are not like hosts. They are like libraries. It is now universally considered bad practice for libraries to Monkey patch language primordials: if I was preparing to argue about what what ways to cope given that my answer is no for which some of them were discussed, but that your statement that if the answer is no, there are things we can do of the answer is, yes, there are things we can do. I think is adequate sounds like there's no crisis here, if the committee's answer is no. So I'm taking a strong no position. The primordials defined by 262 should only have properties defined by 262, and the exemption for host is a legacy ugly thing that we should actually try to weaken over time. And ideally should not should never have been there.
MF: Hello. I think this is kind of a two-part question. First, it's a question of fact whether this is permitted today, which I believe the answer is that it is. There's a section on what hosts can do and we can apply that to extending specifications. The second part of the question is, what do we want? But just to answer the first part, which I think is what we are looking for today for the resolution of this topic: anything that's not written in that restricted section is permitted. So any specification including 402 can update built-ins, can add properties of globals, and do anything else.
MM: so I want to be a reply to Michael. the exemption in the spec specifically for hosts. extensions are not house. So I dispute the, the idea that the current spec allows us,
MF: If it was a restriction it would be in the restrictions section.
MM: I don't. Understand.
MF: I can get you the section number. I don't remember the number. I think it is 19. That has restrictions on extensions. What exemption are you referring to?
MM: The idea that hosts can add properties to promote to the intrinsic objects defined by 262? I mean, do you have any text from expected? the first time? I thought it was quoted in RGN's presentation.
RGN: I excerpted from the conformance section of 262, which off the top of my head I don’t think includes extension restrictions.
MM: I was remembering the host with this says implementation extensions are not. I think this text dates from when we didn't have clear, clear distinction, between implementations and hosts.
MF: The section I was referring to, by the way, is 17.1 for restricting extensions. Which does talk about implementations at the moment. But I'm taking it to also apply to extending specifications. Even if I wasn't though, this is a section that is adding restrictions not permitting extension. That's just implicit.
MM: So whether the 262 spec itself currently allows this in some sense, we're the ones defining 402, so we can decide to disallow for ourselves things that 262 would allow us to do. Whatever that seems like a fairly weird hair to split. But if we believe, as I certainly do, that it would be a bad idea for 402 to engage in this practice. Then we can disallow ourselves from engaging in the practice.
WH: I see this kind of thing as just factoring the spec into parts which are internationalization-related and parts which form the core of the language, and sometimes those parts interact in a way where it is useful for Ecma 402 to be able to stick properties onto objects defined in Ecma 262. I see nothing wrong with that. It's just another abstraction mechanism, and we can coordinate in the committee to make sure that our two TGs are not working against each other. So I see nothing wrong with allowing this.
DE: Yeah, I guess I want to agree, sort of, ad MF was saying that the important thing isn't what we can or can't do, but we want to do. In a lot of ways I just sort of disagree with the way that ES6 was was specified in terms of what host and implementations can do, with some ideas that implicitly you could extend the syntax and everyone would kind of have to do that for certain cases. I think we move more towards a model of a complete description of where you have an embedding API. That's the whole state, and I'm happy with that Evolution path. even within that we can still decide how much we expose embedding API. We want to encourage adding to existing APIs, like in web APIs where IDL permits ways of adding to existing APIs, but this is mostly used to add to globals or maybe sometimes to add to specific other things. So yeah we could decide what kind of balance we want. in multiple ways.
PDL: Hello. just to clarify my understanding, because I think this there's a misleading thing here about implementations versus hosts vs. Whatever. Because to my mind and extension is not an extension of a host or an extension of its implementation, within extension of a specification. So, if an implementation decides to implement 262, that's great, and if it also implements the extension 402, for internationalization, and that's also great, but that the 402 is an extension to the specification. So the real question is: where is it written down? Is it written down in the core specification that everybody has to implement? Or is it written down in an extension that's also subject to the quote, unquote terms and conditions of this committee, right and it is part of this committee, and it is an extension to the specification. So, it's literally a question of, where do we write it down? And in that case, and that's why I'm actually contrary on a strong yes. Because I don't want a 262 specification or an implementation that intends to implement 262 to be obliged to implement a whole bunch of properties on built-in globals, because it knows it will never need because it decided not to implement 402. I'm imagining here and embedded like Moddable: why would it ever want to implement the getters, Even if they do nothing, and if they do nothing, what would they do? Return undefined probably, I don't know. Why would we want to force them to implement that by forcing it to be specified in 262 when we have a quite logical place is 402, which is also under the purview of this committee. So to me this is you know, I was even asking when we came up when or when we hit this I was even asking should we even put this onto the agenda? Because to me the answer seemed to logical or so obvious. I guess I was wrong on that one, but I'm still of the same opinion that the answer should be obvious.
SFC: So just to add a little color here, if if we say the answer is no, that means that means is that the getters need to be defined in 262 and what this means is that whenever you know, in CLDR or Unicode comes along and says, there's a new property for this new calendar… for example, someone's adding the the tibetan calendar to CLDR. That's great. But say the Tibetan calendar has a new getter on it. So then as a response to someone in CLDR Unicode, adding that calendar, the if the answer is No, then basically the what we needed to be able to accept is that like I will make a pull request against ecma 262 to add the getter? That's what that the Tibetan calendar needs, and that's the path forward. So I guess I'm sort of looking at this. more of like, you know, I want to make sure that we have a path forward for when we do need to add more getters for internationalization purposes, where do we add them? And I personally don't have a super strong opinion of whether they go, although if I had to pick I tend to agree more with PDL's argument here, that this is clearly an internationalization concern. It's just a matter of where it's written down. I think it belongs to the Internationalization part of the specification.
DE: [via tcq] Being nimble like that sounds good to me.
SYG: I think we should allow 402 to add properties to the built-ins by 262. And I say this, purely on practical, pragmatic grounds. Like, we are the same body, if there was an actual coordination problem that we were worried about that there were other extensions that there were going to be competing over the same namespace, that might do things we don't like, that kind of thing. If there were an actual problem to solve their for coordination than okay, but I think, in this case, I really don't see what advantage we have by insisting that they go through TG1 plenary.
EAO: +1 on what PDL and SYG said. It matters that we are talking about something done in ECMA-402 which is effectively governed by the same entity as ECMA-262. If it was any other spec then this sort of dependency would need to be considered in a different way.
MM: Yeah, I think people are making a category. Are retreating the some think shame a might have been maybe was PDL said explicitly. referred to 40 to, as the internationalization part of the specification. 402 is optional. A conforming implementation can omit 402. The question then are do the primordials defined by 402 different in a conforming to 262 implementation, depending on whether the implementation also implements the extension? and I would argue that the way in which users should unpack, should be able to understand that it is very much like thinking of the extension as an optional library, that may or may not be loaded. And optional libraries can monkey patch system intrinsics, but it's universally understood to be a bad idea to the point that it's no longer part of common user understanding that libraries can monkey patch the primordials. Internationalisation, because it's optional is not just like another chapter of the spec.
PDL: I completely agree with what you said except for the bit where you said, it's universally understood to be a bad idea. I agree with your statement that it is considered to be a bad idea for libraries, but this is not an optional libraries that some users will load and some users in the same environment will not load. It's an implementations choice to implement the spec including 402. So an implementation that has made the choice to either Implement 402, in which case it's not monkey patching. It's by definition from the start before any actual code starts running has everything, or if an implementation like Moddable decides to not Implement 402, that it will never happen for that environment. So, it's not like a library that a user program can decide to sometimes load and sometimes not. and if it loads it and in what order then, sometimes patched sometimes not, that's a universally bad idea, I agree. But here we talking about defining this at specification level and that means it's defined and well defined before the first byte of code actually run.
WH: Ecma 402 is not a library. It's a layer. I can give examples from other specs, for example, C++ defines floating point operations where you can have a variety of floating-point implementations, but you can overlay the IEEE floating point standard on it, which changes and restricts the behavior of C++ floating point operations. You cannot say that floating point is a library — it’s layered onto the C++ spec.
RGN: Yeah, thanks everyone for the feedback. I wanted to be explicit about the possibility of a narrow yes which is basically that we would say such extension is allowed where explicitly mentioned in 262 with a forward reference to 402. For those Temporal types that I mentioned, there could be text saying that Ecma 402 implementations are allowed to add properties to these specific intrinsics, which is similar to what we do with the toLocaleString methods on other prototypes.
RPR: Okay. Any objections to that?
WH: I have mixed feelings about that. I would prefer a stronger yes than that and I don't want to encourage other entities to exploit these extension points. So I would phrase it as: I would be perfectly happy if Ecma 262 had informative notes saying that Ecma 402 extends these classes with additional properties. That's just useful for cross-reference. What I don’t want is to phrase those as permission or encouragement for adding properties — we already have a blanket allowance for implementations adding properties, and adding more blanket allowances for 402 to implement some properties doesn't make much sense.
RGN: To be clear, I think we're in alignment that we as a committee can decide that we don't want to do this without such references and such commentary inside of 262. If you just went in front of notes saying that there are extra properties for implementations which implement 402, fine, that's great. Useful.
RPR: Okay then we're one minute over it sounds then in addition we have Mark saying that he tends to believe he likes this narrow yes. So I think we seem to have something that we're close to agreement on I think if anyone has any problems with this please speak to RGN. afterwards. RGN, are you happy with that conclusion?
RGN: Very much.
Remaining TCQ items:
- (HAX) It's possible an impl only support some calendars.
- Consensus for the "narrow yes" solution.
Presenter: Shane F. Carr (SFC)
SFC: I'm not going to give a full detailed overview of the proposal. I'm just going to give an update on the parts that have changed. So, since the last proposal we have, made the following change to the roofing, you numb to the use grouping option, based on feedback from Kevin Gibbons, among others. We converged on special casing, the strings, true and false, and then throwing an exception on anything that is not one of these explicit choices that's shown here in the table. That PR landed, and that's one change that has been made.
SFC: Another change, it's a little hard to read on the projector screen here in the room, but we made some changes with the rounding increment. The rounding increments requires minimum and maximum fraction digits be the same. And if they're not the same, you get an exception, and they are set to the same by default. So those PRs have landed in addition.
SFC: Thanks to the review from from KG. It's strings as decimals also landed which is great. and the PR there is merged. So there's a few other open normative PRs and want to talk about today.
SFC: The first, and maybe the most that could possibly raise feedback, which if you have feedback on this, I would like to hear it, is to limit the range of intl mathematical values, so you know, again at stage three were mainly concerned about implementer feedback, so this is implementer feedback. We've had a lot of challenges implementing intl mathematical value, and one way to make intl mathematical values easier to implement is to to limit the range of intl mathematical values, but it's like, well, isn't the whole point of imtl mathematical value to allow us to form at higher precision numbers? And the answer is, of course it is, but the use case here is to be able to format very large amounts of currency. So one example of a very large amount of currency that we need to be able to support, is this this value here is on the bottom of the slide is the total value of Bitcoin in circulation. It's one point to quadrillion, followed by a whole bunch of digits. We need to be able to support formatting this number. There's 20 significant digits there. So if we were to put a limit of 30, or 48, 64, 100, that's more than sufficient to cover the use case that motivated this intl mathematical value feature. In addition to that the the string exponents, the exponent of the intl mathematical value, could also we also want to limit that as well, and this make it more efficient because Implement and intl mathematical value, because then we can actually serialize it into a certain type instead of carrying around a reference, to a potentially very large string representation of it. So if you have feedback, if this approach is not something that you're happy with, please raise on the pull request. It is open right now and I'm seeking committee consensus on moving forward with the pull request
SFC: A set that as normative change to the the proposal, is to set the shared Source in the approximately format. This is a very small bug. It's a bug that Andre (Anba?) found will implementing this in Firefox. We have a pull request up now to make this change as well. I think this one's probably not too controversial, but it's a normative change fixing a spec bug but I consider a spec bug.
SFC: There's also two issues that don't yet have pull requests. but which will have pull requests very soon. One is that resolve plural range needs to needs to account for approximately formatted ranges meaning that the plural rules Constructor needs to be able to properly handle options that are passed into it that are newly added in number formats and it also needs to be able to handle some locale data that doesn't actually render an approximately sign because of CLDR issues there. So, it's a normative change but it's sort of a very Locale data-specific change. Hopefully not too controversial, this is the other part of that intl rules is needs to be updated a bit too, to respect the options passed into total number format.
SFC: So Hopefully, those are not. I consider the expect bugs because, you know, there are things that like implementers found when implementing the proposal and they're clearly things that we're intended to be one way. But then, we're that way when we presented for stage 3.
SFC: So, yeah, I'd like to open up the floor to questions after what I just shown showed is all merged and updated with tests and stuff. I plan to requests stage 4. I plan to request stage 4 hopefully maybe as soon as January for this proposal as described.
SYG: Maybe this is more of a question for FYT. So, during the review of this, the arbitrary precision thing requiring arbitrary precision was problematic because there was this range ordering that required the two ends of the range before ordered with a comparison. But I think you SFC found some compelling examples in the real world like the parking scientist, up that was in fact out of order. So did we remove the ordering?
SFC: Yes. a good question. The removal of the ordering was already presented in the last update, I believe so, there's no longer a requirements to do a comparison on the arbitrary precision strings. This this change about interprets was recited that here it is. This is in addition to that the this is a separate change, that's motivated by the ability to use IC4X as a polyfill and implementation, as which is largely driven by, you know, some of the findings that FYT made during his V8 implementation, we don't necessarily want to have to redo that again when we have to implement again. So by having these limits, this was one of the things that FYT had suggested as well. If we did have these limits, it would be a lot more easy to implement so I'm proposing that we add these now.
SYG: I see. Okay, that's that sounds good to me. I just want to make sure what the motivation was.
- Consensus for the presented PRs
Presenter: Shane F. Carr (SFC)
SFC: Okay. So in intl-related proposal. What's the problem? So, the problem that we're trying to solve is this. What I showed here on the screen, this is code, I'd ran this code in Chrome and Firefox and other browsers do the same thing. I can put into completely different dates and I get the same output. Oh my goodness, there's something broken here. What's broken? What's broken? Is that the date on the top is, you know, is A positive date and the one on the bottom is a negative date. So it's like 2021 years before Year One in the Gregorian calendar, this is in the Gregorian calendar output. Yet ecma 402 does not currently permit implementations to add that. The bottom one is actually BC or BCE. So the eraDisplay fixes that. So how does it fix it? It adds a new option to Intl.DateTImeFormat. with three choices. First, we have always to always show the era, in this case, being DC or AD. we have never, which is always hide the era. I don't know why you'd want to do that before. But perhaps, if there's enough context Elsewhere on the page, you might want to hide the era. And then the third one is auto, which is to show the era if and only if it is different from the reference era - the reference era being defined in the specification as the era of the current dates. Temporal that now or whatever. So, that's the environment reference era. So currently of course, you know, you just saw that the default is basically never, because we don't show the era. So the change with this proposal is to have the default behavior be auto. So it's a change to the current behavior as well. In addition to giving an option that you can fiddle around with and change to your pleasing. So what makes this proposal interesting?
SFC: It seems like a fairly obvious proposal but it's a little bit interesting because it has runtime pattern selection. So to do run what I mean by runtime pattern selection is that since all date-time format needs to be able to choose based on the input date which pattern to use to do the internationalisation of the date. In this case, is there an era field or not? And the error could, you know show up before and after these localized patterns. And unlike things like our cycle, we actually have to be able to choose the pattern at runtime, like, we can't choose it in the constructor, using the format method. There's some precedents for doing this. DateFormatRange, which this committee approved for stage for a couple of years ago now, is the first proposal that did this where it actually the way that we implemented it was that in sold a time format gains an additional internal slots one for the like default pattern and then add additional internal slot for the extra pattern for range formatting. Temporal is is doing this again to supports formatting of the different Temporal types, like PlainDate and PlainDateTIme and ZonedDateTime those are all getting their own internal slot. So our fault, we're following the same pattern set forth in those in those examples by adding an additional internal slot. So here's what the suspect looks like a little bit, the stuff toward the bottom is a added. So we add a new pattern era field that contains the era-specific pattern. And then this is the code for how we selected at runtime. The spec text for how we selected at runtime shown here.
SFC: So, the status of the proposal. So the stage 2 entry requirements. Are you have to satisfy all this stage one requirements, which is checked because it's already at stage one. We have to have initial spec spec text, which is available. You can get the link to that, but the asterisk here is that the spec text was not available at the 10-day stage advancement deadline. So if anyone is concerned and wants to review the spec text, before you know, that would be grounds text, before we go to stage, 2. to say we should hold this for January but you know, it's also just going to stage two, not stage 3. So, you know, stage 2 signifies that, you know, the committee is happy with this with, with the shape of the solution and wants to move forward with it. You know, and the actual detailed full review, the spec text will happen, you know, subsequently. The third bullet point of these last three bullet points are stage 2 entry requirements for ecmascript proposal. Specifically the third is prior art. Meaning, we've discussed this proposal several times in the TG2 calls. and the TG2 folks are happy with the direction of the proposal. It is expensive implementing in user land, because the user land solution is very tricky to write correctly and it has broad appeal on the grounds of, you know, benefiting a multilingual web, especially for calendar systems that, you know, use eras much more frequently than the Gregorian calendars, for example the japanese calendar benefits greatly from this proposal.
SFC: So yes, I'm asking now for, I'd like to ask for TG1 consensus on moving forward with this proposal at stage 2.
RPR: There is no one on the queue. No one's asking me any questions today. I like when people ask me questions, obviously, as we do at any stage of constant, which were also asking, anyone in support, support. We? have a plus one from USA. Thank you.
SFC: I also want to ask for stage three reviewers stage, three reviewers you know? I think maybe this proposal can go for stage 3 in a couple meetings from now. So I'm also looking for maybe stage three reviewers if you're interested. In. learning more about 204and the Ecma ecma 402, you can be a stage three. Reviewer would be nice to get a couple people to vocally. sign up for that. Luke. now, objections.
RPR: So I think we can we can say that this has stage two. and then, Joe question of stage three reviewers did anyone anyone put their hand up? Oh, here we go. EAO has said, they can review.
- Advancement to stage 2
- Stage 3 Reviewers:
- EAO
- DLM
Presenter: Shu-yu Guo (SYG)
SYG: So table of contents for this agenda item is there are a few bugs that I want to quickly go through. That are bugs, so they are normative to get consensus on those bug fixes and then a design question about the transfer method, I like to spend most of the 30-minute time slot on. So there are three bugs. that are that need to be fixed in the suspect pointed out by constellation, who is a who works for Apple JavaScriptCore to my understanding. So thank you very much to Apple folks for sussing out some remaining spec bugs here.
SYG: The first one is that in Atomic accessories there are multiple arguments in read-modify-write methods. So things like Atomis.exchange, or add which I guess we just call add subtract and stuff like that. There are multiple arguments and arguments are coerced. The coercion can call user code and the user code can resize the buffer. This was not correctly checked and this is an issue that fixes that. Correct checking and the way it fixes it and this is the issue number is 10, but the fix itself is number 110. But yeah the way it fixes it is - the mental model of how resizable buffers work as a quick recap is that there is a different type of array or a data view backed by a resizable buffer, wherever it is, it is possible that the offset and the fixed length as specified by the type of the ArrayView or the DataView can index into index into indices on the underlying buffered that have now been resized to be out of bounds. And the mental model is that, if they can index out of bounds things, it is considered like it were detached and there were a few calls in the atomics stuff that missed replacing, his detached with is integer index object, out of bounds which does both a check and also can be out of of bounced checks. So that's picks number one. Any questions on this? before? I move on to the next fix.
(queue is empty)
SYG: All right. Fix number. two. Is the screen updated to fix number to locate a fix. Number two is about DataViews. DataView as far as I can tell, when I wrote the spec, the way that the data view lengths are computed for these lengths-tracking things were just wrong. So, that is fixed this PR as well. The background here is that when you have a resized buffer, you can choose your array buffer view in this case of ???, right? DataView to be length-tracking, which means that its length is automatically, updated depending on the length of the underlying buffer, and this computation was incorrectly specified for data views. It was correct for typed arrays, but I just got to really go wrong when I wrote the spec draft, when people didn't catch it at the time. and this PR, which is number 109. basically, copies the TypedArray computation over to the abstract operations for DataViews. Any questions on that fixed before moving onto the next PR?
(queue is empty)
SYG: And the final one, which I merged already because it was super wrong, before getting consensus here, which I hope is uncontroversial. So there are two arrays in the spec that assigns values from one typedarray into another TypedArray. This is my typedarray: I got set. and, this just reads the modified copy of that TypedArray and initializes TypedArray from the library. So there is type the right that set which kind of sets the values, which splices the values of one type of array into another type of the right, and there's initialize decoration type array, which is maybe make a TypedArray and you pass another TypedArray to its constructor and ask for values of that into the new time period, both of these arrays are similar and and they were incorrect in the draft spec on, similar ways along the two bullet points. I list basically one is that if the source type through a that you're copying from is out of bounds, they should be treated like they were detached. Plus throw instead of setting the length,???. That I honestly don't remember what exactly happened here. And there is a more mechanical bug in set TypedArray the way from TypedArray where because the source type is in fact now resizable, it should not be reading as you're going to be resizable, it could be length tracking of resizable, buffer is should not be reading the array length field directly. Instead, the issue is that you calling an AO that computes the length if its length, which is what this PR fixes. Okay. I see nothing on the queue. So I hope that is also uncontroversial.
SYG: Which were direct implementation feedback from j.c. So again, thank you very much to JSC now.
DLM: So I just wanted to say let those bug fixes look very reasonable, we explicitly support them.
SYG: Of course, thank you. All. right, now into the meat of this agenda item that I want to talk about. So it was brought up recently. now that we're getting ready to ship in Chrome. trying to tidy up some loose ends. Namely: HTML integration, and how this could be used in other web specs like streams. And one of the questions that came up is how this interacts with the transfer function. The transfer method is kind of orthogonal to the rest of the proposal. the proposal at its core is about resizing buffers and allowing typed arrays to track these responsible beverage in the transfer method was something that that kind of fitted in the same space that went in and I put it in the same proposal and what it does is it gives you an API to transfer your buffers. It detaches the source buffer, and it returns you a new buffer of the same contents or basically same contents with a length that you specify and transfer. And this can be implemented as a realloc, or zero-copy. And the idea of the transfer originally as originally motivated was basically realloc when needed, or zero-copy when they could. This proposal is originally proposed and got to stage 3 with the transfer semantics currently our that when you transfer an array buffer, transport does not preserve resize ability. The original use case that I posited, was that you would have resizable buffer, and what you want to do is you would transfer it after you'd like finish your work load, that no longer needs to resize it. You will transfer it to a new length or to the final length. and that would fix it into a new fixed length of our career. In a way that the implementation can optimize as a zero cost move, and then you can free up. The virtual memory space that you allocated ahead of time for the It's come up from the HTML folks, and the streams folks that would have a more natural use of transfer is basically an API to do what you currently do with transfer and structuredCloning, and then postMessage, and they're the most natural thing is not to do these fixed semantics where transfer always produces a fixed length buffer. But you would have transfer preserve the resizability and return a new buffer with the same responsibilities as the source buffer. The reason I bring this up now is that now that we're getting ready to ship, if we ship, the current behavior as specified, that kind of closes that. That’s not future-proof if It turns out there the majority use case in the future should be to preserve resizability. So we should make this decision now before we ship transfer. And, the API design questions here are (1) how to talk transfer what kind of array buffer to return? How do we tell it to return a resizable one or how to cook Ware reports, we turn a fixed length 1 and (2) should transfer preserve and restore the behavior? that we should give up its receiver by default and if so How do you override that default behavior? One way of thinking. of is you can mirror the constructor and admin options bag that specifies the next byte length which tells you, whether the result array buffer ought to be resizable or not, but this kind of has interactions with (2) about what the default which are the building should be what the behavior be. Should it preserve the resizability? If you take the default option, meaning when the options bag is not passed to mean that it should get its value from the receiver, preserve resizability. Then there's really no way to tell it exactly that you should produce a fixed length of something. So, if this preservation semantics, is in fact, that most natural one and judging from the new use cases that come up, and kind of convinced me that most people think the preservation semantics is the most natural one. Then we can't have this behavior, which means that the current specified behavior is not future-proof. I think there are few choices moving forward. (A) is to stick with the current design of transfer, ie always return fixed-length buffers, when we extend transferring the future to produce resizable buffers as a follow-on proposal. This explicit options bag must always be passed. It does not preserve resizability. We have another option, where we make transfer preserve resizability, but this means is that we cannot transfer from your size into fixed length. and we need a new method. Perhaps, trying to follow proposal. We have another option option where there's a, you can consider transfer to have a special overload, if it's not worry, if neither. parameters, not the options back, nor the initial length one or two new lines are cast but then you consider that a special overloading and you preserve your behavior, and otherwise you produce a fixed length or resizable buffer depending on whether the options bag was present, if there's at least one parameter present. That's feels a little bit weird, I guess. But I think these are the options going forward. But before we dive into that and I want to see your folks’ opinions on this. I'm going to just preempt this saying that since transfer is barely orthogonal, what I'm proposing. is the first things you get consensus on is to split out transfer from the resizable buffers proposal and not ship it with resizable buffers, demote the transfer thing to stage 2. And depending on the result of the discussion, here, I come back at a future meeting. with a separate program proposal for just transferred to try to advance the stage 3. Does anyone have concerns about that? I know, moddable was to the first implementor to do resizable buffers.
RPR: At the moment there no one on the queue.
ABO: Yeah. so, I was wondering whether the idea was that that transfer would work the same as structuredClone, when transferring an array buffer. So if there, if we had the options to make it resizable, to set the possible sizes and so on, like is the idea to also change the HTML spec to add those options to structuredClone and postMessage?
SYG: Not exactly. I think the only sensible behavior for structuredClone serialization and deserialization is to preserve the resizable buffer and indeed that is some folks’ mental model that it should mirror structuredClone and therefore transfer should also by default preserve resizability. What structuredClone cannot do is to say, I want to serialize this array buffer but with a new length, which is part of what transfer gives you the ability to give you a new line array buffer so you can like shrink it. but you don't have to copy it in the implementation because it gives you that information. Does that make sense?
ABO: Yeah thanks.
JRL: My initial preference is that transfer preserves the resize ability. If I give you a resizable thing, you should get a resizable thing. If it comes down to the fact that people want to be able to make a resizable array buffer non resizable, then why not just provide a method that would allow you to do that. Without doing a clone or anything, it just caps the size or some other behavior. You get a new instance of your date view or something and just keeps the same array buffer. But the array buffer can no longer be resized or whatever, whatever the behavior you need here. And then we don't need to discuss transfer option bags because you call it with the thing you want to transfer and you get the thing out on the other side.
SYG: My initial thought is a modification to be where instead of fixed, includin gdetaching the source buffer and giving you back, when you fix like the rig up for it, kind of fixes it in place.
JRL: Yeah.
SYG: Okay. that I haven't thought through the ramifications of that but that is definitely a point in the design space. And I think points to more to yes, we should demote this to stage 2 to explore it. but yes, I've kind of overwhelmingly done this small sample of that most people's intuitions are opposite of intuition, which is At that, the transfer. the transfer should preserve your resizability. So something like being transfer, always produces the like aside from the fixing the use case, ignoring the fix use case the transfer use carries it. Is there anyone in the room who has an opinion that it should not preserve resizable?
(silence)
RPR: No one seems to be. objective. okay, I think Matthew has one item on the queue. Yeah.
MAH: I've been thinking that there's a lot of performance issues with array buffers and handling them and it feels like a lot of those performance issues would be solved if implementations had a copy on write mechanism for array buffers. And in this case, you wouldn't need a transfer(). I mean, if you could build a new buffer from another array buffer and internally the implementation did copy-on-write, so internally you would never do a copy unless needed. I haven't really thought this through, but I'm curious if adding a transfer method is really an explicit API to paper over limitations of implementations.
SYG: detach semantics is is part of the desire here as well.
MAH: I think the detach semantics are valid, and if you want to explicitly neuter an Array buffer, that is valid, but that's different than a transfer. Currently neutering is a side effect of transfer.
SYG: So, are you proposing some copy-on-write trick? Plus a separate method for just detaching instead of the tricks instead of like this 2-in-1 method currently?
MAH: I think copy-on-write would be incredibly valuable for the whole ecosystem using ArrayBuffers, and I'm sad that no implementation seems to have it. And yes, an explicit .detach for the use cases of specifically neutering an array buffer.
SYG: I can't speak now to why nobody has implemented copy on write. That seems like a different use case then the transfer here, and it's strictly strictly an implementation optimization anyway. So, in effect, you're wondering would we be served for this use case that we just had .detach() that detaches something in place.
MAH: Right the semantics of transfer would be to create a new array buffer that has the shape that you want (resizable or not) from an existing one, and then detach the original one.
SYG: Yeah, that's another point in this design space that we can explore. I imagine though copy-on-write stuff is much more invasive to implement than in something like a transfer, and it's just independently desirable to do it. Like, V8 has copy-on-write optimizations for JS arrays. There are two ways to implement copy-on-write stuff: you can depend on OS tricks, maybe you can do that on all platforms that we care about but that doesn't seem true for all implementations. The other way to do with copy-on-write is manually do copy-on-write where you swapped out the backing store when you detect a write right? That Manual kind of smart, it is at odds with a lot of the security requirements. for the implementation of both over re buckers, where you want some guarantees that once you allocate the array buffer, the data pointer underlying data pointer does not move so that if there were independent bugs in the Jets. For example, that try to Hoist the data point out that when you do that, you could do that for a copy on write and you get a plug there that it is not a security bug think so, so, Like that. My first blush is copy-on-write for array buffers sound scary, and might introduce more security overhead than is acceptable.
LCA:I wanted to explicitly support copy-on-write. I think there's a lot of the use case for this transfer method would be solved by copy-on-write array buffers, although I do acknowledge the security implications that you bring up. It would probably be very difficult to provide but we've thought about this a lot copy-on-right away. There's a lot of optimization potential that we see if we were to have. something along those lines. That did not explicitly.
PST: So excess implemented resizable or you prefer for a while and we are really using them and it would be nice if transfer would preserve his eyes ability. I think that's what I mean, the feeling I have from the people using it with, with access So I think that should be the before and then any Oxygen back to change that. I mean is welcome, but not Uh, sorry.
SYG: Thanks Patrick. okay, I think That is all presented. To recap then for the conclusion: one is consensus on the bug. Fix PRs, I will get those merge soon and to is to split out transfer from resizable buffers. So recycle buffers, that's a whole remain stage 3 and chrome and is likely to ship soon, transfer is split out into a separate proposal and is demoted to stage 2. Now that new use cases have come up to explore the design space some more again in light of the concrete, use cases from HTML and streams weather. it sounds like the closest thing we have so far, too people would support transfer that preserves resizability. Whether transfers needed at all, it's an interesting question that we need to explore as well. We'll try to get something called, try to think some more about the implementation complexity implications of copy-on-write. In general I'm weary to like And too much. Performance for copy-on-write and regular behavior are going to be significantly different. And because I think I'll be worried to actually specify that in the specification. I'm still pretty much in favor of something like transfer instead of ending up. with in a place where folks have to sniff out whether the patient does and an and an optimization. all right now, and I invite the folks to express opinions. Yeah.
MLS: So we just implemented this and we have met with the current design where it's always returning a fixed buffer. So it sounds like they maybe need to redact that. from the implementation until we decide we're going to do. and implement the new semantics.
SYG: Exactly. This is why. It's this is this is the splitting out. Thing that Trent considered transfer excised from the current proposal, and it's going to be explored in a separate report, okay?
MLS: Like you said, you're going to make this stage 2.
SYG: exactly, only transportation.
MLS: and we just did a simple copy. We didn't copy-on-write.
SYG: Okay. think we just just like, get a realloc and depends on what realloc wants to be. Okay. Yeah. okay, and I invite Matthew and other folks who expressed opinions here. I'll try to help make a after binary. Make it make a new proposal. Repose a split this up, you can collaborate there.
- Proposal split, .transfer goes to stage 2
- No objections to any normative bugs
Presenter: Eemeli Aro (EAO)
EAO: So yeah, effectively this is is what I'm looking to. do is split the existing in pulled out, messageformat stage one, proposal into two separate stage one proposals. for clarity in this context. The. meaning of a couple of terms ought to be clarified, because of course, we use the same words for many things. So what I'm saying, message here, that really means it's a message that's meant for human consumption, rather than a message going between computer systems of various descriptions. And when a resource is in this context, it's a collection of related messages which might have internal hierarchy to it as well. Now, the idea here is that separate the concerns that we have around single message formatting versus the formatting a whole resource a set of related messages at the same time and also to reflect the fact that as this foundational work is ongoing in the Unicode Consortium. Their resource work has been separated from the signal message work, and it makes sense for these two also match in this sort of structural way in what we are doing in global JavaScript. There is a difference in the advancement of language where these are, which these are so the single message, message format to specification is at the level where ICU72 includes a technical preview for the ICU4J. And there is a existing polyfill for the JavaScript implementation for the same. A message. Part of the whole a specification, but the resource is much more under development at this time. And also because these are effectively separate changes, it would be nice for these to be atomic. So, you know, we don't end up with a huge one thing when we could have one thing and then a second thing building on top of that. Now what does this actually mean? I'm now going through some slides with code. Please feel free to look at the slides. afterwards, but if this proposal of spitting is accepted, then effectively was left in the in pulled out message for my proposal is this sort of a structure where we can build a single instance of an Intl.MessageFormat around a single message, and then resolve that and then work with it at that level. The code for interacting with this API looks as you see on the screen, roughly with therefore the source this is another format to syntax. I'll show a little bit more of that later. And what sort of a message, when resolved and for method, does that look like and and really, how do you read the end quite often? How do you get a string out of that with the formatted values? And now, the proposal that I'm asking for here is that this parse resource would effectively, which was or already in what was earlier presented and accepted for stage 1, as a part of one big a proposal is to have this ability of having a static method parseResource which is able to take a string representation of an entire resource of messages and to build from this was is actually a JavaScript map object that might have hierarchical levels within it ending up with MessageFormat instances within. The way that you would end up using this sort of interface, is that you have the source such as the two messages arrive and depart they're just as examples and when you pass this source to the the forest, Resource method, you would end up with a map effectively and from this, you can get the actual messages that you have in there and then resolve and format them. Now, a very valid question at this point to ask is why do we need a new format for this in the first place? And unfortunately, there are actual proper answers to this the main of the main three of them are mentioned here. One is that we really need a format that establishes a good way and a solid formal way of communicating between developers and translators, who explicitly are not developers themselves. We need something like comments and metadata that we can attach to these messages and pass them on to the translators who need that context to do their work. And actually, if you start looking at the specifications, it's interesting to note that really almost none of the existing specifications for configuration file formats, for instance, really do not define how comments and metadata attach to specific messages or nodes of or values. In any case here explicitly, we want to format where this is well defined. Secondly we want that format supports organizing messages to some level. And fairly, given that we are specifically needing to to have a format for message format to messages, which have a certain kind of a structure and a shape that is a little bit different from what strings in general or messages in existing other formats, or look like in particular that they end up often it's being multi-line. And having an interesting shape. but that's beyond the discussion.
EAO: Perhaps here we want these to be ergonomically usable within the resource format that we end up with. And and we have reviewed a number of existing formats and another effectively, they end up being too generic or too closely tied to the specific formats and frameworks that they're working with such as get text copy, fluent .ftl files, of course to some extent, we are looking to build a little bit of the same relationship for message format to because it turns out that the messages and the resources that you put them in are relatively closely connected.
EAO: So the syntax that the very much work in progress syntax for what does something like a message resource look like is presented here. It has a very toml-y structure, but the values are then message from up to Values and we're still working on this. You can see also the metadata comment there. That's a very JSDoc, JavaDoc type of the many parts of the syntax will still evolve and change. but the be asked here for this committee is not really to say, to to discuss specifics of the message Resource Center acts. It's too approve that you know, we can start with the general. I'll shape of an idea of having a parser and tools for working with this sort of a syntax for not just individual messages, but whole resources or files of messages.
EAO: And then there's a bunch of links to where this is progressing. and that's it for my presentation. And yes. I am asking for stage 1 advancement for the MessageResource proposal here.
SFC: Yeah, thank you EAO for the presentation. I definitely support having two proposals for this, for reasons we've discussed previously. I think that it's going to be a lot better to focus the main MessageFormat stage 1 proposal on message strings, and it also corresponds to the output of the MessageFormat working group. So I support at the splitting, the proposals. One question, I wanted to bring up to the group because I thought, maybe this group would have some thoughts on it. is regarding whether a TC39 is the right body to for the bundle side of the proposal. I think that's you know, like, for example, you know, one way that, you know, bundled message models have been described to me in the past is like it's sort of like a CSS format, where it's like if it's a file format. And maybe I'm maybe I'm outdated in that perception, but you know, is TC39 the right sort body? Iis ecma402 to the right place to put the definition of the of that syntax in the parser for that syntax? you know and does this fit better in some other place? like you know in the in tag or something like that? So, yeah. But yeah, I provide support the proposal so I definitely supported going to stage 1 because it gives us room to explore these questions.
KG: I'm not necessarily opposed to this going to stage 1, but I know that the sort of upstream proposal is itself only stage 1, and is not likely to advance in the near future. And I don't see much motivation to be worrying about the exact surface of what goes in what proposal right now given that all stage 1 represents is the identification of a problem which in this case is sorting out some method for handling multiple language resources. And like that is all we have committed to, by getting MessageFormat to stage 1, and this seems like - if we had advanced MessageFormat to stage 2 with a particular API in mind, then a follow-on proposal might then make sense. But we do not have anything like a commitment to an API shape for MessageFormat it right now. So I'm not sure it makes sense to be trying to add follow on proposals, at this stage. Like I said, I'm not opposed, I just think that this seems a little bit premature, given the very early stage of all of this.
EAO: So, one part why we are interested in starting to advance the MessageResource work in parallel with the single MessageFormatting part of this is to enable communication also backwards too. to the level at which we are defining the syntax for the resource, which is intended to be defined under the Unicode Consortium. So that we can be sure that it really works and does fulfill the needs of the users of which well in fold-out message format would be one of the users. So,
KG: I mean, surely the appropriate way of doing that would be at the library, not as an addition to the language.
EAO: The challenge here is that the way you end up parsing a resource like this effectively means that you need to understand the individual messages within it. And therefore gets really kind of weird and limiting on the resource format if you need to presume that you're going to be doing it with a library rather than the same implementation where you're going to be the doing the single MessageFormatting.
KG: I don't understand that. I can write a parser in user land just as well as I can write it in an engine. There's no meaningful difference between where I am doing parsing.
EAO: What I mean is that if you were able to having the same in the in the something like MessageFormat.parseResource, and the ability to directly parse the whole resource and then parse the messages within it, you can come up up with a parser that's a single pass parser through a whole resource and emits the individual messages. And we are already talking. So the the the signal message part of this is being able to take a string representation of a single message and build a formatter out of that. So if we were to require effectively a library to be doing the work of parsing a whole resource then, first of all, we need to be have each user deployed at library to a client, whether they can use it, and then double-parse the individual measure messages that we're getting out of that in pulled out, message format itself,
KG: Yeah, sorry, to be clear. I am not saying that we should never have something like this in the language. What I am saying is that when you are at the stage of experimenting with designs for the sake of getting feedback, the appropriate way of doing that is as a library, not as an actual addition to the language, because when we have added it to the language, we can't take it out. Like when you are still experimenting with things, that thing that you were experimenting with can't be something that is shipping as part of the language: once it is shipping as part of the language, it is done. There's no possibility for deciding you did it the wrong way. So when you are still experimenting, it can't be in the language and therefore has to be a library.
EAO: So, would that not be the actions at stage 1 of this proposal.
KG: I mean, you can write a library and ship it on npm whenever you want.
EAO: so, just just could you clarify whether you're objecting to recognizing that parsing and time invested resources is a separate concern than parsing and formatting individual messages, which is effectively the ask here or whether you're saying that given that we already have this stage 1 Intl.MessageFormat a proposal that we should be doing this work within that scope.
KG: Like I said, I don't necessarily object to having a separate proposal for this. I don't see a reason for it, but if you would like to split it out, go for it. The thing that I was just talking about was specifically because you mentioned something about wanting to advance resources so that you could experiment with it and I think you should experiment with it before advancing it. But that's all.
RCA: Yes, I totally support this proposal for stage 1. I think this is one of the building blocks for message format and I do support that we split and we are working on, MessageResource separately from the basic MessageFormat proposal and they both have different responsibilities. But also they deeply connect. Work on MessageResource can advance in potential in different spaces from MessageFormat, I support this.
RPR: We had at least one voice of support, maybe two. Any objections to stage1?
(silence)
RPR: Congratulations you have stage one.
EAO: Excellent, thanks.
- Stage 1 for MessageResource
Presenter: Philip Chimento (PFC)
PFC: (Slide 1) This is another update on the Temporal proposal. Happy to be presenting it again. My name is Philip Chimento. I'm from Igalia and this work is done in partnership with Bloomberg. (Slide 2) This presentation is going to be slightly different from the Temporal items that you have seen in past meetings. It'll still be a status update and I'll still have some normative changes to present, but as the implementation continues, the number of issues that have been been opened by implementers during the process of implementation has been decreasing and I'd like to take a bit of extra time in this presentation to give a progress update on what issues the champions group feels are remaining and what we expect to do about those issues. So, I'll do that part first - the tour of the remaining issues - and then open the floor to discussion, depending on how much time we have. Then I have a short section at the end with a few normative changes to present for consensus.
PFC: (Slide 3) Just the first section to take you on a tour of the remaining normative changes that we potentially make to the proposal before stage 4. (Slide 4) First of all, an update on the progress of standardizing the string format in the IETF. To recap, here, we are standardizing calendar and time zone annotation syntax in the IETF. And we agreed, when Temporal reached stage 3 to block shipping until there is a standard that we can normatively reference. The IETF working group was chartered and completed this document. It's now passed working group last call and is undergoing IESG review, which stands for Internet Engineering Steering Group, before publication. As far as I can tell this is a mostly automatic process. We don't have to do anything from our side. The IESG may ask for changes. It seems unlikely but possible. Once it has an official RFC number, changes will not be possible and that will remove the blocker from our side. So, here for this open issue, we made all the changes that we expect to make. There may unexpectedly be more, but the only thing we have to do is wait here and it seems pretty unlikely.
PFC: (Slide 5) We have an issue raised by Yusuke from JSC about the optimizability of built-in calendars and time zones. What I'm going to do for this issue, as well as the others, is just to take a quick tour of the problem. There's obviously more details that I'm not going to go into, but just to give you a sense of what the issue is that we're trying to solve and how we might solve it. The summary of this issue is that we would like to make some changes that make it easier for implementations to determine when it's okay to elide a Calendar or TimeZone object, and just use the built-in behavior. (Slide 6) I've mentioned this issue a few times before in other presentations, and I mentioned it as one of the big blockers. I don't think it's any longer in that category: we've come to a solution. It's not ready to be presented yet as a normative change, as we don't have spec text for it and we're still discussing a few edge cases, but we're pretty happy with this solution as it neatly solves a couple of other issues that people have raised as well. (Slide 7) The summary of the problem is shown in this code snippet, which I'm displaying now. You can create a Temporal object with a the name of a built-in calendar as the value for the calendar, and then when you get it back out of the object, it'll of course, be a Temporal.Calendar instance, and every time some calendar calculation is done we have to look up calendar methods on that instance and call them, which is observable. Most of the time people are just going to use a string for the calendar, and we want implementations to be able to elide those lookups. But, if you pass in a string calendar, maybe you want to polyfill calendar methods or something like that. Or if you pass in a custom calendar, then we do actually want those lookups to happen. (Slide 8) So what we are proposing to do is to have two paths depending on whether a Temporal object has a string calendar name in its [[Calendar]] internal slot or an object, which is what currently happens in the proposal. Then there won't be a getter anymore on Temporal objects exposing directly the value in the internal slot. Instead you'll either get the calendar ID string, or the string that was in the internal slot of the custom calendar that you passed, and there will be a separate API to get the calendar instance, and it won't be a property. So if you create an object with a built-in calendar and then get a calendar instance out of it, it'll create a new one each time. That means that if it's just a string in the internal slots then implementations don't have to do all the lookups; passing a string means you get the built-in behavior all the time. The same thing for Temporal.TimeZone but just everywhere replacing Calendar with TimeZone. So this is a pretty complicated issue and the solution is probably more than can fit in just four slides. There are more details in the issue thread and if you're following the slides that I attached the agenda, you can click through. These are links to the actual issues. Anyway, we hope to present spec text next time.
PFC: (Slide 9) I'll move on to the next open issue. This is more integration of time zones and calendars with Intl. TG2 is expressed the wish for Temporal to include closer integration of Temporal.TimeZone and Temporal.Calendar objects in Ecma 402. This is a fairly large amount of work to do regarding the spec text, but it's not likely to require discussions. It seems pretty mechanical - it's a work in progress.
PFC: (Slide 10) There's an issue open about extra calendar fields. This actually has a separate agenda item scheduled to discuss during this plenary. I'm not sure whether it was discussed already today or not, but to get clarity about what Ecma 402 may add to objects that are defined in Ecma 262. Once this is resolved the Temporal spec text change should be trivial.
PFC: (Slide 11) We'll move on to the next one. This one is about the domain of arithmetic in Temporal.Duration calculations. So in a previous normative change to the proposal we changed the internal slots of Temporal.Duration to hold float64-representable integers, which is a new term that we introduced for real numbers that are also numbers that can be stored without any loss of precision in a float64. We did this in response to an implementer concern about the storage size of Temporal.Duration, to make sure that it's fields such as hours, minutes, etcetera could all be represented using doubles. There are still concerns about the domain in which the arithmetic is performed with these values, should it be real number arithmetic or floating-point arithmetic? Currently it is real number arithmetic, and in the champions group we feel that this is a trade off, sort of a least worst solution that balances the various concerns that we've heard. But we are open to alternatives. (Slide 12) What we plan to do to resolve this one is to make a short explainer motivating the choices that we've currently made in this trade-off, and detailing the alternatives that we considered, and just see if anybody has an alternative proposal that seems feasible within the constraints that we have. And if not the fallback is to retain the status quo, because that's the sum of what we had getting to stage 3, and also the normative changes that we've made so far.
PFC: (Slide 13) Another issue is dealing with calendars in conversion to Temporal.PlainTime. Temporal.PlainTime is a type that doesn't have any calendar. But we do want to keep the options open to introduce one in the future, since there may be use cases that we were not aware of. This issue is pretty low in severity. PlainTimes don't have calendars because the use cases are not clear. Maybe they exist. Maybe they don't. It's also pretty small in scope, but we do have to find out how to keep the potential future introduction of PlainTime calendars web compatible without affecting the developer experience here in the present. Or alternatively, maybe a resolution to this issue is that we decide that PlainTime won't have a calendar and we're not going to introduce that in the future. So that's something that we are still discussing in the champions group and hope to have a resolution soon.
PFC: (Slide 14) Next one. There are a couple of issues open from implementers about unnecessary calls to user code. This may sound familiar because I presented normative changes that are related to this before. I think it's fair to say that implementations have turned up several cases of calling redundantly into user code. I've presented a few normative changes before to fix these case by case. I think we should probably spend some time auditing the whole proposal for unnecessary user code calls. And this audit is in progress. Hoping that in the future, we can present sort of a grab bag normative change where we've gone through and addressed unnecessary user calls all at once. And then this will be pretty much done.
PFC: (Slide 15) Another audit I want to let you know about is range-checking for the MakeDay, MakeDate and TimeFromYear operations. These operations are part of ECMA-262. They do their calculations in the floating-point domain, so they can overflow to Infinity, and there is actually already a ticket open in Ecma 262 pointing out some places where they do overflow to infinity and that's not caught. So at the least this would require an audit of call sites of these operations in the Temporal proposal text. One possible solution is to make these operations calculate in the real number domain. Another is to avoid reusing them in Temporal and use something else instead. So there's some work in progress in discussions about what we should do.
PFC: (Slide 16) So that's the end of my list of open issues that we're planning to address in the future. A very understandable question is when is it ready to ship? I'm aware that we have a separate agenda item to discuss the definition of ready to ship at this plenary, and I am not aware of whether it was discussed already or not. So I'm not current in that sense. But from what I understand from the slides, the definition that is being discussed about "ready to ship". I'd say is this, we in any case, we need the IETF to publish the RFC, and that fulfills the condition that we imposed on ourselves at stage 3 where we agreed to only ship Temporal with this string annotation format when there is something that we could normatively reference. So that needs to happen before we could declare the proposal ready to ship in any case. That's not new. Assuming that happens soon, I would say it probably makes sense to ship after landing the change to enable the optimizability of built-in calendars and time zones. And any changes that we make to the duration arithmetic domain, if we do decide to make a change there. Aside from those one or two issues, we talked about this in the champions group and we feel that all the other normative changes that I described are at the level of bug fix and unlikely to break the web if they're changed after Temporal is exposed to the web. So this is assuming that no more big issues are uncovered by implementations. (Slide 17) There are still some implementations in progress, which kind of brings me to the question about what is needed for stage 4. I would say the test262 coverage is probably sufficient if we include the tests in the staging section. Although those don't count towards stage 4 requirements. So this needs some more work, but it’s a bounded amount of work. There are a few implementations that we are aware of that are near completion. There's GraalJS, and LibJS which is the subject of another agenda item at this plenary meeting. V8 seems like it's near completion, and we know of implementations in progress in Boa, JavaScriptCore and SpiderMonkey. Then, in order to avoid the problem that we had at stage 3, where we had the impression that the reviewers and editors found the proposal too large to review each part of it with full attention. I'm wondering if at the point that we getting ready to go to Stage 4, we could stage the spec text in in sections into Ecma 262, where the editors can review each section once the previous section is agreed upon. We don't need to discuss this right now, we can discuss the process with the editors closer to the time, but it's something that we're already thinking about.
PFC: (Slide 18) This is the end of the first section before we go on to the normative PRs. I'd like to invite questions and discussions and then I think when there's 20 minutes left in the time box, I'd like to go on to the next session and run through the normative PRs.
YSV: Yeah, that sounds great. We have three topics on the queue.
RKG: I was a little surprised at your suggestion of going with the status quo with regard to number types for the data, just because sort of the way that I had understood the issue is that the status quo itself is not consistent, regardless of the solution specifically—in that, it's fine if Duration has a different type from many other constructs in Temporal when you're simply holding onto data, but because these constructs interact, it seems like "oh, I can be smart about this when I'm implementing this particular method that connects these two classes", and then all of a sudden, even if it were just a matter of temporary values, that’s not actually possible. I guess one thing that bears on my comment here is the fact that you've suggested that V8 is near completion, I would actually love to have a discussion with implementers from other engines on like what the hell they're doing here because I actually had no idea what the ideal realization is. Like it sounds really great that Duration needs a smaller type than other classes, but if every operation that Duration does requires it to convert, then I'm not sure if that's a gain. So I mean that's kind of my understanding of the status quo I guess. To the extent that the status quo would be viewed as consistent, you would store things as Number, but you would not be able to do any calculations as Number because it wouldn't be safe because you're not allowing us to deal with the boundaries of what is safe as a Number.
PFC: That is the status quo where the values are stored as float64-representable integers in the spec. So, stored in doubles in implementations I guess. And then, calculations are done in the real numbers domain, which for implementations, I guess that means big integers.
PDL: I think it's important to understand what the current solution says is is not "we're storing Floats or we're storing numbers". it's saying that any integer that is stored in the internal slot is in the scale that can be represented as a number. So what we're thinking of is that the internal slot is actually sort of you know, an integer type, but values that it can hold are only values representable as a Number for the purpose of converting to a number when read in JavaScript world, right? Behind the scenes in the actual internal slot, and what's used in the calculation is actually a in this case, I didn't expect for …
RKG: Fair enough.
PFC: I think SpiderMonkey does have this part of the implementation covered in the draft patch set. So it sounds like it might be good to facilitate a discussion. I don't know how V8 has implemented this part.
RKG: Yeah, if we want to not worry about time zones syncing we can make use of the TC39 implementers channel for instance. Or we can make use of a moment here, but I don't want to waste too much time.
YSV: Sounds like we're good to move on.
USA: I just wanted to talk a bit about the time calendars. I think it would be a mistake to disregard PlainTime calendars. In order to speed up work and not get distracted we decided to split this out of the current proposal and defer this until later. But well, first of all, what we talk about here, when we talk about time calendars, in the general calendaring spaces as time scales. So, these do exist even outside of fun examples we talked about (Mars time and stuff) - there's atomic time, there's mean solar time, GM1 and so on. So it is okay not supporting them at the moment. But I'd be against removing future the pathways we could add them in the future or add support for time scales in the future.
PFC: Okay, that's good data.
SFC: I had a question about the shipability. A big part of the unimplemented part of Temporal is the Ecma 402 bindings and there's two parts of that. One part of that is the DateTimeFormat integration, which is the the older part, like toLocaleString. And then the other part of that of course is calendar systems. So, I just wanted to get a feel for if we were to ship a 262-only version of Temporal, is that something that we would be happy shipping? You know, the 402 side of it is in the works and it's coming. I just don't know if we'd be happy as a committee or browser engines, even as implementing something that's the 262 only part of Temporal without implementing the 402 part because they're really two proposals that go together. They are separable, but do we really want to ship something that's only halfway complete as far as users are concerned?
USA: I assume SFC when you talk about the missing 402 part, you're referring to the calendars.
SFC: So I said there's two parts of the 402: the first part is DateTimeFormat, and the other part is the calendar stuff that doesn't even have a specification yet, which is kind of a problem. But the DateTimeFormat does have a very good part of the specification and that's not implemented yet.
FYT: I will say when you mentioned that V8 is near completion... I'm the only one writing the code. SYG reviewed my code and Adam (?) and I don't think that's the case. We did make a lot of progress. We have most of the functions have a ??? but I don't think I ever claimed near completion. I think there is still a lot of work to do, so please be very careful. That's a wrought-iron(?) told understand your have that issue with Duration. We are also struggling with that, so I don't think… I'm the only person from V8 around Temporal. I mean there at work. Also I don't think that's a great picture of that. Also, talking about whether it's ready to ship, I don't think this particular committee is doing any shipping yet, right? So this committee deals with Stage advancement. Shipping is something that each browser engine has to decide. So I don't understand why we need to discuss it here. We could talk about whether is this ready to go to stage 4 or not? This thinks this already I see three(?). I don't think spending time to discuss ready-to-ship here is productive. I will not recommend V8 to ship anything until the spec is stable, and then and passes ready. So I tried my more question about is that how complete is test262? Because I keep hearing that. I think PDL did a great job to move a lot of the whatever existing Temporal tests to test262. So one of the things that's blocking us to ship is one, is this spec is not stable, right? It's slowing down but not stable. The other thing is actually, how complete is test262? I have no picture? Is it 30% there, 60% there, or 90% there? I've no clue. So that's something I think will be interesting to know from PDL how, how much of your existing tests has already moved to test262?
PDL: This is to what we mean when we talk about ready to ship. FYT, this is precisely what you're talking about. So we are at stage 3, which should mean the spec is done and stable, right? And then implementers implement it. We got implementation feedback, right? And because of the size of the proposal, there are a lot of changes happening even now based on implementer feedback. And what we mean when we talk about ready-to-ship is that we say we integrated the implementer feedback that we've gotten, and there are now no more expected changes to the spec. So that so that you have exactly that assurance of "okay, you know, nothing's coming down the pipeline from that". So, when we talk about ready-to-ship, we're not. we're talking about exactly this chicken and egg problem, right? And we're not talking about, we make a decision to ship from your end? It's more like we are now no longer doing changes right? So to resolve that and test this extreme(?) is actually one of the items where we are now focusing our efforts on so that those two sides are done, and declared to be done. So that then it's up to you to go take it from there and no longer expecting changes in the spec as you were rightfully complaining about.
PFC: Yeah, what it actually means when the proposal champions say that the proposal is ready-to-ship, the definition of that is going to be discussed or has already been discussed in another agenda item in this meeting as far as I know.
DE: Yeah, it's fair to you to disagree potentially, with the concepts that that PDL laid out. We hopefully will discuss this next meeting. and yeah, but I roughly agree with PDL was saying. It makes sense, that this would be documenting that changes are done and everything is established. The normal thing for stage 3 is that things are by default ready to ship anyway. It's fair to disagree but let's discuss this next meeting when we have an agenda item about this topic. We could just leave this as an undefined forward reference for now.
PFC: Well, I see the ready-to-ship agenda item has been bumped to the next meeting. Sorry, I didn't know about that.
DE: Anyway very happy about all this progress. This is great.
SYG: This may not be directly related. This might go into the ready to ship this question as well, but V8's experience, I want to back up FYT here. I think it's not exaggerating to say that we have not had a good time implementing this proposal. And I think it's not really the fault of the proposal pushing against the limits of the staging process and how well it works. For smaller more bite-sized things, at stage 3, we have much higher chances of getting to a point of stability on stage 3 entrance. For something of this size we just can't do that. You need to have a back(?) will be established with you actually try to implement it. To get the things, the bugs, the issues that will result in this high volume of normative changes that seem to keep going. So I would appreciate that we as a committee do some post mortem here eventually. How do we approach proposals of this size in the future? I think the current working mode has not been the most productive that it could be.
FYT: Yes, I agree with the point. I think I mentioned earlier the issue with this proposal. One of the reasons is because of the size, which I totally agree with, but I think the other issue is actually... I want to bring this up because I know in the future there will be people making proposals this way. I do think a lot of issues in retrospect are because it was originally based on a JavaScript polyfill, as prototype. In that approach, there's a lot of things that cannot be surfaced. When you write a spec text, which is the ???, right? I'm not against working via a polyfill, but I do want to point out that with that approach there are issues very difficult to spot if that is the reference from beginning. So I would encourage people who want to try to do some things you propose, to be careful of that. I mean, honestly, it's not a wrong thing to do. I'm just saying there are things you cannot do that way.
USA: FYT I'm afraid what we're talking about here might be a cyclical problem. You might be correct that a lot of problems might have stemmed from the fact that the source of truth for some time was a JavaScript proof of concept, but at the same time that approach was chosen by the champions group because of the size. Because it was such a large amount of spec work to be done, without really many pathways to verify that. Maybe in the future with better tooling we wouldn't need that, but at the moment it was the only way to write such a huge proposal.
PFC: I think we've been going for 40 minutes. I can't see the queue. How many things are left on it?
YSV: We have one item left on the queue, but that may be better handled separately, as we're already getting into the topic of the post-mortem on a large proposal, like records and tuples. If it's all right, I'd be happy to allow you to move on with your slides.
PFC: Okay, let's do that. (Slide 19) I'll quickly present the normative PRs that we have for this time, and ask for questions on those and then ask for consensus. (Slide 20) All right. We have a change to how we handle non-numeric inputs to APIs that expect numbers. So the problem that we are trying to solve, you can see here, where you try to construct a Temporal.Duration, or Temporal.PlainTime, or any number of other APIs that expect numbers here, with things like NaN, a string, a regular expression, or the Temporal object. All these would silently convert to zeros, so that you would get a zero-length duration or midnight time. That seems like it's not good for programmers. What we've done in this PR is to align the conversion better with Web IDL conversions for doubles and for [EnforceRange] long long types, which are two of the four types that Web IDL recommends new APIs use. I did an informal poll in Matrix about a change like this, a few months ago and there seemed to be enough positive support. I know that previously for APIs on Array.prototype we've chosen not to do this, but at the same time we've been happy to do this for new APIs that are not on an existing prototype in the language. So that's what this change would do: it would align with Web IDL conversions by throwing RangeError for all these non-numeric inputs, where a number is expected. And then treating arguments with a default value by first assigning the default value to cover up any undefined that you pass it.
PFC: (Slide 21) The order of observable property accesses. In general, we want to access the properties of property bags in alphabetical order. For the most part this was already done, but there were a few places where it was not consistent. There's a more detailed explanation of our design principle described in the issue. This also brings us into alignment with the Intl.DurationFormat proposal where there was also a separate normative change which you can click on the link in this slide. (Slide 22) We want to add a fast failure for the attempted conversion of a Calendar object to a TimeZone object. So, in other words, we throw when passing an object with the Temporal.Calendar brand to an API that expects a time zone, and vice versa. This is mainly to prevent falling into this trap where you mix up the order of arguments 2 and 3 to the ZonedDateTime constructor. Since either of those could be plain objects, before this it would try to interpret the time zone as a calendar and the calendar as a time zone, and silently create a ZonedDateTime object, that would fail later operations because of calendar methods, or time zone methods missing. So this anticipates that case and throws. Or fail fast in other words.
PFC: (Slide 23) We have a change that's a small left over from the changes that I presented last time regarding the IXDTF annotations format. This is because we had some open questions about the syntax of UTC offsets in ISO 8601. So this is a tweak that allows syntax that consists of month/day with annotations, and year/month with annotations. It disallows a UTC designator or UTC offset after any format that does not have a Time component. So no year-month-day dates with UTC offset. (Slide 24) We want to add a yearOfWeek API. This is a problem identified in the wild, where if you want to identify the ISO week and the corresponding year to go with it, you may have a problem if you just use the year getter. So January, 1st 2022 according to ISO week rules, it's day six of ISO week 52 of 2021. And in this case, the terminology is the ISO calendar's yearOfWeek. Basically we just want to add a getter to the prototypes that gives you that piece of data.
PFC: (Slide 25) I talked earlier about unnecessary calls to user code. This is another one of those case-by-case. We don't want to run user code in the id getters of Temporal.Calendar and Temporal.TimeZone. This was kind of an unintentional leftover from an earlier change.
PFC: (Slide 26) Last one. Fixing rounding in the getters on Instant and ZonedDateTime for epoch time. This has been a mistake that's been present for a while and we missed it when previously fixing round, but for times that are expressed in a certain number of seconds, milliseconds, microseconds or nanoseconds before or since a date, in other words epoch times, rounding up means towards the end of time, even when the number is negative and down means rounding towards the Big Bang even when the number is negative. So this fixes these getters, as illustrated in the code sample here. Previously getting the number of epoch ms would round up, even though it should have been truncated. (Slide 27) So, that's all. Any questions about these.
FYT: We're at the point of being ready to ship, and you look at this PR, we're adding four new functions to this bag. This is something we should do before reaching Stage 3, right? And we also make it huge. I mean, at least several changes just want to make, I'm not opposed to those changes. I just want to point out when we talk about ready to ship. That change itself, tells you how ready it is.
YSV: Given that the "ready to ship" item on the agenda has slid off the agenda, maybe we can defer further discussion about what constitutes ready to ship until it can be presented.
PFC: That works for me.
FYT: Well I just want to find out what kind of changes are we still talking about. We're talking about adding four new functions here. yearOfWeek is 4 new functions that have to be added to the spec. And I'll post that. I'm just saying that's the shape of the spec right now.
YSV: I think that's noted. Are there any responses to that or any questions on other topics?
SYG: I do. A response about that topic to the champion group. That was the one that was the one that was identified from a use case in the wild, right?
PFC: That's right.
SYG: Given that it is stage 3 - though it's a pretty special stage 3 proposal - what is the champion groups bar for new use cases, identifying the wild that whether they be added now, or as a follow-on proposal?
PFC: It's case by case. We have a whole list of things that people are welcome to do as follow-up proposals if they want. For example, full week-year calendar support, which is related to this, is one of them. We weren't considering that for inclusion in this proposal. But the thing that made the difference here was that not having a yearOfWeek is kind of a trap if you need to calculate in ISO year weeks. Because, the the previous situation was that we had an API that looked like it should do the right thing, but didn't. Also if you're calculating the weekOfYear number already, then it's trivial to get the yearOfWeek number. But if you're not calculating it, because you are getting the weekOfYear number from a Temporal API, then you would have to calculate it separately. So that's one factor that influenced the decision here. Another alternative that we considered was to remove the weekOfYear getter. That way there wouldn't be this trap for programmers to fall into, because they'd just have to calculate the weekOfYear and yearOfWeek numbers themselves all together. But that didn't seem like it was in the best interests of the proposal either, to remove functionality that we'd already specified.
SYG: It seems like a reasonable reason to me, thanks.
SFC: I think PFC went into fairly good detail on this. If I had to summarize, preventing foot guns based on educator feedback is something that we've previously discussed in other proposals at stage 3, about valid feedback for addressing in stage 3. Implementer feedback is definitely one, and then educator feedback because we don't get that feedback before proposals reach stage 3, and preventing foot guns is totally in the ballpark. And we we definitely took a scalpel change, as PFC just just said, we could have done this in a much bigger way. We we took a scalpel in order to cut out the foot gun, and I think that's totally in scope for a stage 3 change.
YSV: Just one quick note on the time we are getting into the last five minutes on this topic. And we have one item on the queue from DE. Please go ahead.
DE: Overall, I think the changes that are happening in that are proposed today are well-motivated. I'm in favor of them. It is unfortunate that changes of this size are still occurring, but I think the roadmap that PFC set out at the beginning of the presentation shows that hopefully these are drawing to a conclusion. I was worried for a while that the changes were just kind of an endless flow, But it seems like these are well scoped. About what kinds of changes make sense. Regarding being at stage 3, I do think it's regrettable to have educator feedback only coming at stage 3. In the future I hope that we can encourage more educator feedback in earlier stages and I think the work that the work that RCA is is doing in terms of building a more active educator group should hopefully bring this to happen. As far as which things procedurally make sense to be in scope to happen at this stage: remember that the committee can come to consensus on normative changes for even the final specification, for things that are at stage 4. So the committee can agree on a semantic change for something that's at stage 4 as well. But it is held to a high bar. The default is that we wouldn't add anything. I do think that we should remember that stage 3 does mean that we all made our best efforts to fully design this and it's really just because of the magnitude of this proposal that the things worked out a little bit differently. I think it makes sense to keep things stage 3 and not propose a demotion as we were discussing with with groupBy, because in the past such demotions have have just inhibited progress, and not recognized that things are still incrementally moving forward, and increasingly solid and complete. So, I'm happy with this state of progress, even if it's complicated to conceptualize and talk about.
DLM: [via tcq] +1 for the normative changes
FYT: I just wish from now if the committee faces new requirements, for example, if you have to choose between adding new API or removing sites using API, go for the removing one. It doesn't mean you later cannot add it back because I have to say, I'm very frustrated. I keep having people asking me when can you ship that thing in V8: I say which one you're talking about? Are we talking about what test262 has or that something will be changed in the next couple months? So just how I feel the shore is leaving my side as if I was a boat, so I wish in the future that you choose a more conservative way, so I don't need to keep chasing it. Thank you.
PFC: Yeah, thanks. I understand. I think that stage 3 is the compromise between keeping things frozen and incorporating the feedback that you get from when your plans actually meet reality. In closing I'd certainly love to participate in a discussion about what we do with large proposals and share the experience from Temporal. But anyway, I'd like to formally ask for consensus on this slate of normative changes.
YSV: Do we have any explicit statements of support other than DE and DLM? Anyone objects to the changes that have just been presented getting consensus? It sounds like consensus.
- No objections to any normative changes (and explicit support for DE and DLM)
Presenter: Shane F Carr (SFC)
SFC: What does "narrow yes" actually mean? We should write that down in the notes. Okay. Our understanding of it is that we as a committee commit to not make such extensions without a note in 262, or other text into 262, describing that 402 is specifying what they are.
SFC: Okay. so it's just a note. It's a non normative note back referencing 402. Which is, but that's not the same as a toLocaleString method, because toLocaleString method is an empty method that gets overwritten. So this is more like what? I think Shu says, which is to characterize it as additional this class may have additional properties. Not defined here. I was just looking back in Matrix, and I just want to make sure that we are aligned on that because it seemed like SYG and USA were not aligned on what the the discussion was.
SYG: Is it going to be exactly like toLocaleString because toLocaleString is, is in the suspect as a specified as there's always this method except it's like its behavior is patched out by 402 whereas that's not what we understood narrow. Yes to me and we understood narrow, yes to mean a note saying "it's not that there's always that this property is that 402 my add new properties".
SFC: Yeah, that that allegedly understanding is want to make sure that that was what we agree on. a point of order. Can we have a queue item?
FYT: So so my question is that with that conclusion, does it means that the era and eraYear need to be defined or not need to be defined in the first 14 chapter of Temporal? I just try to understand that If.
RGN: We did not ask that question and we did not answer that question.
- We as a committee do not allow such extensions by specifications under our control except where indicated in the text of ECMA-262.
- The form has not been defined yet (note vs spec text)