Remote attendees:
| Name | Abbreviation | Organization |
|---|---|---|
| Bradford C. Smith | BSH | |
| Robin Ricard | RRD | Bloomberg |
| Waldemar Horwat | WH | |
| Kris Kowal | KKL | Agoric |
| Caio Lima | CLA | Igalia |
| Ujjwal Sharma | USA | Igalia |
| Frank Yung-Fong Tang | FYT | |
| Philip Chimento | PFC | Igalia |
| Chip Morningstar | CM | Agoric |
| Richard Gibson | RGN | OpenJS Foundation |
| Leo Balter | LEO | Salesforce |
| Michael Saboff | MLS | Apple |
| Sergey Rubanov | SRV | Invited Expert |
| Shane F. Carr | SFC | |
| Chengzhong Wu | CZW | Alibaba |
| Devin Rousso | DRO | Apple |
| Daniel Rosenwasser | DRR | Microsoft |
| Felienne Hermans | FHS | Leiden University |
| Thomas Levy | TLY | Evernote |
| Shu-yu Guo | SYG | |
| Istvan Sebestyen | IS | Ecma |
| Jordan Harband | JHD | Coinbase |
| Dave Poole | DMP | Apple |
| Mattijs Hoitink | MHK | Apple |
| John Hax | JHX | (Invited Expert) |
| Arthur ??? | Huawei | |
| Shane Carr | SFC | |
| Yulia Startsev | YSV | Mozilla |
| Aki Braun | AKI | Paypal |
| Rick Button | RBU | Bloomberg |
| Brian Terlson | BT | Microsoft |
| Daniel Ehrenberg | DE | Igalia |
| Jason Yu | JYU | Paypal |
AKI: Has everyone had a chance to review last meeting's notes? [silence] That sounds like yes. One thing I really wanted to quickly mention—we had announced on the reflector that DRW will be helping us facilitate this meeting. I just want to make sure that we're all good with that. Does anybody have any concerns?
(silence)
AKI: Ok let’s take that as a yes then. Alright, I think we're ready to move on to the secretariat's report.
Presenter: Istvan Sebestyen (IS)
IS: So this is the Secretariat report. So these are a couple of new things. So I have identified that we have one new TC39 member company in terms of application to Ecma and I tell you that immediately they are allowed to work within TC39. The next one is just to see to status of the meeting participation, how many people have participated, then as usual I will just show you the Downloads from the access statistics without going into the details because very much the same as it seems to be and then the status of the ES 2021 approval. and then the next point is the feedback of TC39 related items from the recent Execom meeting. So type setting support and other types of supports. So maybe that's really the interesting new message here, and then next are the usual time tables for relevant meetings (GA, ExeCom, TC39).
IS: Okay, so here is the new TC39 member. Actually, I just saw it from the Ecma general Assembly document files. So there is a new application for associate membership by the Chinese company Bytedance Network Technology. Honestly speaking I have not heard about them. But so apparently we have a new member and if they are here we would like to welcome that company. They have also signed in the TC39 royalty free TG form. Actually, it a RFTC form because we are royalty free technical committee are and not a task group. I am told they are now full member of TC39 and can contribute to the work etc. etc.
IS: Okay regarding the next one, meeting participation. So here the new information is our last March 2021 meeting: so we had 80 participants in total and then 25 companies. That participation is still a very high number. It is not as high as in the January meeting, but I think we can be still very very satisfied with that. So we have a good participation in spite of teleconferencing.
IS: the next one and this is what I said that I will go over them very quickly because the nature of the download and access statistics for tc39 standards, they are very much the same as in the past. So altogether up to now until April 12, there were seventeen thousand downloads of all Ecma standards from the Ecma site so far in 2021, but as you can see the TC39 standards they are approximately half of all. This is the same information as in the past. This is for the download. So this is very much the same. The next one is the typical access and download statistics for the different variants of the Ecma 262 standards. And what work is good already that for the latest addition it is for the access point of view. It is quite remarkable still to have so many accesses for the version 6 and 5.1. I have no idea why that. And then these are the figures for the downloads of ECMA-262 and this is a more clear message. For the latest addition we have the most downloads. So almost 5,000 so far, so I go to the figures of ECMA-402, the html access is 6,500 and then here the download of 200 for and also here is the latest seventh edition. This is the majority of the downloads.
IS: So next one is, what is the situation regarding the approval schedule? The formal approval of ES2021 - as I said a couple of times - it will be in on the 22nd of June by the Ecma General Assembly. I am not sure whether it will be held as a face-to-face meeting. Probably not. I mean this would be only my guess. In Europe the corona figures are bad: in Switzerland very bad, in Germany very bad. So I am rather pessimistic, but the meeting will be on the 22nd, and we have done everything in terms of publication of the necessary documents. So the publication of the ES2021 specification. So that was done two months before the vote. So that is okay. Also, we have launched and I have already reported just at the last meeting that the so-called “opt-out” for the royalty-free IPR policy we have initiated that on the 10th of March. So that was the second day of the March meeting and it will end in two months on the 10th of May 2021. I have communicated with Patrick Charolais on that and so far we have not received anything back. So my expectation is that this just a “formal opt out” and most likely nothing will come in.
IS: here are in the bottom of the slides the list of the appropriate documentation that have published announcing the out-out period and the draft standards on the Ecma file server. So this is the status. So, we are now quite well prepared for the June approval.
IS: So now this is for the regarding the feedback from the ExeCom that I got. As you may remember we had a request to the ExeCom regarding to produce a nice good quality version for the download versions of ECMA-262 and -402 and especially we were very interested in a good pdf version. Okay. So now what? That 15,000 swiss francs was approved. The request was actually to get it on a periodical basis every year, but we have not received that so we have only received that for the first year. Probably the ExeCom wanted to see, how it works etc. and if it works well, that I'm quite sure we will get it also in 2022. The ExeCom request was that the output should follow the Ecma template and the editorial guidelines. Then they would like to have first a Word document because out of the Word document it is much easier to edit by the Secretariat and they can also easily convert it into a pdf version and even in a HTML version Etc. So this is a positive feedback from the execom. It could have been even better, but I am already happy with that. Now we should proceed, there are a couple of people in TC39 who are already involved in that and they should give concrete advise how to proceed. You know, what kind of types setting services we should be use etc. They should consult this with the Ecma Secretariat. The secretariat has to negotiate the contract with the typesetting service. But also the TC39 editors, that should also be in the process in the sense that they should review before the final blessing the finished product. They should have a look on the Word version in order that everything is okay. So this is regarding the typesetting support.
IS: We also also have additional requests and this will be discussed maybe the third or fourth day. I don't know. DE is going to have a session on the future requests. How we should do that and then what kind of concrete requests should be done vis-a-vis the Ecma Secretariat. And I can't just confirm that first of all, you know, the Secretariat needs for every new thing supporting materials in order that they can be approved. One of the early feedback already that I have already received was for a teleconferencing system. I saw that in the slides mentioned by DE that maybe we also ask to finance a teleconferencing system. So these are the moment Ecma is has as standard teleconferencing system Zoom. So in order that if we have also something else there the chances are, I would say, rather slim. So what Patrick Luthi told me that the way how they are looking at it that they would like to apply the same type of rule, that applies also for hosting physical meetings, which is covered by the host. So it means that if you think and if you are not satisfied with the Zoom system then the replacement system should be provided by the host. What we have already seen it like Google, Microsoft, etc, etc. Also the current 8x8 system Etc. So this is widely accepted and we are happy using it. So these are regarding the additional requests.
IS: and now the feedback regarding the Ecma recognition awards. So the ExeCom has agreed to JHD’s nomination. The other nomination. I don't want to mention here the name etc. basically was that the Ecma Recognition Award is a recognition for Ecma members only. It was also a problem that that Ecma-wide only 2-3 awards are given at every GA, and many awards are already “scheduled” for well-deserving not-TC39 people. So the number of Ecma Recognition Awards for a large group as TC39 not really optimal.
How to solve this problem, I am thinking about it for a long time…. So my suggestion is the following. Actually we are in TC39 a very large group and they are many excellent contributions. So probably it would be better if we ourselves invented and introduced a TC39 internal recognition program and that we would have more freedom also to include more people within TC39 but also for those who are not working for Ecma members, but do a useful work for TC39 projects. So we would have more flexibility. But concretely how to design a process for that and implement it - because this is really a very sensitive subject really to give those people the awards who have best deserved it - we need a good process, and the details are not clear yet. It is a very sensitive issue. I have honestly speaking not really a good idea how we could do this in TC39. But this is now a very rough idea and if the rough idea is acceptable then we should think about the implementation. The easiest part of the implementation that I am quite good at it is, where and how to purchase the awards and then how to order it and then how to distribute it Etc. So on that part, I certainly would offer my services, but the other one, how to make the selection Etc. I would like to invite ideas to work out something in the TC39 community which makes sense. So this about the recognition award.
IS: now the next meeting schedules. So the next GA is on the 22 of June 2021. This is important for us because ES 2021 will be approved there. The next execom meeting will be in October 6th-7th of October in Geneva. I don't know if that will be still remote.
SYG: (on TCQ) Is the typesetting funding actually contingent on being in MS Word?
IS: Oh, that's that's a good question. I don't know. I will ask back. Yeah, I mean, I understand you know why they would prefer MS Word because that is the Ecma publication standard. Honestly speaking I was happy also for a couple of years only to have the PDF, but I understand why they want to have MS Word because of these easiness for editing; on the other hand in practice editing is done by the editors so I can ask them back. I mean how serious that is and whether they could go back to the PDF, but that's that's a very good question.
YSV: Regarding the TC39 recognition award. I think it's very unfortunate that we won't be able to recognize the work of individuals, especially those who have been supporting TC39 and the specification with a great deal of work on their own free time as independent contributors. I think I would support the formation of a TC39 recognition award in particular so we can recognize those contributions which have been very significant for the committee.
IS: I fully agree with you. Yeah, I mean unfortunately the situation is that for these ECMA recognition awards to have two or three per semester is not much and I know for the June awards they are already taken by others from other TCs who also deserve it (like people who have been working for Ecma on certain things also in a TC chair position, for 20 years), so for us with such a big committee, you know to share it with ECMA a whole it is not a good solution. So therefore I fully agree with you.
DE: I'm quite disappointed in what sounds like the results of the recent execom meeting. I used to be on the execom but because there were more volunteers. I left it to the committee this most recent meeting to not have a competitive election for the seats and I hope that there's good TC39 representation on the execom one way or the other. It seems like the execom is not respecting the TC39 consensus, not for the for the Ecma recognition award where we achieved consensus to propose Feliene for that at the same level as JHD. I think if there were numerical limitations. I feel like we put them at the same level for this award. So I do support creating a TC39 level award as Yulia said I think ECMA should also be more more active in communicating to us what they want from award recommendations because the award was for both on the agenda.
DE: I'm happy that typesetting funding was approved. I think it makes sense for this to be one-time funding the first time. But if it's successful, I think it makes sense to repeat. I'm disappointed that the execom has decided to take this as an opportunity to tell the editors that they should be doing more work because the editors are already doing quite a lot of work in drafting this specification and explain clearly why typesetting is an additional task. I'm surprised that the execom has already decided that video conference funding would be within scope for them. This is a small thing. it's always going to be a very small cost but there had not even been a proposal made yet in the execom already saying that it would be be rejected. I was just being open to the chairs into the execom about what funding request might happen in the future. The thing is I don't think it makes sense to consider meeting hosts the same way for all remote meetings. These are in practice run by the chairs not run by any particular host. So we could say well the chair should pay for it and that's what they're doing this meeting, but I don't think that's the optimal practice long-term. This is a cost that the committee as a whole is assuming and it's not really fair for the one committee member to have to expense the cost of these meetings for the video conferencing software.
DE: About how the committee makes decisions on funding matters, so I have it I have an agenda item later about this. I'm you know, I think there's more to discuss about the process here, I think because TC39 doesn't have the authority to make funding decisions. For example, the execom has already told us that they will reject our video conference request even if we get consensus on it. I'm not sure if TC39 consensus is the appropriate kind of mechanism. Maybe this is more about gathering feedback the (?) needs and then consolidating that feedback and sending it to the exact copy rather than our typical complete all-in-one consensus for language changes or procedural changes his language or procedural changes are categorically more important more vital to not get wrong than these funding things which are more squishy. We have needs that need to be met even if they're not acknowledged by everyone. IS has repeatedly told us that our form of consensus is quite unique among TCs within Ecma. So I don't understand why the execom is asking us to use this specifically for funding requests.
DE: I hope that in the future we can have strong TC39 representation in the execom meetings because it sounds like you're making decisions about us and that they're kind of final or they're seen as that and it seems like they might be missing information.
IS: Okay, so at the moment I do not know who is participating from TC39 in the ExeCom meeting. I didn't participate, you know, I participate if they invite me. I mean that's quite clear. And so I didn't participate. I mean obviously, you know, I spoke before the meeting to Patrick Luthi and after the meeting to him again, so what I have presented here they were based on on emails and on talks. On the other hand, maybe there will be more information in the report of the minutes of the ExeCom. The meeting was not that long ago. And as far as I know it has not been the minutes has not been published yet. So it is possible that in the meeting minutes you will find some more information. On the other hand, I don't know who else from TC39 management participated in the execom meeting. I mean, everybody from the from the chair group is automatically invited to participate like other chairs of Ecma technical committees, but to be honest, usually the case is that not many of the chairs are participating. So it is also possible that from our management team nobody participated and in that case, you know, it really happens it goes ahead in the usual way and then our interest is not really sufficiently represented at the execom meeting, So I don't know actually, you know what happened very concretely word by word that the execom meeting, I just got this feedback from Patrick.
DE: The minutes are quite ters. I'm not optimistic about learning a lot more from with minutes when it published. I made several other points about issues with the resolutions there. Are you suggesting that we take those up with the members of the execom because you are not involved in those decisions.
IS: Correct.
AKI: It's not that we don't care or aren't trying to attend these meetings. I mean, I have a finite amount of time and yet I do try to attend the execom meetings. I don't think any of the the TC chairs got the e-mail this time. I had no idea there was an execom that I missed.
IS: I don't know, you know about this this sentence, you know that chairs are invited, it goes out, it is almost an automatic invitation to each and every meeting.
AI: We didn't get an email this time around. Yeah, I was a little bit surprised to see me IS's comment because I didn't realize I had missed a execom meeting.
DE: In meeting I was in there were decisions that were being discussed about things that pertain to TC39 and I think it's important that the execom understands the needs of the committee, and they were very interested in understanding our needs. So in the future, I hope they get come will Sure we'll be more careful about making that emails reach the chairs. I know the Ecma has long had problems with its email system and resisted using an external email system and insisted on using its own Consultants to to fix their technical problems, which nevertheless persist and I don't I don't think it's a good state for ECMA for to stay like this to you know, be losing emails, to be not inviting people to these meetings even if by accident by technical mistakes, these things that need to be fixed.
AKI: We can talk more about this later.
Presenter: Kevin Gibbons (KG)
KG: (presents slides)
AKI: There's nothing on the queue
KG: Okay, that's it.
Presenter: Shane Carr (SFC)
SFC Hi. My name is Shane. I'm a convener of the TC39 task group 2, we work on the ECMA 402 standard also known as Intl. I'll be giving the status update.
SFC: What is Ecma 402? we're ecmascript built-in internationalisation Library. We own everything under the Intl namespace. as well as things related to it like toLocaleString on various ecmascript primitives. We're developed as a separate specification by TC39 task group 2, however our proposals move through the TC39 stage process. We have monthly phone meetings to discuss the details. We'd like to see you get involved. Here are some of the people involved with TC39 TG 2, a list of people who've attended recent meetings as well as the editors RGN and LEO. Thank you for your work so far. I'm SFC, the convener, and USA is the Apprentice; I'm calling USA the Apprentice as kind of the jack of all trades who does basically everything that needs to be done. We're also fortunate that we were able to sponsor Igalia to continue improving ECMA-402 this year. Google's been able to take on that sponsorship again.
SFC: Stage three proposals. So now I'm going to go through a summary of the open proposals that we have.
SFC: First here is Intl segmenter which is stage 3. I expect this should be moving to Stage 4 fairly soon. There was an update on it last TC39 meeting. This is already shipped in Chrome. It may be shipped soon in JSC. They're still working hard on it over in spider monkey, but hopefully that should be unblocked within the next few months.
SFC: And now we have a lot of stage one and stage 1 and stage 2 proposals. I'll just give a quick update on these because for several of these we have presentations later in the meeting with more details.
SFC: So first is Intl display names V2. FYT is the champion for this one and this is up for stage 3 this meeting so I won't steal FYT’s Thunder that will be coming up. I think it's tomorrow morning is the advancement for this one. Another proposal up for stage 3 this meeting is intl Locale info. FYT is also the champion for this one. This adds several features that have been long requested by users and I'm pretty happy with the way that this is working out. You can see some examples of how this works on the slide here. Again, there would be an update with many more details later in than the meeting.
SFC: intl number format V3. This is a proposal that I'm championing. We hope to put this one up for stage 3, hopefully at the next meeting. We've been saying that for a little while we hope to put up for stage 3 at the next meeting. There keeps being a lot of design problems to solve but I think hopefully we have most of those design issues resolved. And again, I have an update later this meeting for this proposal with more details.
SFC: Intl.DurationFormat. This one is largely inspired by Temporal and USA is now going to be the champion of this proposal and to help to put this up for stage 3 very soon. This has been a challenging proposal for some reason. It doesn't seem like it should be that hard. But there's a lot of challenges with the API design on this proposal. So I hope to finally get those resolved and then proposed for stage 3 at the next meeting.
SC: intl enumeration API. Also by FYT. We hope to put this one up for stage 3 at the next meeting. The good news is that we should hopefully have the privacy and fingerprinting concerns resolved. There's also an update later this meeting where FYT will share more details on that. This is a feature that many people including from this committee have been requesting.
SFC: we're not done yet.
SFC: Now, we're going to our stage 1 proposals. Extend TimeZoneName by FYT, we've had several discussions about this; it is a small proposal but it's also an important one. So we have this one for advancement this meeting for stage 2.
SFC: As you can tell FYT has been championing a lot of these proposals so we can thank him for all the time that he's been putting into solving these problems. So, thank FYT for your work there.
SFC: eraDisplay: I'm Champion for this one. This one is still at stage one and it's been at stage one since January, but I think I'll start focusing more of my time on this one after I get number format to stage three. This is also another important one for date time formatting. The implementation of this one is going to be a little interesting to make sure that it's efficient. But yeah, it's an important feature.
SFC: Intl Locale matcher. Long Ho (LHO) is the champion for this one. It's currently at stage one. There are still several open design questions, you know, we're mostly pending on LHO to take action on advancing this proposal.
SFC: We also still have smart unit preferences at stage 1. This is currently blocked. I expect that this will start getting unblocked soon as we start thinking more about the design space for this proposal for exactly what we should standardize in 402. The main questions here have been on scope. Are we doing too much by trying to both convert the units and display the unit? So there's some open scope questions.
SFC: As a reminder, we have a proposal and PR progress tracking. I'll open the link to this after the presentation so you can see how we track our progress. Here's the slide again for how to get involved. The thing we need most help on right now is writing mdn documentation. We're a bit behind on that. intl segmenter is still the big one that we need help with writing MDN documentation. We also need help on a lot of the smaller pull requests and other things, so if that's you if you have a knack for writing mdn, that would be really helpful to help us. We also need help with the 262 tests. And implementing in JavaScript engines and so forth.
SFC: So yeah, that's that's the update. Let me go quickly over here to the pr and progress tracking as you can see how we track our we keep our work updated. This includes also older PR. So there's a lot of green on the top here because those are things that have already been merged. everything where there's red X's means that they're still work that needs to be done. So there's a lot of green because we don't delete things when they get done and they get finished but most of the things that have red are currently things that we're working on. Also the things with hourglasses need work, so you can see that there's still a lot of work to do on our stage two proposals, even on our stage three proposal as well as on a lot of these pull requests. There's a lot of hourglasses and red x's here. So you can always check this for the latest updates. This is also a great place to go look for browser compatibility because if MDN is not yet updated, this chart is also a great way to see what version of each browser shipped each feature. So that's another thing you can get from this wiki page. Okay, so that's my update.
SFC: Just One Last shout out to get involved with our meetings. I think there's a lot of work that we have to do and I think there's a lot of mentorship and support in our committee. It's something that I'm striving for. So if you want a way to get involved with spec work, I think this is hopefully a great way to do it and please reach out to me or to USA or to the editors, you know, if you want some more support there and we're really excited to see you get involved.
CM: Ecma 404 lies sleeping. As long as we do not disturb it the foundations of reality will remain intact.
JHD: We have no updates to report.
AKI: Okay, next up real quick an update from the Temporal champions. Normative changes upon which stage 3 was conditional have been resolved. Temporal is now formally stage 3.
Presenter: Yulia Startsev (YSV)
YSV: So context for this is in the January meeting as we were discussing the potential for chartering TG3, which is the security TG. The chair group was tasked with coming with a chair or leadership management selection process Brian and I worked on that together since I have a bit of experience with making sure that we've got a fair processes in place for selecting people who do extra work for the committee and I will quickly present what we came up with for discussion. So the management breakdown is as follows: the leadership of the security TG would be tasked with facilitating the meeting, managing the agenda for the security TG meetings. That means determining the time zone requirements for participating delegates and rotating the remote meetings accordingly. really and also handling or delegating the note-taking and reporting of the results back to this committee. Finally they will be tasked with coordinating with this committee which is TG1 or I believe we're a TC now.
YSV: Okay, so I'm on the "selection" slide, if you can't can't see it, please refer to the slide deck. So what does that selection process of the chairs look like? We propose that tg3 decides its own chair group very much Like the Intl group is deciding its chairs. It does not need to go through the TC39 committee and that the results are presented to TC39. If only one group is presented and there are no objections. This can just be an election through consensus. You don't have to go through any formalized process. In the case that an election does need to happen one of the TC39 TG1 chairs will preside. We would expect that some presentation is done the competing sides and we propose that this will be a simple majority. Each member organization participating in TC39 is an elector. you can also abstain; abstaining does not count to the majority. We're just following the election process that we have elsewhere in the case that we do need to elect the do we want to vote question is posed in the case that you have only one group and it's not contentious, and that's election by unanimous cote or by consensus. Alternatively if there is discussion we have a couple of guiding questions about how that discussion could be had: the ballots are performed asynchronously via email to the chair group so that they can be counted and it's not shared with anybody else. It'll be a be counted completely privately and this discussion should be time-boxed to about 30 minutes. The ballot looks exactly the same as as in TC39 and are further recommendations for the selection of the chair is to have at least two chairs from different member organizations and to take a lightweight approach to selecting the chairs in order to facilitate getting started on the work, which is already been delayed by one quarter. This group was ready to go in January. So we want to make sure that they can get started right away.
YSV: I think in order for this for us to continue and for us to help TG3 get started and start moving. We do need to have candidates from that TG, and I don't know what Process. is there MF if you're on the call, Do you already have proposed candidates who you would like to get started or is this something that still needs to be determined?
MF: We haven't talked about candidates yet. I think we should continue on the reflector thread and if anybody would like to hold any of these management positions in that TG, please volunteer there. I don't know the timing should be for when we hold these.
YSV: I would propose that it can be done before the next meeting which will be next month. That sounds good to me. And I just want to make sure people have a chance to take a look at the slides because unfortunately I was not sharing when I thought I was sharing and get any feedback on the election process if there are any objections to the proposal we can make adjustments.
DE: I support the proposal. It sounds very well thought out; thanks for thanks for presenting this.
BT: We just mostly just copied what we've done before and wrote down in slides. So hopefully it's not too controversial.
YSV: Terribly sorry about the presentation quality. I'll try to figure out what's wrong there.
SYG: If we have time for this item, is there a way we can have a single election process for selecting management position things for all of our TGs. I'm not yet convinced - TGs have different subject expertise, but in terms of management and process do they need to be tailored for each TG or can we just have one?
YSV: I like that idea a lot. I think having one for the entire committee that we follow consistently would be ideal. I think in general we want to have lightweight decisions on this. We don't spend too much time on this stuff if it's not controversial and we've done that in the past, so I would be totally up for that. I actually quite like what we have right now because it allows us to very quickly make a decision if it's uncontroversial and if we're sure the resolution is pretty fair. So I would see it being modeled on what we had what we just proposed for the tg3. I don't know what people think.
YSV: Just just before we move on. I just want to make it clear that this is the last action item for making this TG a reality and we've agreed to all of the previous things. This was the last thing. So we will now have a security TG, that's fantastic. And the other action item out of this is let's unify our election process, which I think is a fantastic idea if there are no objections, I will do that.
MM: Yulia thank you. I'm very excited.
SFC: I support the forming of this TG. I'm just a bit disappointed that you decided to not put Privacy explicitly in the scope because I think that that's really important, especially for the 402 proposals. So, I mean, I think that it's good that we have a security TG. There's nothing wrong with that, but I wanted to express my disappointment because you decided not to adopt the privacy aspect as well.
YSV: I think that's a really good comment. I would love to see a discussion about maybe something privacy focused also because it is a separate expertise than security.
AKI: That would bring me great joy.
TG3 is chartered
Presenter: Shane Carr (SFC)
SFC: My name is SFC and I'm presenting a stage 2 update on the Intl number format V3 proposal. So a little bit of History here. This was advanced to stage two last summer and hoping to advance to stage three soon, but I thought I would give a stage two update because there's been a number of changes to the proposal since I presented on stage 2. So I just wanted to give an update to the committee on this proposal so that if there are any more issues I can resolve those and then hopefully next meeting I can ask for stage 3 and you've already seen all the changes.
SFC: So first, what is a NumberFormat V3? So the way that this proposal was formed is, I went through the dozens and dozens of feature requests that we get filed against ECMA 402 every year and identified all the ones that are related to number formatting and then among those applied a mechanism to try to figure out which ones to prioritize. These three criteria are also the same three criteria that we now apply to all Ecma 402 proposals. These are three bullet points that every proposal and Ecma 402 needs to satisfy: one is that it needs to have broad appeal, two is that it needs to have prior art and three is that it needs to be expensive to implement in user land. So here's an example of how we applied this mechanism. Here are two features that were requested: one of them was additional scientific notation styles. This was requested by Google, but it doesn't have very high quality CLDR support and is also fairly cheap to implement and user lands. So the verdict was to not include it. However, number range has a lot of stakeholders. It has good CLDR Support and it's not easy to implement in user land, so we decided to include this one.
SFC: So I'll now walk through all the parts of this proposal. So this includes all of the features that satisfy those bullet points. So first I already hinted at, this is number range formatting, includes ranges of everything that number format supports including currencies and measurement units. So I listed several use cases on the left; on the right you can see a screenshot where you might see this kind of format being used in the real world. This next slide is new on this stage 2 update. We've ironed out a lot more of the details about how exactly we're going to implement this. So we're going to add two new functions in Intl.NumberFormat called formatRange and formatRangeToParts. Similar to how we do date-time format, date-time format also has these two format range and format range to parts functions. In addition, we have a new function on PluralRules, selectRange, because if you are displaying a format in which you need to pluralize a word that follows a range you need to be able to select the plural form for that. So we're now including the plural rules selectRange in the same proposal. To clarify how format to parts will work. We do like we did in date-time format where the different parts will be annotated by which part of the range they're associated with. We will be adding the localized approximately sign when the numbers are the same. This is ICU behavior, and I've also been working a lot on CLDR to improve the data quality for this. So I think we have pretty good data quality now. The tilde approximately symbol is localized. So it's different in different locales. There's like three or four different approximately symbols that different locales like to use. The one in Japanese is my favorite. Then the last bullet point is we'll support ranges to Infinity, but not to NaN. So you can see an example of what that looks like down at the bottom. So these are the details for formatRange that we haven't discussed in detail before, so this is what's currently being proposed.
SFC: The next section is the grouping enum. The grouping enum now has four options that it is going to take. The update is that we have aliases to two of the options. Currently the "useGrouping" option in Intl.NumberFormat takes undefined or a boolean true and false and obviously undefined as the default for it. The proposal is to add three string values which are shown on the table on the right and alias undefined and true to specific string values. False is going to continue to be the option that disables grouping separators on all numbers. So this is a behavior change because the canonical result returned and resolved options, it is still going to be truthy because if group separators are enabled it's going to be one of these strings and that's by Design. However instead of just returning true, the result options will return a string indicating what type of true because there's three types of true now and still one type of false.
SFC: Next, new rounding/precision options. On my last update last summer I said this was sort of still a work in progress with details to be ironed out. All these details are now ironed out and this is what we're currently proposing. We're proposing three new options for Intl.NumberFormat. One is rounding priority, which I will discuss on the next slide. The second is roundingIncrement , the rounding increments allows the number to be rounded not only to the nearest digit. so to the nearest five digits or ten digits or 50 digits the rule here is that you can specify any integer value which is either a 1 a five followed by any number of zeros. So for example in order to achieve nickel rounding you would write this line here. Where you specify minimum and maximum fraction digits, which tells the number format that you want round to the hundredths place ten to the minus two is essentially what that option says with minimum maximum fraction digits and then at that position you round to the nearest five. So you round to the nearest five hundredths, also known as a nickel. So that's how we support nickel rounding. The third is trailing zero display. This is another feature that's been often requested. This allows you to strip trailing zeros only when the number is a whole number. This is popular in currency formatting when you want to display for example $3 instead of $3.00.
SFC: So, let me talk a little bit more about rounding priority. This is a puzzle. I've spent a lot of time with Richard Gibson among others working through the rounding priority. I'll try my best to explain this to you in a clear way. So what happens when you specify { maximumFractionDigits: 2, maximumSignificantDigits: 2 }? When you do this you specify two conflicting strategies for how you want to round the number. Maximum fraction digits two means that you want to round the number to the hundredths place. in which case you'd get 4.32 as the outputs from the input number. If you gave maximum significant digits two, it means you want to round after the second significant digit, which is 4.3, so those strategies are conflicting, and the way we resolve that conflict is by using the new roundingPriority option. Currently the "significantDigits" option is the current behavior and that will cause the significant digits to always win, but the two new options are morePrecision and lessPrecision. morePrecision means more nonzero digits, and lessPrecision means the one with fewer nonzero digits. morePrecision is useful for compact notation. So compact notation will essentially be { maximumFractionDigits: 0, maximumSignificantDigits: 2 } with morePrecision. And this this solves this puzzle I think in a very elegant way.
SFC: Okay, the next section hasn't changed since the last presentation. "interpret strings as decimals". So you pass a string into the number format function instead of trying to parse that as a number will interpret it as a decimal. This hasn't changed since the update.
SFC: Okay rounding modes. This is new. This is updated. I've talked a lot with DE, CLA and RGN among others and we've arrived at the following list of rounding modes. So there's 9 which are described here. This set encompasses all the rounding modes of ICU and CSS and Ecma 262 math and this is the naming scheme we agreed on. There are four directions that you can round the number: ceiling floor expand and truncate, and we have modes for both the regular version and then the tiebreaking version which we call halfCeil, haveFloor, halfExpand, halfTrunc. And in addition to that we have halfEven which is the ICU mode that's used to reduce bias when rounding numbers; it's useful in scientific and financial applications. So these are the rounding modes which we are currently proposing. The precedent that we set forward with these rounding modes on this slide. I expect it to be followed by the Decimal proposal that DE is championing, as well as with Temporal: Temporal is planning to follow NumberFormat V3 by adopting these modes. So yeah, there is a lot of discussions that went into this, you know, there's a discussion about like should we have a larger set or a smaller set? And if you have a smaller set, what should the smaller set be? And then we decided just to implement these nine and have them laid out clearly like this. So that's the proposal for rounding modes.
SFC: Sign display negative. This is another feature requests that came in that's basically painless to implement, so we decided to add it. It has the appeal that it's also very easy to implement; it's more of a patch than really a feature, so it's easy to add to this proposal because we're already working on Number format options. So the new option is signDisplay: "negative", which is sort of a hybrid between the signDisplay: auto and signDisplay: exceptZero, which were part of NumberFormat V2 from a couple years ago. This basically is the same as Auto except that it does not show the sign on negative zero. Negative 0 is this odd phenomenon that comes from the IEEE floating point representation of numbers where numbers can have a sign bit including 0. If 0 has a sign bit it means that you can display negative zero in certain formats. This format will only display a negative sign of the number if it is actually less than 0 so you don't get the weird-looking output with negative zero.
SFC: So what I'm looking for is basically agreement that this direction is the direction that we want to go with this proposal. If you have any more questions, and you haven't already been engaging with me on the repo, I'd like you to engage in the repo and I'd like to also open up the queue to any questions and if there are any questions, I'll try to resolve those before I ask for stage 3. If not, I plan to just finish updating the spec, ask for my stage three reviews, and then propose for stage 3 as I've just presented this proposal.
SYG: useGrouping @ SLIDE 7 - if I understood correctly. You still alias the true and false to some strings to give it this a stage to why do you need to Alias true and false?
SFC: So use grouping is an existing option. useGrouping currently takes values true and false as well as undefined because that's the default.
SYG: right but existing in the stage to proposal or existing elsewhere in intl?
SFC It's currently in Intl. It's been in Intl since like version 1 of intl.
SYG: I see okay.
SFC: and the proposal is to expand it, because use grouping true and false is not expressive enough. So the proposal is to make it more expressive by essentially splitting the true value into three different types of true which should cover all the use cases which are the three strings shown here. Strings are still truthy. So on input that doesn't matter because if you pass through on input, you'll get the always option, which reflect what users want, the only change that is observably different is if you call resolvedOptions; currently you'll get true and false out of returned options; now after this change you'd you'd a truthy string instead of the Boolean true, but then you still get false where you've always gotten false.
SYG: Okay. Thanks.
WH: SLIDE 11 - If we're rounding 1.225 to nickel, what would you expect the result to be?
SFC: Yeah, so the way that I described the nickel rounding is rounding to even cardinality and even cardinality does not necessarily mean an even number. It does when you're rounding to the nearest single digit, but if you're rounding to the nearest nickel then well, I guess actually nickel ends up being even cardinality as well because it alternates between odds and evens. But if for example you're rounding to some interval that doesn't alternate between the odd and even. 1.225 rounded to the nearest nickel, so that would round to 1.20 I believe, because 1.20 is the option with even cardinality.
WH: Okay. What if you have halfCeiling?
SFC: Half ceiling will round that toward positive Infinity. So 1.225 would round to 1.25
WH: And halfFloor?
SFC: 1.20
WH: The problem is that you might have double rounding. 1.225 cannot be represented exactly as a double, so it won’t be a tie halfway between two nickel values.
SFC: Yeah. The way that the rounding currently is packed to work in Ecma 402 is that we interpret 1.225 is interpreted as the shortest string representation of the IEEE double using the implementation-defined algorithm; currently all the implementations use the grisu3 algorithm, which is also the same algorithm used by Number.toString in Node.js and that algorithm is essentially called before we apply the rounding strategy. So the rounding mode gets called after we convert. We don't have to actually convert to a string, but that's how it is specified. First we can read the double to a string and then we apply the rounding mode based on the exact decimal value. So number format doesn't concern itself with the floating point. It basically goes to decimal space before it does any rounding on it. Which is also why on this Slide, the other rounding mode that is in 262 which is not on this slide is the Math.fround which is not reflected here because that's not how intl number format concerns itself. But yeah that that's a good question. I believe MLS has also asked that question before.
SYG: This may be a naive question. So what I'm struck by with these updates that there are just many knobs to turn for using number format V3. Maybe there are no correct defaults in internationalisation. What is the kind of general take on discoverability of all these knobs, deciding if all these knobs are needed. I know you're responding to feature requests and stuff like that the general usability of the API.
SFC: yeah, so most of these options that I'm proposing are, many of them are extensions of the existing options. Like for example, the reason that we decided to reuse the useGrouping proposed options because we already have that option; it just wasn't expressive enough and we have clear users and use cases for this option in particular. This grouping enum is one of the top two feature requests that we get on Ecma 402: we get bug reports very frequently asking for this particular feature. So this is just an extension. And I can walk through all these: formatRange. There's sort of two central motivations here: one is that we have a lot of users requesting it, at the second is that we support format range in date formats. intl number format range is the natural extension of that. So there's already users who are already familiar with Intl who are already familiar with date-time format range. So number format range is a natural extension of that which should reduce the cognitive burden. That's how we hope to deal with their cognitive burden. On rounding options, these options likely will incur cognitive burden. The options are here for users who want or need them. Again, you know, if you don't use these options you can ignore them. They're just options in the options bag. We hope that the names of these options will make themselves more or less self-describing. Rounding priority is a bit challenging to explain. I hope that my explanation on slide nine mostly answers those questions. The other ones should be fairly straightforward; nickel rounding is important and it is used in several currencies around the world that use nickel rounding; rounding increment is a slightly more general version of nickel rounding. We could have called the option nickel rounding, but then that doesn't scale to dime rounding for example, so we chose to use rounding increments which is slightly more general, but it's mostly focused on the use case of nickel rounding which is an actual clear use case with internationalisation applications. Interpret strings as decimals. This doesn't incur cognitage burden because users don't actually see this one. This is just that they pass in a string, we currently have the wrong behavior and we're changing it to the right Behavior. Rounding modes, this one incurs a bit of cognitive burden, but it's also something that already exists elsewhere in 262 and CSS. So users already know what rounding modes are; we're just expressing them now. And we just didn't support them in Intl.NumberFormat. Sign display negative again is an extension to the existing sign display enum. So this enum already exists and we're simply adding a new option to the enum. So we don't expect this one to increase cognitive burden. So yeah, the question of cognitive burden is definitely an important one and I mean, I really hope with this proposal that we've been able to add these features that clients have requested and that we've established there's broad appeal without significantly increasing the already existing cognitive burden of intl number format. Now one could argue that intl NumberFormat already has a lot of cognitive burden. Maybe that was a mistake in design of intl number format, but this proposal does not in my opinion have a significant net increase to that cognitive burden.
SYG: Yes, part of your answer that I really did like was that it seems like there are other parts of Intl that have similar if not the same options that are accepted in these option bags that you now extend to number format. And that kind of reuse I think does go a long way in getting the cognitive burden down. That's it for me.
DE: I think, like SFC explained, this proposal is quite well motivated. I mean when I talk to JavaScript developers about Intl.NumberFormat it seems pretty widely used more than a few years ago. And a lot of people are at the point where they run into cases where they want to use Intl number format, but it's missing this kind of feature of rounding one somewhere other this happens in a lot of financial applications. often use JavaScript for front-end things which sometimes need to need to do these kinds of operations. So I support this proposal. About intelligibility, an important part of that is documentation, and you know one advantage that Intl has over random npm packages for number formatting is formatting is that it's documented on Mdn, it's supported with types everywhere and different things like that. MDN documentation for intl is not currently perfect. There's like a little paragraph about about each one, but not currently is good code samples and other things so I think there's a lot of room for improvement and I hope that we and Igalia will be able to work on this based on our partnership with Google in the coming year, in terms of improving the documentation of both existing and new NumberFormat and DateFormat options. I think it's really good to add these as options to the existing formatter also because it works well with graceful degradation: if you have an older browser and it runs the code with the options, it will just ignore the new options, but get things mostly semantically right, hopefully So this is all very good. Thanks SFC.
FYT: Yeah, I just wonder whether stage three reviewers have been identified for this proposal since you're going to come here next time.
SFC: Yeah, good question that stage three reviewers discussed at the previous time. This came up. I need to double-check who those were, and it's been a little while since I requested those. So it's a good idea. We should probably double check that the people who volunteered last summer are still interested, let me get that up real quick here. That would have been I believe in the July meeting. It may have been in the June meeting. I'm literally opening up the notes in another tab to check here. Here, it's in the June meeting June 2nd 2020. Okay, so the reviewers you signed up on June 2nd 2020 were USA, YSV will Shadow JSW, WH only for the decimal portion, and SRV.
YSV: There is an issue that has come up since I volunteered with Jeff.
WH: (Note: clarification to the claim that I worked at Mozilla) I never worked at Mozilla.
YSV: Since we had some movement of people, I don't have the expertise on my direct team in the Intl spec to to properly review and we lost the person we have at Mozilla who I was going to do that work with. I can see if I can get in touch with him, but I think that my review can't be guaranteed anymore.
SFC: Okay. Thanks for the update YSV. You may also be able to work with USA and DE the notes actually say DE working with USA. Well, I think USA is now more experienced so he may or may not need the support from DE, but I'm thinking probably still have some so may be able to also work with DE and USA. Thank you YSV but if you aren't able to do the review then I totally understand and think we should have enough other reviewers. We need two reviewers who are not editors. So if SRV and USA do there. Well, I guess USA is sort of an editor. I don't know if we should count USA as an editor so it would still be good if you YSV you can finish your review. But yeah. Well work offline to figure that out. Thank you.
MM: I thought I heard the phrase "implementation defined" go by in your presentation. Could you clarify what it is that is implemented and why is there anything implementation defined: we are trying to make things as determined by the spec as possible.
SFC: Ecma 402 is is filled with implementation-defined behavior. The reason it's filled with implementation-defined is because there's is because there's no right answer for Locale data and we rely on browsers to bring Locale data that solves the needs of their users. So for example the list of locales supported is implementation defined because different browsers may have different needs for locales they support. The exact display in the format of these numbers is implementation defined. We try to strike a balance between putting things in the specification and allowing browsers to basically ship Locale data; that's always a challenging balance to strike. Okay.
MM: So for with regard to locales, I understand and accept that . But you separately mentioned number formats was that still just a locale issue? Or is there any other source of implementation defined variation other than locale?
SFC: It's a good question. So like the symbols obviously are Locale dependent. We understand that.
DE: You were talking about the float to decimal conversion algorithm.
SFC: It's the same algorithm that's used by number toString.
MM: Are you saying this is an issue in regular javascript?
KG: That's correct. Ecma 262 is somewhat wishy-washy about the exact algorithm here. There have been some attempts to investigate nailing this down. The first question is, is there any disagreement among implementations? When this came up last year we talked about it a fair bit among the editor group. The thing that we came to was that we are not aware of disagreements between implementations, but confirming that was going to be more work than we were up for.
MM: Is everybody on board or not objecting at least that if we find that all the implementations agree that we codify that and make it a determinist spec.
DE: The implementations, last time I checked, which was a few years ago, don't agree; if you use different bases they sometimes vary in the number of decimal places that they choose to output and I haven't investigated why. I suspect that those differences don't carry over to Ecma 402 because it's usually a different piece of code that runs but also Ecma 402 doesn't support non-base 10 for these right?
SFC: All the implementations currently use ICU and ICU implements this deterministically using the Grisu3 algorithm.
DE: These algorithms are complex and I don't think it would be appropriate for us to just transcribe it into spec text.
MM: Is there some other standard or spec that defines that that we can reference?
WH: The algorithm is the implementation, but what it implements has a very simple spec. We want the least number of digits is such that if you convert that number back to an IEEE double then you get the same value, with an additional caveat for what happens if there are two such numbers. The actual spec is very simple.
MM: In that one case where there is more than one number that translates back and you mentioned a caveat. Is that a deterministic caveat?
WH: You can make it deterministic.
MM: That sounds good. Okay, Okay, I'm done.
FYT: Is that a 402 issue or is it in 262?
WH: It depends on how you look at it.
MM: I'm concerned about unnecessary nondeterminism in the spec in both cases. Wherever unnecessary non-determinism appears in the spec, I would like to reduce that.
FYT: but my question is, if that thing needs to be resolved, should that be resolved in 262 or 402?
MM: if resolvingin 262 resolves it in both places because 402 delegates 262, then it would be solved in 262.
DE: There is a considerable amount of work needed from here. I think people who are interested in this should volunteer to do that work to push it forward and find an answer rather than just asking it for this proposal.
AKI: Thank you for the update SFC. I look forward to the stage advancement in the future and finding that volunteer champion.
Proposal was not seeking advancement, but will likely come back for advancement with the changes presented here
CLA: So good evening or good morning depending on your time zone. I’m Caio Lima and I'm here today representing the class features champion group. So I work for Igalia and this work was also done in partnership with Bloomberg. So just for clarification, class features are right now three proposals. So public and private instance fields, private methods, and static features, but we are presenting them as like a single bundle because like the idea is to move all of them together to stage 4. Okay. So let's start with the overview of what the proposal is for, some people are probably not used to this yet, or any newcomers.
CLA: So classes were introduced in ecma262. There it was possible to require class and also declare some class elements, so today it's possible to declare instance methods and static methods, and these include accessors as well. For setters and getters the idea of the proposals presented today is to extend the syntax available for not only the syntax but also the semantics available for classes in general. So class fields introduces public and private instance fields declarations, while private methods allows us to declare private methods, and static features allows us to use the static modifier on those class elements. So being able to declare a static public field, static private fields and static private methods as well.
CLA: Okay, so how do they look in code? What is the syntax of those features? so we can see here that in the first line, first column we have a class like all of them. We have a class Trainer and and the class Trainer we have kind of an assignment expression which is invalid syntax right now, but with this proposal it's possible to do so. They are used to declare a field using this syntax where we have the identifier and then the initializer followed after the equals token. And for this case, specifically, we have the literal string as initialization value for this field. So the private version of instance field uses the hash. So in this case, it's a new thing in JavaScript right now. So this is going to create a private field called #pkm. The access to those private members are only possible within the class lexical scope. So in this case, it's not possible to access the field #pkm outside curly braces. It's actually a syntax error if we use hash initiated identifiers outside classes curly braces. The private instance methods are pretty close to what we have for instance methods right now, but then like what we have for private fields, they are started with hash. So in this case, #evolve is going to create a private field called #evolve, and follows like all the same things that we have over private fields where they go only be accessible within the lexical scope of class Pokémon as well. And yeah, I think of course we have the static versions of other proposals. So the static modifier can be applied to a class field declaration or private method declaration. This is going create a static member instead of instance members. So the difference here is that for instance fields to be Installed the elements into the instance of the class while static installs things on the Constructor of the class.
CLA: Let's see a little bit of code with this new syntax mixed into the JavaScript code. So here we have an example of class Pokémon that has two Fields. So one public field name and one private field #hp, that's the way to declare fields and then after that we have a declaration of Constructor and also a damage public instance method. We can see here that it could access both public field and private field. It's pretty common with what we have for ordinary properties right now. Actually public fields are ordinary properties. There are some limitations and there are some syntactic differences between data operation with a private field a public field. So well, I can be deal that those kind of things later if you would like to know which things I'm talking about. But yeah, this is how we can use well public and private fields with the proposal.
CLA: Here we have the examples of using private methods as well. So private methods as I mentioned before, are declared with hash started identifiers. We can see that the same is valid for a private accessor. So following the same thing we have with public accessors, if it's a setter and then it's important to have a parameter for the setter. We also follow the same for private getter as well and we can create private getters in the same way that we create accessors right now. Starting with the hash in the beginning is going to turn them into private members.
CLA: Okay, so the static version we can see here is the class Pokémon. It has couple of static members. So the first one is a public static field initialized with an array of string and then private fieldrivate field that is also initialized as an array of strings. Then we have a private method.
CLA: So here are links for all the three proposals that we have. So the idea of this slide here is to give information and be the point of information for people access the whole story and also some MDN documentation that is already done for public and private instance fields, static features as well and private methods are a work in progress and we will have these soon, so people are actively working on this right now and of course here are some links to the explainer and motivation for each proposal and each new feature. I would like to highlight here a blog posts made by SYG a couple of years ago explaining each class features with a lot of code samples and also discussing a little bit some edge cases and how you can use them. So thank you very much Shu for working on this. This is a very nice source of information if you would like to learn and to understand more about those features in general.
CLA: Well since the presentation to try to move the proposal to stage 4 of course we need have the requirements to achieve that and one of the requirements is to have test262. So let's just take a look on how the test262 status is currently for this proposal.
CLA: So yeah if we consider both field instance fields and private instance fields, we can see that have about 6,000 tests covering them and we have a nice percentage of coverage from implementers as well. And yeah, even though we can see some implementations like SpiderMonkey doesn't have ??. The reason here is that they are shipping with this feature disabled and this situation can actually change pretty soon as I will discuss a little bit later about implementation. Also while the numbers for private methods are also quite close to the class fields in general. So considering also static private methods and getters and setters we have also around six thousand tests as well. We have an interesting number of coverage for the implementation side. And yeah last but not least the static fields coverage both in private fields static fields coverage. We have combined between them around a thousand tests as well.
CLA: Regarding specification text. this specification right now didn't have any open question or semantic changes since the stage 3. So since the proposals which is stage 3 there were no semantic changes and also ??. There were some editorial improvements that happened mainly coming from review and we have already a unified PR request open that got already a lot of attention from the editors. So thank you very much for everyone like investing time on _____ etc. And yeah, those things are going to be addressed as soon as I can.
CLA: Implementation status, I'm happy to show to you this table here so we can see a lot of green markers. And yeah, we have like a huge implementation support already for those features. So if we consider a babel 7.6 we are already able to use all the class features implemented. esbuild, is already supporting all the class features. So including all, you can have static and public fields and static and public private methods. Typescript, if we consider the version 4.3, that is a Beta release and also change in a couple of flags as well. It's possible to use the semantic that is supposed by the proposals right now. But yeah, it's possible to use that by setting the right Flags to experiment the features we are proposing introduced into class fields from the fields and private methods in static members as well accessors . XS and QuickJS have support for class features for a long time already. So yeah, they shipped the whole set of those features I think more than a couple of years ago. If we consider V8 version in before we are able to use all the features and are shipped since version 84. You can use them already and if you have a Google Chrome 84 plus version are able to try out those features there as well. So spider monkey if we consider version 75 it's possible to use both instance fields and static Fields public Fields enabled by default and there is Support for all other remaining features behind runtime flag, but I got some information that they are shipping and those features enabled by default also quite soon. So, yeah, we could see this table be a little bit greener than we can see right now. So yeah nice work of nice on the bottom of people and most of those things were behind a flag because they were doing work on improvements to perform some optimizations on both private methods and static / methods. And do you see Safari 14 shipped public instance fields, I think last year. If we consider Safari Tech Preview of version 122, it's possible to use all the class features. So they are shipping all the class features enabled by default. And hopefully we can see Major version of safari coming with the support for these features as well.
CLA: I would like to highlight here that Igalia worked on implementation for both V8 and JSC, Igalia working on implementation of private methods and also some optimizations for class fields and Etc and on JSC implementation. ?? lot of feedback from every reviewer as well to make sure we are implementing the right thing and just implementation. I was personally involved on this and I would that it's implemented with acceptable performance so far. This work was sponsored by Bloomberg as well.
CLA: Also, Babel 7 defaulted to [[Define]] semantics on August 2018 and Node 12 LTS shipped with private fields in April 2019 and Node 14 shipped with private methods in July 2020.
CLA: So why ask for Stage 4 now? So just to give a little bit of background here. So all the three out of those three proposals moved to stage three almost three years ago. So class Fields reached Stage 3 on November 2017. Private methods and accessors reached stage three in September 2017 and Static class features reached stage three in May 28. First of all is to wait until at least two browsers implementation ships the features, and if we consider V8 and Safari Tech Preview, we're shipping and like Firefox coming also quite soon in the next release. They potentially could enable this feature so we would have instead of all actually three browsers in the ? and Safari Tech preview version 122 to shipped like Three or four weeks ago, so that's why we think it's on a nice time to ask for stage 4. Also, given this amount of time that was given to to collect some feedback from implementers and we had a couple of feedback regarding some parts of these specifications. Well when we did some minor changes, so it was quite the kind of ?? and also implementers are shipping the current spec as is and we believe that we have achieved all the stage four requirements, to ask for stage 4. So yeah, I think here comes like the official thing. Should we move class features to stage 4?
MM: Thank you for all the work that you've all done on this.
AKI: And from JHD the same sentiment: ready for stage 4.
RBU: Yeah similar sentiment we've specifically deployed public and private class fields in production for our main terminal product to all of our users and using a stable version of the V8. So we are strongly in favor. It turned out to be very great.
SYG: Chrome also supports stage four for this. To give a timeline for things even though Chrome 84 for the private static stuff is fairly recent. The immediate previous release for Private Fields was Chrome 74, which was April of 2019. So most of the features have been shipping in Chrome stable for two years to give a timeline.
YSV: I will echo SYG’s sentiment. Firefox supports this for stage 4. We've had all the proposals implemented for eight months now, but we wanted to work on what we thought was a small implementation issue. We consider the proposal to be very mature and thought through. Additionally from our perspective given that it's been shipping in Chrome for so long, it is already shaping web reality.
AKI: I literally can't remember the last time like so many major browsers took the time to specifically say we support. It's very exciting.
CLA: Yeah, personally think that it's good to have these because even though everyone is already supporting shipping like getting those plus one explicitly. I think it sounds like a good message for me. So how goes the queue now?
MLS: We support of course for stage 4 as well. Thank you to Igalia and Caio for the work on this. We reviewed it, you know if we were to go back probably 7 or 10 years some design class features things would be a little bit different but nothing major. This is the best we think we can do given the constraints of what was already in life.
AKI: Approximately 20 minutes before the end of lunch an issue was posted to the class fields repo (tc39/proposal-class-fields#329). I'm going to let JHX speak.
CLA: Okay, give us a sec just to take a look at this statement okay. I think I got it right here.
JHX: Sorry, I just want to mention that there's an open issue on the repo.
AKI: Okay, so 20 minutes before the end of lunch there was an issue posted in the repo. It definitely spells out a lot of concerns that some representatives from 360 had. The reality is this feature has shipped. It's part of web reality. I think that by the end of that issue, they pointed out that based on our ways of working, I don't think it's actually a formal block.
JHX: Sorry, so I'm not 360 representative anymore but I believe it's a formal block.
JHD: There are two angles I want to talk about. One is, as you mentioned AKI, is that this is web reality - this feature can never go away now. It's what it's on the web. So objecting to it means that even if it doesn't land in stage 4, it's there forever. So that sort of objection to stage 4 has no effect because browsers aren't willing to unship - it doesn't achieve anything. But then the other thing is that we had a long, long-standing norm and convention that was undocumented, restricting the reasons that are reasonable to object to at given stages, and some of those were documented about a year ago. They were added to the process document - that wasn't a change to the process, it was a change to the explicit process to reflect the implicit process we've always had; according to that process I've read through, and that long issue posted in the repo, none of those items meet that criteria, and in fact, it's specifically indicated there. It says “the July 2020 process document update makes our rejection invalid” and that was part of the motivation to make it explicit. We had thought it went without saying that this was how the process works, and it didn’t, and so the committee decided to explicitly document that requirement so that it would be more clear.
AKI: That's what I was referring to when I said, I don't believe it's a formal block because it specifically says “which makes our objection invalid” in the issue.
CLA: So I'll go ahead and then I was just saying the same thing over, I have bonus slides going over most of the comments on this. I mean I didn't have enough time to read the entire thing. Sorry this didn’t come in good time for me, but I read I the issue and I think I have bonus slides that covers a lot of things and like since we have enough time and I think it's fine to like go over there in like at least you document was the reason even though we discuss this like no other place in a lot of previous meetings and Etc at least to document the reasons why we decided to take some design decisions. And so what do you think about like me presenting those bonus? Like I think we have enough time to do so.
AKI: We absolutely have enough time, but I just I would like to mention that I have a great concern with this issue because its timing is inappropriate, and I'm not saying this to change things happening right now, but I want people to think about it in the future and anything that they are bringing to the committee. This was 20 minutes before the agenda item after it had been on the agenda for like 19 days. So let's just think about this going forward and make sure that if you have something to say that the presenter has a chance to read and comprehend it.
CLA: Oh, yeah. I think we could use the schedule constraints if time zone was a problem as well. Okay, so we have two items, but I think I will go over like because some of those items actually are like process-related. So not sure if you we would like to keep discussing. So like there is a specific item that is calling an eye out some of the syntax that we decided to return fields which address in the presentation. So I will go over this and we can resume the queue quite fast. Okay, I promise that I won't be so long on this.
CLA: So yeah, the first thing actually it's kind of a coincidence. I would say it's regarding the way that we have the Syntax for private members. So the way we have the syntax for private members is starting with the hash character so the feedback that we can see in the repo and also outside the repo is that using the hash is ugly. However, like most of the Champions and also I put myself on this as well. It's kind of easy to get used to the new hash and so after writing a lot of code for private fields and tests, so I see hash as most part of JavaScript right now. Now and it's not that strange and there is like not something that came with JavaScript itself. So the language already does use this punctuation to keep privacy of members and they use @ instead of #. They use the @ character and yeah, we didn't decide to use the @ because of decorators proposal etc. So well, the situation for privacy is pretty much the same. So we just change the character and also the ability to use hash here is mainly because we need to differentiate when we would like to access the public and private entities. So after talking with those developers generally and pointing them to the FAQ and also the reasons why we decided to use hash instead of a private modifier or something like that in the class member, they actually get convinced on this. Yeah. She's pretty much what we have a solution at least like the one that is less syntax. Well the the event that creates less restriction on access of public and private members and Etc. So yeah the idea to keep public and private access different have is that we would like to these strong encapsulation as design. So there is also like an order this equation why
AKI: I'm really glad you got through that slide, but I think we've been through this enough times. I think I'd rather switch back to the queue and then if we need to come back to this week can, thank you.
SYG: Hi, I would like to +1 JHD's web reality point. I would urge the folks who are objecting to consider what it is they hope to achieve by trying to object at the stage 3 to 4 here. If the objection is to change web reality, that ship has sailed. If the objection is to, for example, block the proposal from being merged into the main specification, and therefore having the main specification not reflect web reality, I will consider that a major failure of not only the committee process, but also our jobs as specification authors. So the web reality point is the most salient one to me.
WH: I agree with JHD. This is way too late to bring up such objections, inappropriately posting long documents 20 minutes before the presentation, repeating issues we'd gone over and resolved many times. This is completely inappropriate from a process point of view. I’m also unclear on who's objecting since it seems like JHX is no longer employed by an Ecma member.
AKI: The issue was posted by 360 employees if I understand correctly.
YSV: I want to highlight in particular what JHD and WH and SYG have said and in particular I want to spend a little time reflecting on what SYG said about the divergence between the specification and the language that exists on the web. We have in the past had web reality features that were far from ideal to have in the language and they were merged into the spec because if the spec is a document that has no reflection of the web and implementations, it doesn't have any power.
MM: So, is there anybody here who represents the objections, who can speak for the objections, and is there anybody who feels like they could summarize what the strongest remaining technical objection actually is?
AKI: I'm just going to quickly interject and just let you know that those are listed on the issue and they are the same things that have come up in the past.
MM: Which of those objections are currently considered blocking? You mention that for some of the objections there was text that says that they're no longer relevant or they're no longer blocking or something.
AKI: No, I said that the issue itself acknowledges that, given our process, the block is invalid overall.
BT: It's the [[Define]] versus [[Set]] semantics are still a big part of the issue, and then additionally grow-up story from private fields to friend classes and other types of private fields like module privates.
JHD: The other one is around Proxy, and all three of these topics are things that we discussed at length over years in the committee. If we missed any of the technical objections, please speak up.
AKI: Arthur's next in the queue and perhaps can clarify.
Arthur (Huawei, no initials?): Okay, so I've read through this issue, which is objection and I think some points I believe have made these points and I believe you guys have talked about it. But I think the main thing about this objection, I think it is trying to delay the delivery of stage 4. We both agree that JavaScript should have private class fields feature, but right now the design, we believe the proposal is incomplete from our point of view. Also, we have to remind you guys that it was too late for Huawei or 360 to block or object to this proposal at stage 3. Let me just give you guys an example. I tried to program some code today and I found out the Chrome console.log can print both parent and child private fields of its instance. With features like this it's obviously incomplete and because it's really hard to determine if those fields belong to child class or parent class, right? Yeah, and I think things like these just confuse developers a lot. That's why we object that this proposal moves to stage 4.
CLA: Can I try to address one thing? So actually it's mostly like a question. Submission that the class private fields mostly look like they’re incomplete. So I'm wondering if there is any blocker for the current proposal to have a follow-up proposal to address the things that you would like to and if this is if the proposal that is as actually is blocking you to do such kind of things because well it repeats ringing like a strong encapsulation. And so we're now bringing like protected members or any other kind of things. For example, well any other like to use the model scope or etcetera, but we liked the proposal itself. Maybe I'm wrong. Does the proposal disallow you to do a future proposal to have such other kind of members in the future?
So regarding the console.log in Chrome. Details into a problem relation like I will speak by the implementation of JSC. So there is no inspector support yet for JSC class fields. one of the reasons is that this feature is not Stage Four yet. So you are not expecting to support from your browser since its ??, but I think that is not a block. I think we should do such kind of optimizations in the Chrome side afterwards as well. So we could remove the confusion that this would cause for developers in the near future, and it's kind of easy to do. So, it's just a matter of priority of browsers. I would say, I mean I cannot speak for the browser's but just like involve any condition anything that is any blocker Shu to have better support of private members on the inspectors.
Authur (Huawei): yeah, I mean as you say, I guess it's already reality, but I think they'll still issue their opinion. Yeah, that's my full speech.
AKI: Okay, I think I want to hear from DRO. You're next up.
DRO: Awesome. Yeah, this is not at all a comment for or against what was said earlier, but just as a general point of something to remember, Web Inspector, developer tools, whatever you want to call it are very much not - I personally don't think - something that is controllable by this body (maybe to some degree, but not completely), and how they display information in their interface is sort of entirely up to them. To give one example, Web Inspector in WebKit and Safari has a way of showing what we call “internal properties”. As an example, if you log a DOM node, you can see a list of all the bound event listeners. That's not something that's normally exposed to the web or something that really is at all accessible in any way. There's no way for you to right click it and save the value. There's no way to get access to the object, but it's something that’s very useful for developers to be able to see. As far as how private members are shown, that's entirely up to them. And that's something that can pretty easily be changed. So I don't think that that's necessarily something that should be considered as an objection over.
AKI: All right. Thank you. Thank you for that clarification of the point about the inspectors.
DE: So the DevTools point, I think the challenge is figuring out a UI to show which class the particular private name is, used a private name in multiple classes. There's multiple ways to solve it. I mean I don't have experience working in implementing this, but I think the problem exists at that level, not the possibility level. There was also concern raised about sharing private fields and methods outside of the class and the stage 3 static class block initializer allows a quite convenient way to do exactly that kind of share. During the development of the proposal, I was especially hopeful for Decorators. I remain very hopeful for decorators, but they're taking a little bit longer and it seems like we'll have static class initialization blocks first, so I'm happy to talk through more more issues and CLA is beginning to present good arguments for these, but I agree with the points that others are making in general.
AKI: Okay. Thank you.
JYU: I'm just curious about, you know, do we have such cannot be a process? You know, he's such a it's such a kind of condition that we can maybe just postpone the conclusion of the discussion to the end of the TC39 meeting so can give them a lot more time discussing and raising questions when the Champions are able to get online and involved in discussion. So I think, you know, at least for this proposal which is causing a lot of arguments it would be better to be cautious because it's rather critical about moving a proposal to Stage 4 even if it has been implemented by almost all the browsers.
BT: We really have been cautious. If it weren't for hearing these objections, this proposal would have advanced a year ago, maybe even longer. So I think we need to take a decision this meeting, and to that end the chairs tend to agree with those calling for advancing this proposal. Having read the GitHub issue, none of that stuff was particularly new. It's good points, good things to bring up that have been brought up before. We have discussed them before repeatedly both in Committee and in the GitHub issues and in side channel conversations with the Champions. Really, as a practical matter, this proposal is web reality. There's nothing that really changes if we delay to another meeting, and our job as a committee, one of the most important things our job is, in my opinion, documenting web reality. It is super important that we have a document that people can follow that will get them an implementation that can run code that exists on the web now. If we don't do that, we have major problems. Just as evidence for that, we have this quick merge-to-master process for things that are documenting web reality, and it's to the point where private fields could even just skip the stage process and just be merged as a PR because it is web reality. So we understand that there are challenges with this proposal. There were challenges with this proposal and we regret, I think, that some members can’t agree with this proposal as it is. But I think it's time to advance this proposal regardless, and that's because as I mentioned the process document is pretty clear about what is required for stage 4 feedback, and none of this is new feedback. It's all been discussed and we have this web reality concern and process that we need to respect. But that said, we look forward to working with the committee on any process or other changes that we need to make this sort of work go through more smoothly in the future. So if anyone has any feedback about what we can do as chairs, or what we can do as a committee, to ensure that going forward, proposals like this, everyone can be happy with them. We'd love to hear that. Okay, that's my spiel.
CLA: So just a reminder. I think we just have five minutes left on the time box. Is that right?
AKI: That's correct. Okay, so if it's alright I'm going to skip the ‘no’s. [Note: multiple 'no's were on TCQ responding to the question of "should we delay?"] Is there anybody with a 'yes'?
WH: I would like to call for stage 4 for this.
CLA: Oh, I would like to call for stage 4 as well. So can I say we have consensus?
BT: I believe we have consensus on stage 4.
MM: I need to understand process-wise what it means for us to declare consensus under these conditions. There's nobody from 360 in the room, but they are a member of the committee. So can somebody talk out to me how it is that we can declare consensus?
BT: The reasons are effectively that the process document spells out what the kinds of feedback that we expect to be blocking in stage four and one of the primary requirements for those things is that the feedback is new and is based on implementation experience, and the feedback that was posted in the GitHub issue does not meet those requirements. Additionally as a practical matter the reality is that this proposal is web reality.
MM: As a practical matter, I'm completely on board, but I want to make sure that we're not about to make a precedent that weakens consensus too much.
BT: I agree. That's what I think. But I want to make sure that the point about the practical matter is clear. I'm actually making a process argument here. Because as a practical matter, we have a process for things that are web reality that is an extremely abridged merge-to-master style process. We used this, for example, for the … I think Array.sort() ordering was a proposal that used this process recently. And so for things that are web reality, because documenting web reality is so important, we actually have a lower bar and this proposal would meet that bar.
MM: Do we make that point in any of our process documents? Is that exactly written down?
BT: It's in “how-we-work”. It's not actually in the process document, but we do have precedent for advancing such proposals.
AKI: We have a lot of precedent going back to at least 2012. We don't have as good of notes before that, but I did a little research on our web reality decision-making processes. And yeah, it's not new.
YSV: I would like to bring something up regarding introducing a process to accommodate this discussion. I was on the queue and I think it's an important point. Specifically, this was posted 20 minutes before this item was being discussed. Secondly the people who posted it have been members of the committee for over a year and are very familiar with our practice of requesting time boxes that will work for difficult time zones for specific topics, and working asynchronously. If someone can't make a specific time, they can request that the item be moved. They didn't do that. They also posted it 20 minutes before the meeting, not giving the champion even time to read it prior to the presentation. It was a very long topic. This points to something that I hope we don't see in the committee again, which is that rather than allowing discussion to take place, they put down a trump card to stop discussion. They made themselves, and their position, unavailable, forcing a final word onto the committee so they would not be questioned. This is not how we work and it should not be allowed to set a precedent.
AKI: Yeah, like I said, they had 19 days, and also four years, but really 19 days since this was added to the agenda and I think everyone who's ever been accommodated knows I work really hard to get people's schedule constraints in so that they can attend and they can be part of the discussion of things that are important to them. So this comes at a time when I believe that this could have been approached better. And therefore it feels like it was a strategy instead of a mistake.
MM: I agree with everything you guys just said with regard to making a judgment about how they have approached us. Whether that invalidates this as an objection to consensus is not quite the same question, but overall from this discussion, I'm satisfied that we can proceed to consensus.
BT: Okay, I think it is worth noting to be clear that this is in no way attempting to form a precedent for, for example, "Rough Consensus" as other committees operate. This is really a very particular point, a process point based on the arguments that were presented in the GitHub issue and over the last six months. So let's just be very clear about that.
AKI: Okay, I think we talked about process enough. We're over time though, and I wanted to give JHX an opportunity to say a few words as you've been patiently waiting in the queue and then we need to move.
JHX: Thank you. So I'm not a 360 representative anymore, but I try to speak for them. Actually, it's very hard for their guys to participate in meetings because of the limitation of the time zone and the language problems. I hope everyone could read the issue posted in the repo carefully and the many points. The technical issues and the points about the process have been written in the issue include some arguments about the process limiting in which situation one can block a proposal for stage four. I think it's, I think I cannot say any more on that, but my last question is about the web reality, as if it's a good reason why we eventually maybe need to allow that to stage four. But I think the issue has discussed that process problem when the class fields and related proposals achieved stage 3 in 2017, actually, there is no chance to fix anything. So that it eventually will become web reality in that time. So the 360 or any other members who were not members at that time, they can do nothing about that. So I think this is really a problem in that it seems that if a proposal makes it to stage 3, there will be no way to to fix anything. I think the issue posted on the repo also points out that the quality of the proposal actually is not good enough for stage 3 in that time. So this is what I can say. Thank you.
BT: Yeah again, as I mentioned, any updates to the proposal, sorry to the process, that any member has, the chairs would love to hear that. So, you know, feel free to offer those suggestions to us.
JHD: Yeah, just pointing out that because all this stuff is shipped, we can't change or fix it regardless. It is on the web. It is permanent. So anything that can be changed can still be changed in stage 4: we've changed web-compatible things that are already in the spec already. This is sort of underscoring the practical points that have been made already, but if there's anything that can be changed, it can be changed at any time. And anything that can't be changed, can never be changed regardless of the stage. So it doesn't seem to me to be any justification for delaying stage 4 here.
TLY: Sorry, just a very brief thing, is if the process does allow for sending things back stage 2 if there was truly a mistake made when going to stage 3, correct?
AKI: Yes. It's happened in the last couple of years. I can't remember which proposal but it certainly has happened in the last couple of years that something has gone from stage 3 back to stage 2 to resolve some issues.
TLY: I'm not proposing that it should be done in this case. I just wanted to address the suggestion that mistakes in a stage 3 spec cannot be addressed.
AKI: Yeah, I think there's there's a lot of things and a lot of factors will go into that
DE: Yeah, so the process document addresses this. The process doc says that the to be another proposal can propose something for to retract stages in the community can achieve consensus on this and this happened in two proposals that I worked on. It happens in Intl.Segmenter and it happened in part of this proposal Static Class Features was retracted to stage 2 until we thought about it more and decided that actually it was good already. Whereas Intl.Segmenter did undergo significant changes before returning to stage 3. Overall, I think the polarity expected for that is different. It's not like you need consensus. So you need consensus to advance a stage, but you also need consensus to retract a stage. It's not that you can block the presence of something that's already in stage 3 and it just goes back.
JHX: Yeah, I think theoretically it could revert a stage but it needs a new consensus. But also if the topic has some essential disagreements, it's actually impossible to have any new consensus. So is it real consensus or not? I am confused, especially in the class fields proposal. So good consensus is still… only the old consensus… Is this a real consensus on very thought about it, especially in confused, especially in the Class Fields history?
AKI: I'm sorry. I lost your last sentence again. Could you just repeat that last sentence?
JHX: Okay, I mean, to revert a stage it needs consensus, but in the case of this proposal there are many essential disagreements. So it's impossible, in my opinion, to achieve any new consensus. So after stage 3 I think the 360 delegates are saying that the stage 3 consensus of this class fields actually is weak, but it's impossible to achieve any new consensus. So that's the problem.
BT: All right, so we're well over time for this item so we have to move on I think. JHX, thank you for bringing process concerns, you know, we should work to address those going forward. Now is not time to litigate what stage 3 means or which proposals were properly stage 3 or not. We're very much past that point, so I think at this time I'd like to congratulate this proposal for getting to stage 4. It's been quite a journey. And we can work on addressing all of these process concerns going forward. That's something that I am personally very interested in doing and so, you know, anyone can feel free to talk to me about that, to talk to the chairs generally about that. This is, I know, something that the chairs are watching out for a lot, ways that we can improve our process. To help everyone work better together. So please do bring up those concerns. Are there any final non-process related questions before we move on? Sounds like no. Congratulations to everyone who worked on this project - it was a lot of work.
- All three proposals advance to Stage 4
- Any general process concerns should be brought up to the chairs
AKI: Thank you. Congratulations everyone before we move on to import assertions.
Presenter: Dan Clark (DDC)
DDC: Hi everyone. Can you All right. Hopefully folks are seeing slides. Please. Stop me if you're not. Okay, so I'm Dan Clark bringing back on import assertion stage three updates. The purpose here was to discuss a few things that came up during the HTML integration as well as implementation in chromium. There are a couple questions of just like should we go further in driving interoperability between hosts? And then a third just hang on just a quick small Speck book picks. So just quick recap to remind everyone know what's going on with this proposal. This was the thing that we are adding some syntax to some adding to the import syntax to allow. authors to pass additional information along JSON modules another module types were like the biggest first kind of motivator for this and JSON modules are defined in a separate proposal. Also currently at stage three a quick ecosystem update - Sven, if you're on the call, feel free to just jump in here if you want to add anything - but this is shipped in Babel. This has been implemented along with JSON modules in chromium 91 and will ship in chromium 91. That's it's like the May release. Webpack, it's a work in progress. And then the typescript implementation is planned for 4.3.1.
DDC: So the first one of these issues I wanted to discuss was on this question of whether we should enforce further interoperable behavior for unknown values for the type assertion. This has been discussed in GitHub issues before and we didn't really reach a conclusion here aside from where it currently is. So currently if a host sees a module type assertion that they don't recognize they can choose what to do. They can ignore it. They can fail the module graph for they could do something else. On the web, HTML has to fail the module graph if there's an unknown module type value. This is because new module types are added say CSS modules as the implementation for those rolls out across different browsers if an author uses the new module type and that runs on a browser that does not support the new module type then if we merely ignore type values then it'll fall back to JS, and suddenly we are executing JavaScript when the author didn't expect to, and that's like the original security issue that motivated this whole proposal. So that's a non-starter. So HTML will fail fail the module load for unknown values of the type assertion. Something that we could consider is, do we want to standardize that, do we want to require that behavior to just drive further alignment among hosts so that we don't have these things like kind of being ignored on some hosts and triggering failure on others which would be sort of confusing for authors. I think there's one nice way that we could do this which was suggested by (?), which is a new abstract operation like host get supported extra module types that we could add where hosts just specify what module types they support other than JavaScript so they say if they support like JSON modules or other types and then on the ecmascript side, we'd actually trigger a failure. Or if an author asserts something that the host didn't claim to support and this is similar to something that's already in the import of certain spec with (?) supported assertions this kind of a similar idea. And so I think this could really be considered separately from the other issues I had. Maybe we should go to the queue now and get feedback on like is this a bad idea? Is this something that's this is something this is Direction. I like the idea of standardizing this behavior so we could have kind of the same behavior among host, but if there's a reason that someone feels that we should not do this.
MM: This is not an all in objection. It's an issue to think about. I have not thought about much and I don't know that it would uncover a concern, but every time we delegate some decision to the host, we create a new host hook, we should always think about the virtualizability of that host. With the compartments proposal, we're trying to enable JS code to act as a host to other JavaScript code and there are some constraints imposed by that. It's very similar to how in the object model. We enabled the various operations in the object model to be delegated through the proxy mechanism to handler traps so that a JavaScript object could act as an implementation of exotic and non-exotic JavaScript objects. Thanks, so I just want to put that on the table and I want that to be a first-class consideration to be taken into account in this proposal.
BFS: This is tangential but related to Mark's point. So node does have the ability for you to intercept custom user-land based types. They essentially must be transformed into a host known type. I think we shouldn't enforce rejecting these types without some better understanding of what it means to transform a user-specified type or polyfilled type. Whatever into a well-known type. In particular if you transform a module that is, say, yaml or some other type into JSON, what does that mean for import assertions here? What would it mean for the rejection? Because the userland module would eventually become JSON but the apparent type would be yaml. So in particular I worry about the statement that the reason to reject is because it would execute JavaScript because we're not really looking at the ability to execute JavaScript. We're looking at the ability to execute something that has side effects is the problem we've discussed this Pat in previous meetings, so I really don't understand how we get both the proper import assertion behavior and user land types to work properly if you eagerly reject in all environments. Environments that never want you to be able to customize the behavior of their loader like the web that seems okay, but for things like node or bundling tools, which even today specify custom types, I don't I don't understand how it would work. So that's all.
DDC: Can I just speak that part of that? Yeah, just to clarify when I was making the point about the JavaScript security issue earlier, that was specific to the reasoning of why the web has to do it this way. I don't intend to make any claim about why other environments should or should not reject in this manner. Where I'm coming from is more that if, which it sounds like maybe is the case, if there is a reason that for example node should not reject in this manner then that would be a reason to leave this idea out of hand and just not standardize it.
BFS: If all other implementations would be on board for this then we may as well standardize it but it's that that claim is not I think it would be fine, but standardize it you just have to plan for it. I think that the way the web wants to do things just isn't going to work in the other hosts. So you've got to add those like virtualization hooks, which affect the Chrome's you've got to make sure that the other hosts. We should have a well thought through model for what does it mean if you're getting a transform going on for polyfilling purposes or modified user land loaders. Rejecting without those efforts doesn't seem viable, rejecting with those efforts - sure, seems fine.
AKI: All right. Moving on
JHD: I love the idea of standardizing this, and I think similar to Mark's sentiment from a few presentations ago, that any time we can lock down possible behaviors, and avoid implementation-defined or host-defined things, the better. We can’t do that everywhere, but where we can, that's ideal - I haven't really thought this through to the point where I have a concrete opinion as to which direction to go, but my concern is that it's harder to feature-test and polyfill and figure out whether you can use a type if an unknown one is going to fail in the sense that (this may not matter because you could still dynamic import and wait for the rejection to come through, although that would be async) but I think it that's just kind of the vague concern I have. That said, if this is something we want to do, then we can do it.
DDR: I just wanted to say so if there is any sort of concern over our implementation. I think you read before three one was the due date I've had in mind to ship this or implement this triage mistake. My apologies. It'll be closer to August that you'd have like a stable shipping thing for this feature. May be worth mentioning is, we will likely not really do any specific type checking based on these things, we will kind of just ignore them and let the host sort of pick up the slack on whatever needs to be done there. So that may be something worth noting as well just because it's been brought up in this meeting.
KKL: Again following on from Mark's point about thinking through what virtualization means for this proposal. I think that the value of asking that question is that it I think that the answer is that assertions like this become unenforceable when the module system’s virtualized, when you have JavaScript code hosting other JavaScript code with a module loader. So I'm not sure that that's true. But I think it's very worth asking and thinking through can we make a rule like this enforceable in the face of virtualization?
BFS: I'll respond. I do think it's virtualizable I don't think it's virtualizable with a first class API we had problems with node’s loader system, which should be okay virtualizing this but it requires you to bootstrap ahead of your active realm in order to do it. We can discuss this one of the Realms meetings that you want Chris.
SYG: A clarification question for BFS. I didn't quite understand the plan for it comment that you said from what I understood. You said I thought it sounded more impossible than we needed to plan for it if we standardize on the Behavior.
BFS: No, I don't think it's impossible in particular my example with yaml versus JSON is kind of the example that I would point to, it's where you have, Let's say a consumer it says type yaml, because they expect to consuming yaml or type CSS because I expect to consume CSS in reality. There's some kind of transform that happens in your host. Not not a build step in your host. There's some virtualization going on that returns for example a JavaScript module back or a JSON module back instead of the specific type that existed before it was transformed through the virtualization layer. That’s really all you need to need to plan for.
SYG: And the point is that that JavaScript module would be stamped somehow as blessed by this host virtualization hook and if any code execution were to happen. That's just like you have a buggy host. That's your fault because you try to virtualize it. Is that the point?
BFS: Yes, it requires your virtualization be done properly, but it would basically state that although my virtualization returned a JavaScript module it is acting as if it were a yaml module, right, right. Okay, I understand.
DDC: So I think the thank you for Bradley for raising the point like I think yeah, I think the plan is taken that like to the extent. I understand this that we would have to think about how to accommodate that scenario better. Yes, I think where I would come away with this is that we don't - we're not ready to do this yet. It still may be worth pursuing to drive alignment here, but I need to think about think about this case furher just to see if there's a way that we can we can make that work.
?: Just to be clear. I think you have to decide it for you. Go to stage 4. Yeah, like yep, that makes sense. Yep.
MM: Yeah suggest that you come to one of the SES meetings that where we prearranged that this s this s meetings on the top.
DDC: Sounds good to me. Okay, so I can just move to the next issue. I guess if there's there's no more on that. This one was this one is kind of related. But I think we could probably consider it separately.
DDC: so some host might decide to allow a like a lot of time to be specified for just JavaScript modules, right? Like right now you obviously don't have to specify the type of those currently hosts are within their rights to like a lot of something like asserting type JS JavaScript ecmascript to whatever and I could Envision a future in which different hosts do different things for this and some of these different strings work on some hosts and not others and things just it kind of confusing because developers don't know like what to expect for these things working or not. I think it would be interesting to see if we could state that like these sorts of like that kind of the thing that more straightforward way to like try to avoid that potential future is just say that like none of these are allowed to like potentially saying something in the spec with prose like a string value provided to well. I guess it wouldn't be host supported extra modules group type since we are not adding that but we can still add language that is like if a type of search is present like then it must not be done. The specifier must not be loaded as a source text module record. And I think that I think this sidesteps the problems with transforms that Bradley had raised previously, although maybe not I need to think on that but I think it's worth seeing if we can not allow any of these type values to be In order to load a JavaScript module just to avoid ecosystem Divergence there among different between different hosts a couple different ways. This could be done in prose. Is that kind of suggested the idea of like a registry to standardize these among hosted been kind of mentioned in the past and there's also a like we could do it like the hard way and just like come up with a list of strings that the suspect could good and bad, but I think really the most likely way is just to like do this is somehow I think the biggest question is whether well one question is like is this doing second question would be like is this also falling afoul of the issues with Transformations discussed previously? I'll go to the queue Kia cuz I'm still thinking about that.
BFS: Something I don't think it's a problem for Transformations. I think there's some serious confusion on my part on what you're asking to do here. It seems like you're stating if somebody specifies that a dependency is expected to be JavaScript it always fails.
DDC: Basically, yes like so the goal would be. like don't allow more than one way to do things like currently if someone wants to load a JavaScript module. They just don't specify the type. It's assumed that if you don't specify the type, it's a source text module record. And so any so would be like if any type string at all if any type of certian is present then we reject it because like if you want to load the JavaScript module you don't specify the type and that's assumed to be the default. And so if you are specifying a type then like then it's then it's failing
BFS: At least from the framing of it. We should definitely not do this in my opinion doing so basically means that in situations where you have multiple potential dependency types intentionally the same thing you can't assert that. It is JavaScript really which is strange where you could assert for example. Type JSON is optional in this JavaScript spec having the ability to assert the dependency as JSON but knotted dependencies JavaScript walls mm or any other thing gets confusing to me on why it wouldn't be allowed to know the type of your dependency. So it would be good to know why to do this? If you're not guaranteed that your dependency is JavaScript without type already.
DDC: Yeah, I think I think I understand where you're coming from here. I think so, I think for the problem is this I'm not sure that this actually works without having a resolution on the previous thing, right? Like if hosts are able if we haven't resolved on the previous item and hosts are able to like just kind ignore arbitrary strings for the type of solution than yeah. I think then maybe yeah, this just doesn't work. Yeah, actually we would have to go I think we would have to have a resolution at least on the previous item to say that like unknown strings are rejected and then we could consider this as like a kind of a strengthening of that. But yeah, I think the I think the points will take on that. Yeah. I'm not sure it actually makes sense as just as a standalone thing.
BFS: I think it has a problem of just colliding between types if no type assertion as present. I don't think I don't think the previous feature whatever you want to call it for virtualization has a significant effect on this actually. Anyway, that's all I have.
DDC: Yeah, thank you Bradley. Yeah, I'm not seeing anything else in the queue and I think I'm like, it's I'm not yeah, I think I think I'd want to go further with this one until at least until like we've gone made progress on the previous item. So I think I'm gonna just move on to the next one. Unless someone wants to wants to talk further on this one. So this last ones much simpler this way we plug in our spec for dynamic Imports. We were failing to check if this second argument to Dynamic import was an object or not. So we need to check that and then it's a simple question of does the check we check if something's an object and rejects the import promise if it's not an object, or do we use two objects and kind of the arguments my feeling is rather strongly that we should reject we should do an object check and reject the promise if the passed argument is not an object because I feel like doing an implicit conversion here and implicit conversion here to an object is like pretty much never going to be what the author wants and probably they just made a mistake and would want to know right away rather than have it like invisibly accept it and then fail later in some probably more confusing way. So the only question here would be whether there's so I saw that there's precedent it was raised in the issue. And just in my own looking through the spec. I see that there's like some precedent for either approach year looking at just various APIs. But so I like the precedent. It can be made from either direction. So I'm just thinking about it in terms of like what an author might expect. So I think I would like to I'd like to push that like it is object check and I guess I just like to ask like this is is there any objection to that? Is there any like precedents that I might not be aware of or like direction that TC39 is trying to go with this that would suggest that we should go the other way.
AKI: Two minutes left in the time box and the queue has more things in it now. So first Mark Miller.
MM: I like rejecting. The precedent that you're citing on 402 is that specifically for an options object?
DDC: I'm as I recall. No, I don't think it was. I was just looking at difference between remember which I was looking at for some reason.
MM: The reason I raise this as I remember there was something an issue or something that was specifically trying to write down some rules for option up for accepting option objects. So that it so that in so that not only are some object arguments have common expectations but specifically so that processing options arguments have common expectations.
DDC: I think it might have been this.
MM: It doesn't look specific enough. I'm sorry. I don't remember but I think if there is a precedent regarding options object specifically that that says more than just use is object assert that it's is object. It would be nice to take a look at that because you'd be great to have more regularity understood regularity among options.
AKI: All right. Thank you. Mark. Next topic is from Gus, just a note that there's also an issue for import argument evaluation order and they say they would PR open for that. Next up is BFS.
BFS: Sure, So this is an aside we can do this later if we pull off the Prototype that Ihave varied opinions on if it should or shouldn't reject depends upon if we pull off the Prototype all … I’ll follow up offline.
SYG: I want to hear from the 402 folks because reading 402 there is there are two abstract operations that deal with option bags. One of them is called CoerceOptionsToObject, which does the ToObject, and then there's a sentence in that AO that says its use is discouraged for new functionality in favor of the separate AO called GetOptionsObject which raises a TypeError if the input is not an object, so it seems like the Intl folks learned perhaps the hard way that they should not be coercive.
SFC: The new version of the GetOption construct came from Temporal, where previously in Temporal we were using the legacy Ecma 402 GetOption abstract operation. Then some of the Temporal champions basically raised some salient concerns that we should not be autoconverting the argument to an object. We had this discussion and decided that for new Ecma 402 proposals, including those that are shipped in ES2021, we will use the new version of GetOption, but we're keeping the old operation around for backwards compatibility. I'm glad that we're having this discussion now with the greater group because we were seeking feedback from the greater group on this and we didn't get much feedback at the time on this subject. That's the background. This is relatively new. This just happened a few months ago when we added the new constructions. PFC was one of the people behind that as well.
SYG: So given SFC's explanation. I am happy to also support reject and also happy to support it as a precedent for new features that use options bags. I would like for both 262 and 402 to treat options bags uniformly, legacy stuff notwithstanding.
AKI: JHD, 30 seconds.
JHD: Sure, so I'll start backwards. “throw rejects” is the only, choice because for async functions we explicitly decided that things should always, or never, return a Promise. For the object check, we have a lot of precedent in ecma-262: For example, IterationResults have to be Objects; they can not be something that coerces to one. For this case, using anything that isobject coercible, but not an object, is pretty much always going to be a bug. There's just no use case for a non-object, so I support this.
AKI: Thank you.
DE: Okay, so request for services from ecma for TC39, so I want to talk about how we can work with Ahmed to make sure that Community needs are met. So each one talked about how this was done recently for the typesetting request which is going to require continued collaboration. I don't want to come to a conclusion about what services to request that's a much more detailed discussion and it will be for future presentations but more about what kind of process we could use. So why should we request services from Ecma? Ecma is leaders would like to meet TC39s needs we're clearly the biggest and most successful TC and Ecma, you know, most downloads. most people joining these days and paying membership fees and Ecma does want to see us succeed and does want to provide what we need to succeed. At least they have in the past said that when I talked to them about it . that are nine is recognized to have different needs from other TCs in ECMA So, you know, we have three co-editors who are working very hard and Ecma levels So, you know TC39 recognized have different needs from other TCS and works differently other TCS are largely TCS are largely run by Ecma staff and contractors. Actors just to get to get Services being provided by the Secretariat and we're you know, we need different services so So it came over once explicit signals from the committee about what need. and in writing would be the best way to get these kinds of requests for example, they mentioned conclusions in the TC39 meeting minutes. And in particular we talked previously like in the November 20 meeting about different ways that TC39 could get budget like maybe we could get our own budget to allocate ourselves. And so far what I've heard from ecma and I don't know if he's trying is there but, you know, correct me if I'm ? didn't think anything is that the ecma secretary would prefer if instead of asking for a budget we ask instead for services. So that's why this presentation is to bill services that are planned and we're encouraged not to think about the overall economic budget because that's the domain of the Ecma Secretariat the equity exact calm in the I could General Assembly. All TC39 member organizations can go to the Ecma General Assembly meetings in order. Your members vote on the budget. So I want to propose a kind of flow for making these requests. So, you know, someone will propose a request in DC that are 9 mm?. Plenary somehow the committee will come to conclusion. I'll talk more about that in a minute. So then the chairs or a chair appointed liaison would explain this request to to ECMA; ECMA can consider these requests and make a final judgment. And then you know from there it may take three to six months for the Ecma Secretariat or exact calm or GA or whichever decision-making bodies equities appropriate to decide on it in this type of setting case. I guess it was the Secretariat of the execom who needed to be engaged.
DE: So we previously sent this typesetting request to ECMA, we discussed it in November 2020, chairs and editors agree this is necessary. And so we raised the topic to them in December and these slides are outdated because now know that they apparently approved it in the April 2021 execom meeting. So there's some ideas for what we could ask for in the future. But later in meeting. We will see a presentation about the nonviolent communication funding request for service request. So what I would propose for the process here is that it's about gathering feedback on the committee's needs rather than voting or consensus oriented around blocking things. So delegate presents the need for the service to the plenary, the committee gives feedback and then at the end either synchronously or asynchronously the chair group can consider all feedback and judges whether to forward the request to ECMA. So the rationale for this process is that the goal is to share to expose real needs. It's not as core to the decision making function of the committee as when we change the language or the process. ECMA processes tend to discourage voting, but they don't they also don't require this hundred percent consensus, which is each one has told us is pretty unique to TC39 and maybe related groups that came off of it. And finally, we don't have the authority to come to consensus on spending ECMA’s money, that Authority lies with the ECMA Secretariat in GA. It was already told us that even if we do come to consensus on something like need for video conferencing software, they'll probably reject that request so doesn't seem like thinking of us as consensus and making these firm decisions and even I don't see if that even makes sense. So I want to ask if people have concerns about this process for requesting services from ECMA and if people are interested in collaborating on formulating these requests.
SYG: The linchpin to me seems to be in that liaison part in relaying the request and dealing with questions judging from what Istvan said earlier in the meeting about the contingencies possibly on the typesetting request. It seems like there was at least miscommunication like producing a Word document is clearly out of the question. For what we want to do like we'd rather. I don't want to speak for the other editors, but I certainly would not want to put in any effort in producing a Word document like I would just not take ECMA’s money in that case. So what do you have in mind for who not only liaises I guess but acts as Champion for these requests at these extra meetings?
DE: Oh, short answer me. The chair group is In the in the case and I've done a bad job of this so far in the chair group in the case of typesetting is communicated to ECMA that they authorized me to help with this communication. I you know ?’s presentation was the first time that I heard from the chair group. I mean from ECMA they were making these requirements so I clearly did quite a poor job of liaising and I'll try to improve in the future. Criticism your job here. Well, you know it was I think there's there's more steps that I could take like going forward now that we have this result from the exec com know I'll start an email thread with the relevant parties and we can try to talk this over. And I certainly don't think that this deserves another six-month delay until the next execom meeting.
WH: Can you go to slide 8? Process for considering requests for services. I am not comfortable with delegating decisions on whether to request services or not to the chair group. I think this should be done by TC39.
DE: Can you say more?
WH: I just don't think this stuff should be decided by the chair. I think these should be decided by the committee.
DE: Can you say why?
WH: I'd rather not get into the reasons.
DE: Okay, it's hard for me to respond in that case. So we can just leave it at that.
WH: Can you say why this committee should not decide whether to forward these things?
DE: I have rationale written right there. I mean, I think the committee should be should be making these proposals and the decision should be based on the feedback from the committee, but I think the standard that we use for consensus for changing the language in the process is just is just different from what we need to make organizational decisions like that. The chair group doesn't ask for consensus from the committee when organizing the agenda of the meeting. And there is a strong decision making process for the budget. It happens in the exec com and the secretariat and GAl. So I don't think we need to be that very strong filter ourselves. I think we need to just you know, these are administrative things.
WH: Some of what you said is just factually incorrect. The GA is not a strong filter.
DE: Well, the secretariat’s a pretty strong filter, you know, they're saying no to things. I don't know. I think the request will be passed on unless there's enough support for it. Just like there would have to be enough support to make these administrative changes that the decisions of the Chair group makes all the time.
WH: Yeah. Anyway, I object to this proposal of its current form because I'm afraid that it will make it too easy to make requests.
DE: Okay. Well, thanks for the feedback. Any other thoughts?
AKI: It is end of day and the queue is empty.
DE: Okay. Well, thanks everyone.