diff --git a/meetings/2023-09/september-26.md b/meetings/2023-09/september-26.md index cacbb60a..2cce909b 100644 --- a/meetings/2023-09/september-26.md +++ b/meetings/2023-09/september-26.md @@ -1,11 +1,9 @@ -98th TC39 Meeting -Tuesday 26th September 2023 +# 26 September, 2023 Meeting Notes + ----- -Delegates: re-use your existing abbreviations! If you’re a new delegate and don’t already have an abbreviation, choose any three-letter combination that is not already in use, and send a PR to add it upstream. -You can find Abbreviations in delegates.txt +**Remote and in person attendees:** -**Attendees:** | Name | Abbreviation | Organization | | -------------------- | ------------ | ----------------- | | Ujjwal Sharma | USA | Igalia | @@ -39,118 +37,42 @@ You can find Abbreviations in delegates.txt | Ron Buckton | RBN | Microsoft | | Kevin Gibbson | KB | F5 | -??: If you do want to get, like, a plastic card, you can get them either at the Ginza or Ueno -stations at the ticket office. You won’t be able to get them from the machines. But you show -your passport, you’ll be able to get them at the ticket office. - -RPR: Just another starter thing, we are masking here today. Dan has spare masks with him, if you -need one. Thank you. -All right. Let’s get started. So we are in Tokyo, as Paproki said. We’ve been trying to come -here for the last four years, and fourth time lucky, here we are. So can we have a round of -applause for being in Asia? I know we’ve got some newcomers here as well today, so we really -appreciate you coming and visiting us. So, yeah, Tokyo is a wonderful city, most Michelin -starred restaurants in the world, vending machines are never far away, and there’s something -called the Disney sea, which is something you don’t get anywhere else in the world, some kind -of park. We have the chair group with us today. I’m Rob from Bloomberg, and I’m -one of the three co-chairs, along with Ujjwal and Chris here. Ujjwal and Chris will be dialing-in -remotely. I think they’re both with us at the moment. Ujjwal, I can see on the call, -hello! Chris, are you here? We have our facilitators, Brian, Justin and Yulia. I don’t think they’re with us at the moment, but they are part of the crew. Please could everyone sign in. Obviously if you’re dialing in using Zoom with your laptop, please shut off the microphone and shut off the speakers so that you -don’t interrupt the AV. We want to make sure we have a good experience for our dial-in folk. +??: If you do want to get, like, a plastic card, you can get them either at the Ginza or Ueno stations at the ticket office. You won’t be able to get them from the machines. But you show your passport, you’ll be able to get them at the ticket office. + +RPR: Just another starter thing, we are masking here today. Dan has spare masks with him, if you need one. Thank you. +All right. Let’s get started. So we are in Tokyo, as Paproki said. We’ve been trying to come here for the last four years, and fourth time lucky, here we are. So can we have a round of applause for being in Asia? I know we’ve got some newcomers here as well today, so we really appreciate you coming and visiting us. So, yeah, Tokyo is a wonderful city, most Michelin starred restaurants in the world, vending machines are never far away, and there’s something called the Disney sea, which is something you don’t get anywhere else in the world, some kind of park. We have the chair group with us today. I’m Rob from Bloomberg, and I’m one of the three co-chairs, along with Ujjwal and Chris here. Ujjwal and Chris will be dialing-in remotely. I think they’re both with us at the moment. Ujjwal, I can see on the call, +hello! Chris, are you here? We have our facilitators, Brian, Justin and Yulia. I don’t think they’re with us at the moment, but they are part of the crew. Please could everyone sign in. Obviously if you’re dialing in using Zoom with your laptop, please shut off the microphone and shut off the speakers so that you don’t interrupt the AV. We want to make sure we have a good experience for our dial-in folk. Paper sign-in form will be passed around, please sign. -RPR: We will need to arrange something to document participation in the social dinner, because we -are right at the limit for the social dinner of 24 people, so we’ll do that later. We have a -code of conduct. You can find it on the website, TC39.ES, and please, you know, we will be -enforcing that. Please read it and do your -- you know, your best efforts to follow it. If -you have any concerns, if you think there has been a violation or you want to report anything, -you can come to either one of the chairs or any of the code of conduct committee people. This -is our daily schedule. So hopefully you’ve all had some breakfast here today. This -- we’ll -also be in the room for lunch as well. That will be served promptly at 12. So we’ll try not -to overrun because the food will be very close and appetizing. We’ll have a break in the -afternoon, and then our meeting stops at 5:00 each day. It’s 4:00 on the final day, on -Thursday, and we need to vacate this room by 6 p.m. - -RPR: In terms of special events this week, hopefully anyone who arrived yesterday and you visited the -community event with JSConf Japan. That went really well. Thanks to all the people that -presented, Dan and the panelists, Nicolo, Luca, Jack Works and Kevin Gibbons. I -think that went really well. And the sushi was good. We’ll also run in newcomers event, so if -you’re new to TC39, I think we have about maybe three, maybe four people today, at the end of -today, a few of us will gather here and we’ll do some Q&A and just some easy intros. And then -we have our social dinner on Wednesday at 6:30 at what is known as the kill Bill restaurant, -the restaurant made famous for appearing into a film, and it also has good food as well. So -you can watch the film before that point. - -RPR: For our communications, we have a range of tools, and the most important thing is just to -remember for everyone that has the privilege of being in the room today, many people are -remote, and it is our duty to make sure that the remote folk have a good experience. What that -means is that we want to keep conversations linear, so we have eight microphones in the room, -so we’re going to need to be passing them around. Please turn them off when they’re not in -use, and please help out by passing them along and doing your best to get them to the speaker. -If anything is going wrong with the AV, please call us. We’re supported by a team of people -here today. I think we have -- well, we have Taka, who our events host today and has helped -arrange this meeting, and then we also have, I apologize, I don’t remember their names, but I -have been introduced yesterday. We have AV support team as well. So hopefully it should be a -great experience. - -RPR: We use TCQ as our agenda, main agenda driver, as well as also our way of list ordering -the discussions. You can find this on the reflector posting. This is the main view when we -have a topic running, and you got those buttons there if you wish to contribute to the linear -discussion. So start off with normally your default, if you want to talk about the current -presentation, it should be a new topic. That’s your go-to. If you have a reply to the -current, to someone else’s topic, you can use discuss current topic. If something is unclear -and you need an urgent clarification, please use clarifying question, and then finally, if you -need to interrupt everything because I don’t know, something has gone very, very badly wrong or -maybe the comms tools have gone down, the notes, then you use point of order. That’s the -highest priority interruption. - -RPR: Then I think, here we go, we also have the Matrix. So we have a variety of rooms there. The -delegates is your privileged one, which is normal three default during these meetings. There -is also a Temporal dead zone for anything that is off topic such as Pokmon. I know that Michael -has at least visited the main Pokmon shop here in Japan and recommended it. Yes, excellent. We -also have an IPR policy. So normally everyone here is an ECMA member. If you are not, then -you are expected to be invited expert that has signed the form or if you are none of these, -please let us know, but if you are here purely to observe, then please do not talk during the -conversations. - -RPR: The notes, so we have this, we obviously have detailed transcriptions thanks to our -transcriptionist. We have Julie. Excellent. Welcome, Julie. And so, yeah, please be -aware that these notes are being recorded. You’ll have the chance to fix them up in the Google -doc or a PR afterwards, if that’s not there. I do realize we were a little bit delayed on the -previous meetings notes and we’re trying some things with the previous meetings and we’ll work -on sorting that soon. - -RPR: Also remember as of little Dan’s presentation from the previous meeting, we’re going to try and -stop at the end of each topic to summarize the key points so that we’ve got high quality -summaries. The next meeting is back to remote. So this is at the end of November. That is on -Pacific time. That’s been on agenda, on the schedule for quite a while. We are -in the process of sorting out next year’s meeting. Thanks to everyone who has got back to me -on the schedule for that with the schedule constraints, but also with the volunteers for hosts. -We nearly have that all sorted out. Still trying to sort out an Asia meeting at the end of -next year. So if you are able to help out with that, please do let me know. I think we have -one potential candidate. We’ll find out soon. But there is a special announcement, or at -least a special meeting is coming up. Anyone that pays attention to numbers knows that this -current meeting is 98. The 98th meeting of TC39, so meaning that the next remote one will be -99. And what follows 99? We have the 100th meeting. So we’re trying to make this a bit -more special. So the 100th meeting will be in San Diego. ServiceNow have been kind -enough to host that meeting. And this one, ECMA will be helping to support this to be a strong -meeting with special celebrations. +RPR: We will need to arrange something to document participation in the social dinner, because we are right at the limit for the social dinner of 24 people, so we’ll do that later. We have a code of conduct. You can find it on the website, TC39.ES, and please, you know, we will be enforcing that. Please read it and do your -- you know, your best efforts to follow it. If you have any concerns, if you think there has been a violation or you want to report anything, +you can come to either one of the chairs or any of the code of conduct committee people. This is our daily schedule. So hopefully you’ve all had some breakfast here today. This -- we’ll also be in the room for lunch as well. That will be served promptly at 12. So we’ll try not to overrun because the food will be very close and appetizing. We’ll have a break in the afternoon, and then our meeting stops at 5:00 each day. It’s 4:00 on the final day, on Thursday, and we need to vacate this room by 6 p.m. + +RPR: In terms of special events this week, hopefully anyone who arrived yesterday and you visited the community event with JSConf Japan. That went really well. Thanks to all the people that presented, Dan and the panelists, Nicolo, Luca, Jack Works and Kevin Gibbons. I think that went really well. And the sushi was good. We’ll also run in newcomers event, so if you’re new to TC39, I think we have about maybe three, maybe four people today, at the end of today, a few of us will gather here and we’ll do some Q&A and just some easy intros. And then we have our social dinner on Wednesday at 6:30 at what is known as the kill Bill restaurant, +the restaurant made famous for appearing into a film, and it also has good food as well. So you can watch the film before that point. + +RPR: For our communications, we have a range of tools, and the most important thing is just to remember for everyone that has the privilege of being in the room today, many people are remote, and it is our duty to make sure that the remote folk have a good experience. What that means is that we want to keep conversations linear, so we have eight microphones in the room, +so we’re going to need to be passing them around. Please turn them off when they’re not in use, and please help out by passing them along and doing your best to get them to the speaker. +If anything is going wrong with the AV, please call us. We’re supported by a team of people here today. I think we have -- well, we have Taka, who our events host today and has helped arrange this meeting, and then we also have, I apologize, I don’t remember their names, but I have been introduced yesterday. We have AV support team as well. So hopefully it should be a great experience. + +RPR: We use TCQ as our agenda, main agenda driver, as well as also our way of list ordering the discussions. You can find this on the reflector posting. This is the main view when we have a topic running, and you got those buttons there if you wish to contribute to the linear discussion. So start off with normally your default, if you want to talk about the current presentation, it should be a new topic. That’s your go-to. If you have a reply to the current, to someone else’s topic, you can use discuss current topic. If something is unclear and you need an urgent clarification, please use clarifying question, and then finally, if you need to interrupt everything because I don’t know, something has gone very, very badly wrong or maybe the comms tools have gone down, the notes, then you use point of order. That’s the highest priority interruption. + +RPR: Then I think, here we go, we also have the Matrix. So we have a variety of rooms there. The delegates is your privileged one, which is normal three default during these meetings. There is also a Temporal dead zone for anything that is off topic such as Pokmon. I know that Michael has at least visited the main Pokmon shop here in Japan and recommended it. Yes, excellent. We also have an IPR policy. So normally everyone here is an ECMA member. If you are not, then you are expected to be invited expert that has signed the form or if you are none of these, +please let us know, but if you are here purely to observe, then please do not talk during the conversations. + +RPR: The notes, so we have this, we obviously have detailed transcriptions thanks to our transcriptionist. We have Julie. Excellent. Welcome, Julie. And so, yeah, please be aware that these notes are being recorded. You’ll have the chance to fix them up in the Google doc or a PR afterwards, if that’s not there. I do realize we were a little bit delayed on the previous meetings notes and we’re trying some things with the previous meetings and we’ll work on sorting that soon. + +RPR: Also remember as of little Dan’s presentation from the previous meeting, we’re going to try and stop at the end of each topic to summarize the key points so that we’ve got high quality summaries. The next meeting is back to remote. So this is at the end of November. That is on Pacific time. That’s been on agenda, on the schedule for quite a while. We are in the process of sorting out next year’s meeting. Thanks to everyone who has got back to me on the schedule for that with the schedule constraints, but also with the volunteers for hosts. +We nearly have that all sorted out. Still trying to sort out an Asia meeting at the end of next year. So if you are able to help out with that, please do let me know. I think we have one potential candidate. We’ll find out soon. But there is a special announcement, or at least a special meeting is coming up. Anyone that pays attention to numbers knows that this current meeting is 98. The 98th meeting of TC39, so meaning that the next remote one will be 99. And what follows 99? We have the 100th meeting. So we’re trying to make this a bit more special. So the 100th meeting will be in San Diego. ServiceNow have been kind enough to host that meeting. And this one, ECMA will be helping to support this to be a strong meeting with special celebrations. SHN: Nothing more than what you’ve got right now. We’re going to have a press release to recognize the work that this community has been doing, and recognize the milestone. We are going to do a few special events, but maybe I can make a few more comments on the last day of the meeting because I don’t have them all ready now. I hope to see you all there. It will be excellent. Thank you. -RPR: thanks especially to Roderigo for helping out to arrange that meeting. We can see you -in the room, Roderigo. Thank you. All right. So on to the usual items. So let’s start, -let’s see if we have approval for last -- actually, I don’t think we fully committed them yet, -so we should probably -- let’s return to that perhaps later in the meeting once we’ve got that. -All right, what about the current agenda? Are there any objections to the current agenda? And -I will say because I’m working on a laptop, I cannot see the element room right now. If any of -the other chairs do see anything, please just interrupt. I’m going to take silence as -approval. I will say with today’s current agenda, or this week’s current agenda, it is packed. -It is oversubscribed. You’ll see that we have many really good items in the overflow slot at -the moment. We’re going to work you know, we’re going to do our best to claw some back. -Maybe some people will consider deprioritizing items. I know I’ve already heard some some -candidates there that we may do. But the main thing is we need to really work hard to keep -- -to do food time keeping and stick to our time boxes. And with that, I think I can hand over to -Samina. +RPR: thanks especially to Roderigo for helping out to arrange that meeting. We can see you in the room, Roderigo. Thank you. All right. So on to the usual items. So let’s start, +let’s see if we have approval for last -- actually, I don’t think we fully committed them yet, +so we should probably -- let’s return to that perhaps later in the meeting once we’ve got that. +All right, what about the current agenda? Are there any objections to the current agenda? And I will say because I’m working on a laptop, I cannot see the element room right now. If any of the other chairs do see anything, please just interrupt. I’m going to take silence as approval. I will say with today’s current agenda, or this week’s current agenda, it is packed. +It is oversubscribed. You’ll see that we have many really good items in the overflow slot at the moment. We’re going to work you know, we’re going to do our best to claw some back. +Maybe some people will consider deprioritizing items. I know I’ve already heard some some candidates there that we may do. But the main thing is we need to really work hard to keep -- +to do food time keeping and stick to our time boxes. And with that, I think I can hand over to Samina. RPR: Rob, a point of order. @@ -158,346 +80,172 @@ RPR: Yes, go ahead, Michael. MF: The notes don’t have a place to put our name, abbreviation and organization. -RPR: All right, thank you. I will ask, I think Chris or Ujjwal, if you’re on the -line, please could you fix that up so people can put their name. +RPR: All right, thank you. I will ask, I think Chris or Ujjwal, if you’re on the line, please could you fix that up so people can put their name. USA: Yeah, on it. -RPR: Thank you. Yes, Samina, please do share your screen. Everyone here, it’s best to use your -own laptops when you are presenting to share from there. You are also welcome to use to podium -if you want, your slides are Internet accessible. +RPR: Thank you. Yes, Samina, please do share your screen. Everyone here, it’s best to use your own laptops when you are presenting to share from there. You are also welcome to use to podium if you want, your slides are Internet accessible. ## Secretary general report Speaker: Samina Husain + - [slides](https://github.com/tc39/agendas/blob/main/2023/tc39-2023-040.pdf) -SHN: Welcome everybody to Tokyo. Excellent meeting. Beautifully set up. Thank you very much -Bloomberg for hosting. For those who don’t know me, I am Samina from ECMA, as noted -on the slide. Istvan is online in Munich. Istvan, welcome. I know it’s very early in the -morning for you. If you’d like to make a comment, just raise your hand. I’ll start with the -slides. As usual, we give an update from the secretariat from the office. I want to give you -a summary on the experiences from the summary and conclusions and the technical notes which Rob -just mentioned has not been, if I can use the word finalize. I think it’s important we talk -about that whether it’s some point in the meeting or just after this, will you direct me on -that. I’ll just give some comments on the invited experts and where we are. I want to also -note that we have our nominations for 2024 that are open and everybody in ECMA can nominate, so -I just want to bring that to your attention. Just a status on the nice PDF that you know we -need to do this for our ECMA standard. We have a proposal on the table. I’d like to show that -to everybody and see you’re interested in that or think if it’s a good way forward and -just some other updates generally from the activities. The Annex of the slides will give you, -as always, a list of the documents. If you would like to read them from the general assembly, -just our statistics and how we are participating, the key message from that is the numbers of -participants and the number of organizations continue to grow or if not just stay stable post -pandemic, which is really good. The standards download, you can have a look at that. Since -the June general assembly, the 14th edition was approved. You can see that there are already a number of downloads on that, and there are the next meetings highlighted. But the most -relevant one Rob mentioned, which is the 100th. Since we had our last meeting in July in Bergen, I did attempt to take the work and do the summary and conclusions on spaces that didn’t have it. It was a bit challenging, and did not happen very timely. So I’m looking for some advice on how we can do that better. -It’s relevant for ECMA because we need it in our meeting and we have to have that -documented for all the work that’s being done, so I still think we need to find a slightly -better way forward. In addition, we also published the presentations that everybody does, in a -zip file, so we have a record of what’s been happening at each meeting. My first -recommendation on the summary and conclusion we should do it at the meeting. While we are -here, if we can take a few minutes after and put it down together and come the agreement, that -would be good for the members who are participating to see what’s been discussed and agree on -it and the next steps. If we could do that, that would be great. We do manage to do it quite well, 80%, maybe if we can get that to be a little bit more, I’d appreciate that. And -then it may help us be more timely in the finalization of the technical notes. - -SHN: I’ll be open for your feedback on that. If you’d like to make after I finish just a few -slides. Regarding the invited experts, we have a number of new invited experts. Thank you for -coming in. I think it’s really relevant. Some of the invited experts of course represent an -organization, they’ll be working on TG4. And some of them will consider joining. I hope all -of them will consider joining as new members. I have put in an expiry date, so to say on the -invited expert, it’s to the end of the year, my intention is that we manage it administratively, and I’m doing that for now. I do hope in 2024 some of the 2023 members will become members of ECMA, and for those who haven’t, we can renew based on the needs of the technical committee. - -SHN: The nominations as I mentioned, so the nominations are open. Any ECMA member and all of you -who represent a member can nominate a candidate. We are looking for nomination for the -president, vice-president, treasurer and looking for members from the ordinary members to be -part of the ExeCom. In order to do this, if you have ideas, for example, currently Daniel is -our vice-president, Daniel can run for another term. If you would like to nominate a different -candidate, do so. If you want to nominate Daniel, please do so. There are some deadlines that -need to be managed. So if you can give me any input by the 13th of October, that would be -great. Then we put the slate available to everybody and then it’s finally voted on as the -general assembly. And this is done every year. So now coming to the PDF. And the relevance of -the PDF, so we have discussed on many meetings that the -- that the PDF version of the standard -is relevant because it is the document that we have stored. It is historic. We keep it. It -also has the highest downloads still. We talked about doing -- what we could do. This slide -is a repeat. I think you know that -- what’s already going on with ECMA 262 and the markup and -where we’re at. It’s the PDF format that we need to find a solution to, and as I mentioned, it -is quite downloaded. It’s 30 to 40K per year on its download. - -SHN: The proposal that we want to make, and I had a conversation with Allen and with Istvan, and -Allen has been supporting us of course in the previous version, and he will not be available in -2024. And what we’d like to do is propose it to Bergen university. And many of you were at -Bergen and you know they were very interested and they have a very active group within their -faculty that is involved in language standards, and I’d like to proposal to the professor there -and Mikhail, who is now an associate professor in that same group, to see if there is a master’s -student or senior student who may take this on as a student project. We may support them in -it, but it would be interesting to see if this was an interest to them. I would like your -feedback from this team if you think that could be a good idea. Just from my initial -experiences, they may have the right skills. I know that Phillip, who is not here today, but -is involved in your test requirement, I don’t know if Philip is online, he may be reaching out -to Bergen university also to do some work in that space. So it could be an option. - -SHN: In order to do it, definitely it has to be a student that is interested. There would be some -support needed from Bergen university to just manage that student. But also from maybe -- -maybe somebody from this committee who is an expert on it to give them some guidance as they -begin their work. It can also be something that -- which they do -- you know, they can get -some recognition for it. It’s something that we can take on afterwards, and of course, I would -also be willing to see how we could sponsor a student to support them in doing this work and -how we could continue to use this solution if one comes to do the PDF document. So that’s on -the document side. - -SHN: So, again, any comments on that, please bring it up. I just wanted to give an update on the -JTC1. Every five years we vote on the fast track. The voting ended September 3rd. The -results are still pending. They should be out soon, maybe by the next meeting I’ll be able to -give an update. We assume it’s positive, but we still haven’t got to final results. Some -other projects and new items taking place in the secretariat. We have a new membership -interest in OWASP. They’re an interesting organization. There’s also a conversation ongoing -right now with the project Cyclone DX, which some of you again are already familiar with. -There are a number of ECMA members already active. That one of the discussion we’re having -right now it is potentially that project comes into ECMA as a technical committee. And we’ll -have a discussion on it next week with the executive committee back in Geneva. I also just wanted -to give a short update on W3C. Two weeks ago in Saville, WC3 had its TPAC meeting, and Dan -and I the a presentation there in one of the breakout sessions which was about collaboration -between WC3 and ECMA. I think that was also quite positive. There were a couple of you from this meeting that were present on that call and at the meeting. I think it was a good opening -conversation to remind W3C about ECMA if they didn’t know about ECMA, the work we are doing, -the value we can bring and really show a strong reference with TC39, so I want to thank Dan for -that presentation. We had lots of questions and we’re going to move forward with seeing what -we can discuss with them. So that’s an ongoing conversation. - -SHN: There will be more. We have an executive meeting and do some brainstorming and some strategy -discussions on ECMA and how we can bring in some new projects. - -SHN: I want to comment on Evernotes. Which was acquired by bending spoons, which is an Italian-based organization. I have lost all contact, so this is a call for help. If anybody here or in this organization can help me in finding a name at bending spoons that I can get in touch with, I would appreciate that -greatly. They are still members. Just want to get to know them and as lots has changed in their -staff, in the US is no more or the ones that we knew are no longer involved in the -organization. - -SHN: I think that may be the end of my main slides. It is, and I’m going to stop -there for any questions. - -DE: I want to emphasize the summary and the slide archives are very useful for the -committee. We’ve repeatedly gotten feedback from the committee members or following TC39’s -they would like to see summaries if this was only useful for ECMA, I don’t think you could -expect that this committee would do much work on it. I think it’s useful for ourselves, our -audience, and I really encourage people to write summaries and work that goes into writing -summaries and doing archives I hope is made visible by putting that in our GitHub. For the -PDF, I agree that this is useful. And I want repeat the suggestion that the committee has made to -ECMA leadership that we pay someone to do this work rather than asking for a student volunteer. -Allen’s suggestions have been received in the past. I think Kevin would have more -understanding of the details of that. - -KG: I’m definitely open to having external contributors help with this. Especially if we -can hire someone to do things. This is the first time I’ve seen Allen’s slides and his -detailed write-up of the actual process that he went there, so I’m going to need some time to -go through that and see to what extent we can easily automate, and I think we will need to do -before we can meaningfully talk about what additional work is to be done. Because he has -written up this nice, you know, 20 pages or whatever of what the process is. And previously, I -hadn’t known exactly what process he was following, so give us some time, basically. - -SHN: Thanks, Kevin. Just to point out, the two reference documents are added to the agenda. Ones -Kevin is referring, I appreciate that, Allen and I had a conversation last week and he -reminded me of the documents, and I think they may have been sent -- they may have been on the -agenda previously. Have a look at that and give me some feedback, then we can -figure out how best to approach Bergen university based on some of the feedback that you bring. +SHN: Welcome everybody to Tokyo. Excellent meeting. Beautifully set up. Thank you very much Bloomberg for hosting. For those who don’t know me, I am Samina from ECMA, as noted on the slide. Istvan is online in Munich. Istvan, welcome. I know it’s very early in the morning for you. If you’d like to make a comment, just raise your hand. I’ll start with the slides. As usual, we give an update from the secretariat from the office. I want to give you a summary on the experiences from the summary and conclusions and the technical notes which Rob just mentioned has not been, if I can use the word finalize. I think it’s important we talk about that whether it’s some point in the meeting or just after this, will you direct me on that. I’ll just give some comments on the invited experts and where we are. I want to also note that we have our nominations for 2024 that are open and everybody in ECMA can nominate, so I just want to bring that to your attention. Just a status on the nice PDF that you know we need to do this for our ECMA standard. We have a proposal on the table. I’d like to show that to everybody and see you’re interested in that or think if it’s a good way forward and just some other updates generally from the activities. The Annex of the slides will give you, +as always, a list of the documents. If you would like to read them from the general assembly, +just our statistics and how we are participating, the key message from that is the numbers of participants and the number of organizations continue to grow or if not just stay stable post pandemic, which is really good. The standards download, you can have a look at that. Since the June general assembly, the 14th edition was approved. You can see that there are already a number of downloads on that, and there are the next meetings highlighted. But the most relevant one Rob mentioned, which is the 100th. Since we had our last meeting in July in Bergen, I did attempt to take the work and do the summary and conclusions on spaces that didn’t have it. It was a bit challenging, and did not happen very timely. So I’m looking for some advice on how we can do that better. +It’s relevant for ECMA because we need it in our meeting and we have to have that documented for all the work that’s being done, so I still think we need to find a slightly better way forward. In addition, we also published the presentations that everybody does, in a zip file, so we have a record of what’s been happening at each meeting. My first recommendation on the summary and conclusion we should do it at the meeting. While we are here, if we can take a few minutes after and put it down together and come the agreement, that would be good for the members who are participating to see what’s been discussed and agree on it and the next steps. If we could do that, that would be great. We do manage to do it quite well, 80%, maybe if we can get that to be a little bit more, I’d appreciate that. And then it may help us be more timely in the finalization of the technical notes. + +SHN: I’ll be open for your feedback on that. If you’d like to make after I finish just a few slides. Regarding the invited experts, we have a number of new invited experts. Thank you for coming in. I think it’s really relevant. Some of the invited experts of course represent an organization, they’ll be working on TG4. And some of them will consider joining. I hope all of them will consider joining as new members. I have put in an expiry date, so to say on the invited expert, it’s to the end of the year, my intention is that we manage it administratively, and I’m doing that for now. I do hope in 2024 some of the 2023 members will become members of ECMA, and for those who haven’t, we can renew based on the needs of the technical committee. + +SHN: The nominations as I mentioned, so the nominations are open. Any ECMA member and all of you who represent a member can nominate a candidate. We are looking for nomination for the president, vice-president, treasurer and looking for members from the ordinary members to be part of the ExeCom. In order to do this, if you have ideas, for example, currently Daniel is our vice-president, Daniel can run for another term. If you would like to nominate a different candidate, do so. If you want to nominate Daniel, please do so. There are some deadlines that need to be managed. So if you can give me any input by the 13th of October, that would be great. Then we put the slate available to everybody and then it’s finally voted on as the general assembly. And this is done every year. So now coming to the PDF. And the relevance of the PDF, so we have discussed on many meetings that the -- that the PDF version of the standard is relevant because it is the document that we have stored. It is historic. We keep it. It also has the highest downloads still. We talked about doing -- what we could do. This slide is a repeat. I think you know that -- what’s already going on with ECMA 262 and the markup and where we’re at. It’s the PDF format that we need to find a solution to, and as I mentioned, it is quite downloaded. It’s 30 to 40K per year on its download. + +SHN: The proposal that we want to make, and I had a conversation with Allen and with Istvan, and Allen has been supporting us of course in the previous version, and he will not be available in 2024. And what we’d like to do is propose it to Bergen university. And many of you were at Bergen and you know they were very interested and they have a very active group within their faculty that is involved in language standards, and I’d like to proposal to the professor there and Mikhail, who is now an associate professor in that same group, to see if there is a master’s student or senior student who may take this on as a student project. We may support them in it, but it would be interesting to see if this was an interest to them. I would like your feedback from this team if you think that could be a good idea. Just from my initial experiences, they may have the right skills. I know that Phillip, who is not here today, but is involved in your test requirement, I don’t know if Philip is online, he may be reaching out to Bergen university also to do some work in that space. So it could be an option. + +SHN: In order to do it, definitely it has to be a student that is interested. There would be some support needed from Bergen university to just manage that student. But also from maybe -- +maybe somebody from this committee who is an expert on it to give them some guidance as they begin their work. It can also be something that -- which they do -- you know, they can get some recognition for it. It’s something that we can take on afterwards, and of course, I would also be willing to see how we could sponsor a student to support them in doing this work and how we could continue to use this solution if one comes to do the PDF document. So that’s on the document side. + +SHN: So, again, any comments on that, please bring it up. I just wanted to give an update on the JTC1. Every five years we vote on the fast track. The voting ended September 3rd. The results are still pending. They should be out soon, maybe by the next meeting I’ll be able to give an update. We assume it’s positive, but we still haven’t got to final results. Some other projects and new items taking place in the secretariat. We have a new membership interest in OWASP. They’re an interesting organization. There’s also a conversation ongoing right now with the project Cyclone DX, which some of you again are already familiar with. +There are a number of ECMA members already active. That one of the discussion we’re having right now it is potentially that project comes into ECMA as a technical committee. And we’ll have a discussion on it next week with the executive committee back in Geneva. I also just wanted to give a short update on W3C. Two weeks ago in Saville, WC3 had its TPAC meeting, and Dan and I the a presentation there in one of the breakout sessions which was about collaboration between WC3 and ECMA. I think that was also quite positive. There were a couple of you from this meeting that were present on that call and at the meeting. I think it was a good opening conversation to remind W3C about ECMA if they didn’t know about ECMA, the work we are doing, +the value we can bring and really show a strong reference with TC39, so I want to thank Dan for that presentation. We had lots of questions and we’re going to move forward with seeing what we can discuss with them. So that’s an ongoing conversation. + +SHN: There will be more. We have an executive meeting and do some brainstorming and some strategy discussions on ECMA and how we can bring in some new projects. + +SHN: I want to comment on Evernotes. Which was acquired by bending spoons, which is an Italian-based organization. I have lost all contact, so this is a call for help. If anybody here or in this organization can help me in finding a name at bending spoons that I can get in touch with, I would appreciate that greatly. They are still members. Just want to get to know them and as lots has changed in their staff, in the US is no more or the ones that we knew are no longer involved in the organization. + +SHN: I think that may be the end of my main slides. It is, and I’m going to stop there for any questions. + +DE: I want to emphasize the summary and the slide archives are very useful for the committee. We’ve repeatedly gotten feedback from the committee members or following TC39’s they would like to see summaries if this was only useful for ECMA, I don’t think you could expect that this committee would do much work on it. I think it’s useful for ourselves, our audience, and I really encourage people to write summaries and work that goes into writing summaries and doing archives I hope is made visible by putting that in our GitHub. For the PDF, I agree that this is useful. And I want repeat the suggestion that the committee has made to ECMA leadership that we pay someone to do this work rather than asking for a student volunteer. +Allen’s suggestions have been received in the past. I think Kevin would have more understanding of the details of that. + +KG: I’m definitely open to having external contributors help with this. Especially if we can hire someone to do things. This is the first time I’ve seen Allen’s slides and his detailed write-up of the actual process that he went there, so I’m going to need some time to go through that and see to what extent we can easily automate, and I think we will need to do before we can meaningfully talk about what additional work is to be done. Because he has written up this nice, you know, 20 pages or whatever of what the process is. And previously, I hadn’t known exactly what process he was following, so give us some time, basically. + +SHN: Thanks, Kevin. Just to point out, the two reference documents are added to the agenda. Ones Kevin is referring, I appreciate that, Allen and I had a conversation last week and he reminded me of the documents, and I think they may have been sent -- they may have been on the agenda previously. Have a look at that and give me some feedback, then we can figure out how best to approach Bergen university based on some of the feedback that you bring. Thanks, Dan, for your clarification on your added comments on the summary and the conclusions. -As I mentioned in the annex, I will leave you to read it. There are documents that are listed on -the GA if you want to know further about what’s been going on with the TC39 meetings. That’s -all the documents we have in our repository. This is the number of participants. As I say, -it’s just nice to look at. We haven’t decreased our participation. In some ways, I think we -remain quite strong. So that’s good. Just the downloads that we’ve been having on the top -documents, I just wanted to bring that highlight. I think what’s interesting here is -the last version that was just approved, 14. Same here, the last version that were just -approved and you already see the downloads on that. +As I mentioned in the annex, I will leave you to read it. There are documents that are listed on the GA if you want to know further about what’s been going on with the TC39 meetings. That’s all the documents we have in our repository. This is the number of participants. As I say, +it’s just nice to look at. We haven’t decreased our participation. In some ways, I think we remain quite strong. So that’s good. Just the downloads that we’ve been having on the top documents, I just wanted to bring that highlight. I think what’s interesting here is the last version that was just approved, 14. Same here, the last version that were just approved and you already see the downloads on that. I will stop my presentation here. I will leave you to read the rest of the documents. Are there any other questions? ### Summary -Ecma/TC39/2023/040 Report from the TC39 Secretariat, September 2023 was presented and provided the following highlights and information from Ecma: + +Ecma/TC39/2023/040 Report from the TC39 Secretariat, September 2023 was presented and provided the following highlights and information from Ecma: The slides were reviewed, and suggested to read the documents of interest as noted in the Annex. Status and the working process with TC39 technical notes, its “summary and conclusions” and the ES2023 «Nice PDF» versions were discussed, and the relevance of each of these documents for Ecma and TC39 was emphasized. The Invited Experts (IE) status was shortly reviewed, at this time the IE list is beginning to be managed by both Ecma secretariat and TC39 on GitHub. -2024 Nominations deadline for Ecma GA and Management was reminded to all, if they wish to make nomination. Also TC Chairs and TG Chairs need to be nominated and final candidates agreed by the TC39 committee for 2024. +2024 Nominations deadline for Ecma GA and Management was reminded to all, if they wish to make nomination. Also TC Chairs and TG Chairs need to be nominated and final candidates agreed by the TC39 committee for 2024. Potential new projects such as Cyclone DX were mentioned, the OWASP membership application, and in addition ongoing discussions with W3C and LF were noted. -A list of the latest Ecma TC39 and GA documents was shared. Status of the TC39 meeting participation was reviewed, it is positive to note that meeting participation remains high in numbers and participants and representing organizations remain active. - - ECMA-262 ECMAScript Language Specification - - ECMA-404 The JSON Data Interchange Format - - ECMA-419 ECMAScript® embedded systems API +A list of the latest Ecma TC39 and GA documents was shared. Status of the TC39 meeting participation was reviewed, it is positive to note that meeting participation remains high in numbers and participants and representing organizations remain active. + +- ECMA-262 ECMAScript Language Specification +- ECMA-404 The JSON Data Interchange Format +- ECMA-419 ECMAScript® embedded systems API As noted above, the download and access statistics remain high, the newly approved versions already show continued interest with the standards documents. -The next TC39, GA and ExeCom meeting date were noted. It was highlighted that the 100th EcmaScript TC39 meeting is upcoming in February 2024, the first in-person meeting in 2024, to be hosted by ServiceNow in the US. There will be celebratory activities to recognize this important milestone for the committee. -There was a call for help: for any contacts regarding Evernote, acquired by Bending Spoons. We want the participation from Bending Spoons to continue. +The next TC39, GA and ExeCom meeting date were noted. It was highlighted that the 100th EcmaScript TC39 meeting is upcoming in February 2024, the first in-person meeting in 2024, to be hosted by ServiceNow in the US. There will be celebratory activities to recognize this important milestone for the committee. +There was a call for help: for any contacts regarding Evernote, acquired by Bending Spoons. We want the participation from Bending Spoons to continue. + ### Conclusion -Regarding the process suggestions for achieving a PDF version, it was agreed that Kevin Gibbson will review the documents from Allen Wirfs-Brock, as provided in the agenda. Kevin will provide feedback on the suggested process and possibly a way forward. Samina will follow up with Kevin. + +Regarding the process suggestions for achieving a PDF version, it was agreed that Kevin Gibbson will review the documents from Allen Wirfs-Brock, as provided in the agenda. Kevin will provide feedback on the suggested process and possibly a way forward. Samina will follow up with Kevin. An alternate option discussed for the PDF version process could be a university project, but was not considered an ideal solution. -With respect to the TC39 technical/meeting notes, Samina will discuss with Rob Palmer and Daniel Ehrenberg on the process which can be managed better. Samina will work with Ashley Claymore to better understand. +With respect to the TC39 technical/meeting notes, Samina will discuss with Rob Palmer and Daniel Ehrenberg on the process which can be managed better. Samina will work with Ashley Claymore to better understand. -RPR: Nothing on the queue. I think we’re good. Thank you, Samina. +RPR: Nothing on the queue. I think we’re good. Thank you, Samina. -# ECMA262 Project Editors’ Reports +## ECMA262 Project Editors’ Reports Presenters: Kevin Gibbons and Michael Ficcara -[slides](https://docs.google.com/presentation/d/14EMR7dyp5Fe7bZITKNP9upeV4OGo-wwtzWbPsC4cvk0/edit#slide=id.gc6f73a04f_0_0) +KG: Editor’s update, this will be pretty brief because not too much has happened. We have made a couple of editorial changes. The first is a general cleanup and refactoring of the date/time related abstract operations, which were always kind of idiosyncratic and are now significantly more consistent with respect. Someone, I’m now forgetting who, pointed out after the fact that given that Temporal is currently in flight and massive, we should probably avoid further churn, so we’re not going to do any more cleanup in that area for the moment. But this is landed. + +KG: Also we renamed the RegExp parameter N to NamedCaptureGroups. This makes the grammar slightly more verbose, but if you are new to it, it is hopefully more informative. If you’re familiar with the previous notation and wondering where the parameter went, that’s where it went. And then we’ve made a number of improvements to ecmarkup. Some of these are breaking changes you can view on GitHub if you are interested. This probably doesn’t affect you unless you are maintaining a proposal and need to change your build script, except for the most dramatic change is that we have a new font. Michael, do you want to talk about this? + +MF: We just made a number of editorial changes to improve accessibility generally. The font is more readable, all the contrast is, like, triple A. You can see the references pane down there is resizable for you to see as many or few as you want. When you click internal links in the document, it highlights the targeted term that it’s being linked to. And possibly a few more. But anyway, we’ve been spending a decent amount of time focusing on user experience improvements to the spec since the last meeting. -KG: Editor’s update, this will be pretty brief because not too much has happened. We have made a -couple of editorial changes. The first is a general cleanup and refactoring of the date/time -related abstract operations, which were always kind of idiosyncratic and are now significantly -more consistent with respect. Someone, I’m now forgetting who, pointed out after the fact -that given that Temporal is currently in flight and massive, we should probably avoid further -churn, so we’re not going to do any more cleanup in that area for the moment. But this is landed. - -KG: Also we renamed the RegExp parameter N to NamedCaptureGroups. This makes the grammar -slightly more verbose, but if you are new to it, it is hopefully more informative. If you’re -familiar with the previous notation and wondering where the parameter went, that’s where it -went. And then we’ve made a number of improvements to ecmarkup. Some of these -are breaking changes you can view on GitHub if you are interested. This probably doesn’t affect -you unless you are maintaining a proposal and need to change your build script, except for the -most dramatic change is that we have a new font. Michael, do you want to talk about this? - -MF: We just made a number of editorial changes to improve accessibility generally. The font is -more readable, all the contrast is, like, triple A. You can see the references pane -down there is resizable for you to see as many or few as you want. When you click internal -links in the document, it highlights the targeted term that it’s being linked to. And possibly -a few more. But anyway, we’ve been spending a decent amount of time focusing on user -experience improvements to the spec since the last meeting. - -KG: And please direct all complaints about the font to Michael. Give it a chance to adapt -to the new font. I know it’s always jarring when things change out from under you, but it -should hopefully be pretty easy to get used to and is visibly better in some ways, especially -around the digit zero is clearly distinguished from the letter capital O now and that sort of -thing. Other than that, I haven't landed any normative changes. We’ve all been slacking, I -guess. Fortunately there’s some coming up at that meeting, and we still have basically the -same backlog that we’ve always had. But getting closer to churning through some of this. +KG: And please direct all complaints about the font to Michael. Give it a chance to adapt to the new font. I know it’s always jarring when things change out from under you, but it should hopefully be pretty easy to get used to and is visibly better in some ways, especially around the digit zero is clearly distinguished from the letter capital O now and that sort of thing. Other than that, I haven't landed any normative changes. We’ve all been slacking, I guess. Fortunately there’s some coming up at that meeting, and we still have basically the same backlog that we’ve always had. But getting closer to churning through some of this. That’s all. ## ECMA-402 update -Presenter: Richard Gibson - -RGN: So for the most part, since the last meeting, things have been editorial. The few normative changes that have gone in are for aligning better with ECMA-262 in terms of the minimum and maximum fractional -digits in formatting, now allow up to 100 rather than capping it arbitrarily at 20. We also put in -display names v2 and reordered the order of some observable property reading and outputting. And that’s going to be a common theme over the next year as well. The editorial changes are, again, about consistency. We’ve done a whole lot of alignment with ECMA262 as well as with the various Unicode documents and to some extent with IANA. So things like structured headers are about to come in and refactoring some algorithms to better match Unicode technical reports. We’ve also got just general spec consistency, and we’ve updated ecmarkup to match 262 as well. So as I mentioned, the things that are coming in soon are adoption of structured headers. We’ve also got some new named record types, also like 262. And some good changes around how to describe locale matching, where there are two different -algorithms and both of them are actually defined in external documents, but we’re adopting the -algorithms from that and just putting it in by reference as well as a copy for anyone who is -newly implementing any of the ECMA402 functionality. So the common theme really is just around -a holding pattern at this point. There hasn’t been a lot between the previous -meeting and this one. But we are continuing to bring everything in line so that it looks and -feels more like 262, more like a single specification that just happens to be split over two -separate documents. Open for questions. - -KG: No questions, but thanks so much for getting Ecmarkup updated. I know we’ve had a number of -breaking changes, but the integration is very nice now, so thank you. + +Presenter: Richard Gibson + +RGN: So for the most part, since the last meeting, things have been editorial. The few normative changes that have gone in are for aligning better with ECMA-262 in terms of the minimum and maximum fractional digits in formatting, now allow up to 100 rather than capping it arbitrarily at 20. We also put in display names v2 and reordered the order of some observable property reading and outputting. And that’s going to be a common theme over the next year as well. The editorial changes are, again, about consistency. We’ve done a whole lot of alignment with ECMA262 as well as with the various Unicode documents and to some extent with IANA. So things like structured headers are about to come in and refactoring some algorithms to better match Unicode technical reports. We’ve also got just general spec consistency, and we’ve updated ecmarkup to match 262 as well. So as I mentioned, the things that are coming in soon are adoption of structured headers. We’ve also got some new named record types, also like 262. And some good changes around how to describe locale matching, where there are two different algorithms and both of them are actually defined in external documents, but we’re adopting the algorithms from that and just putting it in by reference as well as a copy for anyone who is newly implementing any of the ECMA402 functionality. So the common theme really is just around a holding pattern at this point. There hasn’t been a lot between the previous meeting and this one. But we are continuing to bring everything in line so that it looks and feels more like 262, more like a single specification that just happens to be split over two separate documents. Open for questions. + +KG: No questions, but thanks so much for getting Ecmarkup updated. I know we’ve had a number of breaking changes, but the integration is very nice now, so thank you. RGN: Thank you as well. ### Summary - ### Conclusion - ## ECMA-404 update + Presenter: Chip Morningstar -CM: Well, I was trying to think of something surprising to say, but all I can say is none of you -are surprised. So the usual status. Everything is stable. Everything is copacetic. +CM: Well, I was trying to think of something surprising to say, but all I can say is none of you are surprised. So the usual status. Everything is stable. Everything is copacetic. ## Test262 update -Presenter: Jordan Harband +Presenter: Jordan Harband -JHD: There’s not much to report. We’ve been merging PRs. There’s still a long list of PRs to -review, so sorry you’re waiting on them, apologies. Feel free to ping for those. And as always, -anyone who is interested in helping review those PRs and help maintain test262, you’re more -than welcome. Thank you. +JHD: There’s not much to report. We’ve been merging PRs. There’s still a long list of PRs to review, so sorry you’re waiting on them, apologies. Feel free to ping for those. And as always, +anyone who is interested in helping review those PRs and help maintain test262, you’re more than welcome. Thank you. ## TC39-TG3 status report + Presenter: Michael Ficcara -[slides](https://docs.google.com/presentation/d/1FSukmXtkL0rXqkmgScidr7tZzP9jagxxIyHQllxGWSY/edit#slide=id.p) -MF: TG3 has been meeting now. That is a significant update for sure. We had a hiatus after our chair had left for, I’m not sure, the better part of a year, probably. But we now have two new chairs, and we have two meetings per month. One is supposed to be friendly for US and APAC and the other is supposed to be friendly for EMEA. Initially we’ve been doing a lot of focus on creating our backlog of items we want to work on. We had already previously had a long backlog. We’re going through it to make sure everything still is what we want to do. And we started prioritizing work on our vulnerability reporting policy. -So I’ll talk about that a bit today. As a reminder, in the TG3 charter, we explicitly -mention a need for this group to handle vulnerability disclosures. Currently, we don’t have a -vulnerability reporting policy. We can accept vulnerability reports, but we should have a plan -for how to handle them. So after discussion, we have some outcomes from that, and we’d like to -run it by TG1. +MF: TG3 has been meeting now. That is a significant update for sure. We had a hiatus after our chair had left for, I’m not sure, the better part of a year, probably. But we now have two new chairs, and we have two meetings per month. One is supposed to be friendly for US and APAC and the other is supposed to be friendly for EMEA. Initially we’ve been doing a lot of focus on creating our backlog of items we want to work on. We had already previously had a long backlog. We’re going through it to make sure everything still is what we want to do. And we started prioritizing work on our vulnerability reporting policy. +So I’ll talk about that a bit today. As a reminder, in the TG3 charter, we explicitly mention a need for this group to handle vulnerability disclosures. Currently, we don’t have a vulnerability reporting policy. We can accept vulnerability reports, but we should have a plan for how to handle them. So after discussion, we have some outcomes from that, and we’d like to run it by TG1. -MF: The first recommendation is that we have a TG3 repo under TC39. We would like to make that public and use the GitHub vulnerability disclosure feature to allow people to report vulnerabilities. The way that would work is that the individuals who initially receive vulnerability reports will be just the TG3 chairs and the admin. The reason why we made this decision is because we wanted to limit the exposure of the vulnerability reports to as few people as necessary. Of course, when that report is received, that small group will expand that group to include anyone who is needed to help respond to that. +MF: The first recommendation is that we have a TG3 repo under TC39. We would like to make that public and use the GitHub vulnerability disclosure feature to allow people to report vulnerabilities. The way that would work is that the individuals who initially receive vulnerability reports will be just the TG3 chairs and the admin. The reason why we made this decision is because we wanted to limit the exposure of the vulnerability reports to as few people as necessary. Of course, when that report is received, that small group will expand that group to include anyone who is needed to help respond to that. -MF: The other thing we wanted to get approval from TG1 on is maintaining a list of contacts for reporting engine vulnerabilities when, you know, vulnerabilities are reported in the wrong place. So if something that is specific to an engine is reported to this group. Instead, we would like a way to quickly direct them to the right contact, or the right location. So we have a draft policy here. This draft policy basically just tells the reporter to either report directly to this email address or use the GitHub vulnerability reporting process that we discussed earlier, and, if it is engine-specific, then we give some links to the vulnerability reporting processes for specific engines, because it is likely that they are making that mistake, so we tried to give them some helpful guidance there. We do note, though, however, it’s not going to be an exhaustive list of every single possible implementation. Just the most likely ones that they’ll actually need when they’re going through this process. And this is just a duplicate of that. -And that’s it. That’s the whole update. So do we have consensus on those things that I asked? +MF: The other thing we wanted to get approval from TG1 on is maintaining a list of contacts for reporting engine vulnerabilities when, you know, vulnerabilities are reported in the wrong place. So if something that is specific to an engine is reported to this group. Instead, we would like a way to quickly direct them to the right contact, or the right location. So we have a draft policy here. This draft policy basically just tells the reporter to either report directly to this email address or use the GitHub vulnerability reporting process that we discussed earlier, and, if it is engine-specific, then we give some links to the vulnerability reporting processes for specific engines, because it is likely that they are making that mistake, so we tried to give them some helpful guidance there. We do note, though, however, it’s not going to be an exhaustive list of every single possible implementation. Just the most likely ones that they’ll actually need when they’re going through this process. And this is just a duplicate of that. +And that’s it. That’s the whole update. So do we have consensus on those things that I asked? I can go over them again if needed. -SYG: I want to better understand what the definition of vulnerability is in this sense. Because -you said the status quo is that we accept vulnerability reports as TC39. I don’t know what that -means. - -MF: So it is not necessary to define what we consider to be a vulnerability. That is an -interesting process that we should go through in TG3 at a later date. But we do not get to -control. The point of this process is not to determine whether a thing reported to us is or -is not a vulnerability. That would depend on us defining security properties that we would be -able to determine have been violated. We’ve not gone through that process yet. This is just a -way to accept those reports. - -SYG: Okay, so concrete question, suppose somebody is reporting, let me try the phrase -this better. Other than redirecting the reporter to a particular project where it may be or -may not be a vulnerability, what other, is that the universe of all report, it gets -bucketed into some projects vulnerability and then you redirect them to report to that project, -or are there other reports that somehow we take as committee and say this is, like, in 262? +SYG: I want to better understand what the definition of vulnerability is in this sense. Because you said the status quo is that we accept vulnerability reports as TC39. I don’t know what that means. + +MF: So it is not necessary to define what we consider to be a vulnerability. That is an interesting process that we should go through in TG3 at a later date. But we do not get to control. The point of this process is not to determine whether a thing reported to us is or is not a vulnerability. That would depend on us defining security properties that we would be able to determine have been violated. We’ve not gone through that process yet. This is just a way to accept those reports. + +SYG: Okay, so concrete question, suppose somebody is reporting, let me try the phrase this better. Other than redirecting the reporter to a particular project where it may be or may not be a vulnerability, what other, is that the universe of all report, it gets bucketed into some projects vulnerability and then you redirect them to report to that project, +or are there other reports that somehow we take as committee and say this is, like, in 262? Because I don’t know what that latter part means, if that exists? -MF: The latter thing. When reports are mistakenly given through this process and they are -engine specific, we want them to be redirected either through themselves being redirected when -reading this process or if they still send it to us, getting back to them, or going through -the security focals making sure it goes to the right place. When it is a language -vulnerability, when we have suspicion that it is language vulnerability, which we have not -defined what it is, it will be addressed in the group and expanded as necessary to include -everybody who needs to be involved. +MF: The latter thing. When reports are mistakenly given through this process and they are engine specific, we want them to be redirected either through themselves being redirected when reading this process or if they still send it to us, getting back to them, or going through the security focals making sure it goes to the right place. When it is a language vulnerability, when we have suspicion that it is language vulnerability, which we have not defined what it is, it will be addressed in the group and expanded as necessary to include everybody who needs to be involved. -SYG: In terms of consensus, in asking for consensus, I have no concerns with kind of redirecting -to the right project where necessary. I’m not clear on what the actionable thing is when we, +SYG: In terms of consensus, in asking for consensus, I have no concerns with kind of redirecting to the right project where necessary. I’m not clear on what the actionable thing is when we, for reports in the second bucket that does not fall into any particular projects purview. I guess if the consensus you’re asking for is, you should take that input and then discuss it, I have no concern, but I’m a little bit uncomfortable labeling such things as vulnerabilities if it doesn’t rise to the level of a particular software shipping a fix to do something. Like, if it’s just, we accepted a report, I’m not sure that gives the same messaging as a CBE would. MF: In the interim, between setting up this initial policy and actually defining our desired security properties, it is going to be more of an I-know-it-when-I-see-it kind of thing. Later hopefully we will have more well defined security properties and we will be able to clearly determine whether or not it is a violation of any of these security properties we try to hold. RPR: we have a reply from JHD and about a minute or two left on the topic. -JHD: I just wanted to add that if in fact there does not appear to be a vulnerability in any -existing implementations, there still could be the situation where the specification would -cause a new implementation to have, as a result, another vulnerability, so that would be more the -case where I’m expecting we have no one to report to and we have to discuss it, if that helps -clarify. +JHD: I just wanted to add that if in fact there does not appear to be a vulnerability in any existing implementations, there still could be the situation where the specification would cause a new implementation to have, as a result, another vulnerability, so that would be more the case where I’m expecting we have no one to report to and we have to discuss it, if that helps clarify. DE: I want to think about SPECTRE as an example of vulnerabilities not coming to the group of JavaScript, both engine authors and the committee as soon as it could have. There are real vulnerabilities that could happen. We’re kind of dancing around the issue that there’s a standing disagreement among members of committee about what things are considered the security model relevant for this committee: the web security model, object capability security model, kind of other pragmatic things that are kind of a combination of those, and, yeah, I’m all in favor of this group getting set up and figuring those out. I think the group will have to do some work to prove itself to be a responsible recipient of disclosures because, you know, otherwise we just won’t get disclosures, just like TC39 didn’t get to hear about some of these things, which is legitimate. Everybody has to be careful about this stuff saying we’ll figure out who to tell next will probably not be, like, a good starting point. But anyway, I’m in favor of getting this started, and I hope the engagement goes well. -SYG: For the example of Spectre, in hindsight, I’m not sure how much that would have helped to -discuss in committee, I was not actually involved in embargo, but given what I know how -early the chip vendors engaged chrome and maybe also Firefox, I don’t actually remember, in -terms of embargoed information beforehand, if the committee were dealing with specter on like a -speculation level without being privy to the embargoed information from chip vendors at the same time, I’m not sure how much that would have helped anyway. +SYG: For the example of Spectre, in hindsight, I’m not sure how much that would have helped to discuss in committee, I was not actually involved in embargo, but given what I know how early the chip vendors engaged chrome and maybe also Firefox, I don’t actually remember, in terms of embargoed information beforehand, if the committee were dealing with specter on like a speculation level without being privy to the embargoed information from chip vendors at the same time, I’m not sure how much that would have helped anyway. -DE: my point was more general than that. +DE: my point was more general than that. MLS: As far as Spectre, that’s really a hardware vulnerability. I’m not sure that TC39 or TG3 would be the right place for that. How do you see this being compared to the existing CVE process that certainly all the browser implementations of JavaScript already are very involved in? -MF: So again, we would redirect engine implementation errors to the respective -security tracker for those engines. The things that we would not redirect there are things -that violates security properties of the language. As an example, since we’re not talking any -concretes, here but as an example, you know, we all hold dear this isolation that, like, -functions give our scopes, right? If a function was able to access something closed over in a -different function, that would be bad. I think that is something we can generally agree on. +MF: So again, we would redirect engine implementation errors to the respective security tracker for those engines. The things that we would not redirect there are things that violates security properties of the language. As an example, since we’re not talking any concretes, here but as an example, you know, we all hold dear this isolation that, like, +functions give our scopes, right? If a function was able to access something closed over in a different function, that would be bad. I think that is something we can generally agree on. I’m not aware of any construct in the language that would allow that to happen. If it happened, I think that would be necessary for us to discuss as TG1, to address that. -MLS: So do we know of any examples where the spec had what we consider a security error? Not an -implementation that had a bug, but the spec had a security error? +MLS: So do we know of any examples where the spec had what we consider a security error? Not an implementation that had a bug, but the spec had a security error? MF: Yes, there was at least one that we discussed in TG3. JHD, do you remember? I’m not recalling off the top of my head. -JHD: Yeah, I don’t know off the top of my head either. I think one, a theme we’re having in -these TG3 discussions is trying to make sure we design around potential things as well, even if -there hasn’t been a concrete occurrence yet. Although I suspect something does exist, and even -though MF and I can’t recall it, it’s something that could exist in the future. +JHD: Yeah, I don’t know off the top of my head either. I think one, a theme we’re having in these TG3 discussions is trying to make sure we design around potential things as well, even if there hasn’t been a concrete occurrence yet. Although I suspect something does exist, and even though MF and I can’t recall it, it’s something that could exist in the future. MF: There was something that MM and Nicolo had worked on. @@ -505,101 +253,97 @@ RPR: Waldemar has a reply here. WH: I raised the issue of high-performance timers letting scripts look for cache effects. Actually I raised this and we were discussing this before Spectre and Meltdown came up. So this was one area of a spec that was touching on security. Also, I don’t understand what we’re proposing here when we say that, if there is a vulnerability in the spec itself, then we’ll discuss it. Who will discuss it? -MF: As I discussed, as I listed on the slides, the group that receives it is just the TG3 -chairs and the administrator, who then opens up the discussion to any relevant parties within -TC39. I think +MF: As I discussed, as I listed on the slides, the group that receives it is just the TG3 chairs and the administrator, who then opens up the discussion to any relevant parties within TC39. I think WH: So just the chairs will discuss it? -MF: No, that’s not what I said. The chairs will decide who needs to be involved, and then -invite those people. +MF: No, that’s not what I said. The chairs will decide who needs to be involved, and then invite those people. -RPR: So I think we’re going to have to wrap that one up there. We went a bit over. But thank -you for that, Michael. +RPR: So I think we’re going to have to wrap that one up there. We went a bit over. But thank you for that, Michael. -MF: Can we have consensus on making TG3 public and enabling that vulnerability report and -getting the process and GitHub? +MF: Can we have consensus on making TG3 public and enabling that vulnerability report and getting the process and GitHub? RPR: Michael Saboff is neutral. Shu has a condition. -SYG: My hangup here is I think people who are in the and looking out in the security space -to the practitioners are using the CVE process or used to word vulnerability meaning a -actionable thing around a software artifact. I prefer a different word be used with the second -bucket of vulnerability that with you were talking about that knows vulnerability but if you -were to stick with as a result empty-netterrability, it’s loud and clear that it’s a different -class of thing than an actionable thing that could be exploited or patched in a particular -software. +SYG: My hangup here is I think people who are in the and looking out in the security space to the practitioners are using the CVE process or used to word vulnerability meaning a actionable thing around a software artifact. I prefer a different word be used with the second bucket of vulnerability that with you were talking about that knows vulnerability but if you were to stick with as a result empty-netterrability, it’s loud and clear that it’s a different class of thing than an actionable thing that could be exploited or patched in a particular software. -MF: That’s fair. We can brainstorm wording. +MF: That’s fair. We can brainstorm wording. + +RPR: Okay, and Waldemar is neutral. All right, with that slight change of wording from Shu, I think we have consensus. Last call for any objections? Okay, there are no objections, so you have consensus. Michael, could you just read out for the purpose of the notes the key points. -RPR: Okay, and Waldemar is neutral. All right, with that slight change of wording from Shu, I -think we have consensus. Last call for any objections? Okay, there are no objections, so you -have consensus. Michael, could you just read out for the purpose of the notes the key points. ### Conclusion -MF: The things that were being asked were the TG3 repo is made public, the GitHub -vulnerability reporting process is enabled for our org, and the vulnerability -reporting document that I shared is the document that’s going to be linked to from various -appropriate places, official TC39 places, with of course a change to wording that Shu was -asking. +MF: The things that were being asked were the TG3 repo is made public, the GitHub vulnerability reporting process is enabled for our org, and the vulnerability reporting document that I shared is the document that’s going to be linked to from various appropriate places, official TC39 places, with of course a change to wording that Shu was asking. ## TC39-TG4 Source maps – Report + Presenter: Jon Kuperman -[slides](https://docs.google.com/presentation/d/1E4Mi_q-PKtBJ_hoCX4xQ1IJPNi9dFHMSF22akVX_q2Q/edit#slide=id.p) -JKP: So just a quick update about TG4 source maps. Since the last plenary in July, we convened and formed the task group, and since then we had matrix rooms, I have linked to later in the slides and moved all the repositive over to GitHub and began meeting twice a month. The second Wednesday, talking about new features that we would like to add to source maps and meet the last Thursday of each month at 1600 and that is specification correctness. We go through the current spec and call out any issues there. The primary focus is the correctness that is our top priority. But spending a good amount of time investing in new features, such as adding debug to make tracing back, scope and information into the source map. And things like that. We also had a bit of exciting news, having the first in person meetup last week. We met in Munich and were hosted by Google in Munich. Productive session. We went through a bunch of the issues on the GitHub repo and got through a lot of those with good updates. We did some cool demos. People from Chrome demoed this idea of adding the scopes and variables. Nicolo had built some cool source map snapshot testing to add a bee Babel. And did a cool around, from century, around adding debug IDs. Not looking for consensus on anything. Just wanted to give the committee an update and also say that we are still looking for anyone who is interested in contributing. The matrix rooms linked here. All the stuff on GitHub is where we are doing our discussions as well. The meeting and interested in people helping out with source map testing and validating, contributing, things like that. +JKP: So just a quick update about TG4 source maps. Since the last plenary in July, we convened and formed the task group, and since then we had matrix rooms, I have linked to later in the slides and moved all the repositive over to GitHub and began meeting twice a month. The second Wednesday, talking about new features that we would like to add to source maps and meet the last Thursday of each month at 1600 and that is specification correctness. We go through the current spec and call out any issues there. The primary focus is the correctness that is our top priority. But spending a good amount of time investing in new features, such as adding debug to make tracing back, scope and information into the source map. And things like that. We also had a bit of exciting news, having the first in person meetup last week. We met in Munich and were hosted by Google in Munich. Productive session. We went through a bunch of the issues on the GitHub repo and got through a lot of those with good updates. We did some cool demos. People from Chrome demoed this idea of adding the scopes and variables. Nicolo had built some cool source map snapshot testing to add a bee Babel. And did a cool around, from century, around adding debug IDs. Not looking for consensus on anything. Just wanted to give the committee an update and also say that we are still looking for anyone who is interested in contributing. The matrix rooms linked here. All the stuff on GitHub is where we are doing our discussions as well. The meeting and interested in people helping out with source map testing and validating, contributing, things like that. + +RPR: All right. Great. Yeah. Lots of energy from this new task group! -RPR: All right. Great. Yeah. Lots of energy from this new task group! ### Summary/Conclusion + TC39-TG4, the new source maps task group, has continued to make good progress towards its goals of improving correctness/precision of the specification, implementing a test suite, and designing new features to improve debugging. + ## Code of conduct updates + Presenter: Jordan Harband JHD:. We have no incidents to report. There’s certainly things we keep an eye on. Please let us know if you have anything to report. And although we have closed the issue for a call for new members, we always would welcome new members. And more people to help. So please reach out, if you are interested. Thank you. ## Normative updates to ECMA-402 + Presenter: Ben Allen ## Normative: Change the hourCycle default logic + - [PR](https://github.com/tc39/ecma402/pull/758) BAN: We had associated the 12 hour clock, which is the default clock that is used in the United States, associated with the h24 clock, when the `{ hour12: false }` option is passed. This is not, as you might think, the 24-hour clock as used across the world, but it is a clock that is not used anywhere. It goes from 1 to 24. It’s – I believe we have CLDR and it’s not used anywhere. What this PR does, is break that sort of erroneous association between the two of them. Previously, if the – the time stored was – if they had been using h12, and hour12 was set to false, so requesting the 24-hour version of the clock, that would set it to h24, which is just plain wrong. That’s not correct anywhere. So we have changed it to instead associate that with h23. Which is the thing that makes sense, in this context, which is the international clock. DLM [on queue]: support + ### Summary + This patch fixes a bug in options processing where Intl.DateTimeFormat would sometimes use hours from 1-24, when the right answer would be 0-23. + ### Conclusion + Consensus on #758 with explicit support from Dan Minor ## Normative: Added note about sets of locales for web browser implementations needing to not change as a result of user behaviour + - [PR](https://github.com/tc39/ecma402/pull/780) BAN: Yeah. So this one, I probably shouldn’t say this, but I am anticipating a fair amount of controversy with it. We are in a weird space, where we kind of have to care more about fingerprinting than the rest of the spec. This one is about making it such that it’s not possible to individually identify users on the web platform from the set of locales installed. If someone has installed non-system locales, after downloading the browser or the localized version of the browser, that should not be revealed to servers because that can be used to identify individual users. If you have a sort of idiosyncratic set of locales, that fact alone can be used to immediately identify exactly who you are. -The question here though is obviously this is incorporating this specifically for security concerns in the web environment. We have got sort of two parts to it. One, which is going to be – considered normative. Which is that essentially the short version is, the locales for everyone with the same engine and platform version should seem like they have the exact same set of locales, even if hypothetically, someone has downloaded and installed new locales. I believe no current browsers support that. +The question here though is obviously this is incorporating this specifically for security concerns in the web environment. We have got sort of two parts to it. One, which is going to be – considered normative. Which is that essentially the short version is, the locales for everyone with the same engine and platform version should seem like they have the exact same set of locales, even if hypothetically, someone has downloaded and installed new locales. I believe no current browsers support that. DLM [on queue]: Explicit support -DE: So I support this as a change, as – well, or clarification about what the browser should do. As an editorial matter, I don’t think we should be referring to non-normative notes this way. If we’re – you can’t use the most must in a note. That’s just kind of a RFC, whatever it was, that set these things up. If you want to use the word MUST, it has to be – it’s normative text. MUST is a normative statement about what the specification requires. A note is for just sort of describing implications of things or context. Even SHOULD can be part of normative text. I know we avoid using SHOULD in the JavaScript specification. There’s no reason we have to. We – we can – yes. So I think neither of these two things should be a note. +DE: So I support this as a change, as – well, or clarification about what the browser should do. As an editorial matter, I don’t think we should be referring to non-normative notes this way. If we’re – you can’t use the most must in a note. That’s just kind of a RFC, whatever it was, that set these things up. If you want to use the word MUST, it has to be – it’s normative text. MUST is a normative statement about what the specification requires. A note is for just sort of describing implications of things or context. Even SHOULD can be part of normative text. I know we avoid using SHOULD in the JavaScript specification. There’s no reason we have to. We – we can – yes. So I think neither of these two things should be a note. RPR: And JHD has thoughts on adding -JHD: I think I agreed with what Dan said. Just an addition, like mentioning a user agent string and so on, I think we should be careful to word this in a vague way. And then if necessary, like parenthetically link to something in the HTML spec that would be an example of it. In the same way for `document.all`, we don’t define `document` in the spec, but make it clear this is what we are talking about. This is an editorial concern. I support the desire behind it. +JHD: I think I agreed with what Dan said. Just an addition, like mentioning a user agent string and so on, I think we should be careful to word this in a vague way. And then if necessary, like parenthetically link to something in the HTML spec that would be an example of it. In the same way for `document.all`, we don’t define `document` in the spec, but make it clear this is what we are talking about. This is an editorial concern. I support the desire behind it. -BAN: To briefly respond to that, I think it’s fine for us to include, we already include references that are specific to browsers. If we want to make a requirement that’s browser-specific, if we are thinking about user agent strings, in a note, I think it’s fine to use say, this refers to user agent strings, and it’s not vague for the sake of layering. As long as we are clear about the generalities of the layering. It’s good to be concrete and give notes that explain what you are talking about. +BAN: To briefly respond to that, I think it’s fine for us to include, we already include references that are specific to browsers. If we want to make a requirement that’s browser-specific, if we are thinking about user agent strings, in a note, I think it’s fine to use say, this refers to user agent strings, and it’s not vague for the sake of layering. As long as we are clear about the generalities of the layering. It’s good to be concrete and give notes that explain what you are talking about. -RPR: All right. And then Mark? +RPR: All right. And then Mark? -MM: So I agree with everything that Dan and JHD just said. But it sounds like we are discussing as well, could this PR instead be normative? Given everything just said, I think it sounds like we agree it’s better off being a note. +MM: So I agree with everything that Dan and JHD just said. But it sounds like we are discussing as well, could this PR instead be normative? Given everything just said, I think it sounds like we agree it’s better off being a note. -RPR: Okay. I see Ben nodding. Is that the direction we shall take, then? +RPR: Okay. I see Ben nodding. Is that the direction we shall take, then? -BAN: Yeah.. It seems like there’s broad consensus on this conceptually, but change the note that makes the normative claims to normative optional rather than a note. +BAN: Yeah.. It seems like there’s broad consensus on this conceptually, but change the note that makes the normative claims to normative optional rather than a note. -DE: So I think we can iterate on the wording off-line. I also really don’t like normative optional, and I don’t think we add new versions of it, if we can’t get consensus on moving it. I think we can have consensus on this and just iterate on the wording and land it asynchronously. So I would support that at least. +DE: So I think we can iterate on the wording off-line. I also really don’t like normative optional, and I don’t think we add new versions of it, if we can’t get consensus on moving it. I think we can have consensus on this and just iterate on the wording and land it asynchronously. So I would support that at least. -KG: Yeah. Agree with Dan. We can just say some things are normative for browsers specifically. That’s fine. Say those words. +KG: Yeah. Agree with Dan. We can just say some things are normative for browsers specifically. That’s fine. Say those words. -RPR: Okay. Ben, so do you have your direction from here? +RPR: Okay. Ben, so do you have your direction from here? BAN: I have my direction from here. I will sync asynchronously with folks @@ -607,21 +351,22 @@ KG: Concretely, are we going to ask for consensus for making it a normative requ BAN: Yes -KG: Do this thing? +KG: Do this thing? BAN: Yes. I would like to move for consensus for this being normative for browsers. [Later discussion on this topic reordered to up here] -SYG: Apologies for the late question. I support it, normatively. The spirit of things, I wanted to make sure that it is outside of my wheelhouse, so I don’t know if there’s implications here with respect to UA reductions. Is there an effort of chrome to reduce the granularity of user agent strings to get people to depend on them less, among other things like minor and patch level versions, all become zeros. Does this have any interaction? +SYG: Apologies for the late question. I support it, normatively. The spirit of things, I wanted to make sure that it is outside of my wheelhouse, so I don’t know if there’s implications here with respect to UA reductions. Is there an effort of chrome to reduce the granularity of user agent strings to get people to depend on them less, among other things like minor and patch level versions, all become zeros. Does this have any interaction? -BAN: I don’t believe so. The key thing is that basically whatever the UA string is, you shouldn’t be able to figure out the – any more information than it is in the UA string from looking at the set of installed locales. So I believe now, I might be missing some cases there. +BAN: I don’t believe so. The key thing is that basically whatever the UA string is, you shouldn’t be able to figure out the – any more information than it is in the UA string from looking at the set of installed locales. So I believe now, I might be missing some cases there. -SFC: Just to reply to this topic, the actual reality, is that the data currently is dependent on the ICU and CLDR version that is shipped in a current browser version, and there may be certain variants, like, for example, if different operating systems have different sets of locales available, like Chrome on Android versus desktop Chrome; that’s the web reality. All browsers as far as I am aware are compliant with this normative specific text. But if there’s anything else that you think we should be aware of, then in terms of a patched version going to zero, that doesn’t sound like something that would impact anything. +SFC: Just to reply to this topic, the actual reality, is that the data currently is dependent on the ICU and CLDR version that is shipped in a current browser version, and there may be certain variants, like, for example, if different operating systems have different sets of locales available, like Chrome on Android versus desktop Chrome; that’s the web reality. All browsers as far as I am aware are compliant with this normative specific text. But if there’s anything else that you think we should be aware of, then in terms of a patched version going to zero, that doesn’t sound like something that would impact anything. -SYG: There is an effort for user agent reduction. On identification, one normative upshot for browsers that use ICU, you cannot do a CLDR upgrade within the same major version of your browser. +SYG: There is an effort for user agent reduction. On identification, one normative upshot for browsers that use ICU, you cannot do a CLDR upgrade within the same major version of your browser. SFC: That would be correct. If the zero thing goes through, that is an implication of the PR. + ### Summary ### Conclusion @@ -629,144 +374,153 @@ SFC: That would be correct. If the zero thing goes through, that is an implicati Consensus on this normative change (pending improved wording where it’s not in a note) with explicit support from DE, MM, KG, DLM, MS, JHD ## Normative: Fix order of rounding* option reads and resolvedOptions() + - [PR](https://github.com/tc39/ecma402/pull/811) -BAN: This PR adheres with how we have been doing things. It places all of the reads and what is reported resolved opposites in alphabetical order. Previously, the rounding priority in number format had been read before rounding increment, even though rounding increment is ahead of rounding priority alphabetically. So that has been moved down. Rounding priority is read in its appropriate alphabetical order place. And also, the table that is used to generate the output for resolved options that has been rearranged as well to put them in alphabetical order. +BAN: This PR adheres with how we have been doing things. It places all of the reads and what is reported resolved opposites in alphabetical order. Previously, the rounding priority in number format had been read before rounding increment, even though rounding increment is ahead of rounding priority alphabetically. So that has been moved down. Rounding priority is read in its appropriate alphabetical order place. And also, the table that is used to generate the output for resolved options that has been rearranged as well to put them in alphabetical order. [Explicit support from DLM] SFC: Yeah. Just pointing out that this type of change, we are working on the style guide and there’s a request open for the style guide change, I believe. Number 831. So if people are interested in this type of issue, please weigh in on question number 831, which modifies the style guide to reflect this type of ordering of these options. -BAN: So on the rounding error one, do we have consensus – or the implement read order one, do we have consensus for that one? +BAN: So on the rounding error one, do we have consensus – or the implement read order one, do we have consensus for that one? -RPR: Any support for 811? Any objections to 811? Dan Minor has support. And no objections. So I think we can say this has consensus. +RPR: Any support for 811? Any objections to 811? Dan Minor has support. And no objections. So I think we can say this has consensus. BAN: Fantastic. Thank you, everyone. Most especially, to the people in Europe who are up at some ungodly hour in the morning -RPR: yes. Europeans have the worst TimeZone for this meeting. So thank you to everyone in Europe who is dialing in. All right. We are getting through things well. To bring some things forward. The next one is RGN. +RPR: yes. Europeans have the worst TimeZone for this meeting. So thank you to everyone in Europe who is dialing in. All right. We are getting through things well. To bring some things forward. The next one is RGN. ### Summary ### Conclusion + Consensus on this normative change with explicit support from Dan Minor + ## Update GetSubstitution to match reality -Presenter: RGN -https://github.com/tc39/ecma262/pull/3157 -RGN: Thank you. So, a quick recap. Someone discovered back in January 2019 that the spec text for GetSubstitution was not followed by implementations when the replacement pattern is a dollar sign and two digits identifying an index that is not present in the regular expression where the first of the two digits identify an index that is present. So this PR updates the spec text to match implementation reality. There’s some late-breaking news, which we will get to in a minute. The idea is, when the index identifies a two digit group that does not correspond with a capture from the regular expression that we trim the tail, look at it as a single digit index followed by a literal digit character. +Presenter: RGN https://github.com/tc39/ecma262/pull/3157 + +RGN: Thank you. So, a quick recap. Someone discovered back in January 2019 that the spec text for GetSubstitution was not followed by implementations when the replacement pattern is a dollar sign and two digits identifying an index that is not present in the regular expression where the first of the two digits identify an index that is present. So this PR updates the spec text to match implementation reality. There’s some late-breaking news, which we will get to in a minute. The idea is, when the index identifies a two digit group that does not correspond with a capture from the regular expression that we trim the tail, look at it as a single digit index followed by a literal digit character. [Aside about calling for note-takers and summary-writers] -RGN: So as mentioned, the change is straightforward. The reason this has been open so long is insufficient coverage in Test262. So we now have a PR in Test262 to validate that. If we look at it, it will be shown as the things we’re talking about. Given regular expressions with 0, 1, 10 captures paired with patterns like dollar 0, dollar 1, 2, et cetera… What we see is that 0 is never a capture group because the references are indexed by 1. 1 is not a capture group, when there are no captures, but otherwise it is acceptable. And likewise, we get down at the bottom into the double digit ones, so $10 does not match and $1 does not match in the first here. We see that the $10 doesn’t match, but the $1 does, so the 0 is carried forward and then likewise for the $20. So basically, again, to recap the idea is, land the tests or extensions thereof, which capture the browser behavior and update the spec to match. I will go to the queue. What we are seeking is agreement to that general pattern, if the PR against Test262 or ECMA 262 requires some tweaks. +RGN: So as mentioned, the change is straightforward. The reason this has been open so long is insufficient coverage in Test262. So we now have a PR in Test262 to validate that. If we look at it, it will be shown as the things we’re talking about. Given regular expressions with 0, 1, 10 captures paired with patterns like dollar 0, dollar 1, 2, et cetera… What we see is that 0 is never a capture group because the references are indexed by 1. 1 is not a capture group, when there are no captures, but otherwise it is acceptable. And likewise, we get down at the bottom into the double digit ones, so $10 does not match and $1 does not match in the first here. We see that the $10 doesn’t match, but the $1 does, so the 0 is carried forward and then likewise for the $20. So basically, again, to recap the idea is, land the tests or extensions thereof, which capture the browser behavior and update the spec to match. I will go to the queue. What we are seeking is agreement to that general pattern, if the PR against Test262 or ECMA 262 requires some tweaks. -JHD: I certainly support the general idea. It’s possible I have the only previously spec compliant implementation which is not useful for anybody: I have the spec PR that RGN put up implemented. And with one major exception so far, it seems to do the right thing. That is, just $01 should like in browsers do the same thing as $1. Once we have accounted for that, assuming I find nothing else with the test cases, I think we are okay. But yeah. I wanted to call out the difference. I just noticed two minutes ago and I am in full support of the direction. +JHD: I certainly support the general idea. It’s possible I have the only previously spec compliant implementation which is not useful for anybody: I have the spec PR that RGN put up implemented. And with one major exception so far, it seems to do the right thing. That is, just $01 should like in browsers do the same thing as $1. Once we have accounted for that, assuming I find nothing else with the test cases, I think we are okay. But yeah. I wanted to call out the difference. I just noticed two minutes ago and I am in full support of the direction. -WH: What happens when you have `$01` and there are a few capture groups? +WH: What happens when you have `$01` and there are a few capture groups? -JHD: The thing I just said is that browsers will treat that as the same like a leading 0 is effectively ignored. And it otherwise works for single digit ones. If you have 01, 2. I am sure that’s $1. Not $12. But that will certainly be verified before this forward. To anticipate Shu’s question, I tested this in Safari. I don’t know what all browsers do, but it’s worth verifying this before updating the tests and the PR. +JHD: The thing I just said is that browsers will treat that as the same like a leading 0 is effectively ignored. And it otherwise works for single digit ones. If you have 01, 2. I am sure that’s $1. Not $12. But that will certainly be verified before this forward. To anticipate Shu’s question, I tested this in Safari. I don’t know what all browsers do, but it’s worth verifying this before updating the tests and the PR. -DLM: Sorry. Yeah. So we support this change in general. And we are not super right about figuring out the details. I am sure it will get done. Thanks. +DLM: Sorry. Yeah. So we support this change in general. And we are not super right about figuring out the details. I am sure it will get done. Thanks. -WH: Yeah. I am generally uncomfortable with changing how text parses based on how many captures are in the regular expression. I am wary of this change. +WH: Yeah. I am generally uncomfortable with changing how text parses based on how many captures are in the regular expression. I am wary of this change. -RGN: To be clear, in treating a 2 digit index as a single digit index followed by a literal digit character, there is agreement in all major implementations and at least the supermajority of minor ones as well. I don’t think we can change the behavior. We just need to document it. +RGN: To be clear, in treating a 2 digit index as a single digit index followed by a literal digit character, there is agreement in all major implementations and at least the supermajority of minor ones as well. I don’t think we can change the behavior. We just need to document it. -KG: Yeah. Waldemar, are you objecting to the behaviour that this request would specify or how it goes about specifying it? I couldn’t tell. +KG: Yeah. Waldemar, are you objecting to the behaviour that this request would specify or how it goes about specifying it? I couldn’t tell. WH: I am not objecting. I am just very wary of this kind of behavior. This is not something that we would have done if implementations hadn’t made a mistake. -KG: Yes. Sorry to use the word objecting. I fully agree with you. This is hateful, but also, you know, it’s what engines do. So +KG: Yes. Sorry to use the word objecting. I fully agree with you. This is hateful, but also, you know, it’s what engines do. So -DE: Somebody saying that there was another case that hadn’t been fully tested? +DE: Somebody saying that there was another case that hadn’t been fully tested? -RGN: Yeah. So $01 through $09, we just found out this morning are treated as if the leading 0 were not present. +RGN: Yeah. So $01 through $09, we just found out this morning are treated as if the leading 0 were not present. -JHD: Actually, sorry to add to that. If you have $012, that is different from $12. Because $12 could be 1 or 12. Depending on how many capture groups you have in the regular expression. $012 will always be $1 followed by a literal 2. And that is the current behavior in all browsers we can verify and the current spec PR needs some tweaks to that. +JHD: Actually, sorry to add to that. If you have $012, that is different from $12. Because $12 could be 1 or 12. Depending on how many capture groups you have in the regular expression. $012 will always be $1 followed by a literal 2. And that is the current behavior in all browsers we can verify and the current spec PR needs some tweaks to that. My implementation of the current spec PR doesn’t include the leading zero. That can be an issue on either side -WH: You said `$012` will always be treated as `$1` followed by literal `2`? +WH: You said `$012` will always be treated as `$1` followed by literal `2`? -JHD: `$1` followed by a literal `2`. `$12`. +JHD: `$1` followed by a literal `2`. `$12`. WH: I am not asking about `$12`. `$012`. -JHD: `$012` will always be the first capture followed by a `2`. +JHD: `$012` will always be the first capture followed by a `2`. -WH: Even if there are no captures? +WH: Even if there are no captures? JHD: If there are no captures, then it would just be a literal `$`, `1`, and `2`. -WH: Without the `0`? +WH: Without the `0`? -JHD: I’m sorry. Yeah. Like, so in other words, my guess as to the purpose of this, it’s to make sure that capture row placements are consumed no matter how many capturing groups in the regular expression. You don’t have to have your replacement string vary based on whether there’s less than 10 or 10 or more capturing groups in the regular expression. Like, by the leading 0, it allows us to use 2 digit replacement numerics and never have to worry about the quantity of capturing groups in the regular expression. +JHD: I’m sorry. Yeah. Like, so in other words, my guess as to the purpose of this, it’s to make sure that capture row placements are consumed no matter how many capturing groups in the regular expression. You don’t have to have your replacement string vary based on whether there’s less than 10 or 10 or more capturing groups in the regular expression. Like, by the leading 0, it allows us to use 2 digit replacement numerics and never have to worry about the quantity of capturing groups in the regular expression. -WH: Okay. +WH: Okay. -DE: So JHD, it’s great you have done this investigation. I think we should come back to this topic once everyone has had a little bit of time to review it off-line. And then maybe that will lead to this patch. I am happy that everyone is following through and making sure that the specification reflects implementation reality. +DE: So JHD, it’s great you have done this investigation. I think we should come back to this topic once everyone has had a little bit of time to review it off-line. And then maybe that will lead to this patch. I am happy that everyone is following through and making sure that the specification reflects implementation reality. -RGN: Right. So ideally, we would not need to revisit this in plenary. If we get consensus, then all follow-ups can take place asynchronously in the PRs, which is my goal today. +RGN: Right. So ideally, we would not need to revisit this in plenary. If we get consensus, then all follow-ups can take place asynchronously in the PRs, which is my goal today. -DE: I would support consensus on that. On consensus, on this to the extent that it matches implementation reality with the understanding that there will be some more tweaks done to meet these fine details based on more testing. +DE: I would support consensus on that. On consensus, on this to the extent that it matches implementation reality with the understanding that there will be some more tweaks done to meet these fine details based on more testing. -Any concerns? I would also understand if someone wants to revisit the plenary later. +Any concerns? I would also understand if someone wants to revisit the plenary later. [Explicit support from Dan Minor, RKG for conditional consensus] -WH: It depends on the reality. We don’t know if the engines agree on all cases. Given the new cases from this morning, are you sure that the engines agree on all cases? +WH: It depends on the reality. We don’t know if the engines agree on all cases. Given the new cases from this morning, are you sure that the engines agree on all cases? RGN: I am not certain. I have high confidence, and I would seek consensus conditional on that agreement. If a case is found where implementations disagree, I don’t see a way to avoid bringing back discussion in plenary -DE: I support that. We should allow them to refine and land this patch offline, if there is agreement among engines. If there is disagreement, then we will discuss it in committee. +DE: I support that. We should allow them to refine and land this patch offline, if there is agreement among engines. If there is disagreement, then we will discuss it in committee. -RPR: Okay zero. This seems like a clear proposition. I don’t think there’s any objection to it. Is there conditional consensus assuming the agreement? +RPR: Okay zero. This seems like a clear proposition. I don’t think there’s any objection to it. Is there conditional consensus assuming the agreement? -I think there are no objections. Okay. +I think there are no objections. Okay. -RGN: I will capture that in the notes. Thank you. +RGN: I will capture that in the notes. Thank you. RPR: Thank you, RGN. Yes. Please do record the key points, as well. All right. RGN, I hope we can return to you, immediately. If that’s okay. You have JSON.parse sourceText access update. + ### Summary + RegExp replace with a string replacement, including a $ followed by two digits, has long had a specification which didn’t match what JS engines, including browsers, shipped. A specification PR has been available for a while, and now test262 tests have recently been drafted to check this behavior. JHD noted that there may be more edge cases with common behavior across browsers which could be better-specified. + ### Conclusion + The proponents of this change will work together on testing the additional cases that JHD pointed out. If all browsers agree, then the committee has consensus that a patch can be landed which fixes these issues (probably this patch + a couple additions). Otherwise, if there is a mismatch between engines, the presenter should bring the change back to TC39 to discuss next steps. + ## ecma402#788 Normative: Allow UTC offset time zones + Presenter: Ujjwal Sharma (USA) -USA: Hello. +USA: Hello. -CDA: We can hear you. +CDA: We can hear you. USA: Oh. Okay. Did you already assign somebody else or should I? - + CDA: If you’re ready to go, I think we would be happy to have you. USA: Perfect. Yeah. Sorry. I have serious issues with Zoom. -This also, I think RGN could you chip in, In this one. But this is fairly straightforward. It’s a normative PR. As you all might know, just to confirm you have my screen, right? +This also, I think RGN could you chip in, In this one. But this is fairly straightforward. It’s a normative PR. As you all might know, just to confirm you have my screen, right? -CDA: Yes. +CDA: Yes. -USA: Okay. So Temporal, introduces a number of TimeZone operations into the interesting sort of space that we have here. Including UDV offset TimeZones. Like fixed Time Zones with a fixed offset. They never change. And these are not allowed within the 402 side of things. Could you have already asked for and the human readable TimeZone. Asia, Tokyo, or any of the other TimeZones that are sort of textual, but not these fixed UTC TimeZones. So this would add support for that, sort of aligning things on both ends. And there’s been a lot of comments from Temporal folks and so on. But overall, this is the end result of this PR. This would align the current 402 with the future 262 by also allowing offset Time Zones. That’s that. Also, it would help us to format the Temporal objects with an offset TimeZone. So yeah. That’s pretty much it for this request. Is there anything on the queue? I could quickly check. Nothing so far. +USA: Okay. So Temporal, introduces a number of TimeZone operations into the interesting sort of space that we have here. Including UDV offset TimeZones. Like fixed Time Zones with a fixed offset. They never change. And these are not allowed within the 402 side of things. Could you have already asked for and the human readable TimeZone. Asia, Tokyo, or any of the other TimeZones that are sort of textual, but not these fixed UTC TimeZones. So this would add support for that, sort of aligning things on both ends. And there’s been a lot of comments from Temporal folks and so on. But overall, this is the end result of this PR. This would align the current 402 with the future 262 by also allowing offset Time Zones. That’s that. Also, it would help us to format the Temporal objects with an offset TimeZone. So yeah. That’s pretty much it for this request. Is there anything on the queue? I could quickly check. Nothing so far. -RPR: Queue is empty. +RPR: Queue is empty. -USA: In that case, I would like to ask for consensus for this change. +USA: In that case, I would like to ask for consensus for this change. -RPR: Of course, this was one added after the deadline, so anyone would object for not enough time. +RPR: Of course, this was one added after the deadline, so anyone would object for not enough time. -USA: Yes. Thank you, RPR. That was indeed added after the deadline. So please let me know if you need more time to review this. +USA: Yes. Thank you, RPR. That was indeed added after the deadline. So please let me know if you need more time to review this. RPR: You have explicit support from Dan Minor and Frank. -USA: That is perfect. Thank you, both of you. Implementor feedback means a lot. And that’s it. Thanks, all. +USA: That is perfect. Thank you, both of you. Implementor feedback means a lot. And that’s it. Thanks, all. ### Conclusion Consensus on the PR, with explicit support from DLM, FYT - ## Import Attributes Implementer Feedback + Presenter: Daniel Minor (DLM) -[slides](https://docs.google.com/presentation/d/1AvdsT0k_etbelbE_HEdEY8YHLbsDv0ObWBaAhDm3TAE/edit) @@ -774,42 +528,42 @@ DLM: Okay. Thank you. So I would like to quickly present some implementer feedba So we have one issue that has been raised as a result of the implementation. And what we would like to do is, restrict attribute keys syntax to be identifiers and strings. So right now, there are also allowed to be numbers and big integers. This is a bit of a problem for us, not exactly a problem we can’t do it, but we find it to be not the nicest way of handling things and that’s because we need to convert keys to strings when we want to parse in order to check for duplicates. And so to be able to do this, big integers, we have to support allocating big integers inside the parser. So that’s not something we currently do. Big integers are garbage collected things and that is something we try to avoid doing inside the parser and we don’t currently do. By avoiding this, it will simplify memory management to allow us to parse more quickly. Push here, complicates the implementation. -What is the benefit? I am honestly not sure. There is a bit of discussion in the issue that it would be symmetrical, but there’s already some things that won’t currently work. And I don’t think there’s really much benefit in allowing this here. -I would also point out it has been implemented with big support inside the JavaScriptCore and possible. But the other implementations are happy about having to do this. And I think it will make life easier for everyone if we allow these restrictions which would be to only allow identifiers and strings. I don’t see the benefit to actual JavaScript developers. With that, I would like to open up to the queue. +What is the benefit? I am honestly not sure. There is a bit of discussion in the issue that it would be symmetrical, but there’s already some things that won’t currently work. And I don’t think there’s really much benefit in allowing this here. +I would also point out it has been implemented with big support inside the JavaScriptCore and possible. But the other implementations are happy about having to do this. And I think it will make life easier for everyone if we allow these restrictions which would be to only allow identifiers and strings. I don’t see the benefit to actual JavaScript developers. With that, I would like to open up to the queue. -RPR: Kevin has support. +RPR: Kevin has support. -KG: Yeah. I support this change. There will never be a key that is numeric here. So it’s not something that users will ever notice, that they can’t write a number here. Because you would get an error anyway, because there is not a key that is a number. So it’s just not worth asking engines to do literally any amount of work given it will never come up. +KG: Yeah. I support this change. There will never be a key that is numeric here. So it’s not something that users will ever notice, that they can’t write a number here. Because you would get an error anyway, because there is not a key that is a number. So it’s just not worth asking engines to do literally any amount of work given it will never come up. -RPR: Nicolo? +RPR: Nicolo? -NRO: Yeah. I want to talk about what Kevin said, these throws are changing when it happens. Like given that the only reason we have was more similar, it’s not worth increasing complexity. +NRO: Yeah. I want to talk about what Kevin said, these throws are changing when it happens. Like given that the only reason we have was more similar, it’s not worth increasing complexity. RPR: Thank you. Michael has support. Michael -MF: I had initially asked for adding support for BigInts in this position. But given that it adds this implementation complexity, I think that’s – that definitely not the right tradeoff. We should – yeah, we should drop this again. +MF: I had initially asked for adding support for BigInts in this position. But given that it adds this implementation complexity, I think that’s – that definitely not the right tradeoff. We should – yeah, we should drop this again. -RPR: Okay. Thank you. There is a clarifying question from Nicolo. +RPR: Okay. Thank you. There is a clarifying question from Nicolo. NRO: Yeah. So like just with absolutely clear, it also asking to remove support for like [inaudible] -DLM: Yeah. That’s correct. So big integers are things to avoid. We already have support in the parser for checking numbers. But I think it’s just more or less a consistent thing. We don’t see a reason to allow numbers at all. +DLM: Yeah. That’s correct. So big integers are things to avoid. We already have support in the parser for checking numbers. But I think it’s just more or less a consistent thing. We don’t see a reason to allow numbers at all. -Okay. Thank you. +Okay. Thank you. -RPR: And Luca has a + 1. All right. I am only hearing support. Shall we just confirm that we have consensus on this change? We have had a lot of explicit support. Mark Miller is skeptical. Could you speak? +RPR: And Luca has a + 1. All right. I am only hearing support. Shall we just confirm that we have consensus on this change? We have had a lot of explicit support. Mark Miller is skeptical. Could you speak? -MM: I am uncomfortable with this. I am not going to object, but I want to state why I am uncomfortable. So there is the hierarchy of constituencies, and implementer complexity comes after people trying to understand the language. And every time one thing in the language cannot simply be explained as it’s like this other thing in the language because of an exception, then it’s one more little exception to have, that either you remember or you, or it’s in your face. So just on language symmetry grounds, on the spec that needs to be absorbed be simpler because it has fewer things that are not exactly like something else, and if the implementation complexity is significant, you know, really significant, then I certainly yield. But we are talking about it within square brackets, the thing that it turns into, if it were, you know, you know, if it were to be recognized within square brackets it the stringification of the BigInt anyway. So if implementations were burdened with treating the symmetrically, it won’t be hard to avoid the BigInt and avoid burdening the garbage collector. And even if they were, we are burdening the garbage collector for a very rare case. What is the benefit of having the parser be able to avoid the garbage collector for a rare case? +MM: I am uncomfortable with this. I am not going to object, but I want to state why I am uncomfortable. So there is the hierarchy of constituencies, and implementer complexity comes after people trying to understand the language. And every time one thing in the language cannot simply be explained as it’s like this other thing in the language because of an exception, then it’s one more little exception to have, that either you remember or you, or it’s in your face. So just on language symmetry grounds, on the spec that needs to be absorbed be simpler because it has fewer things that are not exactly like something else, and if the implementation complexity is significant, you know, really significant, then I certainly yield. But we are talking about it within square brackets, the thing that it turns into, if it were, you know, you know, if it were to be recognized within square brackets it the stringification of the BigInt anyway. So if implementations were burdened with treating the symmetrically, it won’t be hard to avoid the BigInt and avoid burdening the garbage collector. And even if they were, we are burdening the garbage collector for a very rare case. What is the benefit of having the parser be able to avoid the garbage collector for a rare case? -KG: Mark, this will literally never come up. You have to learn about these things that are different in this case. You just don’t have to learn it. It will literally never come up. There will never be a key that is numeric. So there is never a reason that a user would write this in a valid program. +KG: Mark, this will literally never come up. You have to learn about these things that are different in this case. You just don’t have to learn it. It will literally never come up. There will never be a key that is numeric. So there is never a reason that a user would write this in a valid program. -MM: Does the spec of the syntax here not simply reuse productions of syntax elsewhere in the language? +MM: Does the spec of the syntax here not simply reuse productions of syntax elsewhere in the language? -KG: If reuses some of them, it doesn’t reuse the property production because it does not have computed property keys anyway. It’s already different. +KG: If reuses some of them, it doesn’t reuse the property production because it does not have computed property keys anyway. It’s already different. -MM: I see. Okay. And in that case, I withdraw my skepticism. Thank you. +MM: I see. Okay. And in that case, I withdraw my skepticism. Thank you. -RPR: All right. There are some replies. All right. I have only heard positive explicit support. Withdrawn the skepticism. Let’s just final check. Any objections? No objections. So congratulations. We have consensus for this change +RPR: All right. There are some replies. All right. I have only heard positive explicit support. Withdrawn the skepticism. Let’s just final check. Any objections? No objections. So congratulations. We have consensus for this change DLM: Thank you @@ -817,130 +571,109 @@ DLM: Thank you Consensus on the change to only allow Identifiers and Strings as keys in Import Attributes. It’s agreed that this will never happen in user code anyway, and removing support for BigInt and number simplifies implementation. -RPR: 10 minutes between us and lunch. I think lunch will enter the room very soon. Before that, we have a couple of 5-minute items. JHD first with array grouping update. +RPR: 10 minutes between us and lunch. I think lunch will enter the room very soon. Before that, we have a couple of 5-minute items. JHD first with array grouping update. ## Array grouping update + Presenter: Jordan Harband (JHD) -JHD: Just a status update. The array grouping proposal will be in chrome version 117, out this month. It may have already come out. I don’t know. It is implemented in serenity and es-shims. Firefox will ship in v119 in October. My expectation is at the next meeting, assuming no issues with the implementations, that we will be able to come back and ask for Stage 4. +JHD: Just a status update. The array grouping proposal will be in chrome version 117, out this month. It may have already come out. I don’t know. It is implemented in serenity and es-shims. Firefox will ship in v119 in October. My expectation is at the next meeting, assuming no issues with the implementations, that we will be able to come back and ask for Stage 4. ### Summary Array grouping is at Stage 3 and gradually shipping in browsers + ## Array Buffer transfer update + Presenter: Jordan Harband (JHD) JHD: It’s going to be a similar style of update. `ArrayBuffer.prototype.transfer`, the V8 implementation has merged. I am not sure which version of chrome it has shipped or will ship in. But since it merged back in February, I am assuming it’s already shipped. And I don’t have any tracking progress for SpiderMonkey or webkit / JSC or, but the es-shims and implementation and JSC as well. My hope is that SpiderMonkey and JSC will work on the implementations and in a future meeting, I will come back and ask for Stage 4 for it. -DLM: Yeah. So this is already implemented in SpiderMonkey, but we will be changing that in the future. Thanks. +DLM: Yeah. So this is already implemented in SpiderMonkey, but we will be changing that in the future. Thanks. -JHD: Dan, I am looking to see what the status is with JSC? +JHD: Dan, I am looking to see what the status is with JSC? -JHD: Thanks. If you folks could drop me links to the tracking issue, that would be helpful. +JHD: Thanks. If you folks could drop me links to the tracking issue, that would be helpful. -SYG: Just so clarify, chrome shipping v114, it’s been stable for a while. It’s behind a flag? +SYG: Just so clarify, chrome shipping v114, it’s been stable for a while. It’s behind a flag? -DE: That’s what chrome status is. But I haven’t checked the code. +DE: That’s what chrome status is. But I haven’t checked the code. -SYG: I don’t know. That site keeps changing. They are annoying. I will try to fix that. +SYG: I don’t know. That site keeps changing. They are annoying. I will try to fix that. -RPR: All right. Is that all for this update? Yeah, thank you. +RPR: All right. Is that all for this update? Yeah, thank you. JHD: Thank you. ### Summary `ArrayBuffer.prototype.transfer` ad friends are at stage 3 and gradually shipping in browsers. + ## Symbol predicates update + Presenter: Jordan Harband (JHD) JHD: Sure. So there’s nothing really to present there. -There remains one issue open, which is Shu’s question about the utility of the Symbol.isWellKnownSymbol() predicate. There is no clear answer to that question yet. The – rather, not yet compelling enough answer to convince SYG or whichever cohorts he represents, so that’s explored. If we still do not continue to find something convincing enough, then I may come back and split out the two predicates into two proposals to advance the ones that clear utility. But that is where we are at, with that proposal. That’s it. +There remains one issue open, which is Shu’s question about the utility of the Symbol.isWellKnownSymbol() predicate. There is no clear answer to that question yet. The – rather, not yet compelling enough answer to convince SYG or whichever cohorts he represents, so that’s explored. If we still do not continue to find something convincing enough, then I may come back and split out the two predicates into two proposals to advance the ones that clear utility. But that is where we are at, with that proposal. That’s it. -RBR: All right. Any questions for JHD on symbol predicates? No questions? Okay. +RBR: All right. Any questions for JHD on symbol predicates? No questions? Okay. ### Summary Symbol predicates remain at stage 1; still looking for more arguments for the isWellKnownSymbol predicate that would convince those with concerns. + ## Pattern matching updates + Presenter: Jordan Harband (JHD) -JHD: No details to discuss in this meeting, which is why I picked a short timebox. The champion group for pattern matching is nearing completion of a new design, not drastically, but something better matching the feedback from SpiderMonkey about designing iteratively, even if it is shipped holistically. I hope to come back at a future meeting, perhaps at the 100th, and have plenty of time to discuss those changes, and either incorporate more feedback or seek Stage 2. But so we will probably merge that PR before the next plenary. Even though we won’t be presenting. Most likely at the next one. If you are interested, feel free to follow that and feel free to ask if you have any questions. Thank you. +JHD: No details to discuss in this meeting, which is why I picked a short timebox. The champion group for pattern matching is nearing completion of a new design, not drastically, but something better matching the feedback from SpiderMonkey about designing iteratively, even if it is shipped holistically. I hope to come back at a future meeting, perhaps at the 100th, and have plenty of time to discuss those changes, and either incorporate more feedback or seek Stage 2. But so we will probably merge that PR before the next plenary. Even though we won’t be presenting. Most likely at the next one. If you are interested, feel free to follow that and feel free to ask if you have any questions. Thank you. -RPR: Are there any questions on pattern matching? +RPR: Are there any questions on pattern matching? -DE: I was looking forward to a potential presentation of, like, the actual proposal. Or discussion on it or anything like that. +DE: I was looking forward to a potential presentation of, like, the actual proposal. Or discussion on it or anything like that. -JHD: Yes. We had hoped to be able to do that. But the champion group has gotten hung up on a few items we don’t have quite consensus among ourselves yet. We thought it best to delay, rather than, you know, so we can come to the group with a cohesive presentation, instead of risking distracting the group with smaller possibilities. Obviously, if we, I think even if we cannot come to complete consensus, we will bring proposals, some possibilities to the committee. But we just as a group didn’t feel we were ready to present on it, unfortunately. I share your enthusiasm for being able to have that discussion in plenary. +JHD: Yes. We had hoped to be able to do that. But the champion group has gotten hung up on a few items we don’t have quite consensus among ourselves yet. We thought it best to delay, rather than, you know, so we can come to the group with a cohesive presentation, instead of risking distracting the group with smaller possibilities. Obviously, if we, I think even if we cannot come to complete consensus, we will bring proposals, some possibilities to the committee. But we just as a group didn’t feel we were ready to present on it, unfortunately. I share your enthusiasm for being able to have that discussion in plenary. -RPR: All right. Any other questions on pattern matching? No. None for now? Dan, is it worth putting up notes? Are there any topics we would benefit from going through the key points and just documenting what we have already done? +RPR: All right. Any other questions on pattern matching? No. None for now? Dan, is it worth putting up notes? Are there any topics we would benefit from going through the key points and just documenting what we have already done? ### Summary + Pattern matching has gained momentum again, but there are still some things to be solved in the group of champions and once those are settled, there will be a presentation about the changed proposal relying on implementer feedback. + ## JSON.parse source text access update + Presenter: Richard Gibson RGN - [proposal](https://github.com/tc39/proposal-json-parse-with-source) -[slides](https://docs.google.com/presentation/d/1pg1gnNeMIcAbwq-CdQE7vlSldlNZ5q2hC5OA-U8ScI8/edit?usp=sharing) -RGN: So it’s been a little while since we -presented this, but it’s coming to a close now, and I thought it would be a good time to give an -update on where things stand. So the background of course is that we’re dealing with the -problem that JSON.parse is lossy. Even if you have a reviver function, for instance, when you -are parsing numbers, which in JSON are an arbitrarily long sequence of digits, you receive them -inside the reviver as an EMCAScript number, which is limited to IEEE 754 binary64. Here -is a trivial case that has discarded information available in the source. - -A secondary concern, which is not actually addressed right now, at least not fully, is that there’s also insufficient context for reviver functions, so if you’re parsing a object that you wish to represent thing more detailed than just one of the JSON types, you don’t actually know where in the data structure you are, and so it’s really easy to accidentally transform a value that happens to overlap with whatever special syntax you use for indicating rich data. You have to do strange tricks like look at the corresponding key or keep your internal cache or other things like that. And on the flip side, the output from a replacer function when you are serializing into JSON is itself subject to re-serialization, so you cannot output an arbitrarily -long sequence of digits like you might have read in, anything that you output is going to -itself go through JSON.stringify and even if you emit a string, I’m sorry, a BigInt that -doesn’t work. If you emit a number, that’s going to get lossily reencoded, so you can’t -actually output the range of JSON that might come in. - -And the proposal in order to address that is to, well, on the input side, expose the source -text so you might be able to, in the reviver function, look at the raw sequence of digits and -preserve the information from it that it wasn’t available in the case of a number or also to -look at a string and see which characters were represented as escape sequences versus -literally. On the output side, allow image of raw JSON so you can have your arbitrarily long -arbitrarily precise sequence of digits, or any other primitive value that makes sense. - -And in the recent past, being the past couple days, we’ve resolved a couple issues. -Number 1, a surprising result that was overlooked in the original text to deal with forward -modification. JSON.parse reviver function has access to the non-primitive value that is being -dealt with and can peek ahead and make modifications, which are going to invalidate any source -text access if they do so. And also one where it had to do with the discrepancy between -EMCAScript and JSON parsing data models, their grammar. In JSON, a negative sign before a number -is still part of the number token. That’s not true in EMCAScript, where this breaks down into -a unaryexpression. It’s a negation operation on a literal number. So we need the negative sign to remain in -the source. It wasn’t previously. It is now. There’s still a couple open issues, but they’re -open only because the proposal is not yet advanced. We have tentatively made negative decisions on both of these, which deal with exposing more information in the context object that communicates the source. We might do ancestor keys that show where in the data structure a value is, but have decided not -to for now. We might also expose position in the input string where the source text falls and -have decided not to do so for now. - -So in terms of implementation readiness, I’m working on the tests. They will be in a test262 -PR this week. We are ready to implement. And I’m expecting to ask for Stage 4 possibly at the -next meeting, possibly at the one after that, depending on the progress of implementations, but -don’t foresee any issues past there. With that, I’m ready for the queue. +RGN: So it’s been a little while since we presented this, but it’s coming to a close now, and I thought it would be a good time to give an update on where things stand. So the background of course is that we’re dealing with the problem that JSON.parse is lossy. Even if you have a reviver function, for instance, when you are parsing numbers, which in JSON are an arbitrarily long sequence of digits, you receive them inside the reviver as an EMCAScript number, which is limited to IEEE 754 binary64. Here is a trivial case that has discarded information available in the source. + +A secondary concern, which is not actually addressed right now, at least not fully, is that there’s also insufficient context for reviver functions, so if you’re parsing a object that you wish to represent thing more detailed than just one of the JSON types, you don’t actually know where in the data structure you are, and so it’s really easy to accidentally transform a value that happens to overlap with whatever special syntax you use for indicating rich data. You have to do strange tricks like look at the corresponding key or keep your internal cache or other things like that. And on the flip side, the output from a replacer function when you are serializing into JSON is itself subject to re-serialization, so you cannot output an arbitrarily long sequence of digits like you might have read in, anything that you output is going to itself go through JSON.stringify and even if you emit a string, I’m sorry, a BigInt that doesn’t work. If you emit a number, that’s going to get lossily reencoded, so you can’t actually output the range of JSON that might come in. + +And the proposal in order to address that is to, well, on the input side, expose the source text so you might be able to, in the reviver function, look at the raw sequence of digits and preserve the information from it that it wasn’t available in the case of a number or also to look at a string and see which characters were represented as escape sequences versus literally. On the output side, allow image of raw JSON so you can have your arbitrarily long arbitrarily precise sequence of digits, or any other primitive value that makes sense. + +And in the recent past, being the past couple days, we’ve resolved a couple issues. +Number 1, a surprising result that was overlooked in the original text to deal with forward modification. JSON.parse reviver function has access to the non-primitive value that is being dealt with and can peek ahead and make modifications, which are going to invalidate any source text access if they do so. And also one where it had to do with the discrepancy between EMCAScript and JSON parsing data models, their grammar. In JSON, a negative sign before a number is still part of the number token. That’s not true in EMCAScript, where this breaks down into a unaryexpression. It’s a negation operation on a literal number. So we need the negative sign to remain in the source. It wasn’t previously. It is now. There’s still a couple open issues, but they’re open only because the proposal is not yet advanced. We have tentatively made negative decisions on both of these, which deal with exposing more information in the context object that communicates the source. We might do ancestor keys that show where in the data structure a value is, but have decided not to for now. We might also expose position in the input string where the source text falls and have decided not to do so for now. + +So in terms of implementation readiness, I’m working on the tests. They will be in a test262 PR this week. We are ready to implement. And I’m expecting to ask for Stage 4 possibly at the next meeting, possibly at the one after that, depending on the progress of implementations, but don’t foresee any issues past there. With that, I’m ready for the queue. CDA: We have Daniel Minor first in the queue. -DLM: Sure. I want to say that we continue to really like this proposal and that with any luck, +DLM: Sure. I want to say that we continue to really like this proposal and that with any luck, we’ll be starting our implementation later this year. CDA: Shu is next. -SYG: I feel like I missed something. What are these open questions, JSON has been in Stage 3 for -a while? We shipped it already after you fixed the assertion. +SYG: I feel like I missed something. What are these open questions, JSON has been in Stage 3 for a while? We shipped it already after you fixed the assertion. RGN: In that case, I’m happy to close them and they will no longer be open. -SYG: Okay, that’s good, I guess. But, yeah, I would if I don’t know, we shouldn’t have -advanced to Stage 3 if there were open design questions. +SYG: Okay, that’s good, I guess. But, yeah, I would if I don’t know, we shouldn’t have advanced to Stage 3 if there were open design questions. -RGN: The only thing that would change the resolution of these is feedback from implementers. So -if you’re saying that you don’t have any, then their progress is pretty clear. +RGN: The only thing that would change the resolution of these is feedback from implementers. So if you’re saying that you don’t have any, then their progress is pretty clear. SYG: The main feedback was the assertion a failure that caused, not just spec assertion failure but actual runtime assertion failures, but it has been fixed and shipped. So, I don’t know, any changes we want to make would need a higher bar. @@ -952,78 +685,38 @@ RGN: No. Thank you. CDA: All right. -### Summary +### Summary + The proposal is ready for implementation, and a test262 PR will be up this week. ### Conclusion + Having not received implementer feedback to the contrary, open issues regarding design questions will be closed. ## Iterator helper web incompat + Presenter: Shu-yu Guo (SYG) - [proposal](https://github.com/tc39/proposal-iterator-helpers/) - [issue](https://github.com/tc39/proposal-iterator-helpers/issues/286) -SYG: All right, so we, Chrome recently tried to ship iterator helpers, the synchronous iterator -helpers, and we found a web incompatibility that we did not see until it basically hit stable. -This is par for the course because beta and canary populations are non-representative, and -often we don’t find glaring web incompatibility issues until we hit stable. You can read the -full details for what actually broke but it comes to the override mistake. With interaction in -two parts. So one, a lot of code on a lot of websites on the web ship an old version of -the regenerator run time, which they use to polyfill things like async await and generators, -anything with kind of resume points, there’s a polyfill that has a run time support and that is, the run time support is called the regenerator run time. The regenerator runtime tries to set up its own generator function, and it assigns to its constructor, you see this snippet here, it tries to assign to the constructor property of its polyfill generator function with dot access and it just does dot constructor equals blah. This interacted poorly with a separate product called airgap.js, which truth be told, I can’t really tell you what this thing does, but it does something with, I don’t know, some kind of data isolation or something -with cookies and some kind of privacy thing. But in an attempt to, I guess, be extra safe -around exfiltration of data that it promises to safeguard, it freezes the iterator prototype -if there’s a global called Iterator. We added this global when we shipped iterator helpers. - -That’s part of the proposal. We’ve always had this prototype, but we gave it a global name -called Iterator. And this airgap.js, which is a closed source library, a paid product, froze -the Iterator prototype. Now the prototype has a constructor property on it. And the override -mistake now means that after you freeze the built-in prototype, the iterator prototype is on -the prototype chain of the generator prototype, so when you do a dot constructor, the -constructor is read only on the prototype, which means this fails and it breaks the existing -code. So we have another instance of the override mistake causing us to not be able to ship -this proposal. So this is originally, we thought this interaction seemed somewhat -rare, like, freezing intrinsics is very rare. We thought that if we can get the upstream site -so this was discovered on theathletic.com, which is a big enough site that we don’t want to -risk breaking, but we reached out to the athletic and to the parent company that makes airgap.js and they were receptive to updating their site to turn off this freezing mode. - -Unfortunately, after they did that, other breakages also popped up of the same kind because -other sites used airgap.js and the mode where they freeze the intrinsics is the default mode. -So currently, we’re in a pattern that we, the Chrome, has unshipped iterator helpers because -many sites break due to their use of this airgap.js. Our intuition, that it is not -possible to get people to update regenerator. There are too many copies of old regenerator -runtimes around. But the bad interaction comes from airgap.js. It’s not known to us if there -are other popular libraries that freeze intrinsics, and specifically iterator.prototypes. So -yeah, so that’s our intuition, but we are not going to ship it, again, until we can build -confidence that things that are broken currently are not going to be broken anymore. So there -are a couple avenues open to us, and if Michael is comfortable to talk about that, I would like -to turn it over to him. - -MF: Yeah, so of course the first, the most preferred thing is that we work with this company -to update their product and update the use of their product on all of the customers that are -affected. We provided them with a snippet of JavaScript that they could run on their -customers. They were not willing to share their customer list, but we provided some JavaScript -that they could run on their customers to determine if they were affected by this issue and -reach out to them to fix that. This is the preferred approach, because as SYG was kind of -mentioning, we think that this is likely the only instance of the freezing intrinsics. Also, due to some errors when unflagging the feature or flagging, again, the feature, we had a few days of extra data, which didn’t, to my knowledge yet, turn up any other identified incompatibilities. So we will take some time to see if they -can successfully upgrade their customers. We have a backup strategy. It is linked from the -agenda. It is PR number 287 on iterator helpers. That implements the accessor approach that we previously discussed when we were discussing symbol.toStringTag. If you recall, I don’t know, a couple meetings ago, we had already had this issue with symbol.toStringTag and regenerator runtime, and we -decided to solve that by making the property writable. The alternative was to make a weird -accessor where the setter checks whether the `this` value is the prototype. Anyway, this pull request applies that accessor strategy to both `Symbol.toStringTag` and now the `constructor` property that is affected. +SYG: All right, so we, Chrome recently tried to ship iterator helpers, the synchronous iterator helpers, and we found a web incompatibility that we did not see until it basically hit stable. +This is par for the course because beta and canary populations are non-representative, and often we don’t find glaring web incompatibility issues until we hit stable. You can read the full details for what actually broke but it comes to the override mistake. With interaction in two parts. So one, a lot of code on a lot of websites on the web ship an old version of the regenerator run time, which they use to polyfill things like async await and generators, +anything with kind of resume points, there’s a polyfill that has a run time support and that is, the run time support is called the regenerator run time. The regenerator runtime tries to set up its own generator function, and it assigns to its constructor, you see this snippet here, it tries to assign to the constructor property of its polyfill generator function with dot access and it just does dot constructor equals blah. This interacted poorly with a separate product called airgap.js, which truth be told, I can’t really tell you what this thing does, but it does something with, I don’t know, some kind of data isolation or something with cookies and some kind of privacy thing. But in an attempt to, I guess, be extra safe around exfiltration of data that it promises to safeguard, it freezes the iterator prototype if there’s a global called Iterator. We added this global when we shipped iterator helpers. + +That’s part of the proposal. We’ve always had this prototype, but we gave it a global name called Iterator. And this airgap.js, which is a closed source library, a paid product, froze the Iterator prototype. Now the prototype has a constructor property on it. And the override mistake now means that after you freeze the built-in prototype, the iterator prototype is on the prototype chain of the generator prototype, so when you do a dot constructor, the constructor is read only on the prototype, which means this fails and it breaks the existing code. So we have another instance of the override mistake causing us to not be able to ship this proposal. So this is originally, we thought this interaction seemed somewhat rare, like, freezing intrinsics is very rare. We thought that if we can get the upstream site so this was discovered on theathletic.com, which is a big enough site that we don’t want to risk breaking, but we reached out to the athletic and to the parent company that makes airgap.js and they were receptive to updating their site to turn off this freezing mode. + +Unfortunately, after they did that, other breakages also popped up of the same kind because other sites used airgap.js and the mode where they freeze the intrinsics is the default mode. +So currently, we’re in a pattern that we, the Chrome, has unshipped iterator helpers because many sites break due to their use of this airgap.js. Our intuition, that it is not possible to get people to update regenerator. There are too many copies of old regenerator runtimes around. But the bad interaction comes from airgap.js. It’s not known to us if there are other popular libraries that freeze intrinsics, and specifically iterator.prototypes. So yeah, so that’s our intuition, but we are not going to ship it, again, until we can build confidence that things that are broken currently are not going to be broken anymore. So there are a couple avenues open to us, and if Michael is comfortable to talk about that, I would like to turn it over to him. + +MF: Yeah, so of course the first, the most preferred thing is that we work with this company to update their product and update the use of their product on all of the customers that are affected. We provided them with a snippet of JavaScript that they could run on their customers. They were not willing to share their customer list, but we provided some JavaScript that they could run on their customers to determine if they were affected by this issue and reach out to them to fix that. This is the preferred approach, because as SYG was kind of mentioning, we think that this is likely the only instance of the freezing intrinsics. Also, due to some errors when unflagging the feature or flagging, again, the feature, we had a few days of extra data, which didn’t, to my knowledge yet, turn up any other identified incompatibilities. So we will take some time to see if they can successfully upgrade their customers. We have a backup strategy. It is linked from the agenda. It is PR number 287 on iterator helpers. That implements the accessor approach that we previously discussed when we were discussing symbol.toStringTag. If you recall, I don’t know, a couple meetings ago, we had already had this issue with symbol.toStringTag and regenerator runtime, and we decided to solve that by making the property writable. The alternative was to make a weird accessor where the setter checks whether the `this` value is the prototype. Anyway, this pull request applies that accessor strategy to both `Symbol.toStringTag` and now the `constructor` property that is affected. So if we are unsuccessful in a reasonable amount of time, or I guess if the company that makes this product is unsuccessful in a reasonable amount of time, we’ll ask for this change to be made to the proposal. But for now, this agenda item serves as a warning to implementers that there is a web incompatibility, so we’ll hold off until the landscape has possibly changed. SYG, do we have specifics on what we think the time frame would be for when we would try to go with the backup approach? -SYG: I think that, one, that depends on transcend, which is the company that -does airgap.js. Once they give the thumbs up that they have transitioned their customers, we -can try to reship in Chrome if anything new crops up, I think that is probably the limit of our -risk appetite to keep trying to work with the upstream properties to fix their things. +SYG: I think that, one, that depends on transcend, which is the company that does airgap.js. Once they give the thumbs up that they have transitioned their customers, we can try to reship in Chrome if anything new crops up, I think that is probably the limit of our risk appetite to keep trying to work with the upstream properties to fix their things. -MF: How long do we give transcend to +MF: How long do we give transcend to -SYG: I don’t have a, so I can only say that as an implementer, even as implementer -that is not very well connected to the web dev community, this is one of the proposals that the -developers are very excited about being able to use, that’s something I think the committee can -try to come up with a soft timeline on. Chrome is willing to be flexible here. +SYG: I don’t have a, so I can only say that as an implementer, even as implementer that is not very well connected to the web dev community, this is one of the proposals that the developers are very excited about being able to use, that’s something I think the committee can try to come up with a soft timeline on. Chrome is willing to be flexible here. MF: I would recommend not more than two months. Between now and the next meeting. @@ -1031,174 +724,103 @@ SYG Okay. Do we have a queue? CDA: Yes. Nicolo is on the queue. -NRO: Airgap is an example of something doing this, like, freeze that causes problems in -this case. We have people on the committee working with collaborating products to freeze, -like, the global environment, so I wonder if these delegates have maybe a list of other -libraries, other product doing the same things that we could proactively reach out to them, maybe -now or in the future to avoid similar cases? - -MM: Yes, so I don’t have a precise list. We can certainly pull that together. But at this -point, I’m just going to guesstimate, around a dozen. Please make sure that shows up in the notes, that that’s approximate. It might be under or over. - -What happens is metamask is using it both in lava mode and in snap. Snaps is their browser -framework for an ostensible crypto wallet, and there’s something like a dozen companies that -very quickly released snaps that plug into a metamask wall. I was very impressed. So all of -them are continuing on the snaps framework, the snaps framework is in hardened JavaScript. -It’s not that the dozen companies are themselves directly using SES, but their continuing on -SES because snaps uses SES for isolation between the plug-ins, between the snaps. Let me also just respond. The accessor issue, SES has a very well worked out accessor mechanism that we’ve been using now for years. We’ve actually been using it since the first hardened JavaScript -- or the first SES that was shipping from Google back in 2010 or so. And the crucial thing about that accessor that’s different than the accessor that’s in the pull request is that if you do it on the object itself, if the `this` is the prototype, then it throws so that it correctly emulates the behavior of a failed strict assignment. It’s impossible for an -accessor to emulate -- to accurately emulate both a sloppy assignment and a strict assignment, -so you have to choose one or the other. I think we should only care to preserve the behavior -of the strict assignment and in fact, I would object vehemently to anything that fell back to a -silent assignment failure in strict code. +NRO: Airgap is an example of something doing this, like, freeze that causes problems in this case. We have people on the committee working with collaborating products to freeze, +like, the global environment, so I wonder if these delegates have maybe a list of other libraries, other product doing the same things that we could proactively reach out to them, maybe now or in the future to avoid similar cases? + +MM: Yes, so I don’t have a precise list. We can certainly pull that together. But at this point, I’m just going to guesstimate, around a dozen. Please make sure that shows up in the notes, that that’s approximate. It might be under or over. + +What happens is metamask is using it both in lava mode and in snap. Snaps is their browser framework for an ostensible crypto wallet, and there’s something like a dozen companies that very quickly released snaps that plug into a metamask wall. I was very impressed. So all of them are continuing on the snaps framework, the snaps framework is in hardened JavaScript. +It’s not that the dozen companies are themselves directly using SES, but their continuing on SES because snaps uses SES for isolation between the plug-ins, between the snaps. Let me also just respond. The accessor issue, SES has a very well worked out accessor mechanism that we’ve been using now for years. We’ve actually been using it since the first hardened JavaScript -- or the first SES that was shipping from Google back in 2010 or so. And the crucial thing about that accessor that’s different than the accessor that’s in the pull request is that if you do it on the object itself, if the `this` is the prototype, then it throws so that it correctly emulates the behavior of a failed strict assignment. It’s impossible for an accessor to emulate -- to accurately emulate both a sloppy assignment and a strict assignment, +so you have to choose one or the other. I think we should only care to preserve the behavior of the strict assignment and in fact, I would object vehemently to anything that fell back to a silent assignment failure in strict code. CDA: Michael on the queue? -MF: Mark, one of the problems with this library was that, the developers were following -along with the standards process and were predicting iterator helper’s proposal, meaning they -were looking for an iterator global and conditionally freezing it. Would SES do the same thing -or does that? +MF: Mark, one of the problems with this library was that, the developers were following along with the standards process and were predicting iterator helper’s proposal, meaning they were looking for an iterator global and conditionally freezing it. Would SES do the same thing or does that? -MM: SES has done the same thing. SES already anticipates iterator helpers, and in fact, we use -the code that you wrote inside SES in order to obtain the hidden primordials that come in with -iterator helpers. So SES has a list of what we call enablements in a file called enablements.js which is a list of all the properties for which we install this accessor so that assignments that override the property act as if they -- you know, they would act in a JavaScript without the override mistake. I think that, you know, if airgap.js or athletic airgap.js, I’m sorry, if they can just adopt exactly the, you know, the very well road tested access code that SES has been using, as I said, since 2019, and apply it to this case, they -would preserve the tamper proofness that they sought originally, there would be no loss of -safety, and they would correctly work around this issue in exactly the same way hardened -JavaScript anticipates the issue and works around it. +MM: SES has done the same thing. SES already anticipates iterator helpers, and in fact, we use the code that you wrote inside SES in order to obtain the hidden primordials that come in with iterator helpers. So SES has a list of what we call enablements in a file called enablements.js which is a list of all the properties for which we install this accessor so that assignments that override the property act as if they -- you know, they would act in a JavaScript without the override mistake. I think that, you know, if airgap.js or athletic airgap.js, I’m sorry, if they can just adopt exactly the, you know, the very well road tested access code that SES has been using, as I said, since 2019, and apply it to this case, they would preserve the tamper proofness that they sought originally, there would be no loss of safety, and they would correctly work around this issue in exactly the same way hardened JavaScript anticipates the issue and works around it. CDA: JHD? -JHD: Yeah, I mean, essentially what this PR that’s up on the screen does is fixes the override -mistake for these two specific properties, is that an accurate interpretation? +JHD: Yeah, I mean, essentially what this PR that’s up on the screen does is fixes the override mistake for these two specific properties, is that an accurate interpretation? -MM: I would say no, because of what happens if you assign to that property on the -prototype itself. This PR, as I understand it, fails silently rather than throwing if you -assign to the property on the prototype itself. The prototype. +MM: I would say no, because of what happens if you assign to that property on the prototype itself. This PR, as I understand it, fails silently rather than throwing if you assign to the property on the prototype itself. The prototype. JHD: Okay, modulo that behavior change. -MM: It emulates the override mistake in precisely the way that accessor code in SES does. -But airgap.js could just adapt the accessor code from SES if we can get them to deploy that -and upgrade their customers. +MM: It emulates the override mistake in precisely the way that accessor code in SES does. +But airgap.js could just adapt the accessor code from SES if we can get them to deploy that and upgrade their customers. -JHD: My question is if we decide this is something worth fixing, I know we talked about can we -fix the override mistake, is it worth trying to fix it holistically for all future properties, to 34th, this feels like a really, really gross hack to do it in one or two place, whereas if we did it everywhere, then it’s consistency and, you know, JavaScript is full of a lot of these things, but it’s done everywhere. So, like, is it worth trying to just do that instead of, like, if we do this as a plan to move the proposal forward, but I meant should we as a group try to pursue a longer term fix that does this everywhere? +JHD: My question is if we decide this is something worth fixing, I know we talked about can we fix the override mistake, is it worth trying to fix it holistically for all future properties, to 34th, this feels like a really, really gross hack to do it in one or two place, whereas if we did it everywhere, then it’s consistency and, you know, JavaScript is full of a lot of these things, but it’s done everywhere. So, like, is it worth trying to just do that instead of, like, if we do this as a plan to move the proposal forward, but I meant should we as a group try to pursue a longer term fix that does this everywhere? -MM: Yes, and what that amounts to is if we can’t simply fix the override mistake, we need a way -to freeze objects that freezes them as if you know, freezes them in a way that does not cause an override mistake. And if we had such a freezing primitive, then we certainly hardened JavaScript would then use that freezing primitive rather than what we’re doing now freeze all of the intrinsics and our library routine that does a transit of lock freezing objects to tamperproof them would instead use a primitive to would make them exempt from the override mistake. The reason why that should be strongly preferred rather than just manually installing these accessors everywhere, the reason why we have an enablements list -rather than just installing the accessors everywhere, is that the accessors are significantly expensive. And the place where it’s most painful is the accessor, is the accessor that is the one that we, that has the highest priority to turn on, which is object.prototype.toString. The expense is not the setter, obviously, we don’t care, there’s no code we’re aware of that cares how much time it takes to assign to it. The problem is that once you make it into an accessor, then every read from the property becomes a call to the getter. +MM: Yes, and what that amounts to is if we can’t simply fix the override mistake, we need a way to freeze objects that freezes them as if you know, freezes them in a way that does not cause an override mistake. And if we had such a freezing primitive, then we certainly hardened JavaScript would then use that freezing primitive rather than what we’re doing now freeze all of the intrinsics and our library routine that does a transit of lock freezing objects to tamperproof them would instead use a primitive to would make them exempt from the override mistake. The reason why that should be strongly preferred rather than just manually installing these accessors everywhere, the reason why we have an enablements list rather than just installing the accessors everywhere, is that the accessors are significantly expensive. And the place where it’s most painful is the accessor, is the accessor that is the one that we, that has the highest priority to turn on, which is object.prototype.toString. The expense is not the setter, obviously, we don’t care, there’s no code we’re aware of that cares how much time it takes to assign to it. The problem is that once you make it into an accessor, then every read from the property becomes a call to the getter. -JHD: I wanted to clarify, Mark, I’m not necessarily suggesting that we put accessors all over the -place. I'm suggesting if we perhaps pursue changing it so that when you try to write to a property and it goes up the prototype chain, looking that as soon as it finds one that’s not writable, it just goes back to the previous one in the chain. In other words, I’m saying change the semantics there, because accessors are not required. +JHD: I wanted to clarify, Mark, I’m not necessarily suggesting that we put accessors all over the place. I'm suggesting if we perhaps pursue changing it so that when you try to write to a property and it goes up the prototype chain, looking that as soon as it finds one that’s not writable, it just goes back to the previous one in the chain. In other words, I’m saying change the semantics there, because accessors are not required. -MM: That would be the best solution from our perspective. That is exactly what we call fixing -the override mistake. Just changing the language so there is no override mistake. And I think -it was, I think it’s Daniel Ehrenberg who brought up that, even though there was an instrumented experiment to try to do this in the past that failed. -Daniel, please correct me, jump in and correct me if I’m wrong, but I think you were suggesting -that it might be the case that if we simply tried the instrumented experiment today that we -would find that we actually could just fix the override mistake across the language. +MM: That would be the best solution from our perspective. That is exactly what we call fixing the override mistake. Just changing the language so there is no override mistake. And I think it was, I think it’s Daniel Ehrenberg who brought up that, even though there was an instrumented experiment to try to do this in the past that failed. +Daniel, please correct me, jump in and correct me if I’m wrong, but I think you were suggesting that it might be the case that if we simply tried the instrumented experiment today that we would find that we actually could just fix the override mistake across the language. -DE: I’m not sure exactly what I said, then, but at this point, I wouldn’t be quite so -confident in that, but I mean, it’s I think it’s worth looking into the various possible fixes -of the different kinds that we’re discussing. But at the same time, this particular one, I -wouldn’t be opposed to doing this one-off change. You know, even short of a more general fix. +DE: I’m not sure exactly what I said, then, but at this point, I wouldn’t be quite so confident in that, but I mean, it’s I think it’s worth looking into the various possible fixes of the different kinds that we’re discussing. But at the same time, this particular one, I wouldn’t be opposed to doing this one-off change. You know, even short of a more general fix. -MM: Yeah, hopefully we can get airgap.js to just change the code on our side, which gets rid of -the single property emergency, and if that can happen, then we’ve got the breathing room to try -for some holistic solution. +MM: Yeah, hopefully we can get airgap.js to just change the code on our side, which gets rid of the single property emergency, and if that can happen, then we’ve got the breathing room to try for some holistic solution. -DE: I like the idea of capping this to two months, given that we already know that there’s very -strong developer demand for this, or if we want to delay it further, we could just not ship the -iterator global object, just you wouldn’t have iterator.from, that would be quite. In. But that’s another option. I want to not delay due to iterator helper due to an issue we’ve been stalled on for ten years. +DE: I like the idea of capping this to two months, given that we already know that there’s very strong developer demand for this, or if we want to delay it further, we could just not ship the iterator global object, just you wouldn’t have iterator.from, that would be quite. In. But that’s another option. I want to not delay due to iterator helper due to an issue we’ve been stalled on for ten years. -MM: There’s one further option I want to raise, which is if the iterator prototype were an -exotic object, it is allowed by the object invariants for the property to act like an accessor property, but report itself as a data property. And the reason why I’m bringing this up is that if you do it as an accessor, then it becomes part of the language, and if we do a holistic solution later, then there might be code by then that depends on this one being an accessor. +MM: There’s one further option I want to raise, which is if the iterator prototype were an exotic object, it is allowed by the object invariants for the property to act like an accessor property, but report itself as a data property. And the reason why I’m bringing this up is that if you do it as an accessor, then it becomes part of the language, and if we do a holistic solution later, then there might be code by then that depends on this one being an accessor. -DE: I suspect that that would risk additional implementation costs and even performance costs to -an implementation for the prototype or a proxy instead of a full object. +DE: I suspect that that would risk additional implementation costs and even performance costs to an implementation for the prototype or a proxy instead of a full object. MM: I wouldn’t make it into a proxy. -DE: Sorry, I was being sloppy with the words, but it would be valid with what you’re saying as a -proxy just to valid to implement anything as a proxy and expecting engines to make a specialized code path for that is just a lot of potential implementation burden. +DE: Sorry, I was being sloppy with the words, but it would be valid with what you’re saying as a proxy just to valid to implement anything as a proxy and expecting engines to make a specialized code path for that is just a lot of potential implementation burden. MM: Okay, I understand, and if I implement, I certainly find it plausible for implementers to see this as an undue burden, in which case, I certainly would not push this one. It’s a really very localized wart. -DE: The other thing is we might ship it as accessors and it might be web compatible later to do -something else. I wouldn’t really want to plan on that. I don’t understand why you suspect giving a proxy -gives you, sorry, not a proxy, but an exotic object gives us more flexibility than this? +DE: The other thing is we might ship it as accessors and it might be web compatible later to do something else. I wouldn’t really want to plan on that. I don’t understand why you suspect giving a proxy gives you, sorry, not a proxy, but an exotic object gives us more flexibility than this? -MM: Because a plain object has no way to have a property that acts as an accessor but reports -itself as a data property. +MM: Because a plain object has no way to have a property that acts as an accessor but reports itself as a data property. DE: I understand the fix you’re proposing. -CDA: I think we have next steps for this concrete proposal here, which is to continue trying for -maximum of this meeting to the next meeting on this social fix. And then if that doesn’t work, -then next meeting, try to hammer out a solid conclusion for what semantic changes we’ll make, +CDA: I think we have next steps for this concrete proposal here, which is to continue trying for maximum of this meeting to the next meeting on this social fix. And then if that doesn’t work, +then next meeting, try to hammer out a solid conclusion for what semantic changes we’ll make, whether that will be this patch or something else. Is that an agreeable conclusion? -MM: I’m fine with that. And I also will take away from this discussion to raise the urgency of -trying to put a more holistic solution, as Jordan puts it, in front of the committee, whether -that’s just fixing the override mistake or whether that’s a different kind of freezing. +MM: I’m fine with that. And I also will take away from this discussion to raise the urgency of trying to put a more holistic solution, as Jordan puts it, in front of the committee, whether that’s just fixing the override mistake or whether that’s a different kind of freezing. CDA: Shu has a reply on the queue. -SYG: The concrete suggestion sounds good to Chrome, but I want to add some more nuance about the -timeline here. If between this meeting and the next we get a thumbs up from transcend that -they have updated their customers, that is probably not enough time for Chrome to reship to -stable to get a new signal, whether it broke other stuff. This is something I’m trying to get a -new policy for international internally, but there is currently no policy ship and reship it in -the middle of another stable release that’s already happening. What would happen now is that -it’s been unshipped and once we get the thumbs up, we can flip the flag again and have it ride -the release trains from canary to beta to stable, and it’s likely just like this time that we’re -not going to get any representative data until it hits stable again, so once we get the thumbs -up, it might still be a few months until we get the true signal whether it’s okay or not. +SYG: The concrete suggestion sounds good to Chrome, but I want to add some more nuance about the timeline here. If between this meeting and the next we get a thumbs up from transcend that they have updated their customers, that is probably not enough time for Chrome to reship to stable to get a new signal, whether it broke other stuff. This is something I’m trying to get a new policy for international internally, but there is currently no policy ship and reship it in the middle of another stable release that’s already happening. What would happen now is that it’s been unshipped and once we get the thumbs up, we can flip the flag again and have it ride the release trains from canary to beta to stable, and it’s likely just like this time that we’re not going to get any representative data until it hits stable again, so once we get the thumbs up, it might still be a few months until we get the true signal whether it’s okay or not. -DE: So to summarize, we might have a negative signal, but we won’t have a definitive positive -signal before the next meeting, so, yeah, it’s okay for us to potentially wait longer, that’s the question for the committee, do we want to call it quits now or try again, and we won’t know that for sure it works for a little bit longer. +DE: So to summarize, we might have a negative signal, but we won’t have a definitive positive signal before the next meeting, so, yeah, it’s okay for us to potentially wait longer, that’s the question for the committee, do we want to call it quits now or try again, and we won’t know that for sure it works for a little bit longer. SYG: To make it clear, to recap, I think the best case scenario is that before the next meeting, airgap.js says we have updated our customers. At some point before or right after the next meeting, Chrome reships and it’s probably not until 2024 some time, the next next meeting or the next next next meeting that we have a true signal that we have fixed the issue or we have not. That is the best case for not doing any redesign on the proposal. The alternative is at any point, we decide to change the proposal, and if we go through the same thing again, we ship or Safari ships or FireFox ships and then we see what happens. CDA: JHD had a reply. -JHD: I think if by the next meeting we’ve gotten the positive signal from airgap that we’ve -found out that it cannot work. This is a weird hacky thing, so I think as much as everybody -really wants to see this proposal land, I think the wrong thing lasts forever here, so it’s -better to make people wait another couple months than to forever do the wrong -thing. +JHD: I think if by the next meeting we’ve gotten the positive signal from airgap that we’ve found out that it cannot work. This is a weird hacky thing, so I think as much as everybody really wants to see this proposal land, I think the wrong thing lasts forever here, so it’s better to make people wait another couple months than to forever do the wrong thing. CDA: Okay, we have agreement from Michael Saboff MS, RGN, and there is a reply. -LCA: Is it possible in this case for chrome record, the release, the entire ship train to reship? +LCA: Is it possible in this case for chrome record, the release, the entire ship train to reship? Is this something you can investigate internally? SYG: I’m investigating getting a policy in place for such quick reships. This is not something we have a policy for and this is not something that the release people want to do. I think it’s too risky, and I don’t think this one TC39 proposal, they’re going to approve it as an exception. CDA: We have a minute and a half left. Nicolo is on the queue. -NRO: If you don’t want to wait too long to ship this, could we ship it without the constructor -property until when we know it’s safe to do so? Because, like, I know that that’s burden of -polyfill containers and people that care about compat matters, but, like, in practice, would this be -an okay way to, like, avoid this hack, if we cannot solve the problem quick enough? +NRO: If you don’t want to wait too long to ship this, could we ship it without the constructor property until when we know it’s safe to do so? Because, like, I know that that’s burden of polyfill containers and people that care about compat matters, but, like, in practice, would this be an okay way to, like, avoid this hack, if we cannot solve the problem quick enough? -JWK: I think it’s not possible because the iterator prototype is already reachable via -Array#values. The iterator prototype is already existed and this proposal just exposes it on the global. You cannot really move a thing from it. +JWK: I think it’s not possible because the iterator prototype is already reachable via Array#values. The iterator prototype is already existed and this proposal just exposes it on the global. You cannot really move a thing from it. -CDA: Okay, last on the queue is Jordan. Plus one to drop constructor and toStringTag -temporarily in the meantime. End of message. +CDA: Okay, last on the queue is Jordan. Plus one to drop constructor and toStringTag temporarily in the meantime. End of message. -JHD: I did just want to add to Jack’s comment, the hidden iterator intrinsic does not have a -iterator property. It tries to add it. It will fall back to object.prototype. +JHD: I did just want to add to Jack’s comment, the hidden iterator intrinsic does not have a iterator property. It tries to add it. It will fall back to object.prototype. JWK: Oh, I don’t know that, if that’s the case, maybe we can do it. -CDA: Okay, we are at time. So I’m going to ask to move on, Shu. Or, Shu, you’re up next again -with resizable buffers. +CDA: Okay, we are at time. So I’m going to ask to move on, Shu. Or, Shu, you’re up next again with resizable buffers. -SYG: I guess conclusion for this one, I think, but I just want to double-check, I want to ask -consensus for waiting on transcend until the next meeting and be ready with your opinions on -how we should fix this if transcend does come back with a negative answer next meeting. Do we -have consensus on that? I’ll take that as a yes. +SYG: I guess conclusion for this one, I think, but I just want to double-check, I want to ask consensus for waiting on transcend until the next meeting and be ready with your opinions on how we should fix this if transcend does come back with a negative answer next meeting. Do we have consensus on that? I’ll take that as a yes. MM: I agree with that. @@ -1208,206 +830,101 @@ MLS: That sounds reasonable. CDA: Hearing no objections, okay. - ### Summary of Key Points ### Conclusion We'll wait until the next meeting to see if Transcend can upgrade their customers. If so, Chrome will attempt to re-ship the proposal as-is. If not, we'll discuss options at that meeting. -## Resizable buffers for Stage 4 +## Resizable buffers for Stage 4 + Presenter: Shu-yu Guo (SYG) - [proposal](https://github.com/tc39/proposal-resizablearraybuffer) -- [slides]() - -SYG: I see. Okay. Good news is, the bad news is it’s not updating even though I moved -the slides. You know, no, there it is. So the PR has been, the PR against spec of, to add -resizable buffers has been up and undergone many, many rounds of review and there have been no -normative changes since the last time this was presented in committee, last meeting. It’s -shipping in Chrome and Safari. The test 262 PR is up there. That converts, that moves -the, that migrates the test262 tests, which are currently in staging. That migrate them to -the main trunks of the test suite, organizes them according to how 262 organizes them, addings -some front matter, that kind of thing, so that PR, that adds a lot of tests. It’s very large. -There’s been some review delay from the maintainers, but it’s there. And then the PR below is the spec draft PR that adds it to 262. The other two 262 editors have reviewed it. jmdyck reviewed it pretty thoroughly and Anba reviewed it and it that has quieted it down. There’s some nits that have been fixed in the last round, but nothing substantive anymore. -All in all, things look pretty stable to me. And the response I got last time was let’s wait a -meeting for things to settle down before asking for stage 4, so here I am again. I would like -to ask for Stage 4 for resizable buffers. + +SYG: I see. Okay. Good news is, the bad news is it’s not updating even though I moved the slides. You know, no, there it is. So the PR has been, the PR against spec of, to add resizable buffers has been up and undergone many, many rounds of review and there have been no normative changes since the last time this was presented in committee, last meeting. It’s shipping in Chrome and Safari. The test 262 PR is up there. That converts, that moves the, that migrates the test262 tests, which are currently in staging. That migrate them to the main trunks of the test suite, organizes them according to how 262 organizes them, addings some front matter, that kind of thing, so that PR, that adds a lot of tests. It’s very large. +There’s been some review delay from the maintainers, but it’s there. And then the PR below is the spec draft PR that adds it to 262. The other two 262 editors have reviewed it. jmdyck reviewed it pretty thoroughly and Anba reviewed it and it that has quieted it down. There’s some nits that have been fixed in the last round, but nothing substantive anymore. +All in all, things look pretty stable to me. And the response I got last time was let’s wait a meeting for things to settle down before asking for stage 4, so here I am again. I would like to ask for Stage 4 for resizable buffers. CDA: We have Daniel Minor on the queue. -DLM: yeah, we definitely support Stage 4 and I just wanted to note our implementation -in SpiderMonkey is in progress. +DLM: yeah, we definitely support Stage 4 and I just wanted to note our implementation in SpiderMonkey is in progress. SYG: Thank you. -CDA: Nothing else on the queue. Do we have any other explicit support for stage 4 for resizable -buffers? It’s always nice to have a pool greater than one. +CDA: Nothing else on the queue. Do we have any other explicit support for stage 4 for resizable buffers? It’s always nice to have a pool greater than one. DE: It looks and seems good to me. CDA: Okay. Thank you, Daniel Ehrenberg. -SYG: This will be good. I think this will unblock the wasm integration side to get it -integrated into the JS WASM side because they don’t normally reference non-Stage 4 things. So -let’s get it merged into the PR and then, yeah, then WASEM can use it. All right. Thanks. +SYG: This will be good. I think this will unblock the wasm integration side to get it integrated into the JS WASM side because they don’t normally reference non-Stage 4 things. So let’s get it merged into the PR and then, yeah, then WASEM can use it. All right. Thanks. + ### Conclusion -Consensus for Stage 4 -Once merged into ecma262, Wasm/JS integration will be unblocked + +Consensus for Stage 4 Once merged into ecma262, Wasm/JS integration will be unblocked ## Stage 3 update of Intl Locale Info API + Presenter: Frank Yung-Fong Tang (FYT) - [proposal](https://github.com/tc39/proposal-intl-locale-info) -[slides](https://docs.google.com/presentation/d/1pr3lp_gPcaitmmiQZq2xQGEoG-1cfpOU1agLKAYmPqQ/edit) -FYT: Okay. Hi, everybody. My name is Frank tong. Thank you for giving me a chance to talk -about update of the Intl locale info API, which is for ECMA 402 and currently in Stage 3, so I -wanted to give you an update. There’s no changes here. So the agenda we will give a very -brief introduction and seek for a consensus for specific change, and then I will brief you -about some issue that have bring up TG2 and during TG2, thing not worth it to bring to here -because I think the issue just, we don’t think we want to change the spec at Stage 3. And -there’s another pending issue we wanted to update, which is blocked by CLDR, and then there are -a couple issue, we don’t have the chance to talk about it, so just let you know, so in case -you’re interested in that, you can come to TG2 for discussion, and after we have some -understanding, we’ll bring it up to here. - -So first of all, the motivation for the Intl locale API is to expose locale -information, such as a week data, like the first day of the week, weekend starting day, and -weekend end day, or sometimes which day is that, and the minimum day in the first week, which -is dependent on locale. And even our cycle used in the locale. So here are some of the -history. And I think I’ll focus on a couple things. First is the advancing Stage 3 in -April 2021, but then there are a couple changes. We figured out there’s an issue about the -getters. We changed the function. And the last time there was some issue, to address because -we realized that the locale may have an FW extension, which have first day of week impact, and -I think Andrea from Mozilla raised that issue, so we tried to address that. Unfortunately, -there were some issues that we cannot reach consensus, so we went back to discuss with TG2 and -have an update proposal today, and this is the first thing we want to talk about. - -So I’ll give you some background. The Intl locale itself, that have the return, one of the -methods called getWeekInfo, and it has a field called firstDay. And currently it’s a defined -to return from 1, 2, 3, 4, 5, 7 to indicate whether that’s Monday to Sunday have the -synchronized value with what Temporal defines. One of the issues, so is key issue that raised -causing this change is that the locale itself could help this extension SW, which is defined by -the UTS35 as the first day identified, which overrides whatever the locale’s default validator. -And that location is the clearly defined that the value are three letter code, Sun, Mon, or Sat -and this is mandated by UTS35. But in JavaScript when we try to pass anything into option -value or return value, we have our own definition, and this is what we proposed last time. -These four items, and the first two items are not a problem. I think we reached consensus last -time that that’s not an issue. Actually, it’s the first three. The issue is the fourth one, -the Firth (Fifth or Forth?) one, which I circled with the red dot. Whether when we read the option, should we -read at Monte or reopt the thing. I think people feeling that when we read option, we should -also take the value, not just whether the UTF35 defined, but also the 0 and 1, 2, 3, 4, 5, 7 -that JavaScript defined. Because zero actually is used by the date object, and to represent -Sunday, and 7 is actually by Temporal to represent Sunday. The second issue is that whenever -the value return, should that return change to that? And that part is not, we don’t reach -a consensus. - -So we went back to TG2 and discussed that, so now that two part got replaced with the following -concept, and put it into the PR70. And the first one, the get option we decide were code would -read these 15 different values. Right? Seven string of three-letter -string, and eight single digit string. It’s a string read, but the string read will also, if -you send the thing that pass this is a numeric 0 to 7, it will also call toString -to convert it to a string 0 to 7. So this 15 different value will be accepted by the read -option. And whatever we’re calling the first day of week, the value get in, or the get with -info, it will always return either undefined, which mean that if nobody solidified that in the -locale itself or by the option, or one to seven, which means they have specified, but either -way, and one is defined to be represent Monday and seven will represent Sunday, which is -synchronized to the Temporal definition. So this is the, but unfortunately, we kind of -discussed this in the offline discussion when we run out of time. So we kind of not in -official time there, so we have a lot of online discussion, but whenever TG2 is kind of, okay, -five minutes after the time we discussed, so we kind of have a tentative agreement there, but -we decide we’re going to bring it up to here and make sure nobody object to that, because TG2 -really holding accommodation and here, we’re making the consensus. So it’s still bringing -here. So this is coded in PR70, so this is the issue. Any questions about this so far? +FYT: Okay. Hi, everybody. My name is Frank tong. Thank you for giving me a chance to talk about update of the Intl locale info API, which is for ECMA 402 and currently in Stage 3, so I wanted to give you an update. There’s no changes here. So the agenda we will give a very brief introduction and seek for a consensus for specific change, and then I will brief you about some issue that have bring up TG2 and during TG2, thing not worth it to bring to here because I think the issue just, we don’t think we want to change the spec at Stage 3. And there’s another pending issue we wanted to update, which is blocked by CLDR, and then there are a couple issue, we don’t have the chance to talk about it, so just let you know, so in case you’re interested in that, you can come to TG2 for discussion, and after we have some understanding, we’ll bring it up to here. + +So first of all, the motivation for the Intl locale API is to expose locale information, such as a week data, like the first day of the week, weekend starting day, and weekend end day, or sometimes which day is that, and the minimum day in the first week, which is dependent on locale. And even our cycle used in the locale. So here are some of the history. And I think I’ll focus on a couple things. First is the advancing Stage 3 in April 2021, but then there are a couple changes. We figured out there’s an issue about the getters. We changed the function. And the last time there was some issue, to address because we realized that the locale may have an FW extension, which have first day of week impact, and I think Andrea from Mozilla raised that issue, so we tried to address that. Unfortunately, +there were some issues that we cannot reach consensus, so we went back to discuss with TG2 and have an update proposal today, and this is the first thing we want to talk about. + +So I’ll give you some background. The Intl locale itself, that have the return, one of the methods called getWeekInfo, and it has a field called firstDay. And currently it’s a defined to return from 1, 2, 3, 4, 5, 7 to indicate whether that’s Monday to Sunday have the synchronized value with what Temporal defines. One of the issues, so is key issue that raised causing this change is that the locale itself could help this extension SW, which is defined by the UTS35 as the first day identified, which overrides whatever the locale’s default validator. +And that location is the clearly defined that the value are three letter code, Sun, Mon, or Sat and this is mandated by UTS35. But in JavaScript when we try to pass anything into option value or return value, we have our own definition, and this is what we proposed last time. +These four items, and the first two items are not a problem. I think we reached consensus last time that that’s not an issue. Actually, it’s the first three. The issue is the fourth one, +the Firth (Fifth or Forth?) one, which I circled with the red dot. Whether when we read the option, should we read at Monte or reopt the thing. I think people feeling that when we read option, we should also take the value, not just whether the UTF35 defined, but also the 0 and 1, 2, 3, 4, 5, 7 that JavaScript defined. Because zero actually is used by the date object, and to represent Sunday, and 7 is actually by Temporal to represent Sunday. The second issue is that whenever the value return, should that return change to that? And that part is not, we don’t reach a consensus. + +So we went back to TG2 and discussed that, so now that two part got replaced with the following concept, and put it into the PR70. And the first one, the get option we decide were code would read these 15 different values. Right? Seven string of three-letter string, and eight single digit string. It’s a string read, but the string read will also, if you send the thing that pass this is a numeric 0 to 7, it will also call toString to convert it to a string 0 to 7. So this 15 different value will be accepted by the read option. And whatever we’re calling the first day of week, the value get in, or the get with info, it will always return either undefined, which mean that if nobody solidified that in the locale itself or by the option, or one to seven, which means they have specified, but either way, and one is defined to be represent Monday and seven will represent Sunday, which is synchronized to the Temporal definition. So this is the, but unfortunately, we kind of discussed this in the offline discussion when we run out of time. So we kind of not in official time there, so we have a lot of online discussion, but whenever TG2 is kind of, okay, +five minutes after the time we discussed, so we kind of have a tentative agreement there, but we decide we’re going to bring it up to here and make sure nobody object to that, because TG2 really holding accommodation and here, we’re making the consensus. So it’s still bringing here. So this is coded in PR70, so this is the issue. Any questions about this so far? Because the other thing is easy, just update. But this part needs some discussion. -Okay. If not, then I’ll continue. So there are two other issue, and I will come back after -consensus and update the other part. Two other things we have resolved is one of them is that -I think Andrea suggest, the get time zone, if there are nothing passing in, if there are no -definition of the string regional subtext, then we can just do something similar to get with -info and get our cycles to automatically maximize the locale. So let’s say you EN, you -maximize the EN US, and then to get the info based on the US and get our cycle, but in TG2, I -think we have discussed that part. People feel uncomfortable with that. So currently, the -specs just return undefined, you know, if we don’t have region, we just say, well, we don’t -know. We cannot tell what the time zone is for English, right? If you say time zone for US -English, we know what kind of time zone could be using, US, but we don’t want to guess what -would be the time zone for English, which is too much a guess. - -So the TG2 recommendation is that we don't change it. The other thing, the issue about the forward -compatibility issue with the get time zone, because in the locale, there are another shorthand -name, five character name for time zone, and TG2 discuss it and spent a lot of time and we -decided if that thing comes out, we may use a different name to represent that. Right now there -are no use cases to strongly suggest that we should support same thing, and we do not believe -that will cause forward compatibility issues if we somehow keep a name space for that. So we’re -not going to reuse the name for get time zone. We’re using something else. So then -because somewhere else we also have calendar, so we believe we shouldn’t need to change the, whatever currently we already have, the function called get time zones to get time zone ID. So -we just keep it in, get time zones. So those two things got resolved without any change or spec. -The other thing is we currently still have the issue that if somehow the locale have a "ca", -which mean calendar information, then what is their interaction between that to decide to first -day of week. For example, you may have those, the calendar to be iso 8601 and also have the FW -to define FW as Wednesday, right? Then whether you should listen to the iso 8601 to use Monday -or listen to the FW. And that part is actually, we believe it shouldn’t be defined inside the -spec first. We should delegate to CLDR. And we filed a ticket for CLDR and they agreed to -take action on that. So currently they are scheduled to put that into CLDR44 specification. -The specification change is on progress and once it gets released of that, so we will defer our -reason to that, or we’ll have some odd reason defined synchronized to whatever date -defined. So we don’t need to discuss here, but I will bring that back later on whenever they -make that change. Because that won’t be a normative change. We need consensus. So far it’s -too early. - -Then there’s another suggestion, and they say, whether locale info should return me what -incurs to be used in this locale. As a champion, I think it’s a good idea, but since it’s already way past Stage 3 time, this kind of scope change, we’re going to defer that for a later version once this version, we’ll do Stage 4 and then maybe add a second version adding a PR for that. But so far we are not planning to do that here. So now is what I ask, the big question, can we get consensus for PR70, which I talked about earlier? Any questions or any support? +Okay. If not, then I’ll continue. So there are two other issue, and I will come back after consensus and update the other part. Two other things we have resolved is one of them is that I think Andrea suggest, the get time zone, if there are nothing passing in, if there are no definition of the string regional subtext, then we can just do something similar to get with info and get our cycles to automatically maximize the locale. So let’s say you EN, you maximize the EN US, and then to get the info based on the US and get our cycle, but in TG2, I think we have discussed that part. People feel uncomfortable with that. So currently, the specs just return undefined, you know, if we don’t have region, we just say, well, we don’t know. We cannot tell what the time zone is for English, right? If you say time zone for US English, we know what kind of time zone could be using, US, but we don’t want to guess what would be the time zone for English, which is too much a guess. + +So the TG2 recommendation is that we don't change it. The other thing, the issue about the forward compatibility issue with the get time zone, because in the locale, there are another shorthand name, five character name for time zone, and TG2 discuss it and spent a lot of time and we decided if that thing comes out, we may use a different name to represent that. Right now there are no use cases to strongly suggest that we should support same thing, and we do not believe that will cause forward compatibility issues if we somehow keep a name space for that. So we’re not going to reuse the name for get time zone. We’re using something else. So then because somewhere else we also have calendar, so we believe we shouldn’t need to change the, whatever currently we already have, the function called get time zones to get time zone ID. So we just keep it in, get time zones. So those two things got resolved without any change or spec. +The other thing is we currently still have the issue that if somehow the locale have a "ca", +which mean calendar information, then what is their interaction between that to decide to first day of week. For example, you may have those, the calendar to be iso 8601 and also have the FW to define FW as Wednesday, right? Then whether you should listen to the iso 8601 to use Monday or listen to the FW. And that part is actually, we believe it shouldn’t be defined inside the spec first. We should delegate to CLDR. And we filed a ticket for CLDR and they agreed to take action on that. So currently they are scheduled to put that into CLDR44 specification. +The specification change is on progress and once it gets released of that, so we will defer our reason to that, or we’ll have some odd reason defined synchronized to whatever date defined. So we don’t need to discuss here, but I will bring that back later on whenever they make that change. Because that won’t be a normative change. We need consensus. So far it’s too early. + +Then there’s another suggestion, and they say, whether locale info should return me what incurs to be used in this locale. As a champion, I think it’s a good idea, but since it’s already way past Stage 3 time, this kind of scope change, we’re going to defer that for a later version once this version, we’ll do Stage 4 and then maybe add a second version adding a PR for that. But so far we are not planning to do that here. So now is what I ask, the big question, can we get consensus for PR70, which I talked about earlier? Any questions or any support? CDA: Daniel Minor is in the queue. DLM: Yeah. That looks good to us. -CDA: Thank you. Any other words of support? Shane? +CDA: Thank you. Any other words of support? Shane? -SFC: Just noting that this new proposal or how to solve this is a direct response to feedback -from delegates in July, so if those delegates who encouraged us to go this direction could also -fully support, that would be great. If not, I assume we’re okay with that. +SFC: Just noting that this new proposal or how to solve this is a direct response to feedback from delegates in July, so if those delegates who encouraged us to go this direction could also fully support, that would be great. If not, I assume we’re okay with that. -DE: I think I was one of those delegates. I think this looks good, but I want to spend a little -more time looking at this. Apologies for not doing that before the meeting. +DE: I think I was one of those delegates. I think this looks good, but I want to spend a little more time looking at this. Apologies for not doing that before the meeting. CDA: Nicolo. -NRO: We talk about this internally, this approach feels weird. Like, we don’t come up with any -better solution, so it’s supported by us. +NRO: We talk about this internally, this approach feels weird. Like, we don’t come up with any better solution, so it’s supported by us. FYT: Could you clarify when you say not particularly happy, what kind of thing bothers you? -NRO: Like, solving the problem first time is just adding more, like, values that have the same -meaning. +NRO: Like, solving the problem first time is just adding more, like, values that have the same meaning. FYT: I see. Yeah, that’s a lot of historical background, so I think as mentioned last time, there are really three different ways. One comes from date object, the another comes from Temporal and the other comes from UTC 35. I mean, the fact that Temporal and the date have a different value is whatever, within our control, but that’s not what I can handle this time. Because everything changed when Temporal goes Stage 3. -DE: When you say get option would return these things, when you look into resolved options, will -you see the output matches the form of the input? +DE: When you say get option would return these things, when you look into resolved options, will you see the output matches the form of the input? -FYT: No, it will not. So first of all, actually, I take it back. There are no resolver -options for this particular object. So your question is asking non-existence. There are no -such thing called, get result option. Intl locale have no such option. Intl locale do have the -get or of the first day of week, and we’re just showing this slide. +FYT: No, it will not. So first of all, actually, I take it back. There are no resolver options for this particular object. So your question is asking non-existence. There are no such thing called, get result option. Intl locale have no such option. Intl locale do have the get or of the first day of week, and we’re just showing this slide. -DE: So what did you mean by numbers 0-7 whether turn into quotes, 0 to 7? Will it turn into -the number 1 to 7? +DE: So what did you mean by numbers 0-7 whether turn into quotes, 0 to 7? Will it turn into the number 1 to 7? -FYT: So let’s say you pass it in object, right? And the object you may have a, will have -the first day of week, and the value is number 0 to 7, but because in our get option, we are -specifying the type, see the third parameter here? We’re trying to get option the type to -solidify the string, so internally inside the get option abstraction, abstract operation, it -will call the two strings. So 0 to 7 will be called to two string, and that two string will -turn that thing into 0 to 7 as a string form to be read. +FYT: So let’s say you pass it in object, right? And the object you may have a, will have the first day of week, and the value is number 0 to 7, but because in our get option, we are specifying the type, see the third parameter here? We’re trying to get option the type to solidify the string, so internally inside the get option abstraction, abstract operation, it will call the two strings. So 0 to 7 will be called to two string, and that two string will turn that thing into 0 to 7 as a string form to be read. -DE: Yeah, that seems fine. This is a good response to my feedback, which was fundamentally -about making sure that the first day of the week equals Temporal’s understanding of days of the -week, and I think this does a good job of that. +DE: Yeah, that seems fine. This is a good response to my feedback, which was fundamentally about making sure that the first day of the week equals Temporal’s understanding of days of the week, and I think this does a good job of that. -FYT: Right, so both 0 as a string and number as a string will be, eventually be handled -internally. The option is calling the, asking for a type of string. +FYT: Right, so both 0 as a string and number as a string will be, eventually be handled internally. The option is calling the, asking for a type of string. DE: That’s fine. We have all sorts of artifacts due to casting. This is just another. @@ -1415,97 +932,96 @@ FYT: And the return value would be either undefined or numeric 1 to 7. DE: Wait, when is it undefined? -FYT: Undefined means that no one specifies that. Let’s say you have a locale called EN. You have -no value for the first day of week. +FYT: Undefined means that no one specifies that. Let’s say you have a locale called EN. You have no value for the first day of week. DE: It won’t look it up like locale info the first day of the week for EN. -FYT: No, it won’t. Because the locale is what you specify, it is whatever you specify. So if you don’t define -it, you have to tell it you we don’t define it. This is a different -- this is not a -formatting object. This is a representing the locale. +FYT: No, it won’t. Because the locale is what you specify, it is whatever you specify. So if you don’t define it, you have to tell it you we don’t define it. This is a different -- this is not a formatting object. This is a representing the locale. -DE: Wait, does locale info have a way of getting the first day of the week? What does it return -it as? +DE: Wait, does locale info have a way of getting the first day of the week? What does it return it as? SFC: There is a function which will get the computed result from CLDR. This is intl. locale.prototype. This is info in addition to adding the locale info is also adding this new locale keyword, which wasn’t there before. So we’re adding support for the new locale key, which is sort of a separate piece that the locale info is now requiring that we support. This day of week directly returns the value of the subtag and the locale without computing anything. - -EAO: this approach of being effectively [...], is right choice. It kind of being strict on the output, it is only offering the output in the same shape as Temporal is the right way. I like this. +EAO: this approach of being effectively [...], is right choice. It kind of being strict on the output, it is only offering the output in the same shape as Temporal is the right way. I like this. DLM [on queue]: Is implementation blocked on the upstream CLDR issue being resolved? -FYT: So the CLDR issue has nothing to do, was not dealing with this particular PR. There is a CLDC [blk]ing the implementation to be fully Stage 4. That will interact with that, but that is actually a separate, a kind of different issue than this. So this will take the FW in, whatever the CLDR issue, the implementation has to handle how to deal with the order between this value and the calendar. +FYT: So the CLDR issue has nothing to do, was not dealing with this particular PR. There is a CLDC [blk]ing the implementation to be fully Stage 4. That will interact with that, but that is actually a separate, a kind of different issue than this. So this will take the FW in, whatever the CLDR issue, the implementation has to handle how to deal with the order between this value and the calendar. DLM: Okay. Thank you. That’s why I removed myself from the queue because I realized you were talking about this at this moment. I was wondering because you had been asking in the past about SpiderMonkey’s progress on implementing this particular proposal, and my understanding is that we had been blocked on that issue which is now blocked on a CLDR issue, which was why I was asking the question -FYT: Yes. That is tracking, let me see. There’s a tracking on this particular one. Issue number 30. It is related, but it’s a separate one. +FYT: Yes. That is tracking, let me see. There’s a tracking on this particular one. Issue number 30. It is related, but it’s a separate one. -DLM: Okay. Thank you. +DLM: Okay. Thank you. -FYT: And that brings up next time, before we move to Stage 4. It both needs to be there. Yeah. +FYT: And that brings up next time, before we move to Stage 4. It both needs to be there. Yeah. -DLM: Okay. Thank you. That clarifies things for me. +DLM: Okay. Thank you. That clarifies things for me. -CDA: Daniel? +CDA: Daniel? DE: The intl locale thing I was trying to remember was the prototype get week info and that uses numbers days of the week. I am not sure that was a change you made recently or part of this -FYT: This is the part. You see this part? Number 3. That will not be changed. So you’re right. There’s still there. They are two different things. One is when we have the locale, what the locale itself is. Okay? And the other is, with using this locale, what is the information about the week? Because you may have, let’s say you may have US. Right? And the US in the localee, firstDayOfWeek, is undefined because you only define US. But if you ask the US what is the first day in the get week info, it will say Sunday. +FYT: This is the part. You see this part? Number 3. That will not be changed. So you’re right. There’s still there. They are two different things. One is when we have the locale, what the locale itself is. Okay? And the other is, with using this locale, what is the information about the week? Because you may have, let’s say you may have US. Right? And the US in the localee, firstDayOfWeek, is undefined because you only define US. But if you ask the US what is the first day in the get week info, it will say Sunday. DE: Sorry. I was talking about locale info. Is this locale info or locale -FYT: because locale info has to depend on FW, we are adding the first day of the week into locale. In the same proposal. +FYT: because locale info has to depend on FW, we are adding the first day of the week into locale. In the same proposal. SFC: I think – I am next in the queue. I think Dan was asking about the locale info global, but I don’t think that’s a thing. Like, the getWeekInfo is on Intl.Locale.prototype DE: Right. Okay. Have you updated the README. Intl.Locale week info? -SFC: it’s called locale info, that’s the name of the proposal. +SFC: it’s called locale info, that’s the name of the proposal. -DE: Sorry. The Intl.Locale prototype get week info method in the, uses numbers in the README or the incident’ll locale info. And are you saying it uses numbers or strings? +DE: Sorry. The Intl.Locale prototype get week info method in the, uses numbers in the README or the incident’ll locale info. And are you saying it uses numbers or strings? -FYT: Thes README part? I am not 100%. I am not sure I changed the README part. I may have some. I don’t think we added that information to the README yet actually. +FYT: Thes README part? I am not 100%. I am not sure I changed the README part. I may have some. I don’t think we added that information to the README yet actually. -SFC: I think it’s the old `getWeekInfo().firstDay` is not changed by this. +SFC: I think it’s the old `getWeekInfo().firstDay` is not changed by this. -FYT: Yeah. +FYT: Yeah. -SFC: That’s used Temporal style numbers since this proposal reached stage 3. The only thing new is respecting the unicode extension called FW. So we are adding these two new things, the first is read for day of week option and the other is return firstDayOfWeek getter. Which are different than the rest of Intl locale info which is completely unchanged. It’s changed only in the sense it will reflect the firstDayOfWeek, if it was given as an option in the locale constructor. +SFC: That’s used Temporal style numbers since this proposal reached stage 3. The only thing new is respecting the unicode extension called FW. So we are adding these two new things, the first is read for day of week option and the other is return firstDayOfWeek getter. Which are different than the rest of Intl locale info which is completely unchanged. It’s changed only in the sense it will reflect the firstDayOfWeek, if it was given as an option in the locale constructor. -FYT: Right. The interface didn’t change for that part. It preexists. +FYT: Right. The interface didn’t change for that part. It preexists. -DE: Sorry. What is the motivation for this part of the design, it does not use numbers? In the firstDayOfWeek getter? +DE: Sorry. What is the motivation for this part of the design, it does not use numbers? In the firstDayOfWeek getter? -SFC: BPC47 defines these strings. +SFC: BPC47 defines these strings. -DE: Hmm. +DE: Hmm. -FYT: The wrap, this is something we did last time, so this is a real one. +FYT: The wrap, this is something we did last time, so this is a real one. -DE: Okay. I am happy with that. With that part. The API that you had circled in the red outlined is now part of the proposal? +DE: Okay. I am happy with that. With that part. The API that you had circled in the red outlined is now part of the proposal? FYT: This is the last time I bring it here. I wanted to make sure people understand what the wrap part is, we cannot reach consensus last time. So we come back to change and change to this one. The wrap part got replace with this one -DE: Great. I am happy with this proposal. +DE: Great. I am happy with this proposal. -FYT: Okay? Can I get a consensus or support for this change? Anyone support? +FYT: Okay? Can I get a consensus or support for this change? Anyone support? -CDA: A couple messages of support. Nicolo. Eemeli. Also Dan Ehernberg. +CDA: A couple messages of support. Nicolo. Eemeli. Also Dan Ehernberg. -FYT: Anyone object? +FYT: Anyone object? -FYT: Okay. Can I assume we got consensus, since we have one support and one object? Thank you. And so my request for the committee is to help us to have Firefox commitment. This is blocked by CLDR and improve text 262 coverage and polyfill. Thank you. +FYT: Okay. Can I assume we got consensus, since we have one support and one object? Thank you. And so my request for the committee is to help us to have Firefox commitment. This is blocked by CLDR and improve text 262 coverage and polyfill. Thank you. ### Conclusion -- Consensus reach for merging PR 70 + +- Consensus reach for merging PR 70 + ## AsyncIterator helper status update (Stage 2) + Presenter: Kevin Gibbons + - [proposal](https://github.com/tc39/proposal-async-iterator-helpers) - [slides](https://docs.google.com/presentation/d/1nQvAwvOQ0gDJ-eLIVIy3rYrlZj3qGvPHCeH_Veba2cc/edit) KG: This is going to be a brief update on the AsyncIterator helpers proposal, which, a reminder, briefly, was at Stage 3 and withdrawn back to Stage 2 when we realized we could use this as a sort of concurrency primitive. The proposal repo hasn’t been updated heavily because the design is in flux, but please visit the Github and contribute thoughts. -KG: I will start with reminding you of the key points. If you have code like this, you might expect to be able to do two fetches concurrently. And indeed you can if we spec this correctly. So you get concurrency between things within a mapping function or a filter, and it gives you concurrency between a mapping function and the underlying producer of values, the underlying AsyncIterator. And crucially, as with all iterators, the operation is driven by the consumer pulling from the producer, so there’s no new issues with backpressure. You just don’t consume values until you’re ready to consume them. +KG: I will start with reminding you of the key points. If you have code like this, you might expect to be able to do two fetches concurrently. And indeed you can if we spec this correctly. So you get concurrency between things within a mapping function or a filter, and it gives you concurrency between a mapping function and the underlying producer of values, the underlying AsyncIterator. And crucially, as with all iterators, the operation is driven by the consumer pulling from the producer, so there’s no new issues with backpressure. You just don’t consume values until you’re ready to consume them. KG: There’s a new helper. I previously referred to this as `bufferAhead`. I have renamed it to `buffered` for reasons we'll get to. It pulls a few values at once which starts off the process of concurrency. Okay. So that’s the basic shape of the proposal. @@ -1525,11 +1041,11 @@ KG: Also, I learned recently that Rust has almost exactly this helper as a way t KG: That’s not quite the same as AsyncIterator, but it's close. It gives you concurrency the same way. I was excited to learn that. That’s also why I have renamed the bufferAhead helper to be buffered because that’s what Rust calls it. It gives me more confidence in the design, because I hadn’t found anyone doing this. Finding that at least one other person thought this was a good idea makes me feel better about it. -KG: Next thing is that, a lot of times you don’t care about the order. You just want to do things concurrently and deal with them as fast as possible. And there are a few different ways to support that. For example, you might have unordered variants of the relevant functions. Or you might have a method that switches to an unordered helpers prototype and have all of the helpers unordered thereafter. Or you might have a buffer_unordered helper. That’s what Rust does. I cannot figure out if or how that would work with filter. It makes sense how you can do an ordered buffer for map. Filter, the order of the promises depends on previous promises. I don’t know how to make that work. I haven’t had time to experiment. If you have experience with this, I would love to hear from you. +KG: Next thing is that, a lot of times you don’t care about the order. You just want to do things concurrently and deal with them as fast as possible. And there are a few different ways to support that. For example, you might have unordered variants of the relevant functions. Or you might have a method that switches to an unordered helpers prototype and have all of the helpers unordered thereafter. Or you might have a buffer_unordered helper. That’s what Rust does. I cannot figure out if or how that would work with filter. It makes sense how you can do an ordered buffer for map. Filter, the order of the promises depends on previous promises. I don’t know how to make that work. I haven’t had time to experiment. If you have experience with this, I would love to hear from you. KG: My current plan is not to do any of these for the V1. The proposal is complicated enough. If you feel strongly, like Michael, that these need to be included, help me work on the design. Especially if you can help me figure out if you can get filter to work with the unordered thing. That is my preferred solution, if it works. -KG: I mentioned this last time, but I don’t have a solution for it, it’s still a problem. Consuming helpers, like `some` and `forEach`, don’t have a way to specify concurrency because the whole point of this design is that it’s consumer-driven concurrency and these helpers are the consumer. So how do you get concurrency if you are calling one of these consuming helpers? I genuinely don’t know. You can work around it by doing a map of the function and then buffering and then doing the identity function at the end. That doesn’t work for find, it’s even more complicated for find. But it's doable. +KG: I mentioned this last time, but I don’t have a solution for it, it’s still a problem. Consuming helpers, like `some` and `forEach`, don’t have a way to specify concurrency because the whole point of this design is that it’s consumer-driven concurrency and these helpers are the consumer. So how do you get concurrency if you are calling one of these consuming helpers? I genuinely don’t know. You can work around it by doing a map of the function and then buffering and then doing the identity function at the end. That doesn’t work for find, it’s even more complicated for find. But it's doable. So we could have a separate concurrency parameter. That’s another way. It's convenient. It would mean that the signature would get more complicated for these consuming helpers. But maybe it’s worth it. I don’t know. @@ -1542,55 +1058,57 @@ I want to do that so we have the option available to us, but it would be a thing KG: The last one, the plan is for the buffered helper to not start doing work right away. It only starts doing work once you pull from it. I do think that’s the right default. But it’s actually nice to be able to start work early. And it’s impractical to do that yourself, you need the helper to help you out with that. Maybe we should have an option to opt in. I am leaning towards having an option to opt in. But mostly because it seems like it’s hard to do, and it might occasionally be useful and not something all the time. If you feel strongly we should stick to the simpler design, I am okay with that as well. -KG: Yeah. The call to action here is, please come help think about these problems. There’s a decent bit of design space. I think that this will be one of the first concurrency primitives in the language. I am trying to do it right, and review what other people are doing and thinking about RX and other languages and - like I found a library in Java that does things this way as well. I would just love more participation for thinking through all of these problems I have raised and others that I haven’t talked about. Yeah. That’s the update. I am working on all this stuff. Hopefully I will have these settled and bring a pollyfill at the next meeting. It remains to be seen if I have time to finish that. Do we have anything in the queue? +KG: Yeah. The call to action here is, please come help think about these problems. There’s a decent bit of design space. I think that this will be one of the first concurrency primitives in the language. I am trying to do it right, and review what other people are doing and thinking about RX and other languages and - like I found a library in Java that does things this way as well. I would just love more participation for thinking through all of these problems I have raised and others that I haven’t talked about. Yeah. That’s the update. I am working on all this stuff. Hopefully I will have these settled and bring a pollyfill at the next meeting. It remains to be seen if I have time to finish that. Do we have anything in the queue? -CDA: Yes. RGN is first. Just be mindful we have less than 5 minutes. +CDA: Yes. RGN is first. Just be mindful we have less than 5 minutes. -RGN: Okay. So first off, I wanted to thank the deep analysis that you’ve done on this. It’s really inspiring and appreciated. We are in favour of determinism rather than raciness. Unordered ones, I don’t think we have got an opinion just yet. And this call to action is probably something that someone from Agoric will answer. Thank you. +RGN: Okay. So first off, I wanted to thank the deep analysis that you’ve done on this. It’s really inspiring and appreciated. We are in favour of determinism rather than raciness. Unordered ones, I don’t think we have got an opinion just yet. And this call to action is probably something that someone from Agoric will answer. Thank you. -KG: Great to hear. +KG: Great to hear. -CDA: Luca? +CDA: Luca? -LCA: (I am very happy with this direction. I have used `futures::stream` in Rust a lot, and it works very well as a concurrency primitive.) Yeah. Someone who used this, future streams in Rust, recently, i’m quite happy with that direction. It’s a great primitive for concurrency. I think personally, I have used buffered unordered more than buffered in Rust. And yeah. There’s use cases for ordered concurrency too, but I think especially, I guess I can combine this with the next appointment. For example, concurrency and some, buffer and ordered, this is a way for some to effectively run things con specify not the predicate in some is async. +LCA: (I am very happy with this direction. I have used `futures::stream` in Rust a lot, and it works very well as a concurrency primitive.) Yeah. Someone who used this, future streams in Rust, recently, i’m quite happy with that direction. It’s a great primitive for concurrency. I think personally, I have used buffered unordered more than buffered in Rust. And yeah. There’s use cases for ordered concurrency too, but I think especially, I guess I can combine this with the next appointment. For example, concurrency and some, buffer and ordered, this is a way for some to effectively run things con specify not the predicate in some is async. -KG: There’s no way to get concurrency between calls to the predicate. +KG: There’s no way to get concurrency between calls to the predicate. -LCA: What if you have a buffer unordered after the sum? +LCA: What if you have a buffer unordered after the sum? -KG: It doesn’t, it returns a value. That’s the problem. It consumes the iterator. +KG: It doesn’t, it returns a value. That’s the problem. It consumes the iterator. -LCA: I see. Right. Right. Okay. +LCA: I see. Right. Right. Okay. KG: If that’s not something that you have run into in Rust, that’s good feedback. -LCA: I will check to see if we have anything like this. +LCA: I will check to see if we have anything like this. -KG: I would also love to hear if you run into the thing where you do a filter and then a buffer unordered. I cannot figure out how that would work. +KG: I would also love to hear if you run into the thing where you do a filter and then a buffer unordered. I cannot figure out how that would work. -LCA: I will check. +LCA: I will check. -KG: Great. +KG: Great. -CDA: Shu? +CDA: Shu? -SYG: So the topic is more, like the general direction. I want to raise some vague performance concerns that I ran into recent with promises, in current promise combinations where this encouraged you to make promises that get settled when a smaller subset of other promises get settled, with very seen memory issues where because resolution of subclass promises is observable, if you have a bunch of in flight reactions, like the microtask stuff, they have a reference to some global, like a bunch of uncollectible stuff until you return to the event loop to run the reactions to realize they do nothing, because the promise are resolved or already resolved. Does that make sense? +SYG: So the topic is more, like the general direction. I want to raise some vague performance concerns that I ran into recent with promises, in current promise combinations where this encouraged you to make promises that get settled when a smaller subset of other promises get settled, with very seen memory issues where because resolution of subclass promises is observable, if you have a bunch of in flight reactions, like the microtask stuff, they have a reference to some global, like a bunch of uncollectible stuff until you return to the event loop to run the reactions to realize they do nothing, because the promise are resolved or already resolved. Does that make sense? -KG: No. +KG: No. -SYG: I will follow up off line. If we encourage the concurrency, a inflight promises that need to, because of like subclass promises, that need to actually return to the event loop to give up holding resource we have seen in the wild where people write, reasonable looking libraries that run out of memory. If it’s not a built in promise, resolving is observable because you might have had an arbitrary function. So keep that in mind in the background if we are trying to spin up stuff to wait for them to finish. +SYG: I will follow up off line. If we encourage the concurrency, a inflight promises that need to, because of like subclass promises, that need to actually return to the event loop to give up holding resource we have seen in the wild where people write, reasonable looking libraries that run out of memory. If it’s not a built in promise, resolving is observable because you might have had an arbitrary function. So keep that in mind in the background if we are trying to spin up stuff to wait for them to finish. -KG: That’s good to know. Yeah. +KG: That’s good to know. Yeah. -CDA: There’s nothing else in the queue. +CDA: There’s nothing else in the queue. -KG: Okay. Well, I didn’t have anything to come to consensus on so I am done. Thanks very much. +KG: Okay. Well, I didn’t have anything to come to consensus on so I am done. Thanks very much. ### Summary of Key Points + There are a bunch of open questions we're working through. Please come participate on Github. ### Conclusion + Work continues. ## Throw Expressions for Stage 3 @@ -1598,145 +1116,147 @@ Work continues. Presenter: Ron Buckton (RBN) CDA: Great. Thank you. Ron, are you ready? - -RBN: Yes, I am. -CDA: Expressions for Stage 3. +RBN: Yes, I am. -RBN: All right. So it’s been a while since I talked about this. We talked about it at the last meeting. So I would bring it back. For a brief overview, throw expressions allow the use of the throw key word in an expression context such as in parameter initializers conditions, logical null, colace, and a number of different places and the value here is that it adds some additional convenience. There’s no need to introduce a full statement context to throw, expressions can throw. There aren't complexities in the text related to the runtime semantics since this is baked into the language. One of the other motivations is improved debugging experience. You can pause at the point of throw. You could, for example, have just an assert-fail as an example. An expression that can throw. Except that effects stack traces and pauses when debugging and you end up paused inside the function that throws than the code and you step out, and adds complexity to the process of doing debugging. +CDA: Expressions for Stage 3. -So I will give a brief history of where this proposal is. Back in July of 2017, it was first proposed for Stage 1. Adopted. At the time, there was concern expressed about potential overlap with do expressions and the committee requested exploration, what would it mean to have other statements as expressions? That was an ongoing discussion. In 2017, proposed was Stage 2, and was adopted. And in January of 2018, this was proposed for advancement to Stage 3. At the time, it was blocked again by do expressions and a separate syntax issue, and because of the contention with do expressions, it seemed like this proposal was essentially forever blocked until something moved on do expressions. I will also point out that we also presented findings on our position and findings on what we found looking at statements as expressions. We weren’t both myself doing the research and the committee seemed not to motivate to continue down the path of statements as expressions. We looked into potential interest, where debugger as an expression, there hasn’t been a lot of motivation or interest in following up on that just yet. The other was in variables and expressions which is something to come back to later. +RBN: All right. So it’s been a while since I talked about this. We talked about it at the last meeting. So I would bring it back. For a brief overview, throw expressions allow the use of the throw key word in an expression context such as in parameter initializers conditions, logical null, colace, and a number of different places and the value here is that it adds some additional convenience. There’s no need to introduce a full statement context to throw, expressions can throw. There aren't complexities in the text related to the runtime semantics since this is baked into the language. One of the other motivations is improved debugging experience. You can pause at the point of throw. You could, for example, have just an assert-fail as an example. An expression that can throw. Except that effects stack traces and pauses when debugging and you end up paused inside the function that throws than the code and you step out, and adds complexity to the process of doing debugging. -But again we are trying to advance to Stage 3, but blocked by do. And a separate syntax issue. And that has been potentially resolved as the last plenary in July. We had a brief review of proposals that hadn’t been discussed in a while. Throw expressions came up and the block related to do expressions was removed. It was considered no longer blocking and also able to potentially resolve the syntax concern which I will go into here. That syntax concern was the difference in precedence between throw statement and expression. +So I will give a brief history of where this proposal is. Back in July of 2017, it was first proposed for Stage 1. Adopted. At the time, there was concern expressed about potential overlap with do expressions and the committee requested exploration, what would it mean to have other statements as expressions? That was an ongoing discussion. In 2017, proposed was Stage 2, and was adopted. And in January of 2018, this was proposed for advancement to Stage 3. At the time, it was blocked again by do expressions and a separate syntax issue, and because of the contention with do expressions, it seemed like this proposal was essentially forever blocked until something moved on do expressions. I will also point out that we also presented findings on our position and findings on what we found looking at statements as expressions. We weren’t both myself doing the research and the committee seemed not to motivate to continue down the path of statements as expressions. We looked into potential interest, where debugger as an expression, there hasn’t been a lot of motivation or interest in following up on that just yet. The other was in variables and expressions which is something to come back to later. -This requires this to be in the, which one is it? I think it’s in LeftHandSideExpresion. Roughly. And this requirement meant it was UnaryExpression. And it had this requirement to be able to put in the places so on the right-hand side of logical operators, on the right-hand of null coalesce. But to have the same type of statements is something closer to yield, which isn’t the right precedence, because yield is still – would not consume this. We looked into just a restriction on what tokens would follow a throw expression. The next token would not be any infixed punctuator. Not comma or the question token at the beginning of a conditional expression to avoid this ambiguity. Some examples where things are legal versus illegal. So the case of question. Question, throw C. This would be legal. This is also the place you most likely want to use this compatibility. Trying to throw a B or C would be considered illegal, you would have to parenthesize the B question question C to make sure you have the exact precedence. +But again we are trying to advance to Stage 3, but blocked by do. And a separate syntax issue. And that has been potentially resolved as the last plenary in July. We had a brief review of proposals that hadn’t been discussed in a while. Throw expressions came up and the block related to do expressions was removed. It was considered no longer blocking and also able to potentially resolve the syntax concern which I will go into here. That syntax concern was the difference in precedence between throw statement and expression. -And in the same case with conditional expression, you most lie want to throw in either the true branch or false branch. These are both legal. Trying to throw in the head of a conditional expression would be illegal unless you used parenthesis to disambiguate. The use of comma, however, comma is also used in arrays and in parameters. So an argument lists and you would not want to have ambiguity between a throw and default, which is useful to require that a parameter is passed. But you also want to make sure it’s not ambiguous with the following parameters in the parameter list. In those cases, you have to use parenthesis for any leading parameters, you could not require presence on the last parameter. There’s nothing in the grammar that would restrict that. But the cases you would have parenthesis and I wanted to point that out as well. It will affect initializers. In the first slide is the example. Add parenthesis here, even though it’s not necessary. Mostly to kind of emphasize the fact that this is the comma expression will be a place where comma is a place to make sure we have no ambiguity. +This requires this to be in the, which one is it? I think it’s in LeftHandSideExpresion. Roughly. And this requirement meant it was UnaryExpression. And it had this requirement to be able to put in the places so on the right-hand side of logical operators, on the right-hand of null coalesce. But to have the same type of statements is something closer to yield, which isn’t the right precedence, because yield is still – would not consume this. We looked into just a restriction on what tokens would follow a throw expression. The next token would not be any infixed punctuator. Not comma or the question token at the beginning of a conditional expression to avoid this ambiguity. Some examples where things are legal versus illegal. So the case of question. Question, throw C. This would be legal. This is also the place you most likely want to use this compatibility. Trying to throw a B or C would be considered illegal, you would have to parenthesize the B question question C to make sure you have the exact precedence. + +And in the same case with conditional expression, you most lie want to throw in either the true branch or false branch. These are both legal. Trying to throw in the head of a conditional expression would be illegal unless you used parenthesis to disambiguate. The use of comma, however, comma is also used in arrays and in parameters. So an argument lists and you would not want to have ambiguity between a throw and default, which is useful to require that a parameter is passed. But you also want to make sure it’s not ambiguous with the following parameters in the parameter list. In those cases, you have to use parenthesis for any leading parameters, you could not require presence on the last parameter. There’s nothing in the grammar that would restrict that. But the cases you would have parenthesis and I wanted to point that out as well. It will affect initializers. In the first slide is the example. Add parenthesis here, even though it’s not necessary. Mostly to kind of emphasize the fact that this is the comma expression will be a place where comma is a place to make sure we have no ambiguity. So that was the direction that we were looking at when discussing it at the July plenary. That was put together in PR17. Which was reviewed. -But that leads to another issue. The two reviewers signed on back more than five years ago when this reached Stage 2 are not currently regularly involved with TC39. Keith circle, if I am pronouncing this correctly, is no longer regularly involved. He is still a delegate but doesn’t have the time commitment. Till has stated a no longer delicate and will not continue as reviewer. Nicolo has stepped up and hopefully I can find one more to help take up the review either if this advances or deed additional before Stage 3. -And that would essentially get to the end of the slides. Before I can ask for reviewers or talk about potential advancement, I would like to go to the queue. +But that leads to another issue. The two reviewers signed on back more than five years ago when this reached Stage 2 are not currently regularly involved with TC39. Keith circle, if I am pronouncing this correctly, is no longer regularly involved. He is still a delegate but doesn’t have the time commitment. Till has stated a no longer delicate and will not continue as reviewer. Nicolo has stepped up and hopefully I can find one more to help take up the review either if this advances or deed additional before Stage 3. +And that would essentially get to the end of the slides. Before I can ask for reviewers or talk about potential advancement, I would like to go to the queue. -CDA: RGN. +CDA: RGN. RGN: All right. So thanks for this slide. -It looks analogous in a lot of ways to exponentiation, potential confusion in human readers when it comes to this, where you define a behaviour, but it would be intuitive to some and counterintuitive to others. And the resolution by requiring parentheses in those cases, where a human could be confused, is a very good fix that we support wholeheartedly. +It looks analogous in a lot of ways to exponentiation, potential confusion in human readers when it comes to this, where you define a behaviour, but it would be intuitive to some and counterintuitive to others. And the resolution by requiring parentheses in those cases, where a human could be confused, is a very good fix that we support wholeheartedly. + +CDA: Nicolo? -CDA: Nicolo? +NRO: Yes. So I would prefer we wouldn’t have comma in that list of these allowed. In practice, developers use commas in function parameters and nobody writes comma expressions. And having this restriction to require parentheses in function arguments may be except for the last one, because of people for like used to comma expression as the throw argument, it feels like, every developer for some, very few people do it and if they do, they are knowledgeable about how the language works and how the syntax works. -NRO: Yes. So I would prefer we wouldn’t have comma in that list of these allowed. In practice, developers use commas in function parameters and nobody writes comma expressions. And having this restriction to require parentheses in function arguments may be except for the last one, because of people for like used to comma expression as the throw argument, it feels like, every developer for some, very few people do it and if they do, they are knowledgeable about how the language works and how the syntax works. +RBN: I was going to say that while I generally don’t see people write a throw statement that has a comma in it. I have seen more than my fair share of return statements return to something and comma the actual return value. I do see comma quite a bit in those cases. Comma is used in reduce bundle size by inlining various statements of expressions. And people, it’s harder to read the mini filed code, and it white not have course maps and it can be there and debugging and it’s for the most part necessary. It’s a relative care case you will see it, but I think at least for consistency sake, it’s better to ban it. -RBN: I was going to say that while I generally don’t see people write a throw statement that has a comma in it. I have seen more than my fair share of return statements return to something and comma the actual return value. I do see comma quite a bit in those cases. Comma is used in reduce bundle size by inlining various statements of expressions. And people, it’s harder to read the mini filed code, and it white not have course maps and it can be there and debugging and it’s for the most part necessary. It’s a relative care case you will see it, but I think at least for consistency sake, it’s better to ban it. +CDA: I think Kevin has a reply. -CDA: I think Kevin has a reply. +KG: I was basically going to say the same thing Ron did. I am not super worried about people who know this rule, because they are in the habit of writing `throw a, b`. It’s mostly you learn that rule when you’re debugging, because it’s the output of minified code. When you debug frequently, you have to know this rule because it comes up all the time. It is those people that I am concerned about, not people who are trying to write it by hand. -KG: I was basically going to say the same thing Ron did. I am not super worried about people who know this rule, because they are in the habit of writing `throw a, b`. It’s mostly you learn that rule when you’re debugging, because it’s the output of minified code. When you debug frequently, you have to know this rule because it comes up all the time. It is those people that I am concerned about, not people who are trying to write it by hand. +RBN: I will say that banning comma is uncomfort in the function parameter case because it requires presence in almost all the cases that would matter. Trailing arguments. The last argument wouldn’t necessarily require it. But I imagine people would put parentheses around them anyways and that is unfortunate from a, just a consistent inconvenient where all the other places you would have it. I wouldn’t want to mandate you would have to do this because it’s mostly unnecessary in the 95% case of the places you would see it. I expect the major cases where you’re going to see throw expressions used, are going to be unconditionals in the true and false branches or nullish coalesce and logical or. They are the right-hand side and not having the parenthesis there and not requiring them is fairly convenient. It’s just the function parameter default initialize case is unfortunate because it would require parenthesis. -RBN: I will say that banning comma is uncomfort in the function parameter case because it requires presence in almost all the cases that would matter. Trailing arguments. The last argument wouldn’t necessarily require it. But I imagine people would put parentheses around them anyways and that is unfortunate from a, just a consistent inconvenient where all the other places you would have it. I wouldn’t want to mandate you would have to do this because it’s mostly unnecessary in the 95% case of the places you would see it. I expect the major cases where you’re going to see throw expressions used, are going to be unconditionals in the true and false branches or nullish coalesce and logical or. They are the right-hand side and not having the parenthesis there and not requiring them is fairly convenient. It’s just the function parameter default initialize case is unfortunate because it would require parenthesis. - -LCA: I would like to respond to this and I am sorry I am not on TQQ. It’s not loading. Can you check whether it’s working for you? I have a strong preference, nor for the disallowing this with the trailing comma. Because specifically, the function argument case, but also like you have an ObjectLiteral that you’re building. And you want to use like double question mark. And have a throw expression on the right-hand side of the double question mark and a comma because of the next property. Having to wrap all of that in parenthesis is frustrating. Especially because I think these will be cases where it will be frequently used. I think a lot of the arguments make sense, but the trailing comma, it’s very unfortunate. +LCA: I would like to respond to this and I am sorry I am not on TQQ. It’s not loading. Can you check whether it’s working for you? I have a strong preference, nor for the disallowing this with the trailing comma. Because specifically, the function argument case, but also like you have an ObjectLiteral that you’re building. And you want to use like double question mark. And have a throw expression on the right-hand side of the double question mark and a comma because of the next property. Having to wrap all of that in parenthesis is frustrating. Especially because I think these will be cases where it will be frequently used. I think a lot of the arguments make sense, but the trailing comma, it’s very unfortunate. CDA: Okay. We, I think TCQ is broken. Waldemar? -NRO: The same topic apply? +NRO: The same topic apply? CDA: Sure. Go ahead -NRO: With here, it’s possible to have a restriction. But accepting that throw expressions we have differently, when there’s a comma after the first expression of the throw. Just clarifying this because I see people on matrix confused whether it’s possible to remove the restriction. +NRO: With here, it’s possible to have a restriction. But accepting that throw expressions we have differently, when there’s a comma after the first expression of the throw. Just clarifying this because I see people on matrix confused whether it’s possible to remove the restriction. RBN: Yeah. From -CDA: Eemeli? +CDA: Eemeli? -RBN: I am not seeing anything from TCQ. +RBN: I am not seeing anything from TCQ. -CDA: Reload. +CDA: Reload. -CDA: All right. +CDA: All right. EAO: So did the other side of the comma question then is, is there any actual real code that currently uses throw 1, 2? And does anything like this? Do we need to care about this NRO: Minified code. As Kevin said, if you are use that code, you would expect this thing to throw too -RBN: You would see it in minifiers. It’s rare in handwritten code, but in minifiers. The throw at the end of the a statement list, it will be returned in into comma separated, prefixed with a throw, because that’s the last thing that throws. +RBN: You would see it in minifiers. It’s rare in handwritten code, but in minifiers. The throw at the end of the a statement list, it will be returned in into comma separated, prefixed with a throw, because that’s the last thing that throws. NRO: This means minifiers will fill be able to, this doesn’t change anything for me, just for people reading the minifying code. -RBN: To be fair, once this is in the code, minifers could switch to comma separate expressions and the last one is the throw. It’s likely that once this actually has reached option, that case minutefiers is not something you will see, once it supports put throw at the end. +RBN: To be fair, once this is in the code, minifers could switch to comma separate expressions and the last one is the throw. It’s likely that once this actually has reached option, that case minutefiers is not something you will see, once it supports put throw at the end. -RBN: I am not sure if I have a specific direction on comma. There’s interest in not banning comma specifically. I know that the opinion on banning comma. I don’t know Kevin, if you have preference. Would you be willing to allow comma, continuing to ban all the other, all these other punctuators? +RBN: I am not sure if I have a specific direction on comma. There’s interest in not banning comma specifically. I know that the opinion on banning comma. I don’t know Kevin, if you have preference. Would you be willing to allow comma, continuing to ban all the other, all these other punctuators? KG: I really think it’s a bad idea to have the same key word have different precedence, depending on what position it’s in. If it is the only way for proposal to advance, I don’t know if I am willing to say I am okay with dropping that restriction. It just makes code completely unreadable to have something mean two different things in two different places. It seems like a bad idea. If I am only person in the room? -GCL: Are you asking for room consensus whether we should do this, Ron? +GCL: Are you asking for room consensus whether we should do this, Ron? -RBN: I think there are two parts to this. One, I need to make sure we have consensus on the banning of punctuators in general. That was the direction in the last plenary session. I want to make sure that the committee agrees and the individual case of should we ban or allow comma to follow a throw expression. +RBN: I think there are two parts to this. One, I need to make sure we have consensus on the banning of punctuators in general. That was the direction in the last plenary session. I want to make sure that the committee agrees and the individual case of should we ban or allow comma to follow a throw expression. RBN: I guess it’s a good idea to ask the room, we will start with the comma expression. So the easiest thing to ask. -WH: Point of order: I’ve been at the top of the queue for a while. People keep inserting topics in front of me. +WH: Point of order: I’ve been at the top of the queue for a while. People keep inserting topics in front of me. -KG: We have been on the same topic the whole time. +KG: We have been on the same topic the whole time. -DE: We didn’t move to the next topic. Let’s not go to the temperature check until we cover the queue. That would be fine. +DE: We didn’t move to the next topic. Let’s not go to the temperature check until we cover the queue. That would be fine. -DE: So. Waldemar, do you want to talk about what your concern is here? +DE: So. Waldemar, do you want to talk about what your concern is here? WH: Yes. My concern is that this proposal makes line breaks significant for arithmetic operators, which will behave differently depending on if they are surrounded by line breaks or not. This is significant violence to do to the core ECMAScript functionality. Consider the example I gave on the TCQ: `if (e) a = throw b/c; a = throw d - f/g;` -WH: If you stick a line break in front of the first division symbol, then the whole thing will parse very differently. The first division will become a regular expression consuming everything until the next division. +WH: If you stick a line break in front of the first division symbol, then the whole thing will parse very differently. The first division will become a regular expression consuming everything until the next division. -RBN: I don’t believe there is a no LineTerminator requirement there. The next symbol cannot follow – +RBN: I don’t believe there is a no LineTerminator requirement there. The next symbol cannot follow – -WH: Yes! +WH: Yes! RBN: Are you talking about ASI inserting semicolon? WH: Yes. In `a = throw b - c`, ASI will insert a semicolon in front of the minus sign if there’s a line break there. -RBN: We have other restrictions for ASI. +RBN: We have other restrictions for ASI. WH: Not like this. -KG: Ron, this is the issue I raised in the thread. Although the example I noticed was + and - instead of /. There is a solution to this problem. But instead of using look forward for the arithmetic operators, you can have an error early that says, if the throw is the left-hand side of, for example, a X or the division expression that uses the token, then it parse as the same thing either way and then you get an error. They don’t affect ASI in the same way. That solves this particular problem, I think. Maybe I am wrong? +KG: Ron, this is the issue I raised in the thread. Although the example I noticed was + and - instead of /. There is a solution to this problem. But instead of using look forward for the arithmetic operators, you can have an error early that says, if the throw is the left-hand side of, for example, a X or the division expression that uses the token, then it parse as the same thing either way and then you get an error. They don’t affect ASI in the same way. That solves this particular problem, I think. Maybe I am wrong? WH: It would need to have a lot of those things. And I would just find all this too confusing. -We should pick a consistent precedence for `throw` and not do any kind of look ahead restriction. +We should pick a consistent precedence for `throw` and not do any kind of look ahead restriction. -RBN: I am not sure we need a lot of them. We do have other cases of early errors based on where a syntax – where a specific production occurs. Where we say, these things can only appear within this certain place and it’s an early error, if it doesn’t appear within a function boundary or we have used that in other places westbound the specifications. If throws on the left-hand side of the binary expression contained, expression using one of the tokens, then it would be an error. +RBN: I am not sure we need a lot of them. We do have other cases of early errors based on where a syntax – where a specific production occurs. Where we say, these things can only appear within this certain place and it’s an early error, if it doesn’t appear within a function boundary or we have used that in other places westbound the specifications. If throws on the left-hand side of the binary expression contained, expression using one of the tokens, then it would be an error. -WH: That would throw the baby out with the bath water. Let’s say we restrict throw expressions to not occur inside logical expressions. But then we might as well just set the precedence of throw to be lower, and do it without early error restrictions. +WH: That would throw the baby out with the bath water. Let’s say we restrict throw expressions to not occur inside logical expressions. But then we might as well just set the precedence of throw to be lower, and do it without early error restrictions. -RBN: Yeah. The downside would be pretty much any precedence we choose other than UnaryExpression is going to mandate wrapping it in parenthesis everywhere. And unless it’s also at the same level as comma, we can’t take comma and thus every place you would have to use throw other than a – the head of an if, or an expression statement, it’s a throw statement anyways, it would essentially need to require presence and that’s unfortunate for the 95% case is the positions where it appears will not run into these. +RBN: Yeah. The downside would be pretty much any precedence we choose other than UnaryExpression is going to mandate wrapping it in parenthesis everywhere. And unless it’s also at the same level as comma, we can’t take comma and thus every place you would have to use throw other than a – the head of an if, or an expression statement, it’s a throw statement anyways, it would essentially need to require presence and that’s unfortunate for the 95% case is the positions where it appears will not run into these. WH: The examples on the slide here don’t require parenthesization if the precedence is that of below a logical operator. RBN: Yes. -WH: Are saying, you want to use `throw` in arithmetic operations such as `a + throw b` without parenthesizing the throw? +WH: Are saying, you want to use `throw` in arithmetic operations such as `a + throw b` without parenthesizing the throw? RBN: I want to be able to use them in quite a few places. But even if it, even if we change the precedence such that it was immediately after the logical operators, we still would run into the same issue that Kevin had blocked on before, if the precedence differs between throw expressions and statement, and have throw A or B but it has a different expression or space then he’s not going to pass it. -So the banning of the look ahead restriction here or however to implement it trying to find a happy medium between the precedence that makes them – the most sense from a convenience perspective and resolving the issue that is the blocker that has held this proposal back for five years. I am trying to find a compromise. +So the banning of the look ahead restriction here or however to implement it trying to find a happy medium between the precedence that makes them – the most sense from a convenience perspective and resolving the issue that is the blocker that has held this proposal back for five years. I am trying to find a compromise. WH: We have the same situation with other things in the language which can be either statements or expressions. The two forms have different precedence. For example, `function` behaves this way. I don’t know if Kevin objects to `function` being both a statement and an expression. -RBN: Function statement, you can’t write a comma after it. +RBN: Function statement, you can’t write a comma after it. WH: Yes. But you can write -``` + +```javascript …function f(…) {…} (…) ``` + and then whether the trailing `(…)` is a set of arguments or another expression statement depends on whether the `function` was a statement or an expression. -?? You run into – +?? You run into – -KG: The thing I am concerned about is people being able to skim text and understand what it means. - -WH: Yeah. +KG: The thing I am concerned about is people being able to skim text and understand what it means. + +WH: Yeah. KG: And like, you don’t see commas after function statements. So it’s not something that you have to care about. But you do see `throw a, b`. It comes up so you have to care about it. @@ -1746,54 +1266,54 @@ KG: it’s the output of minifiers WH: I don’t understand. Throw-expressions aren’t in the language yet, so how can they be the output of minifiers? -KG: They output throw statements. The thing I am trying to ensure is that the rules that you currently have to learn in order to read throw statements, which are output by minifiers, do not mislead you when reading throw expressions. +KG: They output throw statements. The thing I am trying to ensure is that the rules that you currently have to learn in order to read throw statements, which are output by minifiers, do not mislead you when reading throw expressions. -WH: Okay. I think that’s the lesser of the evils here. - -KG: I could be convinced for comma potentially. The case on the slide here, the last line where you have `throw b ? c : d` I feel strongly that it should be illegal or should throw `b ? c : d`. It should not throw `b`. +WH: Okay. I think that’s the lesser of the evils here. + +KG: I could be convinced for comma potentially. The case on the slide here, the last line where you have `throw b ? c : d` I feel strongly that it should be illegal or should throw `b ? c : d`. It should not throw `b`. WH: Yeah. - + RBN: A lot of the cases that the look ahead restrictions ban, you want that a TypeScript would tell you there’s code not be evaluated. Right-hand side, the second expression with A = B. C you will throw beforehand. TypeScript gives you an error. Saying you can’t do this. I imagine a linter would want to give you an error saying you can’t do this. With throw as UnaryExpressions. Because it will throw before it evaluates the code. All of these things are, except for the case, of the function parameter ObjectLiteral property lists are going to be cases that it’s going to be an error in your code because we had the restriction or something else was going to tell you it’s an error because what you were expecting to happen wouldn’t. The only case that doesn’t occur is comma. -WH: That is not true. +WH: That is not true. -RBN: I’m sorry. +RBN: I’m sorry. WH: That is not true. A counterexample is `a = b && throw(c) || d` or similar such expressions. Here you have `throw(c)` followed by `||` which is neither an error nor useless. -RBN: Actually I find that to be – well. Actually, that is still valid because you might expect A to end up false in that case or empty string. I mean, there are potentially reasonable assumptions being made there. For cases throwing in the head of a conditional, I don’t think it does. Yeah that doesn’t resolve unevaluated code. That results in just – you can only have it being false. +RBN: Actually I find that to be – well. Actually, that is still valid because you might expect A to end up false in that case or empty string. I mean, there are potentially reasonable assumptions being made there. For cases throwing in the head of a conditional, I don’t think it does. Yeah that doesn’t resolve unevaluated code. That results in just – you can only have it being false. -RBN: Okay. +RBN: Okay. -WH: Anyway my position is, we need to pick up specific precedence for this, and not make line breaks significant in front of operators such as + - /. +WH: Anyway my position is, we need to pick up specific precedence for this, and not make line breaks significant in front of operators such as + - /. RBN: I would be happy to look at, look to see with early errors in ways that doesn’t affect. -WH: I do not want early errors. This should be purely grammatical. It’s much easier to understand purely grammatical syntax than rules expressed as early errors. +WH: I do not want early errors. This should be purely grammatical. It’s much easier to understand purely grammatical syntax than rules expressed as early errors. -RBN: I don’t see a way forward for this proposal then. Because either we pick a precedence that means it’s always parenthesized, which is terrible unfortunate because it’s as, parenthesis all the time when we use these expressions or continue with unary which will not advance, with concerns to the grammar difference. And the only compromise I could find is banning look ahead. If we won’t ban look ahead and not going to allow those tokens to exist and have different precedence, then the only other option is to make it expression and require parenthesis every time. I don’t see another way. +RBN: I don’t see a way forward for this proposal then. Because either we pick a precedence that means it’s always parenthesized, which is terrible unfortunate because it’s as, parenthesis all the time when we use these expressions or continue with unary which will not advance, with concerns to the grammar difference. And the only compromise I could find is banning look ahead. If we won’t ban look ahead and not going to allow those tokens to exist and have different precedence, then the only other option is to make it expression and require parenthesis every time. I don’t see another way. -CDA: Okay. We have less than 2 minutes. Do you want to take a look at the queue? What do you want to do with the remaining time here? +CDA: Okay. We have less than 2 minutes. Do you want to take a look at the queue? What do you want to do with the remaining time here? -RBN: We can go back to the queue. That’s fine. There’s some other questions about precedence as well. +RBN: We can go back to the queue. That’s fine. There’s some other questions about precedence as well. CDA: 1 minute -DE: I think we were talking about in 2017 about the potential two things, comma precedence tradeoff proposed is the right one, given, yes, there will be cases where people have to understand the grammar. We can’t avoid that people have to throw an expression case. We are choosing between three different kinds of confusion. I want to hear Nick’s comment? +DE: I think we were talking about in 2017 about the potential two things, comma precedence tradeoff proposed is the right one, given, yes, there will be cases where people have to understand the grammar. We can’t avoid that people have to throw an expression case. We are choosing between three different kinds of confusion. I want to hear Nick’s comment? KG: Which one were you in favour of? -DE: The thing that Nick was advocating on the slide that was saying, illegal with all those. All the various cases and people say, this has to be illegal. That was the proposal. That’s the one I am agreeing with. In particular, the parameter case seems pretty likely legitimate. +DE: The thing that Nick was advocating on the slide that was saying, illegal with all those. All the various cases and people say, this has to be illegal. That was the proposal. That’s the one I am agreeing with. In particular, the parameter case seems pretty likely legitimate. -NRO: I agree with this. I strongly support making sure that like for, for example, the throw? C. It’s illegal or behaves like throw statements which in practice means making it legal. That code is a breakdown. They are throwing the first or second one. For all operators, I strongly agree with this restriction. +NRO: I agree with this. I strongly support making sure that like for, for example, the throw? C. It’s illegal or behaves like throw statements which in practice means making it legal. That code is a breakdown. They are throwing the first or second one. For all operators, I strongly agree with this restriction. -CDA: We are at time. And cutting into the 15-minute break. I will capture the queue and this will appear as overflow. It does not seem we have concluded this item. -So break begins. Please return at 15 minutes after the hour. +CDA: We are at time. And cutting into the 15-minute break. I will capture the queue and this will appear as overflow. It does not seem we have concluded this item. +So break begins. Please return at 15 minutes after the hour. -## Intl.MessageFormat: Stage 1 update and discussion +## Intl.MessageFormat: Stage 1 update and discussion Presenter: Eemeli Aro (EAO) @@ -1811,50 +1331,40 @@ EAO: The second big change is the proposal is previously, it had a single method EAO: And then also further, related to the output shape is the input shape of things. Meaning: when you have to format a message and you want to give it some values with which the formatting is being done, or when the values within a message are being resolved and work through, internally, what is their representation? Those shapes have changed quite a bit in the proposal. I will go through this too a little bit later. -EAO: And then there are a couple of changes here that are coming from effectively the changes that have been applied to the underlying unicode of ethics [?} message format to spec proposal. Looking to become public and finalized by spring next year. So one part here is that the MessageData structure does have a representation that is relatively well defined within the message format 2, specification that we refer to and use here. A MessageData is effectively a POJO JSON data structure. And then another part is that the message from 2 spec has specified [uch] more clearly how to handle bidi (bidirectional) parts. In particular, when dealing with left-to-right and right to left in a single message. How is this to be handled? +EAO: And then there are a couple of changes here that are coming from effectively the changes that have been applied to the underlying unicode of ethics [?} message format to spec proposal. Looking to become public and finalized by spring next year. So one part here is that the MessageData structure does have a representation that is relatively well defined within the message format 2, specification that we refer to and use here. A MessageData is effectively a POJO JSON data structure. And then another part is that the message from 2 spec has specified [uch] more clearly how to handle bidi (bidirectional) parts. In particular, when dealing with left-to-right and right to left in a single message. How is this to be handled? EAO: And then furthermore, one change is that, the default error handling is currently set to warn rather than throw errors. This is coming effectively also in part the message format 2specification which is requiring implementations to always return a formatted value even if stuff broke in between. In order to make sure that we do have the best possible thing to present to a user. And this specifically is a difference that I wanted to highlight in the current shape of the API proposal. That’s different from most of the things we are doing overall in JavaScript -EAO: This is roughly what a vast majority of usage cases of message format, with the current API woul, look like. You have a source string representation of a message. The curly braces around the hello curly braces there, this is a topic of conversation right now, the message format group to Unicode, the exact details of what the source syntax looks like we have a decent solution, now hoping to make a better one all of the other parts are JavaScript parts. You would construct a MessageFormat instance from this source and locale and any options you give it and then you could call format or format to parts, calls on that and you would get either a string or this type of sequence of parts. Much like currently is done with format to parts, but format to parts in particular later +EAO: This is roughly what a vast majority of usage cases of message format, with the current API woul, look like. You have a source string representation of a message. The curly braces around the hello curly braces there, this is a topic of conversation right now, the message format group to Unicode, the exact details of what the source syntax looks like we have a decent solution, now hoping to make a better one all of the other parts are JavaScript parts. You would construct a MessageFormat instance from this source and locale and any options you give it and then you could call format or format to parts, calls on that and you would get either a string or this type of sequence of parts. Much like currently is done with format to parts, but format to parts in particular later -EAO: Going on to a slightly more complex and more powerful localized message, sort of case, is when we have a message that has variance depending on input characteristics. So in this case, for example, we have a message that we want to format and show to a user, where if we have zero as the count, we show a message count saying, you have no new notifications. But when we have the number 1, as the count value, for example, we would end up selecting, in English, the OME named CLDR [gat] [?] letter like Intl rules riting in functionality and select that. So “you have one new notification” and then for other cases in English, “you have 55 new notifications”. These rules are different in different locales -But this is a key part of feature of message format 2 supports +EAO: Going on to a slightly more complex and more powerful localized message, sort of case, is when we have a message that has variance depending on input characteristics. So in this case, for example, we have a message that we want to format and show to a user, where if we have zero as the count, we show a message count saying, you have no new notifications. But when we have the number 1, as the count value, for example, we would end up selecting, in English, the OME named CLDR [gat] [?] letter like Intl rules riting in functionality and select that. So “you have one new notification” and then for other cases in English, “you have 55 new notifications”. These rules are different in different locales But this is a key part of feature of message format 2 supports EAO: Now, to go on to the some of the API questions and answers provided by the current shape of the proposal that I figure about is good to present, one is that quite often, when formatting a thing like a number together with a currencyunit or a number together with a measurement unit, or, for example, a date time in a specific TimeZone, the thing we are formatting is effectively a compound unit. Compound value. So like the 42 Euros that are two separate parts. And this is currently handled by our Intl formatters by passing the currency or the unit or the time zone as one of the options values. But we for localize linearization [?} – the options end up being possibly specifiable by translatorrers. We need to find a way of user of message format with specify that the input they are giving is 42 Euros, rather than having a translator presume that, okay. Euros, but we are in Japan. Of course it should be 42 Yen that is printed and that would be obviously wrong. -EAO: So the solution that we currently have is that, the custom formatters in message format 2 allow for input as objects that we look at whether they have a valueOf method that returns something with a specific shape. And if an object does match this pattern, then we also look at whether it has an options property and that is then merged with structured options that we feed to the formatter. And the way this works in actual code is shown on the screen as well +EAO: So the solution that we currently have is that, the custom formatters in message format 2 allow for input as objects that we look at whether they have a valueOf method that returns something with a specific shape. And if an object does match this pattern, then we also look at whether it has an options property and that is then merged with structured options that we feed to the formatter. And the way this works in actual code is shown on the screen as well EAO: And the utility here is that of splitting a basket of options like this is, for example, it can be useful to see at that the price is a number the style of currency. Rather than just seeing your total is price. And not knowing that that will get formatted also with a currency indicator that is appropriate for the locale. EAO: And then because we are using the valueOf, this is oddly enough given a use case for things like new number that can be, therefore, used. And that object that is, therefore, created can be given an options bag which then carries the currency. -EAO: Now, another significant API question; how do we format the parts? There are two parts, these parts question that are somewhat complex. One is that, a formatted message can itself end up including values like numbers, that themselves formats to parts. +EAO: Now, another significant API question; how do we format the parts? There are two parts, these parts question that are somewhat complex. One is that, a formatted message can itself end up including values like numbers, that themselves formats to parts. EAO: So we have a relatively common case of wanting to formatting to parts, but ending with parts with parts. Separately from this, we want to include values that aren’t strings. For example, if we can use this, we should be able to use the API we end up to have a thing like a DOM element, for instance, or another object where object identity is significant. By giving and passed in as a value or entered by a customer formatter within a message processing and come out of the other side in a way we can use this EAO: And the solution that we have currently are going with is that each of the formatted parts you get out of the format to parts can either have a value which is a string or actually unknown. But it may also have rather than unitary value. It can have a parts array of themselves parts. So for numbers you can solve it by having a part with parts, or then if we have, such as here, we have a custom formatter image that is being used to generate a DOM element within the resolution of the message for formatting. And then what we can use in the formater parts output is that we can the image function can generate, define its output as having a specific sort of shape. And the value there does not need to be a string; it can be effectively anything. -EAO: We don’t have anything like this in the sort of default set of functions that we expect to include with method format. +EAO: We don’t have anything like this in the sort of default set of functions that we expect to include with method format. EAO: This is something that a user could implement and use and such a case that needs to be handled. -And now then having considered the effectively the input stuff and the output stuff then does -the somewhat more complex stuff of what happens in the middle, because messageFormat supports -custom formatters. It comes with, for example, number that I showed earlier that we can well define include it directly in what we’re doing and that ends up calling the input dot NumberFormater. +And now then having considered the effectively the input stuff and the output stuff then does the somewhat more complex stuff of what happens in the middle, because messageFormat supports custom formatters. It comes with, for example, number that I showed earlier that we can well define include it directly in what we’re doing and that ends up calling the input dot NumberFormater. You can imagine we need to support users defining formatting functions that would call something like image that do whatever they want and need it to do. -EAO: This needs to behave in a predictable way and a user, a developer-friendly way, especially as -we have variables that are internal to the message that can get assigned the values of these -expressions that these functions.Those are the really the contents that I had for this. -I would be looking for the specification text for all of this unless we develop this critically -bad for the API than keep on changing it for hopefully sometime soon really soon for Stage 2 -advancement for all of this. +EAO: This needs to behave in a predictable way and a user, a developer-friendly way, especially as we have variables that are internal to the message that can get assigned the values of these expressions that these functions.Those are the really the contents that I had for this. +I would be looking for the specification text for all of this unless we develop this critically bad for the API than keep on changing it for hopefully sometime soon really soon for Stage 2 advancement for all of this. EAO: So a value like this can be used in the whole plethora of different ways within a message. -And that means it gets a little bit tricky or complicated at least. the way that the options is a function -option of mapping of string identifiers to functions and these functions are then called with -source locales (this will probably still change a little bit) and need to return a value, object -value that has the MessageValue sort of shape. +And that means it gets a little bit tricky or complicated at least. the way that the options is a function option of mapping of string identifiers to functions and these functions are then called with source locales (this will probably still change a little bit) and need to return a value, object value that has the MessageValue sort of shape. EAO: And then the presence or absence or whatever the value is undefined or not effectively of the various fields within MessageValue define how they are used within message resolution. If it has select keys method it may be use as a selector as I showed number earlier being used for the notifications example. If it has two parts and toString methods, it may be used to format the parts with toString. @@ -1870,15 +1380,13 @@ EAO: That would be grand. JHD: Yeah, I was just curious about the onError. My intuition from that one slide is that that will be called synchronously each time one of the properties in the record has some sort of error. Is that correct? Or like can you help me understand that? -EAO: So the on error would be called when, during the resolution and the formatting of a -Message. Possibly multiple times. +EAO: So the on error would be called when, during the resolution and the formatting of a Message. Possibly multiple times. JHD: Because it returns void on this slide here, I’m assuming it doesn’t have the ability to alter the result, it’s just a way to notify, to get notified as things are encountered. EAO: That’s the current shape of the proposal, yes. It is not a route back in. -JHD: Is there a strong reason why that approach was included in this API versus like instead of -returning a string, returning like an object containing a string and an array of errors or something like that? Is there a reason you need to have in C 2 notification is my question. +JHD: Is there a strong reason why that approach was included in this API versus like instead of returning a string, returning like an object containing a string and an array of errors or something like that? Is there a reason you need to have in C 2 notification is my question. EAO: I would say in most cases, most users will probably not end up handling errors even though they should. So the default case here, it’s optimized so when you’re just using it and you just want it to work, what you end up with is not needing to bother with unpacking a resulting object shape like this, and you do still end up seeing at least in your logging the warnings for the errors that are encountered. What you’re proposing is a possible alternative API, that could be considered yes. But this felt more ergonomic is the short of the answer. @@ -1887,12 +1395,12 @@ JHD: Thank you. USA: Next guest, Shane. -SFC: Yeah, I was just going to say there’s a lot of good stuff in here. I think the best place to discuss some of these lower level details would be in an incubator call. And I think it would be great to collect interest from the delegates on who would like to be on the list for that incubator call, so we can put out, +SFC: Yeah, I was just going to say there’s a lot of good stuff in here. I think the best place to discuss some of these lower level details would be in an incubator call. And I think it would be great to collect interest from the delegates on who would like to be on the list for that incubator call, so we can put out, so we can create the issue and start scheduling the incubator call to dive into more of the details here. USA: Next we have Gus. -GCL?: Yeah, just want to say I’m super excited with how this is looking especially since the last time I looked at it, yeah, great work. I think we’ll definitely try to be engaging with this more maybe with the incubator calls, +GCL?: Yeah, just want to say I’m super excited with how this is looking especially since the last time I looked at it, yeah, great work. I think we’ll definitely try to be engaging with this more maybe with the incubator calls, yeah. USA: Next we have Dan. @@ -1901,8 +1409,7 @@ DE: I agree with everybody. I’m really happy with the direction. You and I tal EAO: The good reason for non-fatal errors is that unlike the other Intl formatters, this is depending on user data. It’s depending on user data gone through possibly multiple workflows, through translators and other things and when it comes out of that other end, the likelihood of this calls to Intl messageformat ultimately failing, unfortunately likely to fail than other cases and they may fail partially. You may end up in a situation where you have for example user interface that is built of say 15 different messages that all need to be formatted for the whole thing to work. -And then a developer adds a 16th new message and this ultimately in a different locale for a different locale has not gone through translation and what you end up during run time is that the use inner the different locale than what the developer themselves are using ends up with 15 rather than 16 of the messages being available and in such a case, a user who doesn’t explicitly handle the fallbacking manually around these calls may end up with a really bad case that they end up showing to a user. And the whole of the UI and the UX failing because of this. Partly this is something we’ve learned the hard way at Mozilla through the experiences with -similar API development for Firefox and others. +And then a developer adds a 16th new message and this ultimately in a different locale for a different locale has not gone through translation and what you end up during run time is that the use inner the different locale than what the developer themselves are using ends up with 15 rather than 16 of the messages being available and in such a case, a user who doesn’t explicitly handle the fallbacking manually around these calls may end up with a really bad case that they end up showing to a user. And the whole of the UI and the UX failing because of this. Partly this is something we’ve learned the hard way at Mozilla through the experiences with similar API development for Firefox and others. DE: Okay. I’m interested in following up to dig into more details around air handling that we can understand like whether returning void is best. I’m not sure what string will be returned in that case and understanding the semantics more will help. But also the custom formatters with the API being so detailed and having more case studies kind of written up maybe or at least sketched out at a really high level will help us, will help me understand why we need all these various aspects of it. I think you explained well at a conceptual level, just examples will help. @@ -1914,7 +1421,7 @@ DLM: I just wanted to say this is looking really good to me as well. I would lik USA: Next we have Shane. -SFC: Yeah, my previous comment is I would like to get a list of the delegates we should try to organize with and the people who have commented today, GLC, DE, EDIN, and JHD may want to sign them or ping them to be interested. I see BSH and Luke (code? join the queue and it will be on the reflector that people see it and want to to be clear who wants to be on the loop on the incubator. I see a reply from Bradford. +SFC: Yeah, my previous comment is I would like to get a list of the delegates we should try to organize with and the people who have commented today, GLC, DE, EDIN, and JHD may want to sign them or ping them to be interested. I see BSH and Luke (code? join the queue and it will be on the reflector that people see it and want to to be clear who wants to be on the loop on the incubator. I see a reply from Bradford. USA: Bradford has a reply. Do you want to speak that out loud? @@ -1927,7 +1434,7 @@ BSH: I was very interested in seeing that in the examples, it seems to be using EAO: Two thoughts on that. Yes, this is currently at least intended to be blocked on ICU message from the to be released. I’m on the working group as well quite actively and we are currently aiming and intending fully to get this released as part of next spring’s ICU release. So we’re like this close to finalizes the details. We’re mulling over decisions we have made earlier and revisiting them. But I have really high confidence on this landing. This is partly why this proposal is currently at Stage 1. A lot of the work that’s been going on in the committee was actually spun off from work initially started under Ecma402 and then went that way. -EAO: So starting ICU messageFormat, the existing older implementation, that there is no current intent to have that syntax be directly parsable here. It is in the messageformat to work. We made a high priority to make sure it is convertible to Messageformat v1. +EAO: So starting ICU messageFormat, the existing older implementation, that there is no current intent to have that syntax be directly parsable here. It is in the messageformat to work. We made a high priority to make sure it is convertible to Messageformat v1. BSH: So there would be a specification for a tool or a tool provided that would allow you to do that, to take your old ones and transfer them to, translate them to the new format? @@ -1948,15 +1455,11 @@ EAO: Very interested to have you participate in that discussion and for us to it DE: To Bradford’s comment on is there a messageformat effort and how will it relate to the other one? The effort is actually led by many of your coworkers at Google. -DE: I recommend that you, not just you, but everybody can get in touch with the effort because -the UNIcode is another open standards body. This effort is relatively far along. But it’s not completely done in particular, it’s at a stage of concreteness and the working group is really looking for sort of end to end test cases where someone who works in an organization with translators could try integrating the prototypes that exist to applications working with translators and getting feedback on all of that. I’m trying to organize this at Bloomberg like we’re very excited about this proposal and that’s why we’ve been sponsoring Igalia’s work. I encourage you to get involved. +DE: I recommend that you, not just you, but everybody can get in touch with the effort because the UNIcode is another open standards body. This effort is relatively far along. But it’s not completely done in particular, it’s at a stage of concreteness and the working group is really looking for sort of end to end test cases where someone who works in an organization with translators could try integrating the prototypes that exist to applications working with translators and getting feedback on all of that. I’m trying to organize this at Bloomberg like we’re very excited about this proposal and that’s why we’ve been sponsoring Igalia’s work. I encourage you to get involved. DE: If you’re interested in the format, I don’t think it makes sense to aim to include all the very different formats used for this purpose today. There’s just a lot. They all have big problems that this is solving. -EAO: To expand on that a little bit, messageformat 2, the syntax but the data model are also. as -far as we know, capable of representing all currently in use message formats that anyone has that -we’re aware of. So one of the side benefits that (maybe not really a side benefit here) is that through the -messageformat 2 data model that this API also supports we can build a sort of intermediate representation for messages that the ASTs that have been well defined for JavaScript for a while have enabled a lot of community to grow and abilities to grow around transforming messages, much in the way that JavaScript is very much a transforming language itself. +EAO: To expand on that a little bit, messageformat 2, the syntax but the data model are also. as far as we know, capable of representing all currently in use message formats that anyone has that we’re aware of. So one of the side benefits that (maybe not really a side benefit here) is that through the messageformat 2 data model that this API also supports we can build a sort of intermediate representation for messages that the ASTs that have been well defined for JavaScript for a while have enabled a lot of community to grow and abilities to grow around transforming messages, much in the way that JavaScript is very much a transforming language itself. USA: And that was it for the queue. @@ -1974,17 +1477,17 @@ USA: Perfect. So that was all for this topic. - General approval for the proposal’s progress. - Some of the API details will need further discussion in an incubator call. + ## RegExp.escape for stage 2 + Presenter: Jordan Harband (JHD) + - [proposal](https://github.com/tc39/proposal-regex-escaping) JHD: So this is for `RegExp.escape` and I’ll try to summarize. -The ecosystem prefers a static function that takes a string and spits something out that you can put into new regex and implementations and dangers of doing that because user land implementations do not thoroughly escape sufficient characters so that you could safely insert the escaped output in any position in a composed regular expression. +The ecosystem prefers a static function that takes a string and spits something out that you can put into new regex and implementations and dangers of doing that because user land implementations do not thoroughly escape sufficient characters so that you could safely insert the escaped output in any position in a composed regular expression. -JHD: As a result, there were objections or concerns expressed that it might be better to have a -template tag function that creates an entire regular expression in one go, doing the needed -escaping and in fact an implementation was built and published on npm from that but seems like -it has not gotten a lot of adoption and people just aren’t asking for it. And in a previous meeting, it was discussed that if we could come up with a way for `Regexp.escape` to be safe such that the output can be safely used in regular expression position that it would be viable for us to advance that and in particular then node and/or the web I guess node is the one that I know for sure wouldn’t try to implement the static version themselves any way which is. There’s a node TSC member who has basically said as soon as progress stops on this proposal, that node will just ship it anyway. +JHD: As a result, there were objections or concerns expressed that it might be better to have a template tag function that creates an entire regular expression in one go, doing the needed escaping and in fact an implementation was built and published on npm from that but seems like it has not gotten a lot of adoption and people just aren’t asking for it. And in a previous meeting, it was discussed that if we could come up with a way for `Regexp.escape` to be safe such that the output can be safely used in regular expression position that it would be viable for us to advance that and in particular then node and/or the web I guess node is the one that I know for sure wouldn’t try to implement the static version themselves any way which is. There’s a node TSC member who has basically said as soon as progress stops on this proposal, that node will just ship it anyway. JHD: So KG graciously offered to do the research to figure out what would be required to make it safe and I have this gist here which basically lists that if we escape every ASCII function way Tory except underscore and here is explicit list whitespace and any digit zero to nine at the start of the string and additionally we make any of these escape functions that are currently illegal in U and V node be legal and no ops meaning backslash whatever would just be whatever. That’s what I mean by no-op and then here is the additional caveat if you don’t put the output immediately after the beginning of an escape or after a backslash or, you know, in the beginning of a regexp would be safe and cannot lead to complex escapes. Here is more detail that Kevin included. I will add this. I have not yet added this into the readme of the proposal. I will do it if it’s the approach that we go forward with. @@ -1992,13 +1495,9 @@ JHD: And so the output ends up being gross. It has backslashes all over the plac But who cares? No one is reading this output. The intention is to make a regular expression that can be used, not to read the pattern. That’s my personal opinion anyway. So even though it sucks that we have to escape this many things, I don’t really care because it achieves the same semantic goal that the ecosystem already achieves with a number of NPM packages and wants to achieve. The spec text for this is here merged into the proposal which does all of the escapings that KG has described there. And, you know, modulo editorial feedback from the editors and I’m sure cleaner ways to do this and modulo updating the README of the proposal, this seems complete to me. -JHD: So my hope is that we can go forward ideally to Stage 2 with this spec text and the intention -to escape all the things so if something comes up that we missed the spec text will adapt to -include that thing because the goal is make it safe and move forward with the proposal. And if the temporal tag is desired this does not obstruct it and perfectly fine to move forward -with that. +JHD: So my hope is that we can go forward ideally to Stage 2 with this spec text and the intention to escape all the things so if something comes up that we missed the spec text will adapt to include that thing because the goal is make it safe and move forward with the proposal. And if the temporal tag is desired this does not obstruct it and perfectly fine to move forward with that. -JHD: That can be independently motivated and I invite anyone interested to pursue a proposal for -That. I don’t know if there are thoughts, or if we should go to the queue. +JHD: That can be independently motivated and I invite anyone interested to pursue a proposal for That. I don’t know if there are thoughts, or if we should go to the queue. DLM: We discussed this internally. SpiderMonkey team is quite favorable about this proposal and seems like a good idea and I think having it in language will prevent people from using library functions that are out of date. We really support this, thank you. @@ -2013,9 +1512,7 @@ MF: And the term new context that we’re using here is quite broad. We’re not KG: I’m only concerned about multi-character tokens of variable length. `\x00` is always exactly the same length. It’s never ambiguous whether an interpolation is part of that or not. The concern is multi-character tokens where the length of the token is determined by the characters which follow it, like \1 and so forth. I think we should avoid new ones for those. MM: First up, I want to say bravo. You took all of the concerns, the safety concerns very seriously and solved them very elegantly with a nice small explicit list of the unsafe context. -I also want to say that the template tag that Mike Samuel did that I pointed to as the example of something that does it safely that doesn’t have to – you don’t have to remember these -special contexts, it also had a tremendous case analysis because it wasn’t doing all of the escaping independent of context with this in hand, if somebody sets out to write a safe template tag that just checks for these contexts and just uses this full escaper once it’s determined to -be safe. I think that template literal type becomes tremendously easier to write. Just in all ways I just want to say I am very impressed. I really am grateful for KG for doing that analysis and I support this. +I also want to say that the template tag that Mike Samuel did that I pointed to as the example of something that does it safely that doesn’t have to – you don’t have to remember these special contexts, it also had a tremendous case analysis because it wasn’t doing all of the escaping independent of context with this in hand, if somebody sets out to write a safe template tag that just checks for these contexts and just uses this full escaper once it’s determined to be safe. I think that template literal type becomes tremendously easier to write. Just in all ways I just want to say I am very impressed. I really am grateful for KG for doing that analysis and I support this. KG: Thank you MM. @@ -2024,13 +1521,18 @@ JHD: I’d like to ask for consensus for Stage 2 for `RegExp.escape` +1 on the queue from DE, NRO, LCA, JWK, DLM USA: Nobody opposes. You have consensus. Congratulations. + ### Summary -* Based on KG’s analysis of what escapes are necessary for RegExps, in the most conservative, context-insensitive way, JHD proposes adding a simple `RegExp.escape` function. -* A key concern is whether it is sufficiently future-proof to do only this fixed kind of escaping. KG and JHD argued that it was sufficient, as we should avoid adding new tokens that would not fit within this scheme anyway. + +- Based on KG’s analysis of what escapes are necessary for RegExps, in the most conservative, context-insensitive way, JHD proposes adding a simple `RegExp.escape` function. +- A key concern is whether it is sufficiently future-proof to do only this fixed kind of escaping. KG and JHD argued that it was sufficient, as we should avoid adding new tokens that would not fit within this scheme anyway. ### Conclusion -* `RegExp.escape` reaches Stage 2 + +- `RegExp.escape` reaches Stage 2 + ## Reviving export default from; for stage 2? (JHD) + Presenter: Jordan Harband (JHD) JHD: There’s this old proposal here called “export default from” back from, looks like, seven years ago. @@ -2039,9 +1541,9 @@ So it’s 2016 or so. At the time, there were two proposals, one of which ended JHD: This is if you want to re-export the default as a default. So essentially this is right here. JHD: This is in the README of the proposal for many years now. -Just export whatever from the module. And because there’s no curly braces means default on both ends. +Just export whatever from the module. And because there’s no curly braces means default on both ends. -JHD: That’s it. And I’d like to, I’ve not been involved in the proposal previously, but I would like to revive this and, I haven’t, so I would like to become a champion of it and potentially, I don’t know if I’m sure the spec text is out of date and not based on the specification and my hope is, I haven’t looked into it, but my hope it will be a pretty straight forward rebase. +JHD: That’s it. And I’d like to, I’ve not been involved in the proposal previously, but I would like to revive this and, I haven’t, so I would like to become a champion of it and potentially, I don’t know if I’m sure the spec text is out of date and not based on the specification and my hope is, I haven’t looked into it, but my hope it will be a pretty straight forward rebase. JHD: I put Stage 2 with a question mark because I haven’t done the work yet to be able to confidently say it’s ready. But it feels like it’s probably ready and I would like to ideally, if I don’t have Stage 2 for this today, I would like to get clearer feedback for whatever it would take to get Stage 2 at a future meeting so I can take this over and get it to that point. That’s it. @@ -2049,11 +1551,11 @@ USA: I see a clarifying question from Luca. LCA: I think I know the answer already, but I didn’t quite understand when you said it. This is importing default, exporting name. Not importing default, exporting default. Correct? Or is this importing default, exporting default? -JHD: This is the latter. Importing default, exporting default. If you want to import default and export as named, you export curly default as whatever. And if you want to import named and export as default, you export curly whatever as default but if you want to import as default and re-export as default, it would be really nice to have symmetry between the typical import default and export default forms where no curly braces are used. And that’s what this provides. +JHD: This is the latter. Importing default, exporting default. If you want to import default and export as named, you export curly default as whatever. And if you want to import named and export as default, you export curly whatever as default but if you want to import as default and re-export as default, it would be really nice to have symmetry between the typical import default and export default forms where no curly braces are used. And that’s what this provides. JHD: It’s not adding a new capability to the language. It’s just filling in a syntactic, like a surface syntax gap that currently exists. -LCA: In that case, I think if that is the case, then if it is import default, export default, then I don’t think the example that you showed was correct. +LCA: In that case, I think if that is the case, then if it is import default, export default, then I don’t think the example that you showed was correct. JHD: No? @@ -2071,15 +1573,15 @@ That example right there. That's export default as default. JHD: Thank you for clarifying. That makes sense to me. Thank you. -USA: Next we have Jack Works. +USA: Next we have Jack Works. -JWK: Support for +JWK: Support for MLS: Any kind, you know, and prove the point by going through this and not understanding what the proposal was trying to explain or features it was trying to move forward in the reviving of the proposal, what is the use case trying to solve and be able to have examples to, how the exporting would work? I don’t think there’s any rush here. I agree with some of the other comments. Specifically I would like to have a well thought out presentation to explain what we’re adding and why we’re adding it, and what’s the use case. -JHD: That’s totally fair. I’m very content if the answer is like that’s what I need to do to come back to Stage 2. The reason it sat here is because nobody picked it up. I don’t recall there ever being any real push back against it, just like maybe it’s not that important is what I recall. But I didn’t recall anything that was like this can’t happen for these reasons. +JHD: That’s totally fair. I’m very content if the answer is like that’s what I need to do to come back to Stage 2. The reason it sat here is because nobody picked it up. I don’t recall there ever being any real push back against it, just like maybe it’s not that important is what I recall. But I didn’t recall anything that was like this can’t happen for these reasons. So certainly this is not a well-crafted presentation I have right now. This is jetlag and winging it. It’s completely reasonable to ask me to come back with that. Before I did any work on the proposal, I wanted to get a clear signal from the committee, and never go anywhere. I have lots of other things on my plate. USA: There’s a reply by Luca. @@ -2095,7 +1597,7 @@ SYG: Yeah, I think I agree with what Michael said about not rushing it. I’m a USA: Next is EAO. -EAO: I have two things. I don’t understand why this is proposing something like export V from mod where V is the default export of mod and it ends up as the default export of the current one and it is not actually made locally available anywhere. I don’t understand why it doesn’t require export default from mod only. +EAO: I have two things. I don’t understand why this is proposing something like export V from mod where V is the default export of mod and it ends up as the default export of the current one and it is not actually made locally available anywhere. I don’t understand why it doesn’t require export default from mod only. LCA: Yeah, I’m happy to clarify that real quick. Turns out this proposal is actually two separate things. One is export default or sorry import the default from the module you’re importing and export as default and the syntax for this is export default for mod. And the other one is you import the default but you export it as a name and that syntax is `export v from mod`. So this solves both the import default export default and import default export named case. These are two separate things. The export v mod the module written in is default export of mod. @@ -2116,8 +1618,7 @@ EAO: That import makes V locally available. LCA: Yeah, exactly. It’s the desugaring minus having it locally available just like other exports export curly brace default as V end curly brace. -EAO: I don’t think I still understand with the symmetric export from on the screen export V from -mod, what does it matter what’s in that string that’s currently V?. +EAO: I don’t think I still understand with the symmetric export from on the screen export V from mod, what does it matter what’s in that string that’s currently V?. LCA: On the consumer of this program, of this module will be a named import called V. @@ -2139,36 +1640,34 @@ USA: Next we have a comment from Hax (CODE?) that says, yeah, it’s a little bi USA: And that’s the queue. -JHD: So it sounds clear that this is not ready for Stage 2 from multiple fronts. So I want to paraphrase what I’m hearing as the signal for what it needs when I come back in order to be ready for Stage 2. +JHD: So it sounds clear that this is not ready for Stage 2 from multiple fronts. So I want to paraphrase what I’m hearing as the signal for what it needs when I come back in order to be ready for Stage 2. It needs to be very clear what the use cases are in 2023, what the motivation is for it, the perhaps the prose here might be reworded to be clearer about the two different pieces of functionality that this proposal adds and that will include justification for the existing one-liner way to do things and why this would be a preferred alternative and so on and then of course the spec text will need to be rebased, conceptually, on top of the latest 262 spec. -JHD: Is there anything I’m missing for what would be required bring it back and have a reasonable -expectation of getting Stage 2? Okay. Then it sounds like I will become the champion of this proposal and perhaps work with LCA as well. Welcome to have more champions if anyone is interested. +JHD: Is there anything I’m missing for what would be required bring it back and have a reasonable expectation of getting Stage 2? Okay. Then it sounds like I will become the champion of this proposal and perhaps work with LCA as well. Welcome to have more champions if anyone is interested. In a future meeting I will bring this back with those updates. Thank you. USA: There was one last item by Nicolo. Go for it. -NRO: In case with the committee decide we don’t want these export V from mod form, like how do you all feel about export source V from mod which is like exactly that form specifically for -sourcing parts? +NRO: In case with the committee decide we don’t want these export V from mod form, like how do you all feel about export source V from mod which is like exactly that form specifically for sourcing parts? -JHD: To me, it seems important that they be the same. If we shipped one of them, we’re kind of forcing the other one to be shipped. So it seems worth holding off the export source X from X piece until that question has been answered with this proposal because I would imagine if that piece of this proposal was rejected, that to me they feel like they go hand in hand. +JHD: To me, it seems important that they be the same. If we shipped one of them, we’re kind of forcing the other one to be shipped. So it seems worth holding off the export source X from X piece until that question has been answered with this proposal because I would imagine if that piece of this proposal was rejected, that to me they feel like they go hand in hand. If we reject one, we reject the other. If we accept one, we accept the other and important they are consistent. LCA: We didn’t include export source from mod in import source because specifically we wanted to do this with this proposal. It is note while it is possible to do everything proposed in this proposal in the one-liner already, it is not possible to do that with export or with import source because there’s no export form. Also the current solutions would not work for export source because the solution, the one-liner solutions we have right now rely on the fact there is a name space object which can be sort of destructured. It’s not really destructuring but sort of destructured. This is not the case of module source imports because they don’t have a namespace object. So, yeah, I guess we can talk about that next time we come back. -USA: There is a reply. +USA: There is a reply. EAO: Just don’t think on my part if that is the case, then source exports not being otherwise available makes for a decent use case to implement this in order for the shapes to be in parallel with each other. JHD: I agree. That will be more compelling motivation, I will make sure to include that. Thank you. -USA: Jack Works mentioned their position which is to support this proposal to fill the gap. And LCA’s use case is also important for them. +USA: Jack Works mentioned their position which is to support this proposal to fill the gap. And LCA’s use case is also important for them. ### Summary - Prior to requesting stage 2, JHD will make it very clear what the use cases are in 2023, including motivations. The repo prose here needs to be reworded to be clearer about the two different pieces of functionality that this proposal adds, and to include the existing one-liner way to do things and why this would be a preferred alternative. Additionally, the spec text will be updated to use modern 262 idioms. + ## DataView get/set Uint8Clamped methods for stage 2 (JHD) Presenter: Jordan Harband (JHD) @@ -2187,12 +1686,9 @@ USA: I would like to support this proposal. It looks odd that there’s just the USA: Also we have Jack Works with support in the queue. -JHD: Just to make sure all the viewpoints are being represented, I definitely heard from at least -one if not two delegates that they see no benefit in filling this gap. I have heard nobody say there would be harm in doing so. I haven’t heard any defensible opinion there. More that, like, it doesn’t seem worth even doing it. But my particular personal use case is dynamically dispatching based on TypedArray type and it’s super annoying to have to put a special case in there just for UN 8 clamped arrays for -completeness and this makes my code cleaner. That’s why I would like to do it. +JHD: Just to make sure all the viewpoints are being represented, I definitely heard from at least one if not two delegates that they see no benefit in filling this gap. I have heard nobody say there would be harm in doing so. I haven’t heard any defensible opinion there. More that, like, it doesn’t seem worth even doing it. But my particular personal use case is dynamically dispatching based on TypedArray type and it’s super annoying to have to put a special case in there just for UN 8 clamped arrays for completeness and this makes my code cleaner. That’s why I would like to do it. -So I guess hearing nothing, I have message on the queue NICOLA on the category not harmful -and not useful. I’m completely content with people having the opinion and I find it useful for me. +So I guess hearing nothing, I have message on the queue NICOLA on the category not harmful and not useful. I’m completely content with people having the opinion and I find it useful for me. I want to be certain I’ve given people a chance to air an objection because I would prefer not to hear the same opinion when I seek Stage 3 since it feels like a stage, like a concern for today and not a concern for next time. USA: We have GLS in the queue. @@ -2207,7 +1703,7 @@ USA: Next we have CHU with support. MLS agrees with NRO and HAX agrees and then KG: I do think these are not particularly harmful. I think they’re slightly harmful because they suggest that there’s two things with different behavior and there’s not two things with different behavior. Like you just shouldn’t use the getUInt8Clamped because it’s getUInt8 and the fact it exists suggests that there’s some difference and there’s not. This is not a major harm. But it’s a very slight harm which makes me very slightly not want this proposal. Only very slightly, though. -JHD: Is that concern mitigated if it’s the same as get UN8? +JHD: Is that concern mitigated if it’s the same as get UN8? KG: Not even a little bit. @@ -2238,8 +1734,7 @@ USA: Next we have Michael Saboff. MLS: The only motivation is to make a dynamic dispatch in some JavaScript function, doesn’t sound like a lot of people necessarily want that to be easy, you’re basically putting on the implementations the effort to write in test and support these APIs, that are probably not used that much. So you’re moving, you know, the burden from one place to another. Not eliminating. -JHD: True. I mean, the implementation already has the code because that, you’re able to work with UInt8Clamped arrays and it’s just how it’s exposed. I will definitely agree that a small number of developers will write code that uses this. But the package in which I use it has a vast amount of downloads. So the number, you know and admittedly this specific code path is not used by most of those people. But there are potentially larger numbers of users who will transitively benefit from having -this functionality. +JHD: True. I mean, the implementation already has the code because that, you’re able to work with UInt8Clamped arrays and it’s just how it’s exposed. I will definitely agree that a small number of developers will write code that uses this. But the package in which I use it has a vast amount of downloads. So the number, you know and admittedly this specific code path is not used by most of those people. But there are potentially larger numbers of users who will transitively benefit from having this functionality. USA: Next we have Shu. @@ -2247,10 +1742,8 @@ SYG: Before I lose this train I thought I want to ask JHD to clarify, I don’t JHD: That’s effectively what I’ve done for the get. It’s the same functionality. That one is easy and annoying ternary that I don’t feel like I need. In the set method I have to reimplement the clamping logic. That, you know, it’s how would I say? It’s not super hard to get it wrong. But it’s still a bunch of math that could be gotten wrong. And I think I, I’m sure I didn’t get it right the first time I typed it out. It would be nice to have that logic covered in there. -And in particular, it’s because the data view methods allow to provide an argument whether it’s -little or big endianness and all the other type array methods use the default endianness. -If I’m trying to inoperability reasons or whatever force specific N-ness this is the one case -where it gets super wonky and different. I don’t personally when I’m writing this code I don’t want to have to think about the underlying bit patterns. If we add two more TypedArray types next year, I don’t want to have to think about that. I want it to work because the data view methods abstract that away from me. +And in particular, it’s because the data view methods allow to provide an argument whether it’s little or big endianness and all the other type array methods use the default endianness. +If I’m trying to inoperability reasons or whatever force specific N-ness this is the one case where it gets super wonky and different. I don’t personally when I’m writing this code I don’t want to have to think about the underlying bit patterns. If we add two more TypedArray types next year, I don’t want to have to think about that. I want it to work because the data view methods abstract that away from me. SYG: Okay. Thanks for explaining. My current thinking is so I’m more and more convinced the more I think about it, that the name aligning thing for the getter is harmful. Like I see, I agree with KG’s reasoning here completely basically that everything is kind of divided on machine typed lines and UintClamped is not machine integer. I think the disagreement with JWK support makes it easier, I think it makes it harder and KG said it doesn’t exist. For the clamp thing at least I understand where you’re coming from. It’s missing exclusivity in data view. @@ -2258,7 +1751,7 @@ Like I see, I agree with KG’s reasoning here completely basically that everyth SYG: I don’t want to block it, it doesn’t seem like that big of a deal. I find the motivation particularly weak because you want to write your particular library and the other support arguments we have heard is it fills out the symmetry thing that I think is a little bit tricky and not like the symmetry thing is not some strong motivation in my opinion. SYG: So, I guess overall I think that puts me into the camp of against the getter. -But weakly against the setter. But not willing to block on the setter. That said, Stage 3: like the endianness thing I’m also jet lagged and I don’t think there’s more code to write for this and if there is and no use case, that’s not something that I want to write. +But weakly against the setter. But not willing to block on the setter. That said, Stage 3: like the endianness thing I’m also jet lagged and I don’t think there’s more code to write for this and if there is and no use case, that’s not something that I want to write. JHD: My assumption is since Chrome or V8 or whatever runs on machines with either endianness that the code lives somewhere in the implementation any way. I have no idea how the code base is written. @@ -2278,16 +1771,12 @@ But this isn’t all or nothing, right if I just get the setter and not the gett I’m very open to having that happen. I don’t want to drop the getter entirely from the whole plate. So it’s totally fine to split them up or say Stage 2 is fine but the getter may or may not be included. That’s fine with me. The setter is the one I find most valuable. -JHD: Are we okay with Stage 2 but with explicit understanding that the getter may or may not survive -to Stage 3? +JHD: Are we okay with Stage 2 but with explicit understanding that the getter may or may not survive to Stage 3? MLS: So I want to go back to the comment you made that you think that the path and the code you’re writing was going to be seldom used, any method that we add to the language, it has implemented and tested and so and so forth and possibly bugs, I don’t think there would be bugs for something like this. If something is seldomly used and we have a way of doing this in JavaScript itself, it seems to me that’s the better choice to take. -SYG: I can see other solutions in the space where the thing we have, we have made arguments in -the past of something is worth standardizing if it’s done often. Also made arguments, something is worth standardizing if it’s difficult to get correct. You have put forth the claim, it’s difficult to get the clamping thing correct. We have put some forth some counterarguments that we think is confusing to suggest that UintClamp is different and alternative and the thing to standardize is clamping operation that is -used exactly for Uint8 clamp and that is composed with whatever the library is doing together -with the existing data view. +SYG: I can see other solutions in the space where the thing we have, we have made arguments in the past of something is worth standardizing if it’s done often. Also made arguments, something is worth standardizing if it’s difficult to get correct. You have put forth the claim, it’s difficult to get the clamping thing correct. We have put some forth some counterarguments that we think is confusing to suggest that UintClamp is different and alternative and the thing to standardize is clamping operation that is used exactly for Uint8 clamp and that is composed with whatever the library is doing together with the existing data view. JHD: I suppose that is another alternative. That doesn’t address the endianness thing and use set UN 8 with UN 8 with the clamping exposed and that is a viable alternative. I still don’t think it’s ideal because I think it’s, I do think there is value in having this table be nice and pretty and green. Symmetry for symmetry sake, in other words. I understand that’s not compelling to everyone. @@ -2304,10 +1793,9 @@ USA: Well, to be more specific, what exactly do you want to ask for, a temperatu JHD: The goal is, the optimistic goal is the temperature check is many folks who don’t wish to speak, but support the symmetry argument and expose if there are folks who have not spoken who think it would be harmful to include these. Maybe something that offers those as choices in varying degrees. -USA: So suppose to be more precise, you’re asking for a temperature check on specifically the -inclusion of both the get and set methods? +USA: So suppose to be more precise, you’re asking for a temperature check on specifically the inclusion of both the get and set methods? -JHD: Sure. +JHD: Sure. USA: Okay. Well @@ -2320,7 +1808,7 @@ SFC: I feel like it’s sufficient to just say do you support this proposal movi USA: But that doesn’t completely satisfy what Jordan was asking for because it’s -JHD: Let’s have one of the emojis by support adding both methods. One of the emojis being I support adding only the setter. I see RPR shaking his head. +JHD: Let’s have one of the emojis by support adding both methods. One of the emojis being I support adding only the setter. I see RPR shaking his head. RPR: This always becomes very awkward trying to redefine things and much easier if it’s a statement how much agreement is there with that direction. @@ -2329,15 +1817,13 @@ And then let’s see the sentiment, how about that? USA: Temperature check is open. Anyone else? -JHD: This is just about symmetry being a convincing enough argument for following through with -this? +JHD: This is just about symmetry being a convincing enough argument for following through with this? Unknown: I don’t see the temperature check. -RPR: I think TCQ is breaking and going up and down about a number of times today. +RPR: I think TCQ is breaking and going up and down about a number of times today. -SFC: I think the temperature check appears if you have the page open when the moderator pushes -the button. +SFC: I think the temperature check appears if you have the page open when the moderator pushes the button. // much discussion about failures/delays with TCQ and the temperature check, such as: @@ -2345,8 +1831,7 @@ USA: If you reload it goes away. // continuing commenting after temperature check is complete -JHD: Just roughly seeing two digits of positive or better and approaching two digits of -unconvinced and couple indifference. Does that seem about right to everybody with the varying views on the counts? +JHD: Just roughly seeing two digits of positive or better and approaching two digits of unconvinced and couple indifference. Does that seem about right to everybody with the varying views on the counts? MF: Can we give it another minute or two. @@ -2361,9 +1846,9 @@ But I think, you know, all things considered it’s your conclusion to make. Would you like to ask for consensus? JHD: I suppose. That’s what I will ask is consensus for Stage 2. And I guess there’s three possible paths forward based on SYG’s proposal: - - both the getter and the setter, - - just the setter, or - - coming up with some alternative shape that expresses the clamping logic and leaving the getter and setter as a gap. + +- both the getter and the setter, +- just the setter, or - coming up with some alternative shape that expresses the clamping logic and leaving the getter and setter as a gap. And with one of those three options, we could move forward. They’re all probably the same tiny number of spec steps. But they may have different implementation maintenance costs as Michael indicated. @@ -2373,23 +1858,21 @@ USA: There is a queue. I would request to be quick. JWK you were on the queue pr JWK: the getU8Clamp is the same as getU8 because the data is already clamped when it was set, maybe it can be set with the same function. We have prior art in the language that Array#value and Array@@iterator are the same function. -JHD: That’s definitely a, you know, whether it’s a new function object or the ailious function -object as you described, those are two possible ways of implementing the getter. +JHD: That’s definitely a, you know, whether it’s a new function object or the ailious function object as you described, those are two possible ways of implementing the getter. USA: Nicola. -NRO: Moving forward, mean towards consistency side and just have both rather than just one so -that people who know about the set will see the get and not be surprised when it’s not there. +NRO: Moving forward, mean towards consistency side and just have both rather than just one so that people who know about the set will see the get and not be surprised when it’s not there. USA: JHD, real quick, can you refine this a bit and be more specific about what you think would be the ideal because I don’t think we can get consensus. -JHD: Okay. So I was asking for earlier, is Stage 2 with the understanding that there are three paths forward for this proposal: One is both the getter and the setter, one is just the setter, and the third would be a single function that takes a number and returns the clamped version of that number. +JHD: Okay. So I was asking for earlier, is Stage 2 with the understanding that there are three paths forward for this proposal: One is both the getter and the setter, one is just the setter, and the third would be a single function that takes a number and returns the clamped version of that number. And so that’s a pretty simple straight forward API that wouldn’t change. It’s not trivial whether the getter is ailious or new function object that can be resolved within Stage 2 and it’s trivial where the clamping function lives, that can be resolved within Stage 2. So that’s what I’m asking for. -SYG: So I think I’ll do the hard thing. I’ll withhold consensus for Stage 2 for this reason which I would like this to be settled between my suggestion and the setter specifically. I think there’s possible confusion in the setter if, UN8 clamped array does not have an endianness argument and to have it in the data view. +SYG: So I think I’ll do the hard thing. I’ll withhold consensus for Stage 2 for this reason which I would like this to be settled between my suggestion and the setter specifically. I think there’s possible confusion in the setter if, UN8 clamped array does not have an endianness argument and to have it in the data view. I think could introduce confusion about what the clamping does, it’s not like the endianness is coding on the numeric value and clamping is done on the numeric value and doing a endianness argument you can control are you clamping one byte or another byte and taking the value and it’s not clear. JHD: The clamping is when you assign to UN 8 clamped array. @@ -2398,8 +1881,7 @@ SYG: You cannot choose it. Does what the machine does. JHD: The way it already works is the clamping produces a number value and the number value in store in whichever order the endianness is. That would be the case. -SYG: Now you made it user-provided argument I think it introduces confusion on what actually is -happening. +SYG: Now you made it user-provided argument I think it introduces confusion on what actually is happening. MLS: It has to do with how bytes are ordered in word not how bits are ordered in a byte? @@ -2407,8 +1889,7 @@ JHD: Yeah, I think that same argument. MLS: There is no N-ness for 8 bit value. -JHD: I think the same confusion would exist for all of the values for which truncation occurs and -you coerce it. I don’t think that’s a new thing with the methods. No one has been confused by this. +JHD: I think the same confusion would exist for all of the values for which truncation occurs and you coerce it. I don’t think that’s a new thing with the methods. No one has been confused by this. USA: We need to really end this. We ran over timebox, we need to take this offline. @@ -2421,44 +1902,36 @@ While there is strong support for this proposal with both a getter and a setter, No conclusion or advancement; ran out of time. ## Withdrawing Symbol.thenable + Presenter: Jordan Harband (JHD) + - [proposal](https://github.com/tc39/proposal-symbol-thenable) -JHD: There was a proposal a while back – Symbol.thenable. We did this in 2018, I think, and the idea was this was back when native ESM just shipped in browsers and the hope was to prevent modules from being thenable meaning when you dynamically import a module, the current status is that if that module exports a then function, that the thing you get from dynamic import won’t be a module end space it would be whatever the exported then function resolves to. +JHD: There was a proposal a while back – Symbol.thenable. We did this in 2018, I think, and the idea was this was back when native ESM just shipped in browsers and the hope was to prevent modules from being thenable meaning when you dynamically import a module, the current status is that if that module exports a then function, that the thing you get from dynamic import won’t be a module end space it would be whatever the exported then function resolves to. -JHD: One of the hopes with this proposal was to allow – provide a generic mechanism in the -promise protocol so that things could opt out of being thenable even if they have a then -function. The primary purpose was so that module end space objects would define this and then not be -thenable even if you exported the then function. +JHD: One of the hopes with this proposal was to allow – provide a generic mechanism in the promise protocol so that things could opt out of being thenable even if they have a then function. The primary purpose was so that module end space objects would define this and then not be thenable even if you exported the then function. -JHD: A tiny benefit is that any folks annoyed that their then functions in the libraries have to be -promised then functions, this would give them a way to have a then function without – I mean, +JHD: A tiny benefit is that any folks annoyed that their then functions in the libraries have to be promised then functions, this would give them a way to have a then function without – I mean, without participating in promises. -JHD: But this was rejected at the time or stalled at the time because the web had shipped modules -and so had – people were already depending on this functionality. -In the intervening years, it doesn’t appear that that situation has changed nor does it appear -that anyone has run into massive problems from thenable modules. +JHD: But this was rejected at the time or stalled at the time because the web had shipped modules and so had – people were already depending on this functionality. +In the intervening years, it doesn’t appear that that situation has changed nor does it appear that anyone has run into massive problems from thenable modules. It’s just another annoyance that we now have forever. -JHD: So my proposal is essentially I’m saying I think we should just mark this proposal as withdrawn -and, you know, explain that it’s not likely to ever progress for web compatibility reasons. +JHD: So my proposal is essentially I’m saying I think we should just mark this proposal as withdrawn and, you know, explain that it’s not likely to ever progress for web compatibility reasons. DE: Do we need consensus for withdrawals? I’m in favor of withdrawing it. Thanks for presenting it Jordan. What is our process for withdrawals? I assumed for any stage advancement or demotion, whatever we decided to call that, you need consensus. Withdrawal would also kind of need consensus. -JHD: Stage zero. +JHD: Stage zero. DE: Okay, sorry. -JHD: The way we operated in the past is you can summarily drop any proposal you’re suggesting -and someone could bring to the stage it was at when you withdraw it. -Since it was at stage zero and failed to have Stage 1, in the case of stage zero proposal, there’s like withdrawing it is just sort of formally moving it in the proposal’s table and not -something that – +JHD: The way we operated in the past is you can summarily drop any proposal you’re suggesting and someone could bring to the stage it was at when you withdraw it. +Since it was at stage zero and failed to have Stage 1, in the case of stage zero proposal, there’s like withdrawing it is just sort of formally moving it in the proposal’s table and not something that – DE: So for the proposals that I’m planning on withdrawing, I’m going to ask for consensus on withdrawal. I want the committee to have a shared decision on where they think the proposal is, rather than encouraging the reintroduction. Anyway, we can have the process discussion later. -JHD: For anything where someone want to reintroduce it, that seems like a wise approach -regardless of the process. +JHD: For anything where someone want to reintroduce it, that seems like a wise approach regardless of the process. DE: I think we have different readings of what the current process is. We don’t need to conclude today. @@ -2479,16 +1952,19 @@ GB: The main thing I think about is just interop with other languages where you DE: But, yeah. So we can imagine problems. We already have problems. But does that – could that justify from this broad of a thing where you add the extra property access to this common code path? -GB: Yeah, I appreciate that. Any way, sorry, do you have— +GB: Yeah, I appreciate that. Any way, sorry, do you have— NRO: Given that consensus we can do anything, we could say some more data and change our mind and now we have consensus and actually adding, doing whatever we said we would never do. I don’t think consensus is never doing something is like really is useful for how our process works. MLS [on queue]: Agree with NRO + ### Summary + - Some aspects of the TC39 process need to be clarified. ### Conclusion + - Symbol.thenable is withdrawn. ## Approval of minutes @@ -2496,5 +1972,3 @@ MLS [on queue]: Agree with NRO SHN: We may not have approved the minutes of the last TC39 meeting. RPR: Any objections to approving the July 2023 minutes? OK, we will consider that approved. - - diff --git a/meetings/2023-09/september-27.md b/meetings/2023-09/september-27.md index a710179c..65206f4c 100644 --- a/meetings/2023-09/september-27.md +++ b/meetings/2023-09/september-27.md @@ -1,11 +1,9 @@ -98th TC39 Meeting -Wednesday 27th September 2023 +# 27 September, 2023 Meeting Notes + ----- -Delegates: re-use your existing abbreviations! If you’re a new delegate and don’t already have an abbreviation, choose any three-letter combination that is not already in use, and send a PR to add it upstream. -You can find Abbreviations in delegates.txt +**Remote and in person attendees:** -**Attendees:** | Name | Abbreviation | Organization | | -------------------- | ------------ | ----------------- | | Ujjwal Sharma | USA | Igalia | @@ -39,169 +37,93 @@ You can find Abbreviations in delegates.txt | Philip Chimento | PFC | Igalia | ## ShadowRealm: Implementer Feedback and Demotion to Stage 2 + Presenter: Daniel Minor (DLM) [proposal](https://github.com/tc39/proposal-shadowrealm) [slides](https://docs.google.com/presentation/d/1WJd9g3df_ibVHK3LdoKX2FboDwYQBUBJNxuRAWOYYbM/edit#slide=id.p) -DLM: Okay, perfect, thank you. Great, so, yes, today I’d like to talk about ShadowRealms, -provide some implementer feedback and talk about demotion to Stage 2. ShadowRealms provide a mechanism to execute JavaScript code in the context of a -global built-in and the goal is integrity, trying to isolate code in the separate realms and -isolate interaction and this advanced to Stage 3 at the July 21, meeting. So we talked about -the current status in Firefox and we landed our initial implementation in Firefox 104 which is -just over a year ago. It’s currently turned off and what’s been implemented so far is -basically JavaScript parts, SpiderMonkey specific parts and is ShadowRealm also, but in this -case, the work on the HTML integration is stalled and it’s our opinion that there’s -insufficient tests available and there’s potentially large impact on the DOM side of the code -base. So talking a little more about HTML integration. We suspect it will be a substantial -amount of work because, at least in Firefox’s case, I’m not sure about other -implementations, we need to audit any DOM API that is going to be exposed to ShadowRealm -that documents are a [INAUDIBLE] or work. So that’s all over the place in our code base and -going to require some closed cooperation and coordination between DOM and the JavaScript engine -team because a lot of this work might end up on the DOM side of the thing. Those are perhaps -Firefox-specific problems, but I wouldn’t be surprised if that’s the case for other -implementations as well. So in our position is that this proposal isn’t -implementable as it currently stands. What we really need the is review of which DOM APIs that -should be exposed to ShadowRealms. And we also are looking for sufficient tests to -ensure the correct behavior of these APIs in ShadowRealms, my understanding is up until -recently, the only tests available basically just instantiate the API inside of ShadowRealm, -but there was no test of functionality. And so that, at least in our case, would not be enough -to uncover bugs in the integration. So in terms of next steps, I see three ways ahead. One -is to just remove the HTML integration completely and make this a JavaScript only proposal. In -that case, it would be acceptable to SpiderMonkey to keep this at Stage 3 and the V8 team has -already communicated to me this is not an acceptable way ahead for them. The other option is -demotion to Stage 2, pending more work on HTML integration and testing. I understand that this -kind of work is already underway or 3 would be to drop the proposal completely. I don’t think -we should leave this at Stage 3. I think that’s going to send a wrong message to the community -about how ready this proposal is. I have heard efforts have begun to write more -tests, but SpiderMonkey team’s position is that we should demote this to Stage 2 until -the tests have been completed and we have had a chance to review them. To be honest, we -probably would have not allowed this to go to Stage 3 if we had understood the state of the testing -at the time that it advanced. And that’s it for my presentation. So I guess I’d like to open -it up for the queue. - -DE: I’m in agreement with demoting this agreement to Stage 2. I worked on the HTML integration for the proposal and we worked on an attempt to figure out which API would work with HTML integration. That was more from a design perspective and it lacked sufficient implementation participation, and yes, we are insufficient on tests. So I have been hoping that someone would pick this up. -It’s been a couple years and hasn’t been picked up. I’m really glad that Mozilla is bringing -this to agenda because it continues to not be a shippable state. So, yeah, I just want to note -that there is some integration and the problem is it’s just not in a good enough state yet. +DLM: Okay, perfect, thank you. Great, so, yes, today I’d like to talk about ShadowRealms, +provide some implementer feedback and talk about demotion to Stage 2. ShadowRealms provide a mechanism to execute JavaScript code in the context of a global built-in and the goal is integrity, trying to isolate code in the separate realms and isolate interaction and this advanced to Stage 3 at the July 21, meeting. So we talked about the current status in Firefox and we landed our initial implementation in Firefox 104 which is just over a year ago. It’s currently turned off and what’s been implemented so far is basically JavaScript parts, SpiderMonkey specific parts and is ShadowRealm also, but in this case, the work on the HTML integration is stalled and it’s our opinion that there’s insufficient tests available and there’s potentially large impact on the DOM side of the code base. So talking a little more about HTML integration. We suspect it will be a substantial amount of work because, at least in Firefox’s case, I’m not sure about other implementations, we need to audit any DOM API that is going to be exposed to ShadowRealm that documents are a [INAUDIBLE] or work. So that’s all over the place in our code base and going to require some closed cooperation and coordination between DOM and the JavaScript engine team because a lot of this work might end up on the DOM side of the thing. Those are perhaps Firefox-specific problems, but I wouldn’t be surprised if that’s the case for other implementations as well. So in our position is that this proposal isn’t implementable as it currently stands. What we really need the is review of which DOM APIs that should be exposed to ShadowRealms. And we also are looking for sufficient tests to ensure the correct behavior of these APIs in ShadowRealms, my understanding is up until recently, the only tests available basically just instantiate the API inside of ShadowRealm, +but there was no test of functionality. And so that, at least in our case, would not be enough to uncover bugs in the integration. So in terms of next steps, I see three ways ahead. One is to just remove the HTML integration completely and make this a JavaScript only proposal. In that case, it would be acceptable to SpiderMonkey to keep this at Stage 3 and the V8 team has already communicated to me this is not an acceptable way ahead for them. The other option is demotion to Stage 2, pending more work on HTML integration and testing. I understand that this kind of work is already underway or 3 would be to drop the proposal completely. I don’t think we should leave this at Stage 3. I think that’s going to send a wrong message to the community about how ready this proposal is. I have heard efforts have begun to write more tests, but SpiderMonkey team’s position is that we should demote this to Stage 2 until the tests have been completed and we have had a chance to review them. To be honest, we probably would have not allowed this to go to Stage 3 if we had understood the state of the testing at the time that it advanced. And that’s it for my presentation. So I guess I’d like to open it up for the queue. + +DE: I’m in agreement with demoting this agreement to Stage 2. I worked on the HTML integration for the proposal and we worked on an attempt to figure out which API would work with HTML integration. That was more from a design perspective and it lacked sufficient implementation participation, and yes, we are insufficient on tests. So I have been hoping that someone would pick this up. +It’s been a couple years and hasn’t been picked up. I’m really glad that Mozilla is bringing this to agenda because it continues to not be a shippable state. So, yeah, I just want to note that there is some integration and the problem is it’s just not in a good enough state yet. Thank you. -SYG: V8 agrees with the reasoning that DLM put forth. So I also support demotion -to Stage 2 because it’s not in an implementable and shippable state and I want to reiterate -what DLM has already said, which is that option 1 on the screen right now we consider -- V8 -objects to taking path 1 and I want to take that off the table. I think it is important that -the ShadowRealm’s feature remain integratable into the host and should get a subset of host -APIs that make sense on the ShadowRealm instead of only shipping the ones that are in 262, +SYG: V8 agrees with the reasoning that DLM put forth. So I also support demotion to Stage 2 because it’s not in an implementable and shippable state and I want to reiterate what DLM has already said, which is that option 1 on the screen right now we consider -- V8 objects to taking path 1 and I want to take that off the table. I think it is important that the ShadowRealm’s feature remain integratable into the host and should get a subset of host APIs that make sense on the ShadowRealm instead of only shipping the ones that are in 262, because we don’t want to ship our org chart and all that. That’s all. -NRO: Yes, so, like, depending on work on HTML integration, like, how -- do we have a way to tell -when this work is done? Because the problem with this proposal is that for every API, we need -to choose whether to expose it or not. That’s the biggest HTML problem. So, like, is there a -way to somehow verify that the proposal is now ready for Stage 3, or do we just keep rechecking -all the APIs hoping that we didn’t miss something? +NRO: Yes, so, like, depending on work on HTML integration, like, how -- do we have a way to tell when this work is done? Because the problem with this proposal is that for every API, we need to choose whether to expose it or not. That’s the biggest HTML problem. So, like, is there a way to somehow verify that the proposal is now ready for Stage 3, or do we just keep rechecking all the APIs hoping that we didn’t miss something? -LEO: First of all, I am in favor of the demotion. We have a plan to tackle this problem. Unfortunately, Salesforce had to cut our earlier contract with Igalia, but it is now restarted. Now, Igalia will focus on HTML integration, including testing, with the goal to complete it to the point where the HTML PR can be accepted. I believe the ECMAScript parts are good, and our intention is to -keep them as they stand in terms of the ECMAScript parts, unless something comes up in the course of HTML integration. And I’m glad to be working back with Igalia. This will put us back on track again and accelerate this work. +LEO: First of all, I am in favor of the demotion. We have a plan to tackle this problem. Unfortunately, Salesforce had to cut our earlier contract with Igalia, but it is now restarted. Now, Igalia will focus on HTML integration, including testing, with the goal to complete it to the point where the HTML PR can be accepted. I believe the ECMAScript parts are good, and our intention is to keep them as they stand in terms of the ECMAScript parts, unless something comes up in the course of HTML integration. And I’m glad to be working back with Igalia. This will put us back on track again and accelerate this work. DLM: I think we’re in agreement, but, you know, when this comes back to Stage 3, I would just go through the normal review and consensus process then, and I’m sure the implementation will be happy to have a look at tests before that if you want to make sure that we will be happy with the level of testing prior to bringing this back to the committee. -LEO: Yes, I assume the HTML integration will require the tests to be complete. So I’m -fine going, again, with the consensus process, but I am best faith here assuming if we -have integration, we can have tests in good shape. We are following up. So this is even, -like, tests are not a requirement to enter Stage 3, but my hope is actually to have a -good implementation status when we come back to request Stage 3. But hopefully we should not -go back to the ECMAScript aspects of the API when we ask for Stage 3 again, but -I can only hope. - -DLM: Yes, I’m in agreement with that. Our only concern is can with the level of testing and -making sure that we have chosen the right set of DOM APIs to expose the ShadowRealms. - -LEO: Yes, and I fully understand, and I agree with the sentiment, like, this doesn’t feel ready -for implementation. As, like, it’s -- like, anything on the web, we can get this ready for on -the ECMAScript side and it works in some implementations, but it doesn’t work on the web, so I -think it’s fine bringing this back to Stage 2 until we complete this. Hopefully we can work -things out and run the tests again. - -CP: Yeah, I want to add to that, hopefully I’m audible now, I want to add to that that obviously -these particular proposals is in the sense that it requires a significant amount of work on -HTML. I haven’t seen a lot of proposals that have that level of integration with HTML and we -lost some funding with Igalia to get it to the finish line for over a year, so now we’re back -on the horse. So hopefully we can push through and get this in. We have already start getting -some tests in. Rick (?) has been working on that for a couple of weeks now. And so we continue to -do that, and we’ll continue to engage with Igalia and see if we can get all the pieces ready. +LEO: Yes, I assume the HTML integration will require the tests to be complete. So I’m fine going, again, with the consensus process, but I am best faith here assuming if we have integration, we can have tests in good shape. We are following up. So this is even, +like, tests are not a requirement to enter Stage 3, but my hope is actually to have a good implementation status when we come back to request Stage 3. But hopefully we should not go back to the ECMAScript aspects of the API when we ask for Stage 3 again, but I can only hope. + +DLM: Yes, I’m in agreement with that. Our only concern is can with the level of testing and making sure that we have chosen the right set of DOM APIs to expose the ShadowRealms. + +LEO: Yes, and I fully understand, and I agree with the sentiment, like, this doesn’t feel ready for implementation. As, like, it’s -- like, anything on the web, we can get this ready for on the ECMAScript side and it works in some implementations, but it doesn’t work on the web, so I think it’s fine bringing this back to Stage 2 until we complete this. Hopefully we can work things out and run the tests again. + +CP: Yeah, I want to add to that, hopefully I’m audible now, I want to add to that that obviously these particular proposals is in the sense that it requires a significant amount of work on HTML. I haven’t seen a lot of proposals that have that level of integration with HTML and we lost some funding with Igalia to get it to the finish line for over a year, so now we’re back on the horse. So hopefully we can push through and get this in. We have already start getting some tests in. Rick (?) has been working on that for a couple of weeks now. And so we continue to do that, and we’ll continue to engage with Igalia and see if we can get all the pieces ready. But, yeah, so that’s the current situation of that proposal. DE: For next steps: HTML integration generally goes through WHATWG, and WHATWG processes need support from two browsers, and no objections from any browsers. We will need active review and approval by at least two of the browser engine maintainers, in addition to no objections. Reviewers will be looking for these tests and at the choice of which APIs are provided. Is that correct? DLM: Yes, that’s correct. -PFC: Just wanted to respond to DE. Could we get those list of things in the conclusions -for this item so that we don’t end up having a similar discussion the next time we bring this -proposal back to plenary. +PFC: Just wanted to respond to DE. Could we get those list of things in the conclusions for this item so that we don’t end up having a similar discussion the next time we bring this proposal back to plenary. DLM: I’ll make sure that’s captured in the conclusion. -JHD: I support the demotion. I think in general, we -- as I’ve said a few times in -the past, we should be comfortably moving things through stages up and down so it accurately -reflects where the proposal is and we should all -- this should be under a clearer scope, just -as we’ve done with previous items. This is not an opportunity to be opportunist and relitigate -things that have been decided. It’s to accurately signal to the community and to -implementers where the proposal is. So +1. +JHD: I support the demotion. I think in general, we -- as I’ve said a few times in the past, we should be comfortably moving things through stages up and down so it accurately reflects where the proposal is and we should all -- this should be under a clearer scope, just as we’ve done with previous items. This is not an opportunity to be opportunist and relitigate things that have been decided. It’s to accurately signal to the community and to implementers where the proposal is. So +1. -MLS: I support the demotion to Stage 2. And there have been a lot of comments since then, +MLS: I support the demotion to Stage 2. And there have been a lot of comments since then, but I also don’t want option 1, so option 2 as we move forward. -RGN: Agoric are willing to accept the demotion on this, but really do hope that it comes back, and if -someone wants to pick it up, we’re willing to volunteer support, but don’t have anyone to champion it directly. +RGN: Agoric are willing to accept the demotion on this, but really do hope that it comes back, and if someone wants to pick it up, we’re willing to volunteer support, but don’t have anyone to champion it directly. CP: Certainly, if anyone is available for helping on this, please reach out. DLM: So if the queue is empty, I’d like to ask for consensus on the demotion to Stage 2. + ### Summary of Key Points + * ShadowRealms is a proposal at Stage 3 offering somewhat isolated contexts for JavaScript code to run in. ShadowRealms let JS execute in a fresh global context, including all of the ECMA-262 built-ins, as well as, optionally, APIs that the embedder provides. Prior to reaching Stage 3, the champions made a concrete proposal for which web APIs would be provided for ShadowRealms, and although this integration received high-level signoff from browsers, it did not come backed with thorough-enough web-platform-tests or a thorough audit of the implications of all of the APIs which it proposed adding. Mozilla has found this gap to mean that the proposal is not yet implementable, and the proposal has been at a stalemate for years since it reached this point, with the champions not yet filling in the gaps. * V8 and JSC agree that ShadowRealms should provide certain web APIs inside of ShadowRealms, so the host hook/html integration is a precondition for shipping. This implies that keeping the proposal at Stage 3 is not a viable solution. * For advancement back to Stage 3 we’ll look for explicit support from at least two implementations that the testing and list of APIs to be exposed to ShadowRealms are sufficient. * This will not be an opportunity to relitigate design decisions made already, made about the ShadowRealm API, advancement will focus solely on having a list of suitable APIs to be exposed to ShadowRealms along with sufficient tests. + ### Conclusion + * Consensus for demotion to Stage 2, with advancement to Stage 3 dependent upon having a list of suitable APIs to be exposed to ShadowRealms, along with sufficient tests to ensure correct behaviour in implementations. + ## Stage 3 Reviewers for RegExp.escape + JHD: Volunteers requested. -- JRL -- MF -- RGN +* JRL +* MF +* RGN JHD: Anyone else, please feel free to review, but I’ll stick with those three as the list. + ## AsyncContext update -Presenter: Chengzhong Wang -Slides: https://docs.google.com/presentation/d/12A3LYlqgzmqRqE0mJ47GRWB6uKlqoFXiWE9gsxpRje4/edit#slide=id.g27aef1f6697_0_74 -Repository: https://github.com/tc39/proposal-async-context - -CZW: Hi. I’m CZW from Alibaba and I’m going to present the Stage 2 for AsyncContext update. We -will have a quick recap, what is AsyncContext. It connects the async boundaries between different jobs. In this example, it is broken when multiple click events are being proposed at the same time, -so AsyncContext addresses the problems here. In JS community today, we have several approaches -like monkey-patching and various ad hoc approaches available to those problems, however, + +Presenter: Chengzhong Wang Slides: https://docs.google.com/presentation/d/12A3LYlqgzmqRqE0mJ47GRWB6uKlqoFXiWE9gsxpRje4/edit#slide=id.g27aef1f6697_0_74 Repository: https://github.com/tc39/proposal-async-context + +CZW: Hi. I’m CZW from Alibaba and I’m going to present the Stage 2 for AsyncContext update. We will have a quick recap, what is AsyncContext. It connects the async boundaries between different jobs. In this example, it is broken when multiple click events are being proposed at the same time, +so AsyncContext addresses the problems here. In JS community today, we have several approaches like monkey-patching and various ad hoc approaches available to those problems, however, the monkey-patching problem, it is broken by the async/await syntax, and APIs like AsyncLocalStorage are specific to Node.js and not available on the web platform. The proposal defines a formal model based on AsyncContext with the APIs AsyncContext.Variable and AsyncContext.Snapshot. It addresses the issue with Promise and async at a specification level, so it would not be broken by, for example, whether monkey-patching can control `await`’s behavior. CZW: The normative changes we are going to update is the context of unhandled rejections. Like we mentioned before, AsyncContext captures the async context when a deferred job is created and it will restore the async context when the deferred job is being invoked at a later point. As well, the event of unhandledrejection, it is a deferred job created when HostPromiseRejectionChecker is being called and which is being triggered with, when a promise executor caused the rejection function. The async context captures whenever a deferred job is created, like a microtask rather than a promise rejection itself, so for unhandledrejection event, the async context should be captured at a time when the rejection function is being called, so in this example, the value of the async variable should be called at a time of unhandledrejection event. -CZW: The second normative change is AsyncContext in generators. We defined that generators are -capturing async contexts when they are initialized, regardless of when the next function of a -generator object is being called in different async context value scopes. So in the example of -this slide, the value of async variable will be consistent throughout the generator function bodies, and it will always be the value of when the generator is initialized. - -CZW: Our next steps will be determining the full list of events that need the code handling -that is similar to the unhandledrejection event. We had a discussion in TPAC with people -from the browser engines, and we find that for all the events that the default behavior would -be logged at registration time, seeing as the unhandled rejection event is different from IO events. - -CZW: We have been prototyping the implementation to verify the performance regression, and we -found out that the performance regression is sadly observable since it has already propagated a -host set of values across promise continuations, but the -- host continuations, but the -current prototype, we identified the current prototype has performance regression on the -chromium’s task attribution since the web APIs use run under the hood, so we have to -consider optimizations on this part. And we also are exploring the compatibility between -Node.js’s AsyncLocalStorage, since it is the widely used alternative of the proposal, and it will need changes in the promise hooks to be able to describe the call time of the promise executors like we just -mentioned in the earlier slides. And we have to evaluate the performance impact of the change. +CZW: The second normative change is AsyncContext in generators. We defined that generators are capturing async contexts when they are initialized, regardless of when the next function of a generator object is being called in different async context value scopes. So in the example of this slide, the value of async variable will be consistent throughout the generator function bodies, and it will always be the value of when the generator is initialized. + +CZW: Our next steps will be determining the full list of events that need the code handling that is similar to the unhandledrejection event. We had a discussion in TPAC with people from the browser engines, and we find that for all the events that the default behavior would be logged at registration time, seeing as the unhandled rejection event is different from IO events. + +CZW: We have been prototyping the implementation to verify the performance regression, and we found out that the performance regression is sadly observable since it has already propagated a host set of values across promise continuations, but the -- host continuations, but the current prototype, we identified the current prototype has performance regression on the chromium’s task attribution since the web APIs use run under the hood, so we have to consider optimizations on this part. And we also are exploring the compatibility between Node.js’s AsyncLocalStorage, since it is the widely used alternative of the proposal, and it will need changes in the promise hooks to be able to describe the call time of the promise executors like we just mentioned in the earlier slides. And we have to evaluate the performance impact of the change. That’s all the updates we have in today’s present. And we -- we can go to the queue. DE: In those last couple slides, I think both of the concerns are a little bit oversold in this presentation. We don’t currently see a regression with V8 because V8 already stores a single pointer which is propagated across promise reactions (the “continuation local storage”). This has been on by default since 2020 in Chrome. When this was introduced, there was a lot of careful work done to make sure that it wasn’t a significant regression, and this proposal can be implemented in a way which builds off of that mechanism. Hopefully it can be applied similarly in other browsers. About PromiseHooks, I don’t think we’re asking for any particular change to be made to PromiseHooks. SYG can comment best about the future of the V8 API, but our goal is to expose an API at the V8 level analogous to AsynContext.Variable and AsyncContext.Snapshot rather than asking for a particular change to be made in PromiseHooks. Bloomberg is supporting Igalia’s work (e.g., from ABO) to do this prototyping and improve specification, etc. because we see this proposal as strong and very useful. @@ -212,16 +134,10 @@ DE: Yeah, I agree that we shouldn’t put much in these results, because the opt CZW: Yeah, it’s just early prototyping to evaluate the performance consideration that SYG has mentioned earlier. -JRL: The slide at the very bottom, here it says prototyping Chromium task attribution effort. Events in other web API use run under the hood, snapshot run under the hood, not async variable prototype run -events, and other APIs will capture a snapshot at some agreed upon time based on which a you’re -using, usually registration time. There are a couple exceptions that we use call time. They -will capture a snapshot at that time, and then when they invoke your handler, they will restore -that snapshot, called snapshot that run and invoke your handler so that the global async -context state is restored back to whatever that snapshot was. So it’s a different run method. -Which run method had the slowdown? Is it async variable run or is it async snapshot run? +JRL: The slide at the very bottom, here it says prototyping Chromium task attribution effort. Events in other web API use run under the hood, snapshot run under the hood, not async variable prototype run events, and other APIs will capture a snapshot at some agreed upon time based on which a you’re using, usually registration time. There are a couple exceptions that we use call time. They will capture a snapshot at that time, and then when they invoke your handler, they will restore that snapshot, called snapshot that run and invoke your handler so that the global async context state is restored back to whatever that snapshot was. So it’s a different run method. +Which run method had the slowdown? Is it async variable run or is it async snapshot run? -ABO: I have not measured the effects of the variable run. But I suspect snapshot to have -the exact same effective -- like, effective no for 01 behavior as that. +ABO: I have not measured the effects of the variable run. But I suspect snapshot to have the exact same effective -- like, effective no for 01 behavior as that. JRL: Perfect, that’s what I expect as well. @@ -230,6 +146,7 @@ ABO: However, task attribution, the work that is currently done in Chromium to p DE: Right. It’s all about making a new node in the attribution tree for event. So `AsyncContext.Snapshot.prototype.run` should still be almost free, but `AsyncContext.Variable.prototype.run` has some costs that will be optimized. DLM: We’ve started evaluating this in terms of implementability in SpiderMonkey, and unfortunately that’s not ready for this meeting, but I hope the next time this comes up, we can provide our feedback in more detail. + ### Summary * AsyncContext is an API enabling propagating variables across asynchronous control flows, almost like thread-local storage for JavaScript. It is useful for cases like tracking the current OpenTelemetry span ID, which would be impractical to pass around as a parameter everywhere. @@ -240,212 +157,113 @@ DLM: We’ve started evaluating this in terms of implementability in SpiderMonke * The V8 SetContinuationPreservedEmbedderData API can change, and its existence should not be taken to mean that there is zero performance overhead for the mechanism underlying AsyncContext (there is some constant memory usage). * The champion group continues to investigate the appropriate AsyncContext inheritance for running HTML events and other callbacks. * Firefox is going to evaluate the implementability of AsyncContext. + ### Conclusion AsyncContext remains at Stage 2; development will continue ## Get Intrinsics for stage 2, with two possible shapes/paths? -JHD: Okay, so for get intrinsics, the current status of the proposal is that it’s two functions -on reflect, since the last time we discussed this, we all agreed that reflect no longer needed -to be exclusively for things that matched proxy traps. So there’s Reflect.getIntrinsic -singular and Reflect.getIntrinsics plural. The plural returns a set of strings and the -singular takes a set of strings and gives you the respective intrinsic. The only open question -is should this list of intrinsics that is provided in the enumeration and perhaps also -- yeah, -provided in the enumeration be all intrinsics or just the hidden ones, the ones that you can -not discover from traversing global lists? That question is still not completely answered or -at least not -- I have nothing new to bring to the table at the moment. However, the shape of -the API will be the same regardless of the answer to that question and the spec text will be -largely the same, just slightly more complex to only describe the hidden intrinsics instead of -all of them. So to me, that doesn’t feel like a major semantic, so I’m here to ask for Stage -2, with one of the options, all intrinsics or hidden intrinsics, and all other things staying -the same. And obviously that question must be answered before Stage 3. - -JWK: If you’re only including hidden intrinsics, then what if we expose, for example, -iterator helper, expose iterator prototype? You cannot remove it, so it brings inconsistency in the future that some intrinsics exposed by this is not hidden? - -JHD: So that’s a good question. I think that the explicit contract of this would be that -something can only disappear from this list is it, thus -- like, in the same -- like, from -version A to version B of any given implementation, it can only disappear in the list if -version B also exposes it in such a way that it’s accessible from global lists, so I think it -that it would be okay to remove iterator in that case from the list, and then add it as the -global. Certainly there’s non-zero come pat risk for that, and actually a really helpful -argument for exposing all intrinsics, but I don’t think it would be fatal if we did the hidden -intrinsics. +JHD: Okay, so for get intrinsics, the current status of the proposal is that it’s two functions on reflect, since the last time we discussed this, we all agreed that reflect no longer needed to be exclusively for things that matched proxy traps. So there’s Reflect.getIntrinsic singular and Reflect.getIntrinsics plural. The plural returns a set of strings and the singular takes a set of strings and gives you the respective intrinsic. The only open question is should this list of intrinsics that is provided in the enumeration and perhaps also -- yeah, +provided in the enumeration be all intrinsics or just the hidden ones, the ones that you can not discover from traversing global lists? That question is still not completely answered or at least not -- I have nothing new to bring to the table at the moment. However, the shape of the API will be the same regardless of the answer to that question and the spec text will be largely the same, just slightly more complex to only describe the hidden intrinsics instead of all of them. So to me, that doesn’t feel like a major semantic, so I’m here to ask for Stage 2, with one of the options, all intrinsics or hidden intrinsics, and all other things staying the same. And obviously that question must be answered before Stage 3. + +JWK: If you’re only including hidden intrinsics, then what if we expose, for example, +iterator helper, expose iterator prototype? You cannot remove it, so it brings inconsistency in the future that some intrinsics exposed by this is not hidden? + +JHD: So that’s a good question. I think that the explicit contract of this would be that something can only disappear from this list is it, thus -- like, in the same -- like, from version A to version B of any given implementation, it can only disappear in the list if version B also exposes it in such a way that it’s accessible from global lists, so I think it that it would be okay to remove iterator in that case from the list, and then add it as the global. Certainly there’s non-zero come pat risk for that, and actually a really helpful argument for exposing all intrinsics, but I don’t think it would be fatal if we did the hidden intrinsics. JWK: But if you remove intrinsics, the old code will break. -JHD: In what way? You could still call the singular method and get it regardless. It’s just the -enumeration regard. That’s my understanding, at any rate. Is that it’s -- it would disappear from the iterator, but not stop being accessible from the singular -method. All intrinsics would still be accessible that way. But that’s my understanding. +JHD: In what way? You could still call the singular method and get it regardless. It’s just the enumeration regard. That’s my understanding, at any rate. Is that it’s -- it would disappear from the iterator, but not stop being accessible from the singular method. All intrinsics would still be accessible that way. But that’s my understanding. -SYG: Just clarifying, I didn’t understand the distinction. The distinction is there’s the -enumerator -- sorry, the iterator that enumerates all the hidden intrinsics or some set of -intrinsics. There’s also a different set of keys that remains stable for all intrinsics -that -- for the get method -- that the get method accepts? +SYG: Just clarifying, I didn’t understand the distinction. The distinction is there’s the enumerator -- sorry, the iterator that enumerates all the hidden intrinsics or some set of intrinsics. There’s also a different set of keys that remains stable for all intrinsics that -- for the get method -- that the get method accepts? JHD: Yeah, maybe that’s a point of misunderstanding here. SYG: That was not clear to me. -JHD: SYG, your concern before was about all versus hidden. Does that extend to the singular -method, then? +JHD: SYG, your concern before was about all versus hidden. Does that extend to the singular method, then? SYG: Yes. -JHD: In that case, this certainly isn’t ready for Stage 2, but it’s still worth getting people’s -thoughts back was the -- in that case, JWK’s question is actually very relevant, because you -would never be able to remove anything from the hidden list even if you then subsequently -exposed it. +JHD: In that case, this certainly isn’t ready for Stage 2, but it’s still worth getting people’s thoughts back was the -- in that case, JWK’s question is actually very relevant, because you would never be able to remove anything from the hidden list even if you then subsequently exposed it. -SYG: That’s right. Well, I mean, like you said, it’s non-zero compat risk. But the -- I think -the two worlds that make sense is as, speak narrowly towards implementation, although I -understand which is not a directly consumed API anyway, not speaking towards DX, we heavily -favour hidden intrinsics only, and that -- by hidden, I mean the set of string names that are -returned or accepted if all intrinsics are reachable via the getter function via string key, -that has the same issue with consumption and stuff that -- memory consumption that we had -before. It’s not just the enumeration. +SYG: That’s right. Well, I mean, like you said, it’s non-zero compat risk. But the -- I think the two worlds that make sense is as, speak narrowly towards implementation, although I understand which is not a directly consumed API anyway, not speaking towards DX, we heavily favour hidden intrinsics only, and that -- by hidden, I mean the set of string names that are returned or accepted if all intrinsics are reachable via the getter function via string key, +that has the same issue with consumption and stuff that -- memory consumption that we had before. It’s not just the enumeration. -JHD: So basically everything with the hidden half, everything that was hidden at the time this -proposal landed and everything that was added in the future hidden would forever be in the -list, even it later became unhidden? +JHD: So basically everything with the hidden half, everything that was hidden at the time this proposal landed and everything that was added in the future hidden would forever be in the list, even it later became unhidden? -SYG: The mental model would be that these that are not unreachable at this point in time, just -that here is a different way to reach some of them, and some of it was unreachable at some -point, and that’s why it’s in this list. +SYG: The mental model would be that these that are not unreachable at this point in time, just that here is a different way to reach some of them, and some of it was unreachable at some point, and that’s why it’s in this list. -JHD: Okay, I think that is definitely a different mental model that impacts, so, yeah, I’m no -longer asking for Stage 2, then, based on that understanding. +JHD: Okay, I think that is definitely a different mental model that impacts, so, yeah, I’m no longer asking for Stage 2, then, based on that understanding. SYG: But I want to make sure that we have an understanding of what V8’s memory usage concern is, is that if all intrinsics were accessible in some way, via programmatic API, then we would need to keep an extra, like, slot basically for every intrinsic, and for every context, there will be, like, a list of slots. That is something we would like to avoid if possible, because on memory constraint environments like cheap phones and watches or whatever, we would like the context to be as small as possible, so limiting the enumeration doesn’t necessarily solve that if everything is still otherwise accessible. JHD: That is understood. Thank you. -KG: So just to be clear, this would be the first time we would be reifying a distinction between -the things in the list or not? +KG: So just to be clear, this would be the first time we would be reifying a distinction between the things in the list or not? -JHD: There’s a distinction in the host hooks, so a distinction would only be present if it -decided not to expose any intrinsics. I think the expectation would be that a host would add -its own intrinsics to this host method. +JHD: There’s a distinction in the host hooks, so a distinction would only be present if it decided not to expose any intrinsics. I think the expectation would be that a host would add its own intrinsics to this host method. -KG: Given the ShadowRealms discussion, I would like to ensure that before Stage 3, that is -completely worked out. +KG: Given the ShadowRealms discussion, I would like to ensure that before Stage 3, that is completely worked out. JHD: Yeah, that’s a reasonable pre-Stage 3 requirement for this proposal. DE: I was a little confused when reviewing the proposal. First, the README explained that there shouldn’t be memory overhead from this feature, but I hadn’t seen any explanation to the concern that SYG previously raised. For this possibility of two possible paths, I didn’t see any sort of document for that that I could have reviewed beforehand. It would be easier to review a proposal, especially when it’s proposed for advancement, if you provide a slide deck, or gist, or some other written form which explains what it is you’re asking to be advanced. I was confused about what I should be reviewing. -JHD: Yeah, thanks, that’s good feedback. The spec texts plus the open issue, which is an -open question, which is why there’s nothing in the read-me addressing those concerns, because -it’s still an open question. But the -- you’re right that I didn’t write anything out anywhere -that conveys what I said in my intro to this item, so that’s good feedback from the future, +JHD: Yeah, thanks, that’s good feedback. The spec texts plus the open issue, which is an open question, which is why there’s nothing in the read-me addressing those concerns, because it’s still an open question. But the -- you’re right that I didn’t write anything out anywhere that conveys what I said in my intro to this item, so that’s good feedback from the future, thank you. DE: I’m a little unsure about some of the use cases. I think we might want to consider handling writing code with integrity at some higher level. As a use case, JHD cited polyfill libraries, but these cause startup costs to be imposed. I’m not really sure if that’s what we should be encouraging people to ship such polyfill code as a committee. -JHD: Okay. That’s sort of a more foundational thing, but it’s being shipped regardless, so it’s -a question of whether we want to make it, you know, more ergonomic and more reliable and -potentially faster, but it certainly wouldn’t be slower than what myself and a few others are -doing. I would have preferred to have that discussion the last time we discussed. But that’s -certainly something we can still discuss. +JHD: Okay. That’s sort of a more foundational thing, but it’s being shipped regardless, so it’s a question of whether we want to make it, you know, more ergonomic and more reliable and potentially faster, but it certainly wouldn’t be slower than what myself and a few others are doing. I would have preferred to have that discussion the last time we discussed. But that’s certainly something we can still discuss. DLM: I take it that you’re no longer asking for Stage 2, but I wanted to echo DE’s point. We had a very difficult time reviewing this proposal in our internal review meeting because, you know, it wasn’t clear exactly what the two shapes or paths would be. And the README itself was a little bit difficult for us to follow in terms of motivation and that kind of thing, so I’d encourage you next time you bring in to committee to prepare a little presentation with that kind of information. Not trying to complain, but we review many proposals prior to a TC39, so making that job easier for us would be appreciated. Thank you. JHD: Thank you for the feedback. + ### Summary of Key Points + * A new Reflect.getIntrinsic API is proposed which returns the original value of a built-in operation, before polyfilling. This proposal is motivated by enabling the authoring of high-integrity code. * To control the memory overhead, JHD presented an alternative, which includes *only* the APIs which are not reachable via properties from the global object. * This proposal is likely to have significant memory overhead for V8, making that team skeptical of it, possibly even with the “only hidden” mitigation. * The motivation of the proposal and the variants under consideration were not clear to some committee members before this presentation; documenting these better would help TC39 participants prepare. + ### Conclusion + * The proposal remains at Stage 1 ## iterator sequencing for Stage 1 -MF: Iterator sequencing. What we’re talking about when I say that is taking -two or more iterators and combining them into a single one. Additionally, I consider in scope -for this proposal interleaving values that are not iterators among the iterators. So as an -example of what you have to do today to accomplish sequencing of iterators, say we have two -iterators here, called lows and high, you can see they’re low digits and high digits, if we -want to create an iterator of all ten digits, we can use a generator and then -yield star the iterators you're sequencing, and yield is the feature for -interleaving additional values among them. So this is about the best you can do today, having -this immediately-invoked generator for composing iterators. I think this use case is deserving of something, you know, more ergonomic than this. - -MF: This is another strategy you can take. Probably a little bit less likely for your average -programmer to be writing. This composes the values you want together in sequence in an array and gets the array iterator out of that, and then `flatMap`s with the identity function. Not the -most elegant, but it also gets the job done. One possible way we can improve this is -introducing an `Iterator.of` and `Iterator.prototype.flat`. So `Iterator.of` is possibly a slightly -nicer way to get your original iterator of iterators than putting things in array and doing -`.values()` to get the array iterator out. Similarly, `.flat()` is a possibly somewhat nicer way to -flatten an iterator of iterators than `flatMap`-ing the identity function. For both of these, -on the array constructor, we’ve already made the decision that it is worth it to make those -improvements, because basically there’s analogues to both of them on Array. Another possible -solution here is making `Iterator.from` variatic, so `Iterator.from` has already been introduced -as part of iterator helpers and it only takes one iterable-or-iterator thing. If we allow it -to accept more than one, it can, you know, produce the elements of those iterators in sequence. - -MF: A third possible solution in this space is having an iterator prototype method that kind -of concats or appends iterators. We see this in some libraries and it would look like one -of these things either if we allow it only to accept one additional iterator, you can call -it multiple times and chain them together like in the top line. The line following that, you -can see if we allow concat to take multiple arguments, you can pass them in and not have to do -that chaining. Possible downsides of this approach, if you are not starting with an iterator -already, you have to make one. So, for instance, if the interleaved values are at the -beginning -- you know, if we had iterator.of, that might be an easy way to do that, but -we don’t really have that. Another thing is that concat as a name is problematic within JavaScript -because of the whole IsConcatSpreadable, and how iterator.prototype -- the microphone is -going out. - -MF: `Array.prototype.concat` takes, like, non-array things, so I think calling it concat would be possibly problematic, but there are other names -in use, like chain, that also might be problematic -- but append is possibly a workable name for such a thing. So this is also a solution, though not my favorite one. Now, analysis of prior art. On the left I have -usages of, like, similar concepts of sequencing iterators in other languages. On the right, I -have JavaScript libraries that work with iterators that allow you to sequence iterators. And -takeaways from this are that most of these cases, they allow you to sequence more than one -thing at a time. So just having an append that only supports one is probably an -anti-pattern. The ones that do have it, mostly all have also a version that takes an arbitrary -number of iterators. - -MF: But that’s about all I’ve learned from analyzing the prior art here. -That and some of the common naming stuff that I used to influence the prior slides. So what -are my thoughts on it? I think that it is worthwhile to try to solve this ergonomics issue. I -think Iterator.from being made variadic is probably the most elegant solution if we’re just considering iterator sequencing, but if we’re considering the larger context of all of this, like, how we might -expand things in the future, I think Iterator.of and Iterator.prototype.flat also have other -uses not related to iterator sequencing that, you know, make them pay for themselves anyway. -So this would be kind of like solving two problems at once if we went this -route, because of the side benefits. So those are probably both good -solutions in my opinion. I don’t oppose the prototype method for appending -but, it does have those design issues around it. So it’s probably my least favorite -of the solutions. - -MF: Anyway, that explains what I’m trying to accomplish here with iterator sequencing, and I’d like -to ask for Stage 1. - -GCL: Hello. Yeah. Hi, yeah, I’m a big fan. This is a thing that I use a lot, and I see used a -lot in other languages. So I think it will be -- it makes a lot of sense to bring into -JavaScript here. I definitely prefer the chain prototype method but, you know, don’t have to -figure that out for Stage 1, so, yeah, I’m -- yeah, very in favor of Stage 1. - -KG: Yeah, just for the naming, lots of things have concat and no one really gets confused about -whether concat spreadable should apply. Like, string concat and observable concat, etc. And -as far as I’m aware, this never causes problems. I’m not saying that we have to name it -concat, I’m saying that I don’t see a reason to rule out that name. - -MF: My reservation was less about the IsConcatSpreadable and non-iterators being spread. If -I pass a number it to, there are some people, maybe even in this room, who would expect like a -number passed to it to work as if it was passed to iterator.of first. +MF: Iterator sequencing. What we’re talking about when I say that is taking two or more iterators and combining them into a single one. Additionally, I consider in scope for this proposal interleaving values that are not iterators among the iterators. So as an example of what you have to do today to accomplish sequencing of iterators, say we have two iterators here, called lows and high, you can see they’re low digits and high digits, if we want to create an iterator of all ten digits, we can use a generator and then yield star the iterators you're sequencing, and yield is the feature for interleaving additional values among them. So this is about the best you can do today, having this immediately-invoked generator for composing iterators. I think this use case is deserving of something, you know, more ergonomic than this. + +MF: This is another strategy you can take. Probably a little bit less likely for your average programmer to be writing. This composes the values you want together in sequence in an array and gets the array iterator out of that, and then `flatMap`s with the identity function. Not the most elegant, but it also gets the job done. One possible way we can improve this is introducing an `Iterator.of` and `Iterator.prototype.flat`. So `Iterator.of` is possibly a slightly nicer way to get your original iterator of iterators than putting things in array and doing +`.values()` to get the array iterator out. Similarly, `.flat()` is a possibly somewhat nicer way to flatten an iterator of iterators than `flatMap`-ing the identity function. For both of these, +on the array constructor, we’ve already made the decision that it is worth it to make those improvements, because basically there’s analogues to both of them on Array. Another possible solution here is making `Iterator.from` variatic, so `Iterator.from` has already been introduced as part of iterator helpers and it only takes one iterable-or-iterator thing. If we allow it to accept more than one, it can, you know, produce the elements of those iterators in sequence. + +MF: A third possible solution in this space is having an iterator prototype method that kind of concats or appends iterators. We see this in some libraries and it would look like one of these things either if we allow it only to accept one additional iterator, you can call it multiple times and chain them together like in the top line. The line following that, you can see if we allow concat to take multiple arguments, you can pass them in and not have to do that chaining. Possible downsides of this approach, if you are not starting with an iterator already, you have to make one. So, for instance, if the interleaved values are at the beginning -- you know, if we had iterator.of, that might be an easy way to do that, but we don’t really have that. Another thing is that concat as a name is problematic within JavaScript because of the whole IsConcatSpreadable, and how iterator.prototype -- the microphone is going out. + +MF: `Array.prototype.concat` takes, like, non-array things, so I think calling it concat would be possibly problematic, but there are other names in use, like chain, that also might be problematic -- but append is possibly a workable name for such a thing. So this is also a solution, though not my favorite one. Now, analysis of prior art. On the left I have usages of, like, similar concepts of sequencing iterators in other languages. On the right, I have JavaScript libraries that work with iterators that allow you to sequence iterators. And takeaways from this are that most of these cases, they allow you to sequence more than one thing at a time. So just having an append that only supports one is probably an anti-pattern. The ones that do have it, mostly all have also a version that takes an arbitrary number of iterators. + +MF: But that’s about all I’ve learned from analyzing the prior art here. +That and some of the common naming stuff that I used to influence the prior slides. So what are my thoughts on it? I think that it is worthwhile to try to solve this ergonomics issue. I think Iterator.from being made variadic is probably the most elegant solution if we’re just considering iterator sequencing, but if we’re considering the larger context of all of this, like, how we might expand things in the future, I think Iterator.of and Iterator.prototype.flat also have other uses not related to iterator sequencing that, you know, make them pay for themselves anyway. +So this would be kind of like solving two problems at once if we went this route, because of the side benefits. So those are probably both good solutions in my opinion. I don’t oppose the prototype method for appending but, it does have those design issues around it. So it’s probably my least favorite of the solutions. + +MF: Anyway, that explains what I’m trying to accomplish here with iterator sequencing, and I’d like to ask for Stage 1. + +GCL: Hello. Yeah. Hi, yeah, I’m a big fan. This is a thing that I use a lot, and I see used a lot in other languages. So I think it will be -- it makes a lot of sense to bring into JavaScript here. I definitely prefer the chain prototype method but, you know, don’t have to figure that out for Stage 1, so, yeah, I’m -- yeah, very in favor of Stage 1. + +KG: Yeah, just for the naming, lots of things have concat and no one really gets confused about whether concat spreadable should apply. Like, string concat and observable concat, etc. And as far as I’m aware, this never causes problems. I’m not saying that we have to name it concat, I’m saying that I don’t see a reason to rule out that name. + +MF: My reservation was less about the IsConcatSpreadable and non-iterators being spread. If I pass a number it to, there are some people, maybe even in this room, who would expect like a number passed to it to work as if it was passed to iterator.of first. KG: As long as that throws, I’m not super worried. MF: I don’t know if we can get agreement on that throwing, so that’s why I -- yeah. -JHD: Yeah, I’m definitely one of those people. Certainly if the doesn’t accept it, it should -throw, but I very much think it should accept it. And I think that it would be kind of -pedantry that would make it solely to use if we just force to the wrap in an array, for -example. I really do hope that we can find something that takes both. +JHD: Yeah, I’m definitely one of those people. Certainly if the doesn’t accept it, it should throw, but I very much think it should accept it. And I think that it would be kind of pedantry that would make it solely to use if we just force to the wrap in an array, for example. I really do hope that we can find something that takes both. -KG: I think if you would like to argue for that, it would help if you could demonstrate a single -example of another method with that shape in any other language or library. +KG: I think if you would like to argue for that, it would help if you could demonstrate a single example of another method with that shape in any other language or library. JHD: Besides array concat? @@ -459,75 +277,37 @@ JHD: Something that is meant to join two things together. KG: Yes, join two lists together. -RBN: Yeah, actually, this is a bit of a comment in response to what JHD had -just said, that, A, I do agree if we don’t accept, it should throw, and B, I believe we -shouldn’t accept things that aren’t iterable purely because accepting things that aren’t it -iterable can be confusing when you start looking at string, because some folks might expect -string to be included in the list, especially if they’re concatting and a iterable or iterator -that produces strings and they add a string, and the next item, they might expect that to -produce a string, whereas someone else might be producing an iterable that produces individual -code points and then put -- or characters and then produces the string and expect that to -concat that way. And it’s less about we don’t -- that iterable or the iterator helpers are -specific to object iterables, but that this becomes the odd case out where we might allow a -non-object iterable thing and then have confusion as to what that is supposed to mean. I think -it’s just a bad expectation. - -JHD: Yeah, I mean, I think that just pretending that strings aren’t iterable by only allowing -object iterables is -- as iterator helpers is done is the best because the odd thing out is -strippings are iterable and they never should have been, but we’re here, so new APIs should -just not treat primitives as iterable. +RBN: Yeah, actually, this is a bit of a comment in response to what JHD had just said, that, A, I do agree if we don’t accept, it should throw, and B, I believe we shouldn’t accept things that aren’t iterable purely because accepting things that aren’t it iterable can be confusing when you start looking at string, because some folks might expect string to be included in the list, especially if they’re concatting and a iterable or iterator that produces strings and they add a string, and the next item, they might expect that to produce a string, whereas someone else might be producing an iterable that produces individual code points and then put -- or characters and then produces the string and expect that to concat that way. And it’s less about we don’t -- that iterable or the iterator helpers are specific to object iterables, but that this becomes the odd case out where we might allow a non-object iterable thing and then have confusion as to what that is supposed to mean. I think it’s just a bad expectation. + +JHD: Yeah, I mean, I think that just pretending that strings aren’t iterable by only allowing object iterables is -- as iterator helpers is done is the best because the odd thing out is strippings are iterable and they never should have been, but we’re here, so new APIs should just not treat primitives as iterable. CDA: The next on the queue is EAO. -EAO: Could you go back in the presentation to I think about the third slide, about showing a -state-of-the-art for this. My issue with this proposal is I don’t understand why this is not -good enough. Why are we considering the ergonomics of this for this solution to be so bad that -we need to do something about this? Could you speak a little bit to that. +EAO: Could you go back in the presentation to I think about the third slide, about showing a state-of-the-art for this. My issue with this proposal is I don’t understand why this is not good enough. Why are we considering the ergonomics of this for this solution to be so bad that we need to do something about this? Could you speak a little bit to that. -MF: Yes, the iterator sequencing is a very common need. I also think that this particular shape -of solution is not something that your average programmer will reach for immediately. They -might arrive at this after a lot of experience. But the thing that they -will write will probably look more like this, what we saw earlier, which is far less ergonomic, -far less readable. Also, once you have, like, methods for doing this, they’re a first-class -value, you can pass them around, you know, unlike this construction here, which you’d -have to make a function out of. So my argument is mostly on frequency of use of this kind of -thing should be -- even if it’s only a little bit unergonomic, it still justifies it. +MF: Yes, the iterator sequencing is a very common need. I also think that this particular shape of solution is not something that your average programmer will reach for immediately. They might arrive at this after a lot of experience. But the thing that they will write will probably look more like this, what we saw earlier, which is far less ergonomic, +far less readable. Also, once you have, like, methods for doing this, they’re a first-class value, you can pass them around, you know, unlike this construction here, which you’d have to make a function out of. So my argument is mostly on frequency of use of this kind of thing should be -- even if it’s only a little bit unergonomic, it still justifies it. -KG: Just to second what MF said, I -- I really don’t think anyone who is not a functional -programmer is going to reach for this. Like, I would love to move to a world in which everyone -thinks this is intuitive, but it’s not happening. +KG: Just to second what MF said, I -- I really don’t think anyone who is not a functional programmer is going to reach for this. Like, I would love to move to a world in which everyone thinks this is intuitive, but it’s not happening. -EAO: So the problem with the current approach, is it that the create an array and then call dot -values on it, that that’s complicated or that the flatmap part of it is complicated or that -overall the issue is complicated? +EAO: So the problem with the current approach, is it that the create an array and then call dot values on it, that that’s complicated or that the flatmap part of it is complicated or that overall the issue is complicated? KG: My opinion is I don’t think anyone is going to reach for flatMap to do concatenation. DE: I agree this is unintuitive. I could understand the code but it wouldn’t’ve occurred to me so quickly. I think what we’re competing with isn’t even this thing with yield star, which was more verbose, but people just converting the iterators into arrays. Oftentimes iterators are not being used as a correctness thing because it’s incorrect to iterate through, but as a performance thing because you’re trying to pipeline the calculation. So anyway, this feature seems worth it to add to the standard library. -WH: I concur with everybody else who said that this is a non-intuitive pattern. I would add the -additional point that, in this pattern, there’s nothing to search for that indicates -that you’re concatenating iterators. You’re getting `values` and `flatMap`, which don’t seem -to have much to do with iterators. +WH: I concur with everybody else who said that this is a non-intuitive pattern. I would add the additional point that, in this pattern, there’s nothing to search for that indicates that you’re concatenating iterators. You’re getting `values` and `flatMap`, which don’t seem to have much to do with iterators. -KG: All right, I guess I’m next on the queue. So of the option you mentioned, I want to speak -against using iterator.from. Specifically because using iterator.from means if you have a -collection of iterators, you have to splat them all onto the stack, which means that if you -have an iterator of iterators, it just does nothing for you. I would like a solution ideally -that works if you have an iterator of iterators and does not require you to potentially unboundedly -many things onto the stack. There’s just no reason to require a full traversal of your whole -list. +KG: All right, I guess I’m next on the queue. So of the option you mentioned, I want to speak against using iterator.from. Specifically because using iterator.from means if you have a collection of iterators, you have to splat them all onto the stack, which means that if you have an iterator of iterators, it just does nothing for you. I would like a solution ideally that works if you have an iterator of iterators and does not require you to potentially unboundedly many things onto the stack. There’s just no reason to require a full traversal of your whole list. -WH: I’d like to understand the preference for `Iterator.of`, and what exactly does +WH: I’d like to understand the preference for `Iterator.of`, and what exactly does `Iterator.of` do? MF: If you see the first bullet point there, those would be equivalent. WH: Okay, but I still don’t understand what `Iterator.of` is supposed to do. -MF: So let’s say I have two numbers, 5 and 6 and I pass them to iterator.of. That would be the -same as creating an array of 5 and 6 and then getting the array iterator out of that. So it -would produce an iterator that yields 5 and then yields 6 and then is done. +MF: So let’s say I have two numbers, 5 and 6 and I pass them to iterator.of. That would be the same as creating an array of 5 and 6 and then getting the array iterator out of that. So it would produce an iterator that yields 5 and then yields 6 and then is done. WH: And if one of those numbers were an iterator instead, what would it do? @@ -536,84 +316,77 @@ MF: Yield an iterator. This is not promises. MF: Given the feedback, it sounds like it’s possible that we could ask for Stage 1. I would like to ask for Stage 1. +1 from WH, KG, DE, GCL, CHU; no objections + ### Summary of Key Points + * Iterator sequencing refers to the “concatenation” of multiple iterators * Iterator sequencing is common and should be convenient and ergonomic * A survey of iterator sequencing possibilities shows a few patterns around naming and semantics in prior art which we can choose between + ### Conclusion + * Iterator sequencing reached stage 1 + ## Structs and shared structs update SYG: This is the second update about the shared structs and the structs proposal, but focusing on the shared part. That’s where a lot of the interesting design decisions in implementation work is being done. A lot will be – not a lot, the first little bit will be reiterating what the update was. The mission here is to raise the performance ceiling of advanced web apps by giving access and task primitives. Advanced is the key word for apps. Recognize that this is going to require some care to use and to leverage. But where it is needed there’s not really a substitute is my take. The reason it’s needed, there’s not a substitute is that currently, boundary costs kill your performance. There are multiple boundaries in the web app world. The biggest one for scaling your application to multiple workers is that there are post-message boundaries because the only way to communicate is by posting messages. And currently that goes through in a – in the HTML host that goes through the serialize – the API is called structured clone. Which means you have to copy, including all the primitives. Like strings and that kind of copy really kills your performance because it now necessarily means that the amount of work that you need to do scales with the number of threads. If you want to make your application faster, hopefully I do less – you can do work in power level. The work you do increases with the number of threads; that is not a good thing. -So why didn’t SharedArrayBuffer solve the issue? The problem is, that moves the boundary somewhere else. SharedArrayBuffers are low level byte buffers. If you have high level data that you would like to coordinate between your threads, as you probably do because this is a JS application, if you have something in C++, that you are compiling to Wasm, sure. You have basically bytes and you can share them. If that is not what you are working in, that means you have to choose your object layout and how to serialize data in a byte buffer, and copy them in and out. Into a usable state and that also is a boundary cost that will kill you. We are to scale our advanced web apps. Things on the order of, like, Google Sheets, but also things like, you know, advanced video conferencing, applications on the web. +So why didn’t SharedArrayBuffer solve the issue? The problem is, that moves the boundary somewhere else. SharedArrayBuffers are low level byte buffers. If you have high level data that you would like to coordinate between your threads, as you probably do because this is a JS application, if you have something in C++, that you are compiling to Wasm, sure. You have basically bytes and you can share them. If that is not what you are working in, that means you have to choose your object layout and how to serialize data in a byte buffer, and copy them in and out. Into a usable state and that also is a boundary cost that will kill you. We are to scale our advanced web apps. Things on the order of, like, Google Sheets, but also things like, you know, advanced video conferencing, applications on the web. All right. So on to the new stuff. Where we left off last time was, I gave an experienced report by engine to support sharing object zeros, which sounds scary. Hopefully that was proof it is possible to do without requiring derearchitecture. What I want to focus on this time is some feedback from early partners, feedback of people playing with the Dev trial, namely, that the top feedback we have gotten is that the thing that is shared in shared structs is data. What is not shared is behaviour. So functions, code that is not shared because as I will show later in the slides, JS functions are deeply not sharable. So this update talks about what we can do to recover the ability to attach behaviour, which turns out to be very important for DX to incrementally adopt shared structs. Okay. So I will go through what the problem is with sharing – trying to share functions and why they can’t be shared and present the current best solution that we have, which is a combination of using thread locale prototype and how we correlate different types across workers. And then also lay out the next steps. The number of JS functions are deeply not sharable. And comes down to, they are JS functions mutable first class values with identity. This is a JS thing. Most languages do not unless you pass around functions and add properties to them. Which is kind of weird. JS functions are always closures, even when you don’t close over program user bindings. When I brought this up years ago, there is a path here to make a new kind of exotic callable function that is somehow truly sharable. Maybe not closure, but restricted. Pure for some definition of pure we can argue about. The decision is to punt on that, which is a much bigger problem, in my opinion. -I think we can punt on making truly shared functions later. And then the solution here, I think does stop you haves of thinking about new functions -To go through the issues, the functions are to first, class in JS. So ignore the actual code part of functions. Look at functions code container. Functions are objects. Mutable objects and mutable objects with identity. We can’t share them because they are mutable. Unsafe. We add properties that make everything too slow, including singling threaded code. +I think we can punt on making truly shared functions later. And then the solution here, I think does stop you haves of thinking about new functions To go through the issues, the functions are to first, class in JS. So ignore the actual code part of functions. Look at functions code container. Functions are objects. Mutable objects and mutable objects with identity. We can’t share them because they are mutable. Unsafe. We add properties that make everything too slow, including singling threaded code. They have a prototype chain that is [db] goes to a prototype realms, deeply already single threaded. Today, if you load the same modular script multiple times, where you evaluate some function that returns another function or returns a class, a constructor or something, you get different copies of the same code. You get different function container objects, they might point to the same code underneath. First class right now. You can hold them. You can mutate them. This is much unlike say, code in C++ or java or something. For functions qua code, they are always closures and tied to the creation realm. You can always ask a function object where you were created. And this has implications for determining stuff in HTML, for example. -So they are deeply closed over some single threaded state. We can’t share those things -The upshot here is the functions as we have them today are unshareable. I don’t want to introduce an entirely new thing on how to make them sharable. Because I think that is a bigger problem and we can punt on that. And first I want to share data. Before I tackled the bigger problem, how to share code. -So how do we think of solving of problem of attaching behaviour to shared structs when you can’t share functions? The current best idea is to let each do their own thing with thread local prototype. What is the idea here? -Currently, we attach behaviour to objects to ordinary observes and the problem is JS functions are not sharable things we cannot assign them into shared structs. What if we make the prototypes for shareholder structs thread local? Such that each thread had its own copy of a prototype object, much like if you worked in a system with multiple threaded shared memory before, there is a thread local storage. +So they are deeply closed over some single threaded state. We can’t share those things The upshot here is the functions as we have them today are unshareable. I don’t want to introduce an entirely new thing on how to make them sharable. Because I think that is a bigger problem and we can punt on that. And first I want to share data. Before I tackled the bigger problem, how to share code. +So how do we think of solving of problem of attaching behaviour to shared structs when you can’t share functions? The current best idea is to let each do their own thing with thread local prototype. What is the idea here? +Currently, we attach behaviour to objects to ordinary observes and the problem is JS functions are not sharable things we cannot assign them into shared structs. What if we make the prototypes for shareholder structs thread local? Such that each thread had its own copy of a prototype object, much like if you worked in a system with multiple threaded shared memory before, there is a thread local storage. So because these are thread local, they are not actually shared things. So they do not have the restrictions that shared things must have. These can be ordinary objects, reference anything in the thread. So each thread can set up their own prototype for types and if you squint, this is basically how primitive prototypes work today. If you call a method on a string, you manifest this string prototype in your current realm. This exists in the language. You have the same string because they don’t have an identifier as a primitive. Yet, if you call methods on it, it gets this magical context dependent wrapper, depending where you called it. So I am using the word thread here for ease of discussion. It is an open question whether the right granularity for JavaScript is an agent, or if it’s a realm. Which is a subthread thing. The snippet showing it. The syntax is definitely – it’s workshopped with RBN. I haven’t thought too much about it. If you have opinions, hold them. The idea here is that when you declare a shared struct, you have some way to mark it and say my prototype is in fact, not shared. My prototype is a thread local here. And then you can set it to be ordinary objects. In a snippet, I create a SharedPoint and then I attach – assign an ordinary object to its prototype. -That ordinary object is only visible on P in – whatever granularity we choose. Agent-local, only visible in the realm where you set it. Realm local, only in the realm that you’re currently executing in -Such that, when we – sorry. Go back here. Such that when we share this SharedPoint with another worker thread, I can reset it and then call it, but I cannot just call it because it’s thread local, this thread doesn’t have a prototype object for P yet. It can’t find it. It can set up its own. But until then, from the point of view of the other thread, it doesn’t have a prototype yet. The worker has no effect on the thread local field in main because it’s thread local. +That ordinary object is only visible on P in – whatever granularity we choose. Agent-local, only visible in the realm where you set it. Realm local, only in the realm that you’re currently executing in Such that, when we – sorry. Go back here. Such that when we share this SharedPoint with another worker thread, I can reset it and then call it, but I cannot just call it because it’s thread local, this thread doesn’t have a prototype object for P yet. It can’t find it. It can set up its own. But until then, from the point of view of the other thread, it doesn’t have a prototype yet. The worker has no effect on the thread local field in main because it’s thread local. Hopefully that is all clear. -What is the challenge for this? We can – incidentally do a side bar for the implementers in the room. Thread local is not just straightforward to implement. I want to give you a sidebar on how it’s done. What does it look like under the hood? +What is the challenge for this? We can – incidentally do a side bar for the implementers in the room. Thread local is not just straightforward to implement. I want to give you a sidebar on how it’s done. What does it look like under the hood? Last time I proposed that this, the design must be implementable incrementally. I don’t want to require engines rewrite. They have different heaps per workers basically. Because what JavaScript is, single threaded. Why would you intermingle stuff? This has a property that different workers heaps are independently collected. Because they are separate things. So how would you implement the TLS incrementally in such implementations? Going back to the example, I have that SharedPoint thing with XY and a nonshared prototype thread local. -What happens under the hood? Is that the prototype slot instead gets a TLS key, the thread local key, I don’t have the value in the instance. You have to look up in a side, I believe. X and Y are instance shared data properties. And this key is matched to some tables in each thread or realm, wherever it might be that matches – that has a value. That is thread local. The representation looks like this under the hood -Yes. Okay. This is what I basically said -The lifetime of these things is that, if you notice that . . . the TLS key, as long – intuitively, as long as the TLS key is alive, this is alive. It might be able to reference in some thread, its thread local value. +What happens under the hood? Is that the prototype slot instead gets a TLS key, the thread local key, I don’t have the value in the instance. You have to look up in a side, I believe. X and Y are instance shared data properties. And this key is matched to some tables in each thread or realm, wherever it might be that matches – that has a value. That is thread local. The representation looks like this under the hood Yes. Okay. This is what I basically said The lifetime of these things is that, if you notice that . . . the TLS key, as long – intuitively, as long as the TLS key is alive, this is alive. It might be able to reference in some thread, its thread local value. So this entry in the side table is a ephemerons, and they are enters in weak maps. It means you have a pair of things where the life – the liveness of the key, the first thing in the pair, I am employs the liveness of the value, the second thing in the pair. The key is weakly held, but if it’s found out to be live, it implies that its value is also live. So these are – the thread local tables are in fact exactly just JS WeakMaps. -The challenge this presents is, well, how do we collect them? +The challenge this presents is, well, how do we collect them? Ephemeron collection is hard to implement. -What are the required iterator to a fixed point? Because of this implication property. Suppose in the beginning, that is my WeakMap. I have A mapping to B. B mapping to C. And C mapping to D. +What are the required iterator to a fixed point? Because of this implication property. Suppose in the beginning, that is my WeakMap. I have A mapping to B. B mapping to C. And C mapping to D. So some values are also keys. -In the beginning, we don’t know the full live object closure of a heap. We have to keep iterating every time we mark an ephemeron entry. A, live. Which means B is live. Now, because B is live, B is in the same WeakMap. Now C is also live. It turns out the whole thing is live. Once you finish to fixed point of -This kind of fixed point is easy enough to do in a single heap. But the problem is, if you have WeakMaps that span multiple heaps, how do you do this fixed point? +In the beginning, we don’t know the full live object closure of a heap. We have to keep iterating every time we mark an ephemeron entry. A, live. Which means B is live. Now, because B is live, B is in the same WeakMap. Now C is also live. It turns out the whole thing is live. Once you finish to fixed point of This kind of fixed point is easy enough to do in a single heap. But the problem is, if you have WeakMaps that span multiple heaps, how do you do this fixed point? At first, I thought you could do this in some special phased way. Where you collect each heap independently, but publish some kind of coordinated weak list of things that we collect. But I think in the interest of time, you can reach out independently. I can explain the issue, if you’re an interested implementer. The upshot here, I don’t think it’s possible to independently collect heaps and collect cycles if there are cycles that involve ephemerons cross-heap. So yeah. I will skip this. This is too into the weeds for folks not implementers. The upshot, it’s hard to collect cycles with weakness across heaps. However, it’s – you can work around this easily enough by having a special marking phase that has visibility into all heaps. You can still retain the nice property that each heap is independently collected, so long as you never try to collect other heaps’ memory. You don’t try to unmap them or sweep them. You have a shared GC that is able to mark across all heaps, then you are able to collect these ephemeron cycles across the heaps. -So all of this is to say that, I thought it was a hard problem, but there is a way to work around it and it’s not bad and implementable and the lifetime’s work as you expect. For details, reach out to me and I can share some docs. It might be interesting. +So all of this is to say that, I thought it was a hard problem, but there is a way to work around it and it’s not bad and implementable and the lifetime’s work as you expect. For details, reach out to me and I can share some docs. It might be interesting. Okay. So going back to the semantics of things. In the beginning, it is an open question whether these prototype are out to be agent-local or realm local. If it is agent-local, then we don’t need to reset up prototypes per realm. The values don’t differ. If you are arc cease being objects, you are not – don’t want to per realm view of a shared struct. So you might reuse the same object, even inside ShadowRealm. The conhere is that would need special censorship. If we don’t have realm grand later, remember that ShadowRealm have the callable boundaries, a hard constraint where we don’t commingle object graphs from different realms. -But if you have this per thread, per agent key, on a shared struct, if you access it from it is a ShadowRealm, you might get a different realm and that’s annoying -That problem goes away if you choose the granularity to be realm local, which has the nice – how primitive prototypes work today. You might have to reset up the [dled] local prototype – the realm prototype per realm which might be annoying. This an open question that is not yet decided -I am going to move on to the next bit here, which is certain local prototype itself, it turns out, is not good enough to really solve the DX problem of not being able to attach behaviour -There’s also something that we have been calling the correlation problem. +But if you have this per thread, per agent key, on a shared struct, if you access it from it is a ShadowRealm, you might get a different realm and that’s annoying That problem goes away if you choose the granularity to be realm local, which has the nice – how primitive prototypes work today. You might have to reset up the [dled] local prototype – the realm prototype per realm which might be annoying. This an open question that is not yet decided I am going to move on to the next bit here, which is certain local prototype itself, it turns out, is not good enough to really solve the DX problem of not being able to attach behaviour There’s also something that we have been calling the correlation problem. So I will explain what the correlation problem is. Which goes back to functions being to first class. Suppose I have a struct.JS that contains my struct definition. -It has a SharedPoint. I have highlighted relevant details. It has a thread local prototype. This struct that JS sets it up. I evaluate structs.JS in worker A and worker B. +It has a SharedPoint. I have highlighted relevant details. It has a thread local prototype. This struct that JS sets it up. I evaluate structs.JS in worker A and worker B. I try to share them. And then worker B calls foo and it doesn’t work. Because I evaluated the SharedPoint declaration twice. Just like class declarations today, when you evaluate it, you get a new instance, a if you function. So the programming – the JS and the VM doesn’t know that worker A’s evaluation of Sharepoint should be correlated with worker’s B evaluation of shared point. So this is kind of annoying. Basically, you have to correlate them somehow so things work as you expect. -If you don’t correlate them, you would have to set up thread local prototypes for every copy – you end up have N copies of the same type in workers. And you have to correlate them all or you have to ensure that as you use them. Conceptually, you are using a shared thing. If you don’t correlate them, you have to set up different copies of the shared local prototype and that’s really anyway annoying -I evaluated it twice. There’s two SharedPoint shapes with two different TLS keys. +If you don’t correlate them, you would have to set up thread local prototypes for every copy – you end up have N copies of the same type in workers. And you have to correlate them all or you have to ensure that as you use them. Conceptually, you are using a shared thing. If you don’t correlate them, you have to set up different copies of the shared local prototype and that’s really anyway annoying I evaluated it twice. There’s two SharedPoint shapes with two different TLS keys. I only set up one TLS key in the other in worker B. There’s no way to know they are the same. Because this is just somehow naturally the language works. This is, I think, analogous to names, a private names multiple times, you have different copies of the private names, such that they’re not like automatic friends with each other. You can’t get a private name via another method that uses the private name. You have to get the name evaluation. So this is the correlation problem. We want to correlate shared struct types. I think ideally correlation means we shared the TLS key for prototype. VM can deduplicate shapes. This is monomeric. As you scale to the number of threads, you scale the number of types to the number of threads and everything is megamorphic. The types are already correlated. I think it’s surprising that if you – the private name thing, it’s surprising. -So the design constraints for when chatting with Mathieu and Ron but this, we have for solverring this correlation problem, however we choose to correlate is not a new global correlation channel. Better DX than about manually correlating them and there’s a performance constraint that you don’t want your inline caches to be megamorphic -We have a global register industry like so -The idea is you have some way to say that this shared struct declaration is registered. It’s auto correlated. Marked as registered, then when you import the thing from multiple threads and share an instance, somehow things would just work. -So what does that mean? +So the design constraints for when chatting with Mathieu and Ron but this, we have for solverring this correlation problem, however we choose to correlate is not a new global correlation channel. Better DX than about manually correlating them and there’s a performance constraint that you don’t want your inline caches to be megamorphic We have a global register industry like so The idea is you have some way to say that this shared struct declaration is registered. It’s auto correlated. Marked as registered, then when you import the thing from multiple threads and share an instance, somehow things would just work. +So what does that mean? If it’s registered, there would be a single shape under the hood. And that single – there’s one key and when you evaluate the declaration and multiple threads, because it’s deduplicated under the hood, you use the same TLS key and things work as you expect. The semantics that we are currently thinking of is there is an agent cluster wide registry. Across every thread. The key is the source location. It’s not the name. It’s not something that is forgeable by scripts and programs. It is literally the source location of where the declaration occurs. @@ -623,200 +396,199 @@ So on registry hit, with the same source location, there needs to be a check tha If it matches, we deduplicate it in the registry. In the example, the shape exactly matches. And it’s deduplicated to have a single key. Otherwise, if there is a mismatch, I think there’s an open question on what to do. Either you can silently do nothing. Meaning that you just do not get – get a new shape or you can throw. -And the open question is important for the communication channel. So is this a communication channel? +And the open question is important for the communication channel. So is this a communication channel? My current thinking; in practice, no. Because the source location is unforgeable. That’s the key. If registry hits do nothing on layout mismatch, as unobservable as well. -If we care about the DX and wanted to throw, even if that were the semantics, to attack that it seems like you would need to trigger reevaluation of scripts with different mutated script content. I am not sure like if that is your attack model, you can directly exploit things and leak things by this registry as a communication channel -So this doesn’t seem like a communication channel in practice, but we are iterating on the design here. Ron raised the issue that this basically means that the source location is meaningful for registered shared struct declarations. Which means it bundlers cannot just duplicate them in a semantics preserving way. A different bundle for A and B, the register shared structs cannot be duplicated across different bundles because the source location is what we used to duplicate. -So free shaking bunnedders would be aware. That is not a deal breaker to give guidance to give bundler here. I am sure how to duplicate things, but to have these special declarations to be nonduplicatible to me. That’s the current idea of how to share – attach behaviour without sharing methods. To have [dled] local prototype that then are somehow correlated to be the same shape under the hood across different workers so that things work as you might intuitive expect -The next steps here are, we will try to implement this idea, or I will do, this and have continued exploration with partners to see how usable it is currently. Type description, to Ron Buckton, played with the Dev trials early days. The multiple threaded parsing is slower. So that’s not good. So maybe there will be – Figure something out why it’s slowing and iterate on the design to actually get the scaling that we like to see. Babylon.js will use this to get down to the post-message boundary cost. -If you have opinions on the methods sharing thing, we have laid out here, please engage on the matrix channel. There’s lively discussion there. And the current road map is trying to prototype something in Q4 see how well it works. We want to ask for Stage 2 this year. With the data sharing and witness this is iterated this gives a complete picture of what the MVP for sharing data in adaptable way in JavaScript and plan to ask for Stage 2 with actually spelled out semantics not just these pictures at the end of the year. If you have interested in the space, join the matrix channel. And there’s also a regular working call on the TC39 calendar that you can join if interested. Thanks Ron and Mathieu. +If we care about the DX and wanted to throw, even if that were the semantics, to attack that it seems like you would need to trigger reevaluation of scripts with different mutated script content. I am not sure like if that is your attack model, you can directly exploit things and leak things by this registry as a communication channel So this doesn’t seem like a communication channel in practice, but we are iterating on the design here. Ron raised the issue that this basically means that the source location is meaningful for registered shared struct declarations. Which means it bundlers cannot just duplicate them in a semantics preserving way. A different bundle for A and B, the register shared structs cannot be duplicated across different bundles because the source location is what we used to duplicate. +So free shaking bunnedders would be aware. That is not a deal breaker to give guidance to give bundler here. I am sure how to duplicate things, but to have these special declarations to be nonduplicatible to me. That’s the current idea of how to share – attach behaviour without sharing methods. To have [dled] local prototype that then are somehow correlated to be the same shape under the hood across different workers so that things work as you might intuitive expect The next steps here are, we will try to implement this idea, or I will do, this and have continued exploration with partners to see how usable it is currently. Type description, to Ron Buckton, played with the Dev trials early days. The multiple threaded parsing is slower. So that’s not good. So maybe there will be – Figure something out why it’s slowing and iterate on the design to actually get the scaling that we like to see. Babylon.js will use this to get down to the post-message boundary cost. +If you have opinions on the methods sharing thing, we have laid out here, please engage on the matrix channel. There’s lively discussion there. And the current road map is trying to prototype something in Q4 see how well it works. We want to ask for Stage 2 this year. With the data sharing and witness this is iterated this gives a complete picture of what the MVP for sharing data in adaptable way in JavaScript and plan to ask for Stage 2 with actually spelled out semantics not just these pictures at the end of the year. If you have interested in the space, join the matrix channel. And there’s also a regular working call on the TC39 calendar that you can join if interested. Thanks Ron and Mathieu. -WH: The examples you gave contain `with nonshared prototype`. What happens if you don’t include that phrase? +WH: The examples you gave contain `with nonshared prototype`. What happens if you don’t include that phrase? SYG: That’s a good question. I did not include that in the slides. Apologies. In the Dev trials, all have a null prototype. It is – I think there’s 3 possibilities. You can have a thread local prototype. A null prototype. Or a shared struct prototype. -The prototype, if it’s not thread local, it cannot point to a thread local thing, that’s unsafe. Only point to shared things. So it would have to point to another shared struct. But normally, I would expect it would be either null or thread local. It’s just either a data thing or the behaviour has to be local. +The prototype, if it’s not thread local, it cannot point to a thread local thing, that’s unsafe. Only point to shared things. So it would have to point to another shared struct. But normally, I would expect it would be either null or thread local. It’s just either a data thing or the behaviour has to be local. WH: If you have a shared struct prototype, that can’t have methods. I am not clear what the use case would be. -SYG: There’s not too much use case. We might disallow that. I don’t have any concrete use cases for allowing that. +SYG: There’s not too much use case. We might disallow that. I don’t have any concrete use cases for allowing that. -JWK: Can you explain again what is the registered part? What problem does this solve? +JWK: Can you explain again what is the registered part? What problem does this solve? SYG: The problem is this: you have the beginnings of the shared – the declaration of the SharedPoint shared struct. -I have two workers. Importing the same file from two different workers. Without some kind of magical duplication, what happens under the hood is this: there are two evaluations that create two different shapes. Even if the prototype were thread local, that’s keyed by a TLK key, you get two different keys. So worker A has one evaluation. Set up its thread local type for its evaluation. Worker B has a different evaluation. Setting up for its evaluation. Conceptually, they are supposed to be the same. Worker A wants to use instances of its SharedPoint, interchangeably with instances, the workers B SharedPoint. They are supposed to be shared things. Does that make sense? +I have two workers. Importing the same file from two different workers. Without some kind of magical duplication, what happens under the hood is this: there are two evaluations that create two different shapes. Even if the prototype were thread local, that’s keyed by a TLK key, you get two different keys. So worker A has one evaluation. Set up its thread local type for its evaluation. Worker B has a different evaluation. Setting up for its evaluation. Conceptually, they are supposed to be the same. Worker A wants to use instances of its SharedPoint, interchangeably with instances, the workers B SharedPoint. They are supposed to be shared things. Does that make sense? JWK: But if it is not deduplicated, when SharedPoints sent to another worker, another worker can still assess properties right? -SYG: Can access data properties on it. In this case, I left out non relevant details. Suppose it has X and Y. They can access that. What can't be is the thread local prototype because it wasn’t set up. The data is accessible, some methods are unavailable and that’s a DX problem. We are trying to solve a DX problem. +SYG: Can access data properties on it. In this case, I left out non relevant details. Suppose it has X and Y. They can access that. What can't be is the thread local prototype because it wasn’t set up. The data is accessible, some methods are unavailable and that’s a DX problem. We are trying to solve a DX problem. JWK: For example, in the slides, 31, you said the prototype of the SharePoint, but the prototype is a plain object. How can you share that? -SYG: The key is deduplicated. The same key is shared so that in the TLS table for each individual worker, you can use the same key to get a TLS local object. +SYG: The key is deduplicated. The same key is shared so that in the TLS table for each individual worker, you can use the same key to get a TLS local object. -JWK: Still confused, but I think I can leave it off-line. +JWK: Still confused, but I think I can leave it off-line. -SYG: Okay. Happy to explain more off-line. +SYG: Okay. Happy to explain more off-line. -WH: In the materials submitted for this presentation, you list examples such as, if you have two unrelated scopes in the same worker both of which declare shared structs which happen to be named the same `SharedThing` but different contents, the second one will throw. Can you explain that? +WH: In the materials submitted for this presentation, you list examples such as, if you have two unrelated scopes in the same worker both of which declare shared structs which happen to be named the same `SharedThing` but different contents, the second one will throw. Can you explain that? -SYG: So you are talking about … This possible thing? Probably throwing in there’s a layout mismatch? Is that what you are asking about? +SYG: So you are talking about … This possible thing? Probably throwing in there’s a layout mismatch? Is that what you are asking about? -WH: The same worker. +WH: The same worker. SYG: I think you might – either explainer is out of date or I don’t – I need the specific thing you’re thinking of. But there was a previous iteration of this, a programmatic API for the registry that lets you register with different keys, forgeable. In the current iteration, because the key is the source location, it’s not possible to have a mismatch in the same thread, if you have two different source locations in the same declaration. If you somehow manage to trigger a reevaluation of the same file or script or module with a changed content, then you can get a mismatch, in which case it might throw. It seems unlikely for that to happen naturally WH: The confusion stems from, the talk seems to imply that these things are based on source — lexical scoping. The materials presented for this talk imply this is dynamically scoped: if two variables named `SharedThing` appear in different scopes in the program, they refer to the same struct if it’s registered. I’m confused about which is the intended behavior. -SYG: Okay. Apologies. This is not the – the compact semantics are not spelled out in any prepared material. The intention here is that what is deduplicated is the shape. When you evaluate this thing, even though it is the same – even if it’s in the same file, when you – every time you evaluate it, still get a different constructor function. What is the same is kind of under the hood. The shape, that the constructor function points to, for the instances it creates, including – usually this shape unobservable. Where it is observable is via the TLS key for the thread local prototypes. +SYG: Okay. Apologies. This is not the – the compact semantics are not spelled out in any prepared material. The intention here is that what is deduplicated is the shape. When you evaluate this thing, even though it is the same – even if it’s in the same file, when you – every time you evaluate it, still get a different constructor function. What is the same is kind of under the hood. The shape, that the constructor function points to, for the instances it creates, including – usually this shape unobservable. Where it is observable is via the TLS key for the thread local prototypes. -WH: Okay. Let me see if I can phrase my question better. The example given is that if you have two unrelated registered shared structs in two different places in the program, which happen to use the same name, that throws. +WH: Okay. Let me see if I can phrase my question better. The example given is that if you have two unrelated registered shared structs in two different places in the program, which happen to use the same name, that throws. SYG: Okay. That example no longer applies. That’s from a previous iteration using the struct and string name as the key into the registry. That is forgeable and that idea was being scrapped after late discussion actually -WH: Thank you. That clarifies things. +WH: Thank you. That clarifies things. JWK: You just mentioned you need to check the shape. But I thought it’s just like duck type – it does not have something like private fields which you need to check if the object is owned by this struct. -SYG: You check the shape on the deduplication. If you want this registered behaviour to have the autocorrelation, you only want to auto correlate straight structs that in fact have the same shape and the same shape here means order and names of fields and thread localness of the prototype. +SYG: You check the shape on the deduplication. If you want this registered behaviour to have the autocorrelation, you only want to auto correlate straight structs that in fact have the same shape and the same shape here means order and names of fields and thread localness of the prototype. -JWK: What if let’s say what if the shared struct instance is not registered and sent across different workers. For example, in slide 13, you received a shared object from another worker. And you set the prototype, is this page registered? +JWK: What if let’s say what if the shared struct instance is not registered and sent across different workers. For example, in slide 13, you received a shared object from another worker. And you set the prototype, is this page registered? -SYG: This P is not registered. No. +SYG: This P is not registered. No. -JWK: So I see. It also works if you manually set the prototype. +JWK: So I see. It also works if you manually set the prototype. -SYG: Correct. For F you manually set the prototype. The feedback, this solves a DX problem. If you need to have a – manually set up the prototypes of all your shared struct definitions ahead of time – +SYG: Correct. For F you manually set the prototype. The feedback, this solves a DX problem. If you need to have a – manually set up the prototypes of all your shared struct definitions ahead of time – -JWK: Okay. I understand what the problem-solving is. Thank you. +JWK: Okay. I understand what the problem-solving is. Thank you. SYG: Thank you. Registry – registered behaviour is an opt in thing. You are still currently the proposal is such that you don’t have to use it at the point. You could choose to not do that, manually set up all the prototypes. NRO: So you are not trying to explore sharing code. That’s what we are trying to do, module expression proposal. The proposal right now has only models and the older version had some shorthand for other dependencies that don’t have a different function. And that function doesn’t capture any scope because it’s liken closing the models and impossible to share that. -So this share ends up working with my work together and see if – +So this share ends up working with my work together and see if – -SYG: I think we should work together regardless. I want to add to the punting of the code things. Functions in JS, are both code and code containers. And we can't share the code containers. Module expressions as far as I understand, chips away at sharing a qua code. We don’t have a go ahead idea of how to share code containers. Having sharable code is having a prerequisite for sharing contains. +SYG: I think we should work together regardless. I want to add to the punting of the code things. Functions in JS, are both code and code containers. And we can't share the code containers. Module expressions as far as I understand, chips away at sharing a qua code. We don’t have a go ahead idea of how to share code containers. Having sharable code is having a prerequisite for sharing contains. NRO: What is a code container -SYG: It is abstract thing where it is first class thing you can hold that referencing code. JS functions refer to some ECMAScript code under the hood. But it’s like object. Compared to, say, an assembly, you jump to an instruction. There is no code container you can hold. +SYG: It is abstract thing where it is first class thing you can hold that referencing code. JS functions refer to some ECMAScript code under the hood. But it’s like object. Compared to, say, an assembly, you jump to an instruction. There is no code container you can hold. -NRO: Shared buffer – have the shared memory – +NRO: Shared buffer – have the shared memory – SYG: Like that. Yes. Different instances object in different thread, but the backing store is the same memory. -JWK: As I understand the register semantics, if we want to use module blocks, or module expressions to share the code, it’s just share the source text and if we want to make them have the same identity across different agents or realms, we still need to have something on the module expression, or module block, to let it join the registry. Is that right? +JWK: As I understand the register semantics, if we want to use module blocks, or module expressions to share the code, it’s just share the source text and if we want to make them have the same identity across different agents or realms, we still need to have something on the module expression, or module block, to let it join the registry. Is that right? SYG: I don’t have enough of the module expression stuff paged in to say DE: I am happy that you’ve been thinking through how to have these thread-local prototypes. Per-agent code is a good model for methods on shared struct instances. I like your idea of deduplicating by source position. While I had proposed previously that this work via module expressions, your design here should work better given the subsequent evolution of module expressions. You wouldn’t want to require that the module be postMessage’d around to workers to get the right identities for such shared struct classes. DE: Note that the V8 team was previously skeptical of using source positions in the case of tagged template literals. Anyway, I am happy if we end up going to source position. An alternative would be to require these things have to be at the top level of module and exported with a particular name. Then the key in the cache would be the module specifier plus the exported name. I think that could work. And it could compose with module expressions as well, because the specifier is the expression. -It gets worse with module expression identity being based on – which time it’s instantiated, if we are okay going by source position, then we could go back module positions by source. I agree with your finding, that anchoring on source positions is important and we will have to use at some point or other. +It gets worse with module expression identity being based on – which time it’s instantiated, if we are okay going by source position, then we could go back module positions by source. I agree with your finding, that anchoring on source positions is important and we will have to use at some point or other. SYG: Do you have something to think about for the . . . module name plus the thing is – the struct name is the key. Only the top level. Yeah. I am not 100% sure on what constituted like in practice exploitable global communication channel. Source location makes it enclosed, that seems it’s not possible. But your thing also sounds okay. I don’t know -DE: Thanks. Also, I wanted to comment. Some of the early discussion was about what would happen if you didn’t do the two kinds of opt-ins. Maybe we should say, shared means those two opt-ins are included. I was also wondering about whether methods could be declared in the shared structs class body. +DE: Thanks. Also, I wanted to comment. Some of the early discussion was about what would happen if you didn’t do the two kinds of opt-ins. Maybe we should say, shared means those two opt-ins are included. I was also wondering about whether methods could be declared in the shared structs class body. SYG: Yes. So if – yes. That’s – the first part yes is open whether that’s a default. That should be the behaviour. If so, you can allow methods in line, I think there is a counter argument for pre-scheduling in the future, where we have truly shared function objects and how do you opt into that world. But I don’t want to necessarily design things to be so speculative and to be honest, I am not that – nobody last time I talked to was excited about adding a new exotic callable -DE: I’m skeptical of directly sharing function objects between JS threads. If you wanted shared structs and plain old data, that’s something I would understand. +DE: I’m skeptical of directly sharing function objects between JS threads. If you wanted shared structs and plain old data, that’s something I would understand. -MLS: More and more browsers certainly and probably other engines are going for a process per – in the question process per worker is common. You didn’t address how it works. And I see there’s a lot of issues with that. Especially, you’re talking about distributing garbage collection. So my concern is, if this requires a – in the same process, thread then some of the security benefits of going per process are turned off by requiring this to be in the same process. +MLS: More and more browsers certainly and probably other engines are going for a process per – in the question process per worker is common. You didn’t address how it works. And I see there’s a lot of issues with that. Especially, you’re talking about distributing garbage collection. So my concern is, if this requires a – in the same process, thread then some of the security benefits of going per process are turned off by requiring this to be in the same process. SYG: Good question. Security trumps everything here. So I think I have an easy answer for, which is this will be the exact same compatibility as SharedArrayBuffers. So currently, SharedArrayBuffers require cross-origin isolation. I don’t know any browser that does a process per realm. I don’t think that is a possible because realms with be synchronously accessible – there’s out of process iframes, but this is different. -But this will be exactly lined up with SharedArrayBuffers as a capability. So today, to opt in to use SharedArrayBuffers across different workers, you must be cross-origin isolated and agents – cannot be done in – ates in the spec, ES spec E sense cannot be put in different processes if they need to share a SharedArrayBuffers, because they need to be in the same VM space. +But this will be exactly lined up with SharedArrayBuffers as a capability. So today, to opt in to use SharedArrayBuffers across different workers, you must be cross-origin isolated and agents – cannot be done in – ates in the spec, ES spec E sense cannot be put in different processes if they need to share a SharedArrayBuffers, because they need to be in the same VM space. -MLS: You’re just saying that this is building on a SharedArrayBuffer. +MLS: You’re just saying that this is building on a SharedArrayBuffer. -SYG: From the lens as a capability to be denied via like headers or the lack of headers, yes. But like – +SYG: From the lens as a capability to be denied via like headers or the lack of headers, yes. But like – -MLS: Yeah. Obviously implementation-wising, but in the same class? +MLS: Yeah. Obviously implementation-wising, but in the same class? SYG: Yeah. If we introduce some kind of super isolated mode in the web, that precludes all shared memory communication between workers, SharedArrayBuffers is out the window and so is this LCA: Yeah. I have – this is the first time I am hearing about this source location thing and it’s very interesting. This ties very much into the module work we are doing. And I would love to talk to you more about this. I have at an initial look at this, a couple concerns about this keying on source location. Namely, around the complexities that this will bring whether combined with bundlers and tooling because it’s unlikely that most tools do not support any way to mark a module – mark a shared struct to – for different entry points not be duplicated in the entry points but explicitly emitted as a model that is shared between those entry points, especially if they live on separate like – yeah. Like one is a worker and one is a main thread. The – this is particularly concerning because there’s a lot of – this is not easy to see for developers, especially if it happens deep within their import. If they have modules wanting to use shared structs and this tool maybe has minified, and depending on the entry point, it’s determined to be one or the other, the source location will differ. The user will have insight into what is happening here. -And I think this is not an objection to key source location. But we have to be very, very careful about keying things on source location in a way that there is no way to override. If a bundler, for example, had a way to override the key, and make it explicit between two entry points, it may solve the problem. +And I think this is not an objection to key source location. But we have to be very, very careful about keying things on source location in a way that there is no way to override. If a bundler, for example, had a way to override the key, and make it explicit between two entry points, it may solve the problem. SYG: Yeah. RBN has concerns on overriding the registry key. There are competing constraints about folks not having a communication channel, you can observe, collusions which makes it a communication channel. But I am not opposed to being overridable. We need to resolve the competing constraints somehow. Yeah -LCA: I also want to mention the comment about this being the same, I don’t think it is. The evaluation is not shared between two workers. +LCA: I also want to mention the comment about this being the same, I don’t think it is. The evaluation is not shared between two workers. SYG: There’s a template object thing that is supposed to be deduplicated corresponding to source location -LCA: You wouldn’t run into this, the same worker would not load two versions of the same module. +LCA: You wouldn’t run into this, the same worker would not load two versions of the same module. SYG: Fair enough. I see other topics I would like to get to. So can I ask the folks in the queue, if you have – bundler semantics preserving duplication transform concerns, let’s talk about that off-line. It is a nonproblem. Otherwise, let’s go on with the queue of RGN -RGN: One thing I didn’t see in the slides is, what happens to an existing instance when a registered struct is evaluated? +RGN: One thing I didn’t see in the slides is, what happens to an existing instance when a registered struct is evaluated? SYG: The registration is syntactic. You can’t register it after the fact. By the time you evaluate a shared struct evaluation, you have the constructor, which is the thing that is either registered or not registered. You can't make a constructor, make some non registered shared struct instances, and ask them to register the [cuk]er. That’s not expressible -RGN: You have loose things that happen to have the same shape, but don’t get the data attached because they were sent over before evaluation? +RGN: You have loose things that happen to have the same shape, but don’t get the data attached because they were sent over before evaluation? -SYG: No. By the time you are able to create instances, you already know whether those instances – have a shape that is registered or not. You cannot express a program that has already created some non registered – instances with non registered heap and register their shape after the fact because there is no programmatic API to register a shape. It is a syntax thing -Syntax itself can be deferred by things like dynamic import eval. It is in the declaration that creates the constructor. How do you get instances to the same constructor. Instance that is created if it had been evaluated. How did it get evaluated, if you triggered the same script with different contents? No. You had it coming over a post message. So the same shape. +SYG: No. By the time you are able to create instances, you already know whether those instances – have a shape that is registered or not. You cannot express a program that has already created some non registered – instances with non registered heap and register their shape after the fact because there is no programmatic API to register a shape. It is a syntax thing Syntax itself can be deferred by things like dynamic import eval. It is in the declaration that creates the constructor. How do you get instances to the same constructor. Instance that is created if it had been evaluated. How did it get evaluated, if you triggered the same script with different contents? No. You had it coming over a post message. So the same shape. -SYG: The source location thing. Those would just be uncorrelated. You can’t correlate them anymore. +SYG: The source location thing. Those would just be uncorrelated. You can’t correlate them anymore. RGN: Great. Okay. All right. We’re skeptical in general and the slides content on GitHub looked like it had action at a distance. In which case we would be strongly opposed. As for communication channel, that’s best taken off-line. But it is a concern and thing we look at as well SYG: We recognize it as a constraint. We would like to work with you to ensure you don’t oppose it. We need to strike the balance between D and non nonglobal communication channel and bundler concerns. Those are all known constraints going into here. I would like there to be a possible solution. But we recognize your concerns -RGN: All right. +RGN: All right. MAH: I have a clarification question. With RGN’s question and your explanation SYG. Did you say that a struct would be – struct instance received from another thread, before which the definition has not been locally evaluated, from what I understand, you can access the shared properties, but that wouldn’t have behaviour. But you should still be able to evaluate the definition by, for example, by dynamic imports -SYG: Yes, I misunderstood RGN’s example to begin with. What you say is correct. +SYG: Yes, I misunderstood RGN’s example to begin with. What you say is correct. -JWK: I can see the benefit of the registered version. So in which case you need an unregistered version to be the default or the only option? +JWK: I can see the benefit of the registered version. So in which case you need an unregistered version to be the default or the only option? -SYG: Yeah. Dan raised that earlier. I see a compelling argument for it. Yeah. That’s likely. But I haven’t nailed it down yet for Stage 2. +SYG: Yeah. Dan raised that earlier. I see a compelling argument for it. Yeah. That’s likely. But I haven’t nailed it down yet for Stage 2. -WH: I am also confused about SYG’s answer to the prior question: if a thread receives a shared struct via a message, but hasn’t evaluated that shared struct’s declaration yet, and later evaluates that declaration, can the shared struct’s prototype change dynamically? +WH: I am also confused about SYG’s answer to the prior question: if a thread receives a shared struct via a message, but hasn’t evaluated that shared struct’s declaration yet, and later evaluates that declaration, can the shared struct’s prototype change dynamically? -SYG: Correct. Because what – it isn’t acquired per se, but when you evaluate the shared struct definition, that would assign the thread locally prototype. If the definition you evaluate is registered, it would do that and then like that evaluation with the assignment, into the thread local prototype and look like it would get a new method because someone assigned to its prototype. +SYG: Correct. Because what – it isn’t acquired per se, but when you evaluate the shared struct definition, that would assign the thread locally prototype. If the definition you evaluate is registered, it would do that and then like that evaluation with the assignment, into the thread local prototype and look like it would get a new method because someone assigned to its prototype. -WH: Okay. Also, I’m curious how the source location interacts with eval — it seems that this cannot be used with eval code. What is the intent here? +WH: Okay. Also, I’m curious how the source location interacts with eval — it seems that this cannot be used with eval code. What is the intent here? -SYG: We may be able to say – if there are concerns, I am not going to lose sleep on making eval work. +SYG: We may be able to say – if there are concerns, I am not going to lose sleep on making eval work. DE: We already have eval defined for template literals which are defined per source position. It ends up a mess. To WH’s question, “what happens about acquiring the prototype?”: The idea is that GetPrototypeOf throws if the source position (or defining module) hasn’t run yet. This means that you don’t observe a mutation-like change. You observe – if you access something that is not a data property and you don’t have the – local prototype, then it’s an error. I hope this won't be too expensive. -SYG: You would love to see my TDZ talk later and see how things throw before they initialize. +SYG: You would love to see my TDZ talk later and see how things throw before they initialize. -DE: It seems different, since it’s a property access rather than a variable read. +DE: It seems different, since it’s a property access rather than a variable read. SYG: Thank you for your time + ### Summary of Key Points + * Shared structs is a proposal for a limited form of JavaScript objects which can be shared between multiple JavaScript agents * Identified ability to attach behavior a crucial requirement for adoption of proposal, based on dev trial feedback from multiple partners * Presented solution to use thread-local prototypes + auto-correlation global registry by source position + syntax for defining shared struct classes * Champions plan to ask for Stage 2 by end of year + ### Conclusion + * More work needed to iterate on the global registry for solving the correlation problem * Folks seem generally happy with the thread-local prototype mechanism * Shared structs remain at Stage 1 ## Type Annotations: Stage 1 update and discussion -Presenter: Daniel Ehrenberg (DE), Nicolo Ribaudo (NRO) and Daniel Rosenwasser (DRR) -- [proposal](https://github.com/tc39/proposal-type-annotations) -- [slides](https://docs.google.com/presentation/d/1rwrWQkYityiK1pf5UpkgRYMKL8euqtDrrrbngMKJusY/edit#slide=id.p) +Presenter: Daniel Ehrenberg (DE), Nicolo Ribaudo (NRO) and Daniel Rosenwasser (DRR) +* [proposal](https://github.com/tc39/proposal-type-annotations) +* [slides](https://docs.google.com/presentation/d/1rwrWQkYityiK1pf5UpkgRYMKL8euqtDrrrbngMKJusY/edit#slide=id.p) -DE: I want to thank Asuma Takikawa for leading the work on this proposal in general, doing -the majority over the past several months, but he is on vacation this week. He prepared most of this presentation. +DE: I want to thank Asuma Takikawa for leading the work on this proposal in general, doing the majority over the past several months, but he is on vacation this week. He prepared most of this presentation. -DE: This proposal is in an early state. We have a tentative grammar, and it gives some -flexibility, while also having a high level of compatibility with existing type systems. This is still a very early draft, and shouldn’t be taken too literally. But I’m glad we have it out there so that it can be iterated on with feedback from the community. +DE: This proposal is in an early state. We have a tentative grammar, and it gives some flexibility, while also having a high level of compatibility with existing type systems. This is still a very early draft, and shouldn’t be taken too literally. But I’m glad we have it out there so that it can be iterated on with feedback from the community. DE: For example, we’ve received more feedback from Flow and Typescript about certain omissions to be corrected. One very core goal is a high level of compatibility with types used in the current JavaScript ecosystem, for example, TypeScript. This informs a lot of the grammar design decisions. @@ -824,25 +596,11 @@ DE: We held a community call on September 20th and got a bunch of interesting fe DE: The ongoing technical work is around the grammar: there is nothing to do with runtime semantics because it’s type erasure! It’s just as if they were comments. We’re studying the implications of the flexible grammar. WH gave some feedback about the "token soup" approach, where in the context of a type (e.g. after a `:` sometimes) you could just have any “soup of tokens” within those parentheses/brackets, matching the nesting, and that would be treated as part of the type. We’ve been identifying and fixing technical problems with the grammar. There are some ambiguities raised previously, some more ambiguities that we found later. And we’re making progress on a more concrete grammar variant. -NRO: Some major things were, for example, type parameters in function calls, because TS uses this `f()` operator that, like, just is very much ambiguous with the javascript syntax -due of comparison operators. And a solution to the proposal is probably going to use `f::()`. This is not necessary in every case, such as in function declarations, but it’s necessary in some cases in function calls, in some cases like arrow function expressions it might be needed. We’re still -going through all the possible cases to see where we can avoid changing the operator when it’s -not necessary. That was an example of a solution for an ambiguity. There are other examples where we might likely need to change the syntax going on or introduce more cover grammars. We know that cover grammars are not ideal, so one goal is to try to keep the grammar as simple as possible. - -NRO: Some examples in which we will actually have to restrict syntax and this a case of -type syntax that could be parsed in different ways is when you have arrow parentheses in -different times mixed with ternary operators, because, well, they both use colons, so it’s, like, -impossible to tell which colon is for a type and which is for the operator. Typescript tries to be as (?) as possible and changes the latest choice to, like, different -option if it fails the first time. But, like, we cannot and do not want to incur this behavior -in the JavaScript grammar. So, like, the solution for this problem will be to restrict what -you can have in the return of an arrow function, like, after the arrow, in practice, requiring -you to use parentheses or braces with return if the arrow function is going to return another -function that has types or, like, if the -- if the function and arrow function with types. And -the grammar details are in progress. You can follow what’s happening in the proposal repo. And -regarding concrete grammar alternative, like, if possible, the main goals of the proposal is to -go ahead with token soup. While keeping the grammar as LR(1), which is what it currently is, -at least as far as we know, and trying to solve all the ambiguities in the space. Even if that -ends up being possible, if the result might be too bad, there still might be reasons to, in the end, decide to not go ahead with token soup. My colleague is working on comparing the two possible grammars to see which one ends up fitting the language better. +NRO: Some major things were, for example, type parameters in function calls, because TS uses this `f()` operator that, like, just is very much ambiguous with the javascript syntax due of comparison operators. And a solution to the proposal is probably going to use `f::()`. This is not necessary in every case, such as in function declarations, but it’s necessary in some cases in function calls, in some cases like arrow function expressions it might be needed. We’re still going through all the possible cases to see where we can avoid changing the operator when it’s not necessary. That was an example of a solution for an ambiguity. There are other examples where we might likely need to change the syntax going on or introduce more cover grammars. We know that cover grammars are not ideal, so one goal is to try to keep the grammar as simple as possible. + +NRO: Some examples in which we will actually have to restrict syntax and this a case of type syntax that could be parsed in different ways is when you have arrow parentheses in different times mixed with ternary operators, because, well, they both use colons, so it’s, like, +impossible to tell which colon is for a type and which is for the operator. Typescript tries to be as (?) as possible and changes the latest choice to, like, different option if it fails the first time. But, like, we cannot and do not want to incur this behavior in the JavaScript grammar. So, like, the solution for this problem will be to restrict what you can have in the return of an arrow function, like, after the arrow, in practice, requiring you to use parentheses or braces with return if the arrow function is going to return another function that has types or, like, if the -- if the function and arrow function with types. And the grammar details are in progress. You can follow what’s happening in the proposal repo. And regarding concrete grammar alternative, like, if possible, the main goals of the proposal is to go ahead with token soup. While keeping the grammar as LR(1), which is what it currently is, +at least as far as we know, and trying to solve all the ambiguities in the space. Even if that ends up being possible, if the result might be too bad, there still might be reasons to, in the end, decide to not go ahead with token soup. My colleague is working on comparing the two possible grammars to see which one ends up fitting the language better. DE: To summarize, we’ve investigated the token soup issues or the issues raised previously. We don’t yet see any technical issues with token soup. But are willing to entertain different alternatives, and we’ll probably be coming back to the committee in the future with more details to share. @@ -864,54 +622,31 @@ WH: It’s still the wrong question to ask. DE: Okay, what question should we be asking? -WH: The more basic question is why are we trying to create something which -is different from both ECMAScript and TypeScript. +WH: The more basic question is why are we trying to create something which is different from both ECMAScript and TypeScript. -DE: By definition, this would be ECMAScript. That wouldn’t be a separate mode. We’re not -proposing a different top level syntactic goal. Maybe DRR can clarify the relationship between the results of this proposal and TypeScript. +DE: By definition, this would be ECMAScript. That wouldn’t be a separate mode. We’re not proposing a different top level syntactic goal. Maybe DRR can clarify the relationship between the results of this proposal and TypeScript. -WH: Well, not quite — this would not be ECMAScript because ECMAScript does not -define any semantics of this. +WH: Well, not quite — this would not be ECMAScript because ECMAScript does not define any semantics of this. DE: Yes, just like ECMAScript doesn’t define the semantics of comments. We’re allowed to add more syntax that doesn’t have runtime semantics. This is to not to add a new top level goal. Do you think that’s a bad idea, and if so, why? WH: I am uncomfortable with being put on the spot here. I hadn’t added myself to the queue. -MLS: I’m trying to figure out what the use case is, we’re going to delete them away, we’re going -to erase them. If tooling is going to use it, can’t the tooling delete the type annotations -before -- just like what we’re doing, but what Flow and TypeScript and other things do right -now? I just don’t see why we want to parse this. We’re going to increase the payload size and -the parsing time. And I don’t understand that the devs or engines get out of it. +MLS: I’m trying to figure out what the use case is, we’re going to delete them away, we’re going to erase them. If tooling is going to use it, can’t the tooling delete the type annotations before -- just like what we’re doing, but what Flow and TypeScript and other things do right now? I just don’t see why we want to parse this. We’re going to increase the payload size and the parsing time. And I don’t understand that the devs or engines get out of it. DE: The idea is in a typical case, tools would remove the types, just like minifiers remove comments today. -DRR: Yeah, I think, Michael, your perspective and question here is very legitimate. But the core -idea is trying to lower the barrier of entry and make it easier to just iterate with JavaScript -in something that’s very user friendly for very casual development. You know, anecdotal pain -points that people bring up are I can’t take my TypeScript and paste it into the console and -try that out and I can’t just run that off the bat. You always do need some sort of -preprocessing step. The work around that TypeScript has done is to actually parse and -understand and give error messages in violation of types in jsdoc comments. We try to do a -good job there, but it’s not as ergonomic and it’s kind of a pain in a lot of cases, and it -sure would be nice if there were more first class syntaxes to express some of the things that -you might want to do, right, to express the types that you have, to express that something not-null, things along those lines. So it becomes very cumbersome. Now, the question of "can’t the -tools just do this?" is a valid perspective. +DRR: Yeah, I think, Michael, your perspective and question here is very legitimate. But the core idea is trying to lower the barrier of entry and make it easier to just iterate with JavaScript in something that’s very user friendly for very casual development. You know, anecdotal pain points that people bring up are I can’t take my TypeScript and paste it into the console and try that out and I can’t just run that off the bat. You always do need some sort of preprocessing step. The work around that TypeScript has done is to actually parse and understand and give error messages in violation of types in jsdoc comments. We try to do a good job there, but it’s not as ergonomic and it’s kind of a pain in a lot of cases, and it sure would be nice if there were more first class syntaxes to express some of the things that you might want to do, right, to express the types that you have, to express that something not-null, things along those lines. So it becomes very cumbersome. Now, the question of "can’t the tools just do this?" is a valid perspective. MLS: They’re doing it now, right? -DRR: Yeah, they are, they are, right? But, you know, like I said, there is a gap in certain runtimes. Node doesn’t have that built in. You could say Node could build it in, but then the browsers don’t have it built in and then you could say a dev tool built into the browser could do, that but there’s still always this lit extra little gap, right? So if there are ways to alleviate this more and further, then we can also talk about that as alternatives. But as a whole, we’ve also seen that being able to have design-time syntax is extremely valuable and could just make the overall barrier entry for new jobs for developers a lot lower, a lot more approachable. So that’s what we’re trying to explore. And then whenever we bring this to committee, we are interested in hearing, you know, about that, you know, perspective, if it’s valid, if the tools currently serve the needs correctly, things like that. But we also do want to be conscious of the fact that tooling has grown quite a bit in the last few years. Maybe we’re seeing consolidation and you have a linter and type checker and that and that, can we simplify it a little bit. That’s one of things that we’re hoping to see here. +DRR: Yeah, they are, they are, right? But, you know, like I said, there is a gap in certain runtimes. Node doesn’t have that built in. You could say Node could build it in, but then the browsers don’t have it built in and then you could say a dev tool built into the browser could do, that but there’s still always this lit extra little gap, right? So if there are ways to alleviate this more and further, then we can also talk about that as alternatives. But as a whole, we’ve also seen that being able to have design-time syntax is extremely valuable and could just make the overall barrier entry for new jobs for developers a lot lower, a lot more approachable. So that’s what we’re trying to explore. And then whenever we bring this to committee, we are interested in hearing, you know, about that, you know, perspective, if it’s valid, if the tools currently serve the needs correctly, things like that. But we also do want to be conscious of the fact that tooling has grown quite a bit in the last few years. Maybe we’re seeing consolidation and you have a linter and type checker and that and that, can we simplify it a little bit. That’s one of things that we’re hoping to see here. -MLS: But let’s suppose somebody uses a console or they -- you know, they have a local development -environment where they’re -- they have a type annotation. They’ll get no benefit because -they’re not passing it to a tool, so, okay, so they don’t have to, you know, preprocess it -before they pass it on to an engine, but if they’re doing that, then they get the benefit, and -I just don’t see that they’re going to want to keep the type annotated, you know, TypeScript -flow, whatever source and use that directly as they’re developing straight to an engine, you -know, a JavaScript engine, because the engine does nothing with it. +MLS: But let’s suppose somebody uses a console or they -- you know, they have a local development environment where they’re -- they have a type annotation. They’ll get no benefit because they’re not passing it to a tool, so, okay, so they don’t have to, you know, preprocess it before they pass it on to an engine, but if they’re doing that, then they get the benefit, and I just don’t see that they’re going to want to keep the type annotated, you know, TypeScript flow, whatever source and use that directly as they’re developing straight to an engine, you know, a JavaScript engine, because the engine does nothing with it. DE: But the things that DRR is describing is current feedback from current JavaScript developers, where they face this as existing pain points. Another thing you could think of is JSON, why do people complain about how JSON does not have comments? It shouldn’t be a problem because comments don’t do anything at run time, but it clearly causes real problems at many different levels to not allow comments in JSON. Not that we can fix that, but that’s another example of pain point that doesn’t relate to something happening at runtime. -MLS: But then it gets to, like, my other concern, is that in a sense, aren’t we picking the winning syntax that will be an ECMAScript? Even if it’s not comments -- the exact syntax of TypeScript or flow or whatever, we’re picking the -- a winner of a particular tool, aren’t we? +MLS: But then it gets to, like, my other concern, is that in a sense, aren’t we picking the winning syntax that will be an ECMAScript? Even if it’s not comments -- the exact syntax of TypeScript or flow or whatever, we’re picking the -- a winner of a particular tool, aren’t we? DE: So I’m actually comfortable with that. @@ -919,24 +654,19 @@ MLS: Okay. DE: Yeah, because we do have the world moving in a particular direction, TypeScript is very, very widely used. We are working to accommodate Flow syntax as well. But the goal is to align with the actual ecosystem that exists. This has been a design goal of TC39 in the past, e.g., in the design of class fields and decorators. The designs related to us working with the actual JavaScript ecosystem that exists to meet their expectations because they have learned that certain things are useful. -MLS: But being an open standard, I think we need to have not just TypeScript, but Flow and others -at the table. +MLS: But being an open standard, I think we need to have not just TypeScript, but Flow and others at the table. -DE: That’s right, we do have Flow at the table. Flow attended the community call, and we’re -working through more details of the gaps with flow in the grammar in the repository. So I agree. +DE: That’s right, we do have Flow at the table. Flow attended the community call, and we’re working through more details of the gaps with flow in the grammar in the repository. So I agree. MLS: I registered my concerns. TAB: Just wanted to say my support for runtime valid syntax. Being able to run the code locally without requiring the build step cycle is extremely valuable for just usability. It’s no different than when you’re going to ship a minified version and you’re going to write your code with nice white space. This is essentially the same deal there. It would be very annoying if it was required that you executed only minified JavaScript. So no comment on the exact syntax we’re doing, but on the idea of runtime valid type stuff, it’s very, very convenient for authoring. -MLS: But minification is a transformation from an ECMAScript compliant code to an ECMAScript -compliant code. So I don’t think that’s a valid argument. +MLS: But minification is a transformation from an ECMAScript compliant code to an ECMAScript compliant code. So I don’t think that’s a valid argument. -TAB: That’s exactly what’s going on here with purely erasure semantics for the types. You start -from valid code to exactly identical runtime behavior valid code. It’s just shorter. +TAB: That’s exactly what’s going on here with purely erasure semantics for the types. You start from valid code to exactly identical runtime behavior valid code. It’s just shorter. -DE: The idea of the proposal is that we would define type syntax as part of the ECMAScript-compliant standard. We’re not defining a new TypeScript or something like that. I want to mention something that -TAB and I had discussed recently. JS and CSS are having this parallel evolution. As of five years ago, ten years ago, they had to do so much via tooling. Tooling is still very useful for both languages but not essential as far as the authoring experience goes. Increasingly it’s not essential. It’s still essential for CSS for scopes, for JavaScript for types, but now we’re working on this. Instead, tooling can be more about optimization, more about checking, and less about adding tons of syntax. +DE: The idea of the proposal is that we would define type syntax as part of the ECMAScript-compliant standard. We’re not defining a new TypeScript or something like that. I want to mention something that TAB and I had discussed recently. JS and CSS are having this parallel evolution. As of five years ago, ten years ago, they had to do so much via tooling. Tooling is still very useful for both languages but not essential as far as the authoring experience goes. Increasingly it’s not essential. It’s still essential for CSS for scopes, for JavaScript for types, but now we’re working on this. Instead, tooling can be more about optimization, more about checking, and less about adding tons of syntax. DRR: it’s interesting to hear a lot of different perspectives on ECMAScript. We’re trying to bring things into ECMAScript. I don’t quite understand where a lot of the conversation is around, like, the standard thing versus the non-standard thing. This is a Stage 1 proposal, right, and we’re trying to see whether we can bring something into ECMAScript and make it part of the standard. Let’s all keep that in mind. @@ -948,42 +678,19 @@ DE: A major similarity is around having a global view of the grammar. If throw e KG: I think if the goal is that we would like to restrict and shape the grammar that TypeScript programmers use, we would not have constraints at all. -DE: That’s not what I meant. when TC39 edits the grammar, we have to keep this extra shadow grammar into account of possible extensions, e.g., TypeScript. +DE: That’s not what I meant. when TC39 edits the grammar, we have to keep this extra shadow grammar into account of possible extensions, e.g., TypeScript. -KG: Right, and keeping those things in mind is very different from, like, specifying it in full -in a way that makes sense for shipping at runtime. Like, those are just different problems. +KG: Right, and keeping those things in mind is very different from, like, specifying it in full in a way that makes sense for shipping at runtime. Like, those are just different problems. -SYG: So I get the sense that we don’t, as a committee, I don’t think we have consensus on what -the primary goals or the set of goals for the proposal is? I have heard multiple ones. I have -heard it’s to ease kind of development time DX pains for which there are other solutions than -to standardize a subset of TS syntaxes. I have heard kind of unforking TS syntax as goal, for -which there are also other constraints and -- or other solutions and constraints than the dev -tool thing. I’d like to better understand what is the primary goal of the champions for this -proposal? +SYG: So I get the sense that we don’t, as a committee, I don’t think we have consensus on what the primary goals or the set of goals for the proposal is? I have heard multiple ones. I have heard it’s to ease kind of development time DX pains for which there are other solutions than to standardize a subset of TS syntaxes. I have heard kind of unforking TS syntax as goal, for which there are also other constraints and -- or other solutions and constraints than the dev tool thing. I’d like to better understand what is the primary goal of the champions for this proposal? DE: This presentation was light on motivation because we’ve discussed it in previous meetings; I’ll bring up previous meeting slides. WH: My question is very similar to Shu’s, that I heard that a goal of this was to allow programmers to skip some tooling and just execute TypeScript directly, so are we proposing including all of the TypeScript syntax as erasable ECMAScript annotations? -DRR: I want us to not take such a statement so literally. Maybe I’ll rephrase that as a way -to get most of the benefits of TypeScript, still being checked by TypeScript or some other -static analysis, of being able to skip some tooling intermediate thereof., so for example, you -have a question about whether this is sort of like hinting at whether or month this is the full -TypeScript grammar or not, and anecdotally, the thing that a lot of TypeScript users are often -drawn towards is sticking to a version of plain ECMAScript, plain JavaScript with simply -erasable types and type annotation, type declarations and type annotations, a little bit of -extra syntax maybe for type assertions or like casts, basically. So there is a set of -TypeScript syntaxes that probably could be foregone, right, or proposed separately within TC39, -and so basically, it is something like getting TypeScript with all the tooling benefits without -having to go through all of the tooling itself in some cases, right? Does it that mean it’s -not just a drop-in replacement? Possibly, yes. But does that mean that many users would -benefit in such a way where they would be happy to translate their existing code into that -sort of subset or whatever it is? I’d say that that’s very likely for a very large group of -users, maybe the majority of users. So I don’t want to get into a whole discussion about what, -you know, what this is, whether it is a subset, a super set, the full syntax, something like -that. Is the pretty much not going to be the full syntax of TypeScript. That’s what I would -easily be able to tell you. And it’s probably not going to be the full syntax of necessarily -any -- well, anyway, I don’t want to make a definitive statement there. +DRR: I want us to not take such a statement so literally. Maybe I’ll rephrase that as a way to get most of the benefits of TypeScript, still being checked by TypeScript or some other static analysis, of being able to skip some tooling intermediate thereof., so for example, you have a question about whether this is sort of like hinting at whether or month this is the full TypeScript grammar or not, and anecdotally, the thing that a lot of TypeScript users are often drawn towards is sticking to a version of plain ECMAScript, plain JavaScript with simply erasable types and type annotation, type declarations and type annotations, a little bit of extra syntax maybe for type assertions or like casts, basically. So there is a set of TypeScript syntaxes that probably could be foregone, right, or proposed separately within TC39, +and so basically, it is something like getting TypeScript with all the tooling benefits without having to go through all of the tooling itself in some cases, right? Does it that mean it’s not just a drop-in replacement? Possibly, yes. But does that mean that many users would benefit in such a way where they would be happy to translate their existing code into that sort of subset or whatever it is? I’d say that that’s very likely for a very large group of users, maybe the majority of users. So I don’t want to get into a whole discussion about what, +you know, what this is, whether it is a subset, a super set, the full syntax, something like that. Is the pretty much not going to be the full syntax of TypeScript. That’s what I would easily be able to tell you. And it’s probably not going to be the full syntax of necessarily any -- well, anyway, I don’t want to make a definitive statement there. DE: I understand that people are concerned about these differences making it unadoptable, but I want to give a recent example in history where adoption was low-cost. There was some part TypeScript syntax around casting that just didn’t work with respect to JSX, another extension, and so they made a new version, which is TSX, which has different casting syntax. DRR can confirm this, but I don’t think TypeScript users are upset about the missing old cast syntax. As long as they have ways to do the things they’re trying to do, and as long as the transition isn’t that arduous, as long as there’s mostly compatibility, then these things can be worked through. With respect to TSX, there are no long-term plans that I know of to drop TS. But when people use .TSX, they don’t really miss any TS construct. The hope is with type annotations people would be at the points where they can adopt it if they want to and they wouldn’t miss too much the missing TypeScript features. That’s the goal in designing the grammar. @@ -999,30 +706,19 @@ WH: But that’s not really addressing my question. DRR: The goal of this proposal was not to bring all of TypeScript into ECMAScript. -DE: There are pretty few omissions. One omission is namespaces, which I think we have a -clear alternative, to which is objects literals, which doesn’t do things the same way, but gets -a lot of the same things done. Another one is enums, which, you know, also debatably could be -largely served by object literals as well. Interfaces are included–they’re erased. +DE: There are pretty few omissions. One omission is namespaces, which I think we have a clear alternative, to which is objects literals, which doesn’t do things the same way, but gets a lot of the same things done. Another one is enums, which, you know, also debatably could be largely served by object literals as well. Interfaces are included–they’re erased. DRR: Parameter properties. -DE: Parameter properties. This is something I want to get to committee, TypeScript has a -shorthand for when you have a constructor, you could declare a parameter public or private, -which makes it a field. This is something that we’ve talked about over years, and in TC39 back -when we were adding fields, it would be great to have a way that your constructor initializes a field by a parameter more tersely. +DE: Parameter properties. This is something I want to get to committee, TypeScript has a shorthand for when you have a constructor, you could declare a parameter public or private, +which makes it a field. This is something that we’ve talked about over years, and in TC39 back when we were adding fields, it would be great to have a way that your constructor initializes a field by a parameter more tersely. -RPR: I was going to say, Waldemar, to your question, this subset that is possible with just -purely, you know, JavaScript plus a few erased type, at Bloomberg, we’ve been using that kind -of subset, which is basically TypeScript minus the three features that DE just listed, -and we’ve found that we’ve been able to build, you know, a code base with millions of lines of -code, fully functional, getting, you know, 99.9% of the value of TypeScript without using those -extra parts. So even if it’s not the 100% TypeScript that you have today, it is something that -I think a huge number of people could use it and be happy about it. +RPR: I was going to say, Waldemar, to your question, this subset that is possible with just purely, you know, JavaScript plus a few erased type, at Bloomberg, we’ve been using that kind of subset, which is basically TypeScript minus the three features that DE just listed, +and we’ve found that we’ve been able to build, you know, a code base with millions of lines of code, fully functional, getting, you know, 99.9% of the value of TypeScript without using those extra parts. So even if it’s not the 100% TypeScript that you have today, it is something that I think a huge number of people could use it and be happy about it. WH: Are you using the same syntax as TypeScript? -RPR: Yes, it’s the TypeScript syntax minus the syntax for these three features that are going to -have some kind of runtime effect. +RPR: Yes, it’s the TypeScript syntax minus the syntax for these three features that are going to have some kind of runtime effect. WH: Given some of the examples in the presentation, I can’t see how that could be true. @@ -1030,77 +726,42 @@ DE: Could you elaborate on that? WH: Examples given in the presentation where the same syntax means something different in TypeScript and ECMAScript. -DRR: There are cases in which TypeScript preference to parse a certain way that ECMA does today. -The easiest example is in the example we were talking about with type arguments, in which you -provide a less than a set of types and then a less than operator and a token and a greater than operator. Those -are places in which there would be a divergent because we could not break existing ECMAScript -code. In those cases, we can do the same thing can certain syntaxes, certain tokens, and in -those cases, when ECMAScript itself adds those tokens to that syntax, TypeScript itself would -adapt to that as well. So we would add, for example, this ::<` operator -that has been presented in this presentation, if that were to be added to JavaScript and to -ECMAScript, TypeScript would also adopt that syntax. So that’s one example in which if -ECMAScript says it’s going to add these certain syntaxes, if it doesn’t conflict -- basically, -it doesn’t conflict with TypeScript, it will just work in TypeScript and in other cases, yes, -there is a divergence, but for all intents and purposes, nobody will write in that way because -typically it’s a type checking error or something like that. So no one really misses the -ability to have like a less than followed by a greater than operator. +DRR: There are cases in which TypeScript preference to parse a certain way that ECMA does today. +The easiest example is in the example we were talking about with type arguments, in which you provide a less than a set of types and then a less than operator and a token and a greater than operator. Those are places in which there would be a divergent because we could not break existing ECMAScript code. In those cases, we can do the same thing can certain syntaxes, certain tokens, and in those cases, when ECMAScript itself adds those tokens to that syntax, TypeScript itself would adapt to that as well. So we would add, for example, this ::<` operator that has been presented in this presentation, if that were to be added to JavaScript and to ECMAScript, TypeScript would also adopt that syntax. So that’s one example in which if ECMAScript says it’s going to add these certain syntaxes, if it doesn’t conflict -- basically, +it doesn’t conflict with TypeScript, it will just work in TypeScript and in other cases, yes, +there is a divergence, but for all intents and purposes, nobody will write in that way because typically it’s a type checking error or something like that. So no one really misses the ability to have like a less than followed by a greater than operator. -JWK: Yeah, I’m also thinking we should try to do it with something like console dev tools or a -developer mode instead of directly shipping this into the language. +JWK: Yeah, I’m also thinking we should try to do it with something like console dev tools or a developer mode instead of directly shipping this into the language. -EAO: I voiced this also on the proposal’s community call, but looking at TypeScript, Flow, Hegel, and other type systems, these are very clearly communicating that developers have a need and want to have type information available when they’re writing JavaScript. Flow and TypeScript are some of the biggest solutions for this that we currently have, and as on this slide you have up here now, “we are evolving the syntax based on the needs of multiple type systems to ease migration and unify JavaScript.” The current approach that this proposal seems to be taking is that, okay, we have these existing decent solutions like TypeScript in particular with a large user base, how can we account for the specific needs that they have and incorporate those into ECMAScript? +EAO: I voiced this also on the proposal’s community call, but looking at TypeScript, Flow, Hegel, and other type systems, these are very clearly communicating that developers have a need and want to have type information available when they’re writing JavaScript. Flow and TypeScript are some of the biggest solutions for this that we currently have, and as on this slide you have up here now, “we are evolving the syntax based on the needs of multiple type systems to ease migration and unify JavaScript.” The current approach that this proposal seems to be taking is that, okay, we have these existing decent solutions like TypeScript in particular with a large user base, how can we account for the specific needs that they have and incorporate those into ECMAScript? -EAO: This seems like only one possible solution to the motivation and to the question that we’ve previously accepted here for Stage 1. Another way of approaching this could be to identify that, yes, we recognize that there is a potential need for no-runtime-impact typing in JavaScript. Could we solve this problem not necessarily by giving space to specific current solutions, but by identifying what we could add to the ECMAScript syntax that could be parsed easily as comments? This way we wouldn’t end up, for example, with token soup, but we could create the potential for the world that we want to exist rather than the world where we currently are? So my question is, is there any interest among the people that are championing this proposal to investigate this sort of a possibility or is it strictly about finding a way of making sure that what is currently available in TypeScript and what is currently available in Flow or a subset of these are made parsable directly as ECMAScript? +EAO: This seems like only one possible solution to the motivation and to the question that we’ve previously accepted here for Stage 1. Another way of approaching this could be to identify that, yes, we recognize that there is a potential need for no-runtime-impact typing in JavaScript. Could we solve this problem not necessarily by giving space to specific current solutions, but by identifying what we could add to the ECMAScript syntax that could be parsed easily as comments? This way we wouldn’t end up, for example, with token soup, but we could create the potential for the world that we want to exist rather than the world where we currently are? So my question is, is there any interest among the people that are championing this proposal to investigate this sort of a possibility or is it strictly about finding a way of making sure that what is currently available in TypeScript and what is currently available in Flow or a subset of these are made parsable directly as ECMAScript? DE: Sorry, can you restate the question? -EAO: When you are looking for a potential syntax to propose for this proposal, -are you considering at all the possibility of finding a minimal minimal syntax that would -quite probably be incompatible with current existing type systems, but which -would be much, much easier for a parser to parse as a comment and ignore? +EAO: When you are looking for a potential syntax to propose for this proposal, +are you considering at all the possibility of finding a minimal minimal syntax that would quite probably be incompatible with current existing type systems, but which would be much, much easier for a parser to parse as a comment and ignore? -DE: To check if I understand your question, you’re asking: “if we take the proposal to be motivated in -general, then could we make the syntax much simpler, reducing implementation burden?”. That’s something interesting to consider. I don’t think it’s been entirely ruled out. The tradeoff is adoption: how adoptable will it be in practice. You know, we’re guiding a living ecosystem. We’re not designing something in a vacuum. That’s a general thing for TC39, not specific to this proposal. So we’re still discussing this kind of thing and issues about whether the grammar should be much more minimal, but I am a little skeptical that this will be possible -- DRR, do you have any thoughts? +DE: To check if I understand your question, you’re asking: “if we take the proposal to be motivated in general, then could we make the syntax much simpler, reducing implementation burden?”. That’s something interesting to consider. I don’t think it’s been entirely ruled out. The tradeoff is adoption: how adoptable will it be in practice. You know, we’re guiding a living ecosystem. We’re not designing something in a vacuum. That’s a general thing for TC39, not specific to this proposal. So we’re still discussing this kind of thing and issues about whether the grammar should be much more minimal, but I am a little skeptical that this will be possible -- DRR, do you have any thoughts? -DRR: I mean, the initial question, is there a limited syntax. We’re trying to keep it as -reasonable as possible without, like, having everything. That said, everything we’ve added to -TypeScript was added for a reason. If you ask me, can we come up with something that is much more minimal that doesn’t have all these parser gotchas, it’s sort of hard to say, right? One of the reasons that we’re coming here with this proposal is because jsdoc is a bit cumbersome to write and we would prefer to not have users need to use that syntax. But, you know, I think any feedback that could keep it much more scoped and reasonable without tradeoff developer experience, we’d like to hear as part of this proposal too. It’s hard for me to say we would want to give up so much. +DRR: I mean, the initial question, is there a limited syntax. We’re trying to keep it as reasonable as possible without, like, having everything. That said, everything we’ve added to TypeScript was added for a reason. If you ask me, can we come up with something that is much more minimal that doesn’t have all these parser gotchas, it’s sort of hard to say, right? One of the reasons that we’re coming here with this proposal is because jsdoc is a bit cumbersome to write and we would prefer to not have users need to use that syntax. But, you know, I think any feedback that could keep it much more scoped and reasonable without tradeoff developer experience, we’d like to hear as part of this proposal too. It’s hard for me to say we would want to give up so much. -WH: I just wanted to say that I’m also interested in much more minimal syntaxes which -leverage the ECMAScript grammar rather than trying to define a totally separate type syntax. +WH: I just wanted to say that I’m also interested in much more minimal syntaxes which leverage the ECMAScript grammar rather than trying to define a totally separate type syntax. DE: I was a little surprised when I saw how large the syntax was, that the TypeScript team had proposed. But when they showed me example cases of exactly why certain keywords had to be in grammar, it really did seem well-motivated to me. For example, there are certain kinds of type operators that take arguments and then others that don’t, and they just end up needing to be in the grammar, unless we make a sort of radical change. Maybe we should be considering such radical changes. My initial hope was that we could reach both of these goals at the same time as keeping the grammar minimal and simultaneously largely compatible with existing type systems, but now, I’m pretty convinced that they don’t quite match up. The grammar is not *infinitely* huge. -KG: Yeah. This is mostly a response to something DE said earlier about CSS and JavaScript -moving to not needing tools to author, but, like, the whole point of this proposal is that you -still need a tool. I appreciate the goal of wanting to copy/paste stuff from your editor -into the console and run it. The goal of not wanting to have a tool seems like it’s obviously -out. So the question is just, like, given that you already have TypeScript running somewhere, -how much additional burden is it to have to specifically run a tool to strip types before -loading it into the browser as a file, because we could solve the console separately, and given -the amount of benefit that brings for the costs of not actually doing all of -TypeScript because there will be these edge cases, the empirical prediction that we will end up -in a world where you don’t have to do that step I don’t know, I’m not convinced of that -prediction. Given the tradeoffs here. - -DE: I mean, there’s lots of different scenarios. Your type checking can often take place in an -IDE. Your build step may be just when you’re moving to production and not when you’re -debugging. But there are just many different places where JavaScript code gets used, and -assembling the build pipeline for every single one of those becomes not always the easiest. - -KG: Like, there’s two. Either you’re copy/pasting stuff out of you your editor or you’re -running files. I’m not aware of another way of running JavaScript. If you’re copy/pasting -stuff. +KG: Yeah. This is mostly a response to something DE said earlier about CSS and JavaScript moving to not needing tools to author, but, like, the whole point of this proposal is that you still need a tool. I appreciate the goal of wanting to copy/paste stuff from your editor into the console and run it. The goal of not wanting to have a tool seems like it’s obviously out. So the question is just, like, given that you already have TypeScript running somewhere, +how much additional burden is it to have to specifically run a tool to strip types before loading it into the browser as a file, because we could solve the console separately, and given the amount of benefit that brings for the costs of not actually doing all of TypeScript because there will be these edge cases, the empirical prediction that we will end up in a world where you don’t have to do that step I don’t know, I’m not convinced of that prediction. Given the tradeoffs here. + +DE: I mean, there’s lots of different scenarios. Your type checking can often take place in an IDE. Your build step may be just when you’re moving to production and not when you’re debugging. But there are just many different places where JavaScript code gets used, and assembling the build pipeline for every single one of those becomes not always the easiest. + +KG: Like, there’s two. Either you’re copy/pasting stuff out of you your editor or you’re running files. I’m not aware of another way of running JavaScript. If you’re copy/pasting stuff. DE: There’s a lot of ways of running files. -KG: Yes, but a tool which just strips types is effectively instantaneous and produces files, so if you’re -running files anyway, you can still run files. The cost of not having to do esbuild --watch - -If it was the only tool you had to use, I could see the argument. But the whole point of this -proposal is you already have to be using tools. Maybe they’re built into your IDE. And given -that you are already using tools, having one that is stripping types is not that bad. -It’s not as nice for copying and pasting stuff into the console, but, like, copy/pasting stuff -into the console could be solved in other ways. +KG: Yes, but a tool which just strips types is effectively instantaneous and produces files, so if you’re running files anyway, you can still run files. The cost of not having to do esbuild --watch - +If it was the only tool you had to use, I could see the argument. But the whole point of this proposal is you already have to be using tools. Maybe they’re built into your IDE. And given that you are already using tools, having one that is stripping types is not that bad. +It’s not as nice for copying and pasting stuff into the console, but, like, copy/pasting stuff into the console could be solved in other ways. DE: I’ll kind of wonder if people have seen all the blog posts that are saying, “Why I dropped TypeScript and went to “JavaScript” (often with jsdoc comments) instead”. @@ -1110,140 +771,73 @@ DE: Okay, but there is more than just that. KG: Like, it did not -- I agree that some people experience this as a pain point. -MAH: Yeah, I just wanted to say really quickly, it was just mentioned right now, an IDE is a tool, -yes. But it’s a different tool than a compiler that changes what you’re running. I just want -to be able to run the code that I authored without having to run a compilation step. And the -web is not the only platform running JavaScript. Not all environments need to have a -compilation step to run code. I just want to be able to pull dependencies and run them, and -whatever -- whatever type system they are, like, I don’t want to have to run compilation step -before publishing my dependencies. Basically wants to be able to run what I write. - -KG: Okay. The point of my topic was just this does not move us to a world where you don’t -have tools. It moves us to a world maybe where you have an IDE, but you don’t want to use it -as a compiler for some reason and you now don’t have to. I agree that is a change from the -current world, it’s just not at all a world where there’s no tools. - -LCA: So yeah, I can comment on this too. I don’t think the intention of this, like, I’m not one -of champions, but from the outside, it’s not too move to a world that has no tools but to move -to a world where you need less tools in the majority of cases, and I think, like, yes, it is -true that your IDE will still type check, and, like, for production, whether you run a compiler -over this code that will strip out types that will do bundling and all this type of stuff. But -it is not as easy as, say, running `esbuild --watch` and everything works. This outputs things into -a different directory and you now, from your HTML don’t reference your -- the JS source -code you write, but a different JavaScript source code that is generated somewhere, if you want -to publish this onto some Web server, whatever, it becomes more complicated. There’s -- -there’s like many layers of abstractions between you strip out the types and you then being -able to actually use that code. Like, yeah, it’s not non-trivial to do this. And like we see -this because there’s very significant efforts in many, many places to get rid of this, like, -problem. Like, Deno runs TypeScript out of the box but performing this type stripping thing -beforehand, and this is a way you can do this. But this is also not ideal because this means -that, like, you can’t write some code for dino and expect it to just work in node without -having to use some other compilation stuff and you can’t run this in the browser directly. And -while this really nice experience for Deno and nice experience if you’re using tsnode, it’s -still not a great experience if you’re developing for the browser. I think what this propose -seasonal getting at is getting that experience that you get when you’re using tsnode or deno -ore or something like that to have developers that write things for the web also have that -experience. - -KG: Part of what I wanted to say was - I guess this was my next topic, but I will sort of combine them. The grammar is not proposed to be just TypeScript. Like, it cannot be current TypeScript for -reasons we’ve discussed. It also can’t be JSX for other reasons. So this does benefit you in -some cases if you’re doing something sufficiently simple. But if you’re doing something -sufficiently simple, the experience is already simple. If you’re doing a more complicated project -you are not going to be saved by this, because you are doing something more -complicated anyway. - -KG: Like, if you’re using JSX, this gives you no benefit, so you’re going to want another tool -anyway. If you’re doing something that is complicated enough to -- that this would be of -significant benefit, it’s unlikely to be able to be something that you can make use of. - -LCA: So you’ve used simple twice in that thing, and I think those are two different simple and I -want to respond to each of them individually. The simple in this is, like, only useful for -simple projects I strongly disagree with. There’s very complicated projects that do not use -JSX and do not use emit-driven TypeScript syntax. For example, as RPR mentioned earlier, a -significant amounts of code written inside Bloomberg, and like -- yeah, I think that is just -not true. And then simple as in it is simple to set this up to do type stripping or -compilation, it may be simple for you, but there’s a very -- like, there’s a very significant -hurdle to A, newcomers of JS and also people who don’t have very advanced build -systems set up within their company that will, like, automate this for them or do this in some -very easy way. There’s very significant hurdles to do this for many people. - -KG: I didn’t mean to claim it was unambiguously simple to make use of TypeScript right now. -But you have to be making use of TypeScript to get any value from this proposal, and if you are -going through the process of getting TypeScript set up, also having it do emit doesn’t add that -much complexity unless you are doing something more complicated. +MAH: Yeah, I just wanted to say really quickly, it was just mentioned right now, an IDE is a tool, +yes. But it’s a different tool than a compiler that changes what you’re running. I just want to be able to run the code that I authored without having to run a compilation step. And the web is not the only platform running JavaScript. Not all environments need to have a compilation step to run code. I just want to be able to pull dependencies and run them, and whatever -- whatever type system they are, like, I don’t want to have to run compilation step before publishing my dependencies. Basically wants to be able to run what I write. + +KG: Okay. The point of my topic was just this does not move us to a world where you don’t have tools. It moves us to a world maybe where you have an IDE, but you don’t want to use it as a compiler for some reason and you now don’t have to. I agree that is a change from the current world, it’s just not at all a world where there’s no tools. + +LCA: So yeah, I can comment on this too. I don’t think the intention of this, like, I’m not one of champions, but from the outside, it’s not too move to a world that has no tools but to move to a world where you need less tools in the majority of cases, and I think, like, yes, it is true that your IDE will still type check, and, like, for production, whether you run a compiler over this code that will strip out types that will do bundling and all this type of stuff. But it is not as easy as, say, running `esbuild --watch` and everything works. This outputs things into a different directory and you now, from your HTML don’t reference your -- the JS source code you write, but a different JavaScript source code that is generated somewhere, if you want to publish this onto some Web server, whatever, it becomes more complicated. There’s -- +there’s like many layers of abstractions between you strip out the types and you then being able to actually use that code. Like, yeah, it’s not non-trivial to do this. And like we see this because there’s very significant efforts in many, many places to get rid of this, like, +problem. Like, Deno runs TypeScript out of the box but performing this type stripping thing beforehand, and this is a way you can do this. But this is also not ideal because this means that, like, you can’t write some code for dino and expect it to just work in node without having to use some other compilation stuff and you can’t run this in the browser directly. And while this really nice experience for Deno and nice experience if you’re using tsnode, it’s still not a great experience if you’re developing for the browser. I think what this propose seasonal getting at is getting that experience that you get when you’re using tsnode or deno ore or something like that to have developers that write things for the web also have that experience. + +KG: Part of what I wanted to say was - I guess this was my next topic, but I will sort of combine them. The grammar is not proposed to be just TypeScript. Like, it cannot be current TypeScript for reasons we’ve discussed. It also can’t be JSX for other reasons. So this does benefit you in some cases if you’re doing something sufficiently simple. But if you’re doing something sufficiently simple, the experience is already simple. If you’re doing a more complicated project you are not going to be saved by this, because you are doing something more complicated anyway. + +KG: Like, if you’re using JSX, this gives you no benefit, so you’re going to want another tool anyway. If you’re doing something that is complicated enough to -- that this would be of significant benefit, it’s unlikely to be able to be something that you can make use of. + +LCA: So you’ve used simple twice in that thing, and I think those are two different simple and I want to respond to each of them individually. The simple in this is, like, only useful for simple projects I strongly disagree with. There’s very complicated projects that do not use JSX and do not use emit-driven TypeScript syntax. For example, as RPR mentioned earlier, a significant amounts of code written inside Bloomberg, and like -- yeah, I think that is just not true. And then simple as in it is simple to set this up to do type stripping or compilation, it may be simple for you, but there’s a very -- like, there’s a very significant hurdle to A, newcomers of JS and also people who don’t have very advanced build systems set up within their company that will, like, automate this for them or do this in some very easy way. There’s very significant hurdles to do this for many people. + +KG: I didn’t mean to claim it was unambiguously simple to make use of TypeScript right now. +But you have to be making use of TypeScript to get any value from this proposal, and if you are going through the process of getting TypeScript set up, also having it do emit doesn’t add that much complexity unless you are doing something more complicated. DE: I would love to hear more about the experiences of Deno, because I think that provides motivation in itself. -JWK: In my experience, when I want to demo something in the console, I will not write TypeScript -syntax at the first time, so this is very easy, but the hard part is JSX, you need a way more -template code for this, so I think maybe JSX is more valuable. +JWK: In my experience, when I want to demo something in the console, I will not write TypeScript syntax at the first time, so this is very easy, but the hard part is JSX, you need a way more template code for this, so I think maybe JSX is more valuable. -EAO: Yeah, I want to echo what Kevin said. A lot of what he stated, he stated, better than I -think I could have. On exactly the concerns I also have on this front, in that if you are -doing something more than a toy problem with something like TypeScript, you’re going to be -using features that will need a build step of some sort. So the utility here will be much -less. +EAO: Yeah, I want to echo what Kevin said. A lot of what he stated, he stated, better than I think I could have. On exactly the concerns I also have on this front, in that if you are doing something more than a toy problem with something like TypeScript, you’re going to be using features that will need a build step of some sort. So the utility here will be much less. -KG: To be clear, I don’t want make the claim that every significant project is complicated -in a way that they wouldn’t get any benefit from this. Just that many of them are complicated in a way -that they wouldn't benefit from this. The set of people that we are helping gets pretty small when you consider all of the people that it doesn’t work for or doesn’t provide significant benefit to. +KG: To be clear, I don’t want make the claim that every significant project is complicated in a way that they wouldn’t get any benefit from this. Just that many of them are complicated in a way that they wouldn't benefit from this. The set of people that we are helping gets pretty small when you consider all of the people that it doesn’t work for or doesn’t provide significant benefit to. -MAH: I think that’s not true. I think any library author, and, like, there are a lot of large -projects that would benefit from this. Agoric is large and complex and would definitely -benefit from this. +MAH: I think that’s not true. I think any library author, and, like, there are a lot of large projects that would benefit from this. Agoric is large and complex and would definitely benefit from this. -MAH: We want the code that is authored to be the code that executes. We -don’t want to have a compilation step. We do not want to have to audit what the compiler does -exactly. And audit two set of file on what was authored and lose the context of the typing by -auditing the generated files. +MAH: We want the code that is authored to be the code that executes. We don’t want to have a compilation step. We do not want to have to audit what the compiler does exactly. And audit two set of file on what was authored and lose the context of the typing by auditing the generated files. LCA: EAO, did you say this was for toy problems? EAO: That was a term I used, yes. -LCA: Okay, because I think that is, like -- like, you can call the Bloomberg terminal a toy -problem, sure, but it’s not true. I want to give some other context, the Deno standard -uses no JSX and is written entirely in TypeScript that would be supportable using this syntax. -And, like, we are not the only big standard library that does this. Node’s internal code -surely could use, like -- like, could be -- yeah, TypeScript there would be good. And, like, a lot -of server side code does not rely on JSX and does not need to rely on emit driven syntax -and there’s a lot of benefit there. Saying because this does not solve is JSX problem this is -not useful I think is, like, a total oversimplification and just, like is detached from reality -and I don’t think we should be making that statement. - -RPR: So I think what’s interesting here, just to reply to EAO and to KG, along the same -lines as LCA, is that a lot of the folk that have opted into this kind of mode at the moment -of having the types just as comments and to have this transparency between source and generated -is -- it’s not actually the beginners. It’s not the toy projects. It’s actually the really -large ones. So, for example, I mentioned Bloomberg. MAH’’s talked about his company. But also Svelte and webpack, these are actually some of the most advanced JS projects that have the most advanced build set-ups. They’re the ones that are preferring this easier to understand code. The value isn’t about being build-free or tool-free; that’s a red herring and not really realistic for the majority. It’s more about the incremental win, the marginal value that you get from this transparency and bringing source and JavaScript source and generated closer together. - -DE: My intention wasn’t to say that we wanted to be tool-free. There’s benefit for the input to tools to be JavaScript. There’s benefit from us as TC39 participating in the design of what many programmers use, and having that be an open process, rather than only participating in the design of the build output. - -JWK: If your code is for browsers, you won’t ship thousands of files, then you must use bundlers. If you are on the server, you have Deno or ts-node. I don’t think running the code unmodified is really a problem. +LCA: Okay, because I think that is, like -- like, you can call the Bloomberg terminal a toy problem, sure, but it’s not true. I want to give some other context, the Deno standard uses no JSX and is written entirely in TypeScript that would be supportable using this syntax. +And, like, we are not the only big standard library that does this. Node’s internal code surely could use, like -- like, could be -- yeah, TypeScript there would be good. And, like, a lot of server side code does not rely on JSX and does not need to rely on emit driven syntax and there’s a lot of benefit there. Saying because this does not solve is JSX problem this is not useful I think is, like, a total oversimplification and just, like is detached from reality and I don’t think we should be making that statement. + +RPR: So I think what’s interesting here, just to reply to EAO and to KG, along the same lines as LCA, is that a lot of the folk that have opted into this kind of mode at the moment of having the types just as comments and to have this transparency between source and generated is -- it’s not actually the beginners. It’s not the toy projects. It’s actually the really large ones. So, for example, I mentioned Bloomberg. MAH’’s talked about his company. But also Svelte and webpack, these are actually some of the most advanced JS projects that have the most advanced build set-ups. They’re the ones that are preferring this easier to understand code. The value isn’t about being build-free or tool-free; that’s a red herring and not really realistic for the majority. It’s more about the incremental win, the marginal value that you get from this transparency and bringing source and JavaScript source and generated closer together. + +DE: My intention wasn’t to say that we wanted to be tool-free. There’s benefit for the input to tools to be JavaScript. There’s benefit from us as TC39 participating in the design of what many programmers use, and having that be an open process, rather than only participating in the design of the build output. + +JWK: If your code is for browsers, you won’t ship thousands of files, then you must use bundlers. If you are on the server, you have Deno or ts-node. I don’t think running the code unmodified is really a problem. + ### Summary -- The champion group presented some more details about the progress of the type annotations proposal. -- The committee had significant concerns around the complexity of the grammar, and wondered whether it could be simpler. -- Committee members asked for more information about the motivation of the proposal, especially in understanding how this benefits developers given that separate type checking tools will still be needed. +* The champion group presented some more details about the progress of the type annotations proposal. +* The committee had significant concerns around the complexity of the grammar, and wondered whether it could be simpler. +* Committee members asked for more information about the motivation of the proposal, especially in understanding how this benefits developers given that separate type checking tools will still be needed. + ### Conclusion -- The proposal remains at Stage 1 and is expected to be discussed in future committee meetings, as well as in open community calls. -- Future investigation by the champion group will be around possible syntax simplifications. -- The champion group will think about the motivation and come back to the committee with potentially more information there +* The proposal remains at Stage 1 and is expected to be discussed in future committee meetings, as well as in open community calls. +* Future investigation by the champion group will be around possible syntax simplifications. +* The champion group will think about the motivation and come back to the committee with potentially more information there + ## Decimal: Stage 1 update and discussion Presenter: Jesse Alama - -- [proposal](https://github.com/tc39/proposal-decimal) -- [slides](https://docs.google.com/presentation/d/1xOvWslwKi6evMWMYk1PQv9H0IEIhsifHbEBh2BOqHa0/) - +* [proposal](https://github.com/tc39/proposal-decimal) +* [slides](https://docs.google.com/presentation/d/1xOvWslwKi6evMWMYk1PQv9H0IEIhsifHbEBh2BOqHa0/) JMN: Thanks, this is about the decimal proposal. Early stage proposal. I am Jesse. I am working on this with Bloomberg. I presented this in March and then in July. This is still Stage 1. Just to recap about the motivation for decimals. The main use case is dealing with quantities that require an exact representation, and typically use cases, money. And things like that. The difficulty today, if you want to work with money in JS, you can do some hack and represent your data in a different way. So instead, you drop the idea that there is a decimal point there and you multiply everything by 100. And you pretend they are integers. But that’s not necessarily the best thing because not every currency works with cents. And there’s no real good way to deal with binary floats (in this way) unless you use BigInt. So you can still run into difficulties then. JMN: There’s a number of decimal libraries out there. Not necessarily dozens, but high, single digits. 8 to 10 out there. I would say. -JMN: Some programmers maybe don’t know about the issues about binary floating point numbers and their lossy nature. So maybe they have no other alternative (but to use JS Numbers). Maybe they can’t use one of the libraries. They work with the JS Numbers and hope for the best. But you can get rounding errors and other issues when you use numbers in this way. The same goes with human-readable (units, such as) weight and distance and temperature. Things we work with in an everyday sense, binary representing point numbers are not the best representation. +JMN: Some programmers maybe don’t know about the issues about binary floating point numbers and their lossy nature. So maybe they have no other alternative (but to use JS Numbers). Maybe they can’t use one of the libraries. They work with the JS Numbers and hope for the best. But you can get rounding errors and other issues when you use numbers in this way. The same goes with human-readable (units, such as) weight and distance and temperature. Things we work with in an everyday sense, binary representing point numbers are not the best representation. JMN: The use cases for these things I have hinted at. Any kind of computations with human consumable numeric quantities generally require some kind of decimal representation. Data exchange, you imagine that a JavaScript engine is in the middle of two systems. Let’s say one of them or both can handle decimal numbers natively, but JS does not. This is an awkward situation to be in for sure. @@ -1251,7 +845,7 @@ JMN As you might imagine, there are front and back end scenarios. In the browser JMN: I will give a kind of overview in terms of code. That’s all we speak about here. It gives us a sense of where things might go with decimal. -JMN: Let’s get the total for a bill. We are all going for dinner tonight and probably, these days, all of us are tourists here. Except for a couple people. Right? Calculating a bill. We have some items (with a price). Look at the bottom of this. We have some price and quantity. We have some kind of tax. Notice there’s a string representation there. Not a JS number. I made up these numbers. These aren’t coming from some real world data. I am making things up. We just have to iterate over these things. We have to do multiple additions. Start with a 0 and we have to calculate this exactly. Very straightforward example. +JMN: Let’s get the total for a bill. We are all going for dinner tonight and probably, these days, all of us are tourists here. Except for a couple people. Right? Calculating a bill. We have some items (with a price). Look at the bottom of this. We have some price and quantity. We have some kind of tax. Notice there’s a string representation there. Not a JS number. I made up these numbers. These aren’t coming from some real world data. I am making things up. We just have to iterate over these things. We have to do multiple additions. Start with a 0 and we have to calculate this exactly. Very straightforward example. JMN: This (code sample) is a bit bulky and ugly. The time value of money, you have been to a bank and looked at a calculation for your home importing or something like that, you might have seen these formulas yourself. This involves some exponentiation: there's a `pow` down at the bottom, take a base number and raise to a power. Lots of divisions. Here, multiple applications and so on. We are getting into stuff using basic math here. Additions, multiplication. There’s advanced exponentiation. Wow. That’s fine. @@ -1259,7 +853,7 @@ JMN: I am going to try to make the case that raising things to exponents (is som JMN: (third code sample now) We have been running a survey for JavaScript for decimal. Use cases for their cases, in their apps. And one of the things we found is that some developers want to have a stepping up or down functionality in some kind of web app. They don’t want a step up or down functionality using binary floats, but exact representation here. Another example, we say step up a value. We want to start with 1.23. And we want to raise that up to some other slightly greater value. And so this is just some kind of imaginary thing that you might do here. You would add a certain power of 10, to a number or maybe subtract a certain power of 10. And you get something that starts with 1.23 and you say, go up to 1.2305. Or something like that. The main point here is that this is exact data and not approximation (with binary floats). A good approximation is sometimes not good enough with binary floats. -JMN: SQL has been ahead of the curve for 50 years—maybe not 50, let’s say 40—with the DECIMAL datatype. And any of those of you who have made some kind of web app that uses a connection to a database, where you have to plug-in and handle the DECIMAL type in SQL, you know about this. Imagine if we were to have decimals in JavaScript, we could improve our database connections by saying that the SQL DECIMAL type would move to decimals instead of strings or even worse, JS Numbers. Right? So then we could run some queries on – using the database connector here. Fetch things natively from the database where it is handling things with, and JavaScript we work with the confidence we are getting this right. +JMN: SQL has been ahead of the curve for 50 years—maybe not 50, let’s say 40—with the DECIMAL datatype. And any of those of you who have made some kind of web app that uses a connection to a database, where you have to plug-in and handle the DECIMAL type in SQL, you know about this. Imagine if we were to have decimals in JavaScript, we could improve our database connections by saying that the SQL DECIMAL type would move to decimals instead of strings or even worse, JS Numbers. Right? So then we could run some queries on – using the database connector here. Fetch things natively from the database where it is handling things with, and JavaScript we work with the confidence we are getting this right. JMN: Those are some – a handful of examples to make up. You can imagine a number of other ones. I thought I would present some of the current thinking about the proposal in the format of keep, drop and add. @@ -1268,28 +862,28 @@ JMN: As I mentioned, this is Stage 1. Not ready for Stage 2, there are a couple JMN: So as I have mentioned both in March and in July, we are learning towards having a data model here where decimal numbers are represented by IEEE754 Decimal128. This is a format that uses 128 bits for all values. Which means there’s a certain backing there; numbers don’t grow arbitrarily large. There’s always a maximum amount of space that can be used for any number value. -JMN: There was a discussion a long time ago—actually when this proposal was first discussed years ago— about what do we do with Decimal128? Because Decimal128, if you are informed about these things, takes the stance that it works with, say, 1.2 and 1.20 as distinct values. But we decided a long time ago that this is not going to be – a bit odd for many JavaScript developers. So we would work with normal JS values. Internally, implementation of this could use the full Decimal128. The only thing that would be emitted would be serialization, like `toString`. Behind the screens, you could have 1.20 but you would actually emit 1.2 if someone wanted a string representation. +JMN: There was a discussion a long time ago—actually when this proposal was first discussed years ago— about what do we do with Decimal128? Because Decimal128, if you are informed about these things, takes the stance that it works with, say, 1.2 and 1.20 as distinct values. But we decided a long time ago that this is not going to be – a bit odd for many JavaScript developers. So we would work with normal JS values. Internally, implementation of this could use the full Decimal128. The only thing that would be emitted would be serialization, like `toString`. Behind the screens, you could have 1.20 but you would actually emit 1.2 if someone wanted a string representation. JMN: The idea would have basic math only. Things like that are inherently inexact and probably won’t be there. So logarithms, single argument logarithms. Exponentiation, a single argument thing. Trig functions. These might be useful. And we have had some discussion here. But we are leaninging toward not including these. The difficulty is that Decimal would not likely be much better than the Math version of these things except yielding more digits. But do you really need, say, you the 25th digit of a logarithm? -JMN: The third bullet point here. What to do about things like not-a-number (NaN)? We would like to propose to keep the idea that if NaN, whatever the as a result of an operation, then just throw. This is not a value in our universe here. +JMN: The third bullet point here. What to do about things like not-a-number (NaN)? We would like to propose to keep the idea that if NaN, whatever the as a result of an operation, then just throw. This is not a value in our universe here. JMN: There are things that are being dropped based on feedback received from implementers since the July presentation. JMN: In earlier versions of this proposal, we were following the model of BigInt. So that was the initial thinking behind decimal. The idea is that decimal would be kind of another version of BigInt or like BigInt 2.0 you might think. But based on discussions, we have received feedback, operator overloading which are part of BigInt would be difficult and slow things down. And I think we should accept that reality. So the current proposal drops operator overloading. So, in other words, addition, multiple applications, less than, you might want to use when working with decimals, we propose would throw if any of the arguments was a decimal. JMN: Following up this BigInt thinking, the initial version of the proposal was there is new literal syntax here. There’s some discussion that you can find in GitHub about this stuff and I myself have presented this earlier. But again based on strong implementer feedback we decided to drop this. There’s more reasoning here. So the thinking is that if literal syntax were available, but operator overloading is not, this is an awkward situation. We could write these numbers, but not really keep using them in an ergonomic way. -Following the BigInt thinking, the initial thinking that we had was that there is a new primitive type here for decimals. But this – we have decided to drop this too based on strong implementer feedback. And one difficulty here is again following from the decision to not do operator overloading, if it doesn’t happen, having a new primitive type doesn’t have much added value there. +Following the BigInt thinking, the initial thinking that we had was that there is a new primitive type here for decimals. But this – we have decided to drop this too based on strong implementer feedback. And one difficulty here is again following from the decision to not do operator overloading, if it doesn’t happen, having a new primitive type doesn’t have much added value there. -JMN: What have we decided to add since last time? Based on some discussion with various stakeholders and people who are interested in these things, and also internally at Igalia, we decided to add more rounding modes. This is something that goes beyond IEEE 754. Previously, in early versions, you have seen me say, “let’s do it like `Math`”. And we used banker’s rounding only. And there’s no way to do any rounding. I was trying to keep it simple, but some developers pushed back on that and said, we need different ways of rounding. So we decided to try to align with Temporal and I NumberFormat and support that as well, which is something that IEEE 754 says we should support, but we’re going beyond that. +JMN: What have we decided to add since last time? Based on some discussion with various stakeholders and people who are interested in these things, and also internally at Igalia, we decided to add more rounding modes. This is something that goes beyond IEEE 754. Previously, in early versions, you have seen me say, “let’s do it like `Math`”. And we used banker’s rounding only. And there’s no way to do any rounding. I was trying to keep it simple, but some developers pushed back on that and said, we need different ways of rounding. So we decided to try to align with Temporal and I NumberFormat and support that as well, which is something that IEEE 754 says we should support, but we’re going beyond that. -JMN: We start to get to some of the meat of what he would like to talk about today. And not just me, but I would like to hear from you about some of the issues. In the July proposal, there was some discussion about what to do about positive and negative infinity and minus 0. My tendency and both the March and July updates was to drop these things, namely, if these things were to arise as the result after computation, then just throw. But what is interesting is that, in earlier plenary discussions, the support for the values received negative feedback. Again, the thinking is, or the mental model is, decimal just represents a finite value. So + and - infinity aren’t really there and -0 is just 0. So why are we talking about these things? +JMN: We start to get to some of the meat of what he would like to talk about today. And not just me, but I would like to hear from you about some of the issues. In the July proposal, there was some discussion about what to do about positive and negative infinity and minus 0. My tendency and both the March and July updates was to drop these things, namely, if these things were to arise as the result after computation, then just throw. But what is interesting is that, in earlier plenary discussions, the support for the values received negative feedback. Again, the thinking is, or the mental model is, decimal just represents a finite value. So + and - infinity aren’t really there and -0 is just 0. So why are we talking about these things? JMN: But I received the valid fedback, if we’re aiming for IEEE 754, then why are we dropping these things? Positive and negative infinity should be there, and minus 0 and NaN be there. If you want to really go all in. And I think that’s a valid point. Calculations would just work. No exceptions should be thrown. No nothing would get thrown. Weird values, sure, but nothing thrown. Closer to IEEE754. Also a valid point. -JMN: One con, here, the question here, for me, is that important part of a conformance? Does decimal even claim to be conformant or claim to be IEEE754 Decimal128 or are we being misled by that? +JMN: One con, here, the question here, for me, is that important part of a conformance? Does decimal even claim to be conformant or claim to be IEEE754 Decimal128 or are we being misled by that? -JMN: And here’s another thing that I would invite us to think about. I wonder whether developers would expect decimal to handle these weird values. The use cases for decimal, the ones motivating us and the ones we have seen in our developer survey, I think it’s fine to actually throw, if positive and negative infinity when they come up and minus 0 is 0. Think about it going to a cash register and you get a receipt that says NaN or negative infinity. You would ask for them a different receipt! That doesn’t quite match what your expectations would be then. +JMN: And here’s another thing that I would invite us to think about. I wonder whether developers would expect decimal to handle these weird values. The use cases for decimal, the ones motivating us and the ones we have seen in our developer survey, I think it’s fine to actually throw, if positive and negative infinity when they come up and minus 0 is 0. Think about it going to a cash register and you get a receipt that says NaN or negative infinity. You would ask for them a different receipt! That doesn’t quite match what your expectations would be then. JMN: Anyway, so that’s, again, my own tendency there, but I am trying to get feedback from you, the committee here, about these things. I don’t want to take some kind of single-sided stance here. @@ -1309,33 +903,33 @@ JMN: Just to be clear, I don’t want to close the door on a future in which, pe JMN: And adding some advanced functions could be in the cards. There’s one version thinking about decimals which is like math 2.0. I like that idea. But I think we don’t yet have the documented developer node for these things at the moment. -JMN: So that’s all. That’s all from me. I am curious to hear if there any thoughts about some of these issues that I myself still are unclear about, ideas I still struggle with because I can see different ways of going forward. The floor is yours. +JMN: So that’s all. That’s all from me. I am curious to hear if there any thoughts about some of these issues that I myself still are unclear about, ideas I still struggle with because I can see different ways of going forward. The floor is yours. . -CDA: Lots on the queue. DE is first. +CDA: Lots on the queue. DE is first. . -DE: Yeah. I see that a lot of things on the queue are about operator overloading or primitives. Let’s cover topics not related and then give my presentation about withdrawing operator overloading which I was hoping to leave for another meeting to give Time for other preparations. But I could cover it briefly within the timebox. And then go throw the queue on operator overloading. So JHD says, no. I would like to speak now. Go for it. +DE: Yeah. I see that a lot of things on the queue are about operator overloading or primitives. Let’s cover topics not related and then give my presentation about withdrawing operator overloading which I was hoping to leave for another meeting to give Time for other preparations. But I could cover it briefly within the timebox. And then go throw the queue on operator overloading. So JHD says, no. I would like to speak now. Go for it. . -JHD: Thank you. So we don’t need to get into the details. But without those things, which my intuition tells me, if we can’t have these things, we don’t have the proposal. The only thing without those things, now it’s a coordination point. But otherwise, it’s just putting a library into the spec. So, can you help me understand? Is there additional value beyond that as objects? +JHD: Thank you. So we don’t need to get into the details. But without those things, which my intuition tells me, if we can’t have these things, we don’t have the proposal. The only thing without those things, now it’s a coordination point. But otherwise, it’s just putting a library into the spec. So, can you help me understand? Is there additional value beyond that as objects? -DE: We put libraries into the spec. We were talking about adding chains into the spec. +DE: We put libraries into the spec. We were talking about adding chains into the spec. -JHD: Sure. +JHD: Sure. DE: What do you mean? -JHD: I am trying, numbers are such a fundamental thing. That we shouldn’t be putting them in the language unless they can be maximally ergonomic and usable. In this form, I fail to see, I hope, what the benefit would be without ergonomics. Without being primitives and having operator overloading, I don’t see any ergonomic usage. +JHD: I am trying, numbers are such a fundamental thing. That we shouldn’t be putting them in the language unless they can be maximally ergonomic and usable. In this form, I fail to see, I hope, what the benefit would be without ergonomics. Without being primitives and having operator overloading, I don’t see any ergonomic usage. JMN: Admittedly, these are less than ideal. Those (code samples) could be trimmed down quite a bit if these were literals and the operators there. You’re right. You would, I think it’s a bit of a negative way to put it to say that it embeds a standard library into the language. And I take DE’s point that itself is not invalid. Right? -JHD: And I don’t mean to imply negative stuff there. Many of my proposals are like (that). Numbers are a fundamental thing in all of our minds, like I feel like this is a different case. +JHD: And I don’t mean to imply negative stuff there. Many of my proposals are like (that). Numbers are a fundamental thing in all of our minds, like I feel like this is a different case. -DE: I am really having trouble understanding how your argument fits together. I mean, I understand the argument. It would be nice, because numbers are so fundamental and come up for them to have good ergonomics. The part I don’t understand where you say, it would not be worth adding to the language without this. Could you elaborate on that part of it? You have restated this statement. +DE: I am really having trouble understanding how your argument fits together. I mean, I understand the argument. It would be nice, because numbers are so fundamental and come up for them to have good ergonomics. The part I don’t understand where you say, it would not be worth adding to the language without this. Could you elaborate on that part of it? You have restated this statement. JHD: Is there something about the existing, typically when we add existing libraries it’s because the ergonomics of doing it, in user land, are worse or the performance is worse or there’s coordination problems around like we need everyone to be using the same format or the same symbol or whatever it is. So, when I hear about Decimals, the thing that immediately dominates my brain and gets me excited is canceled out by the lack of being a primitive and operating overloading. I am left wondering, what is the kind of iterative value-add compared to using an npm library. -DE: I don’t understand your criteria for library. Which does iterator chain fit? +DE: I don’t understand your criteria for library. Which does iterator chain fit? -JHD: Because we don’t have a pipeline or anything, it’s unergonomic to have a chain of things. That isn't an instance to throws. +JHD: Because we don’t have a pipeline or anything, it’s unergonomic to have a chain of things. That isn't an instance to throws. DE: No. I mean the iterator chain proposal that was concatenating iterators. That didn’t fit the three things you said. @@ -1343,198 +937,201 @@ JHD: You have to do the generator garbage that Michael showed on the slide DE: it’s hard to implement decimal from scratch. -JHD: You don’t have to implement that. You are saying because you could – +JHD: You don’t have to implement that. You are saying because you could – -DE: Yeah. That’s the alternative that you’re proposing. Isn’t it? +DE: Yeah. That’s the alternative that you’re proposing. Isn’t it? -JHD: Sure. I think that if – that in general, if the operation is very common, that – in the case of concatenating iterators, if you need to do it a lot, either don’t – find an alternative way not using iterators or pull in a library that abstracts over it. In this case, because it’s so hard to implement it yourself, they will pull in a library and since all the people who need the feature the decimal are using a library because there’s in way to implement this themselves, then what is the incremental difference between that and using this once it lands in the object – +JHD: Sure. I think that if – that in general, if the operation is very common, that – in the case of concatenating iterators, if you need to do it a lot, either don’t – find an alternative way not using iterators or pull in a library that abstracts over it. In this case, because it’s so hard to implement it yourself, they will pull in a library and since all the people who need the feature the decimal are using a library because there’s in way to implement this themselves, then what is the incremental difference between that and using this once it lands in the object – DE: It’s the thing you might write yourself. But not Temporal because you’re going to pull in a library for that. -JHD: Like Temporal or this, it’s impractical to write it yourself. +JHD: Like Temporal or this, it’s impractical to write it yourself. DE: Why does Temporal meet your requirements? -JHD: There are significant benefits – I don’t think they need to be benefits, but around coordination and with internalization data that don’t apply here. Again like – +JHD: There are significant benefits – I don’t think they need to be benefits, but around coordination and with internalization data that don’t apply here. Again like – -DE: Hold on a second. +DE: Hold on a second. -JHD: Can we please stop. It sounds like you are trying to pull in unrelated proposals in order to attack my argumentation style here. Because you find it inconsistent with my other ones. I am talking about this proposal and my position on other ones should not be relevant in this particular case. My argument – +JHD: Can we please stop. It sounds like you are trying to pull in unrelated proposals in order to attack my argumentation style here. Because you find it inconsistent with my other ones. I am talking about this proposal and my position on other ones should not be relevant in this particular case. My argument – -CDA: I am going to interrupt. We have a super large queue. I would like to move on to the next person. +CDA: I am going to interrupt. We have a super large queue. I would like to move on to the next person. -JHD: Yeah. I mean, I would love an explanation. If we need to move on. Go ahead. +JHD: Yeah. I mean, I would love an explanation. If we need to move on. Go ahead. CDA: Thanks. SFC? -SFC: I will be quick. In that, I had an issue open for a little while asking what is the performance improvement to get from this to web implementation. I have not seen this data yet. If we could have that data, it might really help a lot regarding JHD’s point on another point about the value add. +SFC: I will be quick. In that, I had an issue open for a little while asking what is the performance improvement to get from this to web implementation. I have not seen this data yet. If we could have that data, it might really help a lot regarding JHD’s point on another point about the value add. JMN: I still owe you that. I am fairly confident that an implementation of this will be quite a bit faster than userland. Mine (my NPM library) is working with strings, and there’s no way that some kind of – out of the box C or C++ library will be slower than that. But exact data is still missing. And you’re right. If we had the data that would support the argument. I mean, would that help, JHD, to say that using my decimal128 NPM packages is 1,000 times slower than just using some library? -JHD: Yeah. I mean – I think a concrete performance argument is a valued answer to my question, but I didn’t know if one existed, which is part of why I asked. +JHD: Yeah. I mean – I think a concrete performance argument is a valued answer to my question, but I didn’t know if one existed, which is part of why I asked. -JMN: Right. And so SFC is referring to an outstanding TODO on my part. I need to get to this. +JMN: Right. And so SFC is referring to an outstanding TODO on my part. I need to get to this. -WH: And in regards to JHD’s point about coordination, this library would be anti-coordination. I do quite a bit of stuff with math and if I were doing IEEE 754 math I could not use the library. This does not play well with NaNs. I’d also use things like trig functions and this does not support this. I would have to have two decimal libraries. +WH: And in regards to JHD’s point about coordination, this library would be anti-coordination. I do quite a bit of stuff with math and if I were doing IEEE 754 math I could not use the library. This does not play well with NaNs. I’d also use things like trig functions and this does not support this. I would have to have two decimal libraries. -JMN: Good question. I did hear that those kinds of use cases though would be atypical. I mean, in the survey data we have been gathering for a few years now, there’s been only a handful of people who have said, yes, I need to do trig or these kinds of things. I suppose the use cases exist. +JMN: Good question. I did hear that those kinds of use cases though would be atypical. I mean, in the survey data we have been gathering for a few years now, there’s been only a handful of people who have said, yes, I need to do trig or these kinds of things. I suppose the use cases exist. -API: I can speak to that a little bit. +API: I can speak to that a little bit. -JMN: Okay. Yeah. Go ahead. +JMN: Okay. Yeah. Go ahead. -API: I would say to Waldemar, I strongly believe it should be IEEE 754, that is what makes sense and one main reason for supporting everything like NaN and infinity and everything in this spec is that one of the main motivators for this and use cases is interplay with other languages. If you have a C++ library, wrapped into JavaScript, you’re getting these values from C++ or a language, you need to represent them as you get them in JavaScript. It’s not the result of an operation in JavaScript. It’s just crossing the language boundary. The same that double is taken from C++ in JavaScript. This needs to also be supported when crossing that boundary. At a similar point to what JHD was saying, you can’t easily take – use npm library while you’re writing native code. Bringing the values from pre-existing native code datatypes into JavaScript, you know, it’s – like if you have double in C++, would you represent that in JavaScript when you’re crossing the boundary? +API: I would say to Waldemar, I strongly believe it should be IEEE 754, that is what makes sense and one main reason for supporting everything like NaN and infinity and everything in this spec is that one of the main motivators for this and use cases is interplay with other languages. If you have a C++ library, wrapped into JavaScript, you’re getting these values from C++ or a language, you need to represent them as you get them in JavaScript. It’s not the result of an operation in JavaScript. It’s just crossing the language boundary. The same that double is taken from C++ in JavaScript. This needs to also be supported when crossing that boundary. At a similar point to what JHD was saying, you can’t easily take – use npm library while you’re writing native code. Bringing the values from pre-existing native code datatypes into JavaScript, you know, it’s – like if you have double in C++, would you represent that in JavaScript when you’re crossing the boundary? -DE: It sounds like arguing the point that we should include NaN? +DE: It sounds like arguing the point that we should include NaN? -API: That’s what he’s arguing. Creating an anticoordination point if you don’t support – +API: That’s what he’s arguing. Creating an anticoordination point if you don’t support – -DE: You’re agreeing with that point. We should add that? +DE: You’re agreeing with that point. We should add that? -API: And the third thing performance-ways, I mean more work on that, but anecdotally, when evaluating C++, the decimal types versus double, they are – on – the same order of magnitude as double. We were seeing times roughly 3X slower than double. Right? So there’s no chance I believe that a user land library would approach that. It’s slower than double because it isn’t running directly on the CPU – +API: And the third thing performance-ways, I mean more work on that, but anecdotally, when evaluating C++, the decimal types versus double, they are – on – the same order of magnitude as double. We were seeing times roughly 3X slower than double. Right? So there’s no chance I believe that a user land library would approach that. It’s slower than double because it isn’t running directly on the CPU – -JMN: I appreciate the point. The whole purpose of this discussion today is to try to get reasons for including things like NaN and whatnot. And I take the point, if it’s important to be able to slurp up values as is and handle them appropriately, we should support them at the time. That’s good. +JMN: I appreciate the point. The whole purpose of this discussion today is to try to get reasons for including things like NaN and whatnot. And I take the point, if it’s important to be able to slurp up values as is and handle them appropriately, we should support them at the time. That’s good. -SFC: Yeah. Just to list out some of the others: when we evaluate the 402 proposal, we put them against a list to consider whether they are motivated and in addition to the performance you mentioned, binary size and correctness are two more that could be motivators here. Use WebAssembly and I suspect a fast one in WebAssembly. Not – I don’t know what the delta is there, but pretty fast. But like it’s still too big or large. That’s something you could argue. And then correctness is like, well, userland library with the decimal have bugs and that’s another argument that could be made and a lot of these are Temporal arguments. For why we motivate Temporal. It would be nice to see the laid out more clearly. I do agree generally with the sentiment, it seems like the coordination point of a standard decimal is one of the main motivations right now, and it’s better to have more clarity on the other axis. But there’s more topics in the queue. +SFC: Yeah. Just to list out some of the others: when we evaluate the 402 proposal, we put them against a list to consider whether they are motivated and in addition to the performance you mentioned, binary size and correctness are two more that could be motivators here. Use WebAssembly and I suspect a fast one in WebAssembly. Not – I don’t know what the delta is there, but pretty fast. But like it’s still too big or large. That’s something you could argue. And then correctness is like, well, userland library with the decimal have bugs and that’s another argument that could be made and a lot of these are Temporal arguments. For why we motivate Temporal. It would be nice to see the laid out more clearly. I do agree generally with the sentiment, it seems like the coordination point of a standard decimal is one of the main motivations right now, and it’s better to have more clarity on the other axis. But there’s more topics in the queue. -CHU: So to reply to JHD. So what remains there, so I have the feeling that sometimes this gets framed as just needed for financial – for Bloomberg. This is not the case. So working with decimals, you need all in projects and I had the last meeting, I said, we need something, a thing with a slider. To calculate for this. So there is a clear demand for it. And it’s been stated. Batteries included. We don’t want to look for a library that obviously could do that, but it should come with the ecosystem. And performance, I don’t think that performance – I see there is potential, this the language for performance as well. This is not the driving factor for us. Actually, developing applications. So why do I want to choose? I don’t want to have to be in the choice of choosing a library. And then making potentially the wrong choice. So I just want to view something this I encounter every day. +CHU: So to reply to JHD. So what remains there, so I have the feeling that sometimes this gets framed as just needed for financial – for Bloomberg. This is not the case. So working with decimals, you need all in projects and I had the last meeting, I said, we need something, a thing with a slider. To calculate for this. So there is a clear demand for it. And it’s been stated. Batteries included. We don’t want to look for a library that obviously could do that, but it should come with the ecosystem. And performance, I don’t think that performance – I see there is potential, this the language for performance as well. This is not the driving factor for us. Actually, developing applications. So why do I want to choose? I don’t want to have to be in the choice of choosing a library. And then making potentially the wrong choice. So I just want to view something this I encounter every day. DE: Again, I am next in the queue. Performance is usually not the main factor. We care about performance of decimal operations but for a slider any time you are entering in a human-readable value int, your UI that might have a decimal point, decimal is the right datatype. Maybe some sliders are more like a ratio. But some sliders, if you have human-readable percentage, then that’s probably the right thing, to be a decimal. DE: I want to speak to the IEEE 754 issue. To the NaN question, if you have an arithmetic that will be an exception rather than returning NaN, you can implement your own thing around it that will probably get NaN. And that does have a mode for everything where NaN causes throwing. I don’t see any nonconformance here. This has much lower uptake than IEEE 754 binary floats. If you look at different language programs, nobody except for C uses IEEE 754 binary. Every programming language uses a random decimal format. And users don’t complain about this. They are all different. The people like having a decimal format and they don’t run into the edge cases. The important thing; having a way that you can write decimals that doesn’t error for the kinds of qualities that people typically run into, which typically fit within this 20 or 30 something significant digits. -DE: So yeah. On the queue, no way to resume from exemption. If you want to do arithmetic, with NaNs, you wrap at the point of arithmetic. So you can build a NaN on top if you are using a wrapper. I don’t think that conforming with a whole ecosystem where the entire world is using IEEE 754 decimal is the thing that’s going on in the world. We conform where people use decimal of a number of digits and this is a model of that. It’s a worked-out model. It’s conformant to have NaN throw. And yeah. +DE: So yeah. On the queue, no way to resume from exemption. If you want to do arithmetic, with NaNs, you wrap at the point of arithmetic. So you can build a NaN on top if you are using a wrapper. I don’t think that conforming with a whole ecosystem where the entire world is using IEEE 754 decimal is the thing that’s going on in the world. We conform where people use decimal of a number of digits and this is a model of that. It’s a worked-out model. It’s conformant to have NaN throw. And yeah. -WH: A lot of this is incorrect. It’s nonconformant to have all NaN throw. This comes up in various places, including intermediate results. For example, in evaluation of polynomials. You can raise NaN to the zeroth power to get a constant term of a polynomial. I suggest reading up on the how and why the IEEE spec is defined this way. We should not make changes like that. +WH: A lot of this is incorrect. It’s nonconformant to have all NaN throw. This comes up in various places, including intermediate results. For example, in evaluation of polynomials. You can raise NaN to the zeroth power to get a constant term of a polynomial. I suggest reading up on the how and why the IEEE spec is defined this way. We should not make changes like that. -SFC: Are we ready to move on to mine? Okay. Yes. TCQ, it died again. But yeah. Once trailing zeros, I wasn’t a part of this conversation that said we decided a long time ago not to have trailing zero zeros, but that’s something I feel strongly about. That we want that. So I would certainly hope that the door is not closed on having that be a part of the proposal because that’s, you know, definitely one of things that motivates from the Intl side. +SFC: Are we ready to move on to mine? Okay. Yes. TCQ, it died again. But yeah. Once trailing zeros, I wasn’t a part of this conversation that said we decided a long time ago not to have trailing zero zeros, but that’s something I feel strongly about. That we want that. So I would certainly hope that the door is not closed on having that be a part of the proposal because that’s, you know, definitely one of things that motivates from the Intl side. -WH: My reply to that: exposing cohort member choice would not give you trailing zeros the way you want. You wouldn’t get the effect you want from this. +WH: My reply to that: exposing cohort member choice would not give you trailing zeros the way you want. You wouldn’t get the effect you want from this. -JMN: He says the set of values that have the same mathematical value but with trailing zeros. +JMN: He says the set of values that have the same mathematical value but with trailing zeros. WH: And other very problematic side effects if we expose the cohort members. -MLS: In the slides you said that an operation has decimal, it would throw. Would you propose that it is implemented and we had a valueOf throwing or that the code in an engine would need to check if a decimal object it's dealing with? +MLS: In the slides you said that an operation has decimal, it would throw. Would you propose that it is implemented and we had a valueOf throwing or that the code in an engine would need to check if a decimal object it's dealing with? -JMN: I was probably thinking the second, but maybe it could work. +JMN: I was probably thinking the second, but maybe it could work. DE: I was thinking, the first. Checking in the upper ends would be expensive and unnecessary. I believe that’s what the semantics should be. -MF: We have had discussion that assumed that we – a lot of discussion that it is assumed that we have primitives off the table. As I understand, this was motivated by some requests from implementers previously. Can you reaffirm that stance and clarify motivation and we can reevaluate that and try to introduce primitives here? Is there anyone willing to speak to that? +MF: We have had discussion that assumed that we – a lot of discussion that it is assumed that we have primitives off the table. As I understand, this was motivated by some requests from implementers previously. Can you reaffirm that stance and clarify motivation and we can reevaluate that and try to introduce primitives here? Is there anyone willing to speak to that? SYG: Yeah. TCQ is not working right now. V8 reaffirms the stance in particular towards decimal. I think the quick recap is that for V8, our perception, BigInt has been poor, that we don’t want to do the same thing again and BigInt on paper has a bigger target audience who use it than decimal. We discussed it internally, and it failed for that, in terms of operator, and rolling a new primitive, we don’t want that for decimal. It does not clear the bar for adding a new primitive. And a new – and a new. We don’t want this separately from primitive because of the `===` hazard. So as it stands, the kind of complexity it incurs and the performance (cost) it incurs to all JavaScript programs, it means it is – we declare a very high bar to convince V8 that we want to operate at operator overflowing and decimal does not clear that, in our opinion. -MF: Can you clarify about the ROI of BigInt? What measurement are you using? +MF: Can you clarify about the ROI of BigInt? What measurement are you using? SYG: The amount of work that went into implementation, the cost that, performance cost on all JavaScript programs. The performance optimization work was not paid off in adoption. The main use of BigInt in the wild is scripts that try to hijack the CPU to mine crypto. -MLS: We have similar consensus. We did a lot for BigInt. And optimization and things like that. It affects the operators with numbers. +MLS: We have similar consensus. We did a lot for BigInt. And optimization and things like that. It affects the operators with numbers. -DLM: Yeah. In SpiderMonkey it is more or less the same story. It was very costly for us to implement BigInt. And we feel like there’s a very, very high bar for future new primitives. And I am not sure, I actually am now convinced having decimal is pretty useful. But we don’t feel it meets the bar for primitive. It has the potential to slow down every JavaScript program which is a pretty big thing to ask. +DLM: Yeah. In SpiderMonkey it is more or less the same story. It was very costly for us to implement BigInt. And we feel like there’s a very, very high bar for future new primitives. And I am not sure, I actually am now convinced having decimal is pretty useful. But we don’t feel it meets the bar for primitive. It has the potential to slow down every JavaScript program which is a pretty big thing to ask. -CDA: We have less than 10 minutes left. JMN:, can you see the queue or as it was, I don’t know, 5 minutes ago. 10 minutes ago. +CDA: We have less than 10 minutes left. JMN:, can you see the queue or as it was, I don’t know, 5 minutes ago. 10 minutes ago. -JMN: Yes. +JMN: Yes. -CDA: You want to prioritize any of the remaining topics or go to the next one? +CDA: You want to prioritize any of the remaining topics or go to the next one? -JMN: Yes. Give me a moment to catch up. +JMN: Yes. Give me a moment to catch up. -CDA: The queue just came back. +CDA: The queue just came back. JMN: I am looking at number 4. -SFC (on queue): Disagree with the mental model that decimal represents "a finite value". They represent "a list of decimal digits" +SFC (on queue): Disagree with the mental model that decimal represents "a finite value". They represent "a list of decimal digits" -SFC: Yeah. That's a lower priority. I can talk to you about that later. +SFC: Yeah. That's a lower priority. I can talk to you about that later. -CDA: Okay. Next would be Waldemar? +CDA: Okay. Next would be Waldemar? -WH: I already talked about the first point — we should conform to the IEEE standard and not produce results different from what that standard specifies. And the other point is, I am concerned that in the long term this will result in more than one decimal library in the ECMAScript spec. Looking at the code examples, the user ergonomics are poor. In the longer term, if we adopt this and then choose to improve ergonomics because of user studies or whatever, we will need to have two decimal libraries in the language and that would be rather problematic, the main problem being reference versus value semantics of decimal values. +WH: I already talked about the first point — we should conform to the IEEE standard and not produce results different from what that standard specifies. And the other point is, I am concerned that in the long term this will result in more than one decimal library in the ECMAScript spec. Looking at the code examples, the user ergonomics are poor. In the longer term, if we adopt this and then choose to improve ergonomics because of user studies or whatever, we will need to have two decimal libraries in the language and that would be rather problematic, the main problem being reference versus value semantics of decimal values. -JMN: Yeah. That’s right. But it seems that there needs to be a compromise here. We are getting strong signals from the implementers that adding these things with new values semantics is just – not going to work. +JMN: Yeah. That’s right. But it seems that there needs to be a compromise here. We are getting strong signals from the implementers that adding these things with new values semantics is just – not going to work. -WH: Keep it as an external library. There are other aspects, such as if you want to compute sine and cosine to higher than double precision. There are valid reasons to do such things. Most decimal libraries do that. And they’re part of the IEEE spec. +WH: Keep it as an external library. There are other aspects, such as if you want to compute sine and cosine to higher than double precision. There are valid reasons to do such things. Most decimal libraries do that. And they’re part of the IEEE spec. -JMN: Yeah. That’s true. But there are parts of the optional part of the spec. So there’s a must-implement and optional implement part of the spec. And anything that has to do with trigonometry is in the optional part of the spec. +JMN: Yeah. That’s true. But there are parts of the optional part of the spec. So there’s a must-implement and optional implement part of the spec. And anything that has to do with trigonometry is in the optional part of the spec. -WH: Which then creates a need for a second decimal library, which is a place I don’t want to end up in. +WH: Which then creates a need for a second decimal library, which is a place I don’t want to end up in. -DE: Yeah. So about IEEE 754, when I tried to research other programming languages, I found that the great majority did not use IEEE 754, such as SQL databases. I mean, I found little uptake probably because it was standardized so late. I am wondering where that claim comes from, that most things, libraries use this and in particular, if that’s true, we should be able to find examples of, many other languages having these multiple libraries. +DE: Yeah. So about IEEE 754, when I tried to research other programming languages, I found that the great majority did not use IEEE 754, such as SQL databases. I mean, I found little uptake probably because it was standardized so late. I am wondering where that claim comes from, that most things, libraries use this and in particular, if that’s true, we should be able to find examples of, many other languages having these multiple libraries. WH: SQL predates IEEE 754. Modern languages use this. -DE: I found C using IEEE 754 for decimal. Do you have another idea of a language that uses IEEE 754 decimal? +DE: I found C using IEEE 754 for decimal. Do you have another idea of a language that uses IEEE 754 decimal? -WH: This is not a productive discussion given that we have five minutes left. +WH: This is not a productive discussion given that we have five minutes left. -DE: Next thing. Yeah. I would really like to learn the background of this. I think it’s – I mean, JWK raised the point before, about how it would be nice if we could future proof the decimal object —future proof in quotes— to adding a primitive later potentially. And he pointed out it wouldn’t be complicated. Make sure that the valueOf and to primitive throw as we already should do for the exact reasons that MLS raised. These are wrappers for the primitive. All the operators will throw. So you will – it will be part of our broader pattern of taking something, throwing and not throwing, hoping that it works. +DE: Next thing. Yeah. I would really like to learn the background of this. I think it’s – I mean, JWK raised the point before, about how it would be nice if we could future proof the decimal object —future proof in quotes— to adding a primitive later potentially. And he pointed out it wouldn’t be complicated. Make sure that the valueOf and to primitive throw as we already should do for the exact reasons that MLS raised. These are wrappers for the primitive. All the operators will throw. So you will – it will be part of our broader pattern of taking something, throwing and not throwing, hoping that it works. CDA: SFC You’re the last one in the queue. - -SFC: [on queue: String.prototype.decimalAdd] Okay. Sure. So decimal – yeah. I think it’s something I had mentioned and it sounds like a joke, but not really that much because like, you know, the thing that I want and there’s discussion about this in the matrix, is like, it’s important to have a representation – a representation for how we express decimal values including with trailing zeros in ECMAScript and there isn’t that standard. Now, strings have triple equals that work. There are a lot of semantics that are nice. And if we were to say that, like, if you have a decimal and JavaScript, it is represented as a string that satisfies that regular expression? Right? And then we could still encode like, you know, operations that operate on the strings. And what this does is, they take the strings, turn them into whatever internal representation is the fastest, perform the math and turn them back. Right? It’s not super fast, but kind of solves the problems. We could even make special syntax. Like, not saying it’s great. But I am also not saying that it’s – if we are looking at the best of several bad options on the table, I don’t think it’s an option to take off the table necessarily. -DE: Reply to that on the queue. Yeah. I think that would be a pretty bad option. The reason, decimal is designed to will he, if you use in math operations, except for triple equals. And that’s critically important. If you have a decimal – something that represents a decimal, you would use + and - on it. If you use - on two strings, they'll be cast to numbers and get the wrong answer. If you use +, then you will get a different wrong answer. Maybe with two decimal points. Maybe not. If one doesn’t have a decimal part. Wrong answer. As tempting as it is, it uses operators. But this is the thing we should have type safety and making an instanceof a class would give us that runtime type safety. +SFC: [on queue: String.prototype.decimalAdd] Okay. Sure. So decimal – yeah. I think it’s something I had mentioned and it sounds like a joke, but not really that much because like, you know, the thing that I want and there’s discussion about this in the matrix, is like, it’s important to have a representation – a representation for how we express decimal values including with trailing zeros in ECMAScript and there isn’t that standard. Now, strings have triple equals that work. There are a lot of semantics that are nice. And if we were to say that, like, if you have a decimal and JavaScript, it is represented as a string that satisfies that regular expression? Right? And then we could still encode like, you know, operations that operate on the strings. And what this does is, they take the strings, turn them into whatever internal representation is the fastest, perform the math and turn them back. Right? It’s not super fast, but kind of solves the problems. We could even make special syntax. Like, not saying it’s great. But I am also not saying that it’s – if we are looking at the best of several bad options on the table, I don’t think it’s an option to take off the table necessarily. + +DE: Reply to that on the queue. Yeah. I think that would be a pretty bad option. The reason, decimal is designed to will he, if you use in math operations, except for triple equals. And that’s critically important. If you have a decimal – something that represents a decimal, you would use + and - on it. If you use - on two strings, they'll be cast to numbers and get the wrong answer. If you use +, then you will get a different wrong answer. Maybe with two decimal points. Maybe not. If one doesn’t have a decimal part. Wrong answer. As tempting as it is, it uses operators. But this is the thing we should have type safety and making an instanceof a class would give us that runtime type safety. -CDA: There is nothing else in the queue. We have 1 minute left. Any final thoughts? +CDA: There is nothing else in the queue. We have 1 minute left. Any final thoughts? JMN: Yeah. We – I will give a summary. ### Summary of Key Points + * The champion gave an update about the current status of the proposal. - * Decimal is based on IEEE 754 Decimal128 semantics, with an API based on a class and object instances, with no literal syntax. - * This design is based on feedback from V8 and SpiderMonkey that they strongly disprefer operator support for decimals, which was reaffirmed during the meeting. + * Decimal is based on IEEE 754 Decimal128 semantics, with an API based on a class and object instances, with no literal syntax. + * This design is based on feedback from V8 and SpiderMonkey that they strongly disprefer operator support for decimals, which was reaffirmed during the meeting. * The committee discussed the issue of IEEE 754 compliance or noncompliance and whether that’s a goal. * The committee also discussed whether we want some kind of more advanced math operators, like sine and cosine. * There is still some discussions that need to be had about this. There is no total consensus on these things yet. But there has been some progress in shared understanding. + ### Conclusion + * Decimal remains at Stage 1 + ## Joint iteration for Stage 1 -Presenter: Michael Ficarra (MF) -- [proposal](https://github.com/michaelficarra/proposal-joint-iteration) -- [slides](https://docs.google.com/presentation/d/18Xnd--QmYV8c-qw3tGe4zvlIfF5A-CdXr-qW1tW6j4o) +Presenter: Michael Ficarra (MF) +* [proposal](https://github.com/michaelficarra/proposal-joint-iteration) +* [slides](https://docs.google.com/presentation/d/18Xnd--QmYV8c-qw3tGe4zvlIfF5A-CdXr-qW1tW6j4o) -MF: This is joint iteration. Joint iteration is when we have 2 or more iterators that have values positionally aligned and we want to process those values that correspond to each other together. +MF: This is joint iteration. Joint iteration is when we have 2 or more iterators that have values positionally aligned and we want to process those values that correspond to each other together. So that’s the problem we are trying to solve here. The best way to do this today is unfortunate. This is basically the simplest thing, write a helper, it takes them and yields pairs of them. And makes sure that they end at the same time. And this is about the best you can do. This is solved in most languages and frameworks with a function called `zip()`. So the most likely shape that we could have is something also called `zip()`. Like this. There are options. A simple zip of two iterators or like var-arity zip, that’s all within our design space. -Also, it’s common to parameterize the function that zip uses. In the examples before, you take the corresponding values and tuple them. But you could pass a different function to possibly do something else. +Also, it’s common to parameterize the function that zip uses. In the examples before, you take the corresponding values and tuple them. But you could pass a different function to possibly do something else. So like, Math.max, will be called on them for you. This sometimes exists only on its own. zipWith being given Array.of is the same as zip. It’s possible that we have only zipWith and not zip. If you want to do something else then pass something else. -I mentioned this, but some other open question design space is, do we want to support an arbitrary number of iterators? And an iterable of iterators is possibly another option. If we support an arbitrary number of them, what do we do on 0 or 1? Permit those? Those are some questions we will have to answer. A notable downside of having a varargs version in the middle, if we want to have an options bag for some potential options, I will talk about in the future, it’s not a great API because your options bag is at the end. It’s not great. +I mentioned this, but some other open question design space is, do we want to support an arbitrary number of iterators? And an iterable of iterators is possibly another option. If we support an arbitrary number of them, what do we do on 0 or 1? Permit those? Those are some questions we will have to answer. A notable downside of having a varargs version in the middle, if we want to have an options bag for some potential options, I will talk about in the future, it’s not a great API because your options bag is at the end. It’s not great. Something that I had not seen when doing a review of other languages or libraries, but thought of during that review, is that if we have many different iterators, it can be confusing to have the inputs and outputs just positionally aligned. So if we pass them as named, we could also yield each element under that same name. There’s – this is risky in that there’s no prior art for this, but I think it is an improvement and somewhat related to problems we discussed in the past with Promise.all. -MF: Other considerations in this design space: what do we do with iterators that yield a different number of values? Some prior art has a "longest" version, most defaults to stopping when the first one has stopped, or "shortest". But it has options to stop when the last one has stopped. Yielding undefined or something like that for the values of the shorter ones. +MF: Other considerations in this design space: what do we do with iterators that yield a different number of values? Some prior art has a "longest" version, most defaults to stopping when the first one has stopped, or "shortest". But it has options to stop when the last one has stopped. Yielding undefined or something like that for the values of the shorter ones. Some of them have an option to pass a filler item. So instead of just yielding undefined, it yields the filter item or sometimes they allow passing multiple filters so that if you care about the type safety, you can have a filler for each iterator that matches that iterator's parameter type. There’s also strict variants which will throw if they don’t all end at the same time. Those are possibilities we could consider. MF: So here is a table I have created. This is prior art. Only with other programming languages. I will explain the columns first. -So language column here. Shortest, longest and privileged. This is like, you know, the function that does the "shortest" behaviour. This is the function that does the "longest" behaviour. "Privileged" is unique to Ruby, which is the only one that does this. This is the left one. Ruby zip has a left and right one. Whatever the length of the left, that’s when it ends. +So language column here. Shortest, longest and privileged. This is like, you know, the function that does the "shortest" behaviour. This is the function that does the "longest" behaviour. "Privileged" is unique to Ruby, which is the only one that does this. This is the left one. Ruby zip has a left and right one. Whatever the length of the left, that’s when it ends. "Strict" we explained earlier: it ensures they must end at the same time. "With" allows the program to parameterise the combining function. -All of these are assumed to support two sources, but only some support 3 or more. Some of them support 1 source and one supports zero sources. I made the same table with the JavaScript libraries -Interesting thing I noticed is that in an area of the – in a particular functional programming niche, the zip operation is just considered to be a special variadic version of map. So when we think of map, typically we think of a single iterator with a function of A to B. We could have a map operation on 2 iterators then it’s a function from A and B to C and so on. +All of these are assumed to support two sources, but only some support 3 or more. Some of them support 1 source and one supports zero sources. I made the same table with the JavaScript libraries Interesting thing I noticed is that in an area of the – in a particular functional programming niche, the zip operation is just considered to be a special variadic version of map. So when we think of map, typically we think of a single iterator with a function of A to B. We could have a map operation on 2 iterators then it’s a function from A and B to C and so on. So the typed versions of those, they have map2, map3, etc. In the untyped version, they make it variadic. It’s interesting, but it’s probably not a route we want to go with trying to unify those concepts in JavaScript. But it’s worth noting in the presentation. MF: here is the same table for a bunch of JS libraries that work on iterators. Notable things here, again, zip is the correct name here. I was also surprised to see that there was only one strict variant available. I was surprised to see that for the programming languages only one strict variant is available in Python. That’s probably not very popular or needed. -And I guess a thing I learned here is that when a library supports 0 sources, I guess there’s two possible things that it could produce: it could produce an empty iterator or an infinite iterator of 0-tuples. But it seems they all choose the former. +And I guess a thing I learned here is that when a library supports 0 sources, I guess there’s two possible things that it could produce: it could produce an empty iterator or an infinite iterator of 0-tuples. But it seems they all choose the former. So if we support 0 sources, we should probably follow that. -I went through the thoughts as I presented this. So that’s all I have to present. I would love to hear what is on the queue and possibly ask for Stage 1. +I went through the thoughts as I presented this. So that’s all I have to present. I would love to hear what is on the queue and possibly ask for Stage 1. -USA: Well, there is no queue. We can give it a minute. Okay. There is Dan Minor. +USA: Well, there is no queue. We can give it a minute. Okay. There is Dan Minor. -DLM: Sure. Thank you. That was a great presentation. I appreciate the time you put into that and evaluating different options. And yeah. This seems like a really great idea. We are positive about that in the SpiderMonkey team and yeah. -I guess that's what I had to say. Thanks. +DLM: Sure. Thank you. That was a great presentation. I appreciate the time you put into that and evaluating different options. And yeah. This seems like a really great idea. We are positive about that in the SpiderMonkey team and yeah. +I guess that's what I had to say. Thanks. -USA: Next we have Kevin. +USA: Next we have Kevin. KG: I also support. I want to mention that the Promise.all proposal that we had a few months ago that did something similar, switching on iterable vs bag, I love that idea. I would love to do that as well. That suggests the shape for the design where the first is iterable and then the overload where you can pass a bag. Of course that’s to be worked out later. But I really like that idea @@ -1542,8 +1139,7 @@ MF: That would mean you support what is on this slide as well as the third optio KG: Yes, exactly. -USA: Next, we have TAB who says they support and use zip in Python and agree with the analyst of -the use cases. Danel Ehrenberg would support and then LCA. +USA: Next, we have TAB who says they support and use zip in Python and agree with the analyst of the use cases. Danel Ehrenberg would support and then LCA. LCA: I also support this. I support both the named and the positional options. I think the positional one, that is the default because that is what most languages use. I also prefer the iter of iters in the first argument. So the third one here. And then possibly with the options black that you specify the map first and don’t have to have the separate zip and zip width and also have options such as strict or – whether you want to have longest and shortest and support all within the options bag. That seems nice to me. @@ -1562,36 +1158,33 @@ MF: Do we have consensus on Stage 1? USA: I think so. We only heard support. (several thumbs-ups in the room) + ### Summary of Key Points + * Joint iteration is the ability to “zip” two iterators, possibly mapping over them at the same time. * This need comes up all the time, and is proposed as a quick follow-on to iterator helpers, based on a detailed cross-language comparison. + ### Conclusion + * Consensus on Stage 1 for joint iteration + ## TDZ, what is it good for -Presenter: Shu-yu Guo (SYG) -- [proposal]() -- [slides](https://docs.google.com/presentation/d/1c-rhSUTQVNWD4DWgkNiC9tt50BruWDi7yRPllPHnff8/edit) +Presenter: Shu-yu Guo (SYG) +* [slides](https://docs.google.com/presentation/d/1c-rhSUTQVNWD4DWgkNiC9tt50BruWDi7yRPllPHnff8/edit) -SYG: This topic just to kind of head off some things, I expect this to be controversial. I’m not proposing an actual change here. I’m kind of going through some motivation for why it might be proposing a change in the future. But it’s maybe to elicit some responses and to get a temperature check and to get the discussion started on see how open we are to this kind of -thing. So the topic is TDZ, what is it good for? Reference to the original title of war and peace. So recap for what the temporal dead zone is, it’s the matrix channel where we have off topic discussions. Also to describe throwing semantics for uninitialized lexical bindings. +SYG: This topic just to kind of head off some things, I expect this to be controversial. I’m not proposing an actual change here. I’m kind of going through some motivation for why it might be proposing a change in the future. But it’s maybe to elicit some responses and to get a temperature check and to get the discussion started on see how open we are to this kind of thing. So the topic is TDZ, what is it good for? Reference to the original title of war and peace. So recap for what the temporal dead zone is, it’s the matrix channel where we have off topic discussions. Also to describe throwing semantics for uninitialized lexical bindings. This is semantics introduced in ES6 about the second part. What it is is basically when I say TDZ checks, I mean run time checks that throw when getting or setting an uninitialized lexical binding. Where be lexical bind and I mean a let or const than a bar. I have a let and a const binding in this. Until initialize the let or the const binding by evaluating its declaration so until evaluation reaches the point of let X or const Y, the name introduced by the binding is set to be in TDZ and if I touch it at all to get it or try to assign to it, I get a reference error at run time. In this example, if I touch X, by getting it or assigning to it, it throws. -After let X is evaluated, then I can assign to it. Similarly for Y, I can’t assign -to Y any way as a const, but if I get Y, before const Y is evaluated, then it throws. So the binding is in a temporal dead zone until – I don’t want to call it temporal. I wasn’t in the room but until evaluation reaches the declaration itself. So why does this exist? For DX reasons catches uses before defs and bad form for you to use something before you define it. -This was something that vars allowed and are initialized undefined because it used the name before you used the var and evaluated the var and universally agreed to be bad style and we shouldn’t allow that. Lets const bindings to be const in the way that you can’t observe them to have more than a single value. So const binding either throws when you access it or has the value it will always have. So those are nice properties that we get by having TDZ semantics. -So this talk I will talk about the performance const of TDZ and adoption problems that we have – that we are now seeing with the TDZ aspect of lexical bindings and the idea that I have to -maybe remove TDZ but we’ll see. So the performance const is fairly simple. - -The performance cost – the TDZ have a performance Congress const because you have to check and for CVAR undefined and -that’s it. No specialized uninitialized value that you have to check they’re in and throw if they’re uninitialized. And of the TDZ checks there are two classes I think. There are the ones easily statically eliminate and those that are track tickly hard to eliminate. For the easy stuff the intraprocedural uses are easy to analyze cheaply and eliminate the ones not necessary. You can use any kind of like use def or use chain analysis to figure out if the uses are dominated by a def or another use and trigger TDZ and eliminate the ones dominated. -The very simple example X used here is dominated by let X dominated meaning there is no control flow path that can reach the use of X without also going through the definition in which case if evaluation reaches X, then L must be already initiated and don’t need to emit run time to see if it is in fact initialized. There is gotcha that is because switches are weird because -you can jump into a switch case that has a let binding in it but then falls through to another case. But the other case is still jumpable directly there. You have the weird case and sometimes you don’t know until run time if a let binding is in in fact initialized. Those are fairly rare. People don’t do weird things like that. But that’s just to say not all intraprocedural user are easy to eliminate. Some can’t be. By and large we can do this cheaply and not worry about this. The checks that are hard to eliminate are the uses inside hoisted inner functions. So remember that function declarations themselves hoist. So in the -following example, you have a let X. In the source text, function – the function declaration of foo is after let X but the function declaration hoist definition and all to the top of the block. So the binding foo refers to the function and is usable before the definition of let X. -If foo escapes, you would have – we just have no idea if the use of X inside foo will be called before or after let X is evaluated. This kind of use is in general very difficult to analyze and eliminate because it requires full intraprocedural analysis. We have to know what is ally I can’t say to foo and where it flows to and how it gets called, we just don’t know. -Optimizations in the web browser engines must play for themselves because JavaScript is downloaded and executed end to end if we have an expensive analysis that is able to figure it out, it is not worth it because it is way more expense civil than the actual TDZ checks they eliminate. As a result we don’t try to eliminate this at all outside of the optimizing tier. -And we always take the damage for the performance cost of those TDZ checks up slot of web implementation cannot achieve performance parity with VARS and let and const binding fully require more work. Each check itself is not too bad. This is a death by a thousand cuts kind of thing. My claim is that it cannot achieve performance parity with var in practice for the reasons I’ve been describing and eliminate easy checks up front and eliminate more in optimizing tiers and a lot of code runs one and not hot hot and don’t reach the tiers and full -analysis is intraprocedural and too expensive to pay for itself. I have heard from GitHub posters that JSC doesn’t have this problem. I would like to understand more. In reading the web source code I see that JSC has TDZ checks and similar cheap elision analysis in the front end. It seems like they just do more work. +After let X is evaluated, then I can assign to it. Similarly for Y, I can’t assign to Y any way as a const, but if I get Y, before const Y is evaluated, then it throws. So the binding is in a temporal dead zone until – I don’t want to call it temporal. I wasn’t in the room but until evaluation reaches the declaration itself. So why does this exist? For DX reasons catches uses before defs and bad form for you to use something before you define it. +This was something that vars allowed and are initialized undefined because it used the name before you used the var and evaluated the var and universally agreed to be bad style and we shouldn’t allow that. Lets const bindings to be const in the way that you can’t observe them to have more than a single value. So const binding either throws when you access it or has the value it will always have. So those are nice properties that we get by having TDZ semantics. +So this talk I will talk about the performance const of TDZ and adoption problems that we have – that we are now seeing with the TDZ aspect of lexical bindings and the idea that I have to maybe remove TDZ but we’ll see. So the performance const is fairly simple. + +The performance cost – the TDZ have a performance Congress const because you have to check and for CVAR undefined and that’s it. No specialized uninitialized value that you have to check they’re in and throw if they’re uninitialized. And of the TDZ checks there are two classes I think. There are the ones easily statically eliminate and those that are track tickly hard to eliminate. For the easy stuff the intraprocedural uses are easy to analyze cheaply and eliminate the ones not necessary. You can use any kind of like use def or use chain analysis to figure out if the uses are dominated by a def or another use and trigger TDZ and eliminate the ones dominated. +The very simple example X used here is dominated by let X dominated meaning there is no control flow path that can reach the use of X without also going through the definition in which case if evaluation reaches X, then L must be already initiated and don’t need to emit run time to see if it is in fact initialized. There is gotcha that is because switches are weird because you can jump into a switch case that has a let binding in it but then falls through to another case. But the other case is still jumpable directly there. You have the weird case and sometimes you don’t know until run time if a let binding is in in fact initialized. Those are fairly rare. People don’t do weird things like that. But that’s just to say not all intraprocedural user are easy to eliminate. Some can’t be. By and large we can do this cheaply and not worry about this. The checks that are hard to eliminate are the uses inside hoisted inner functions. So remember that function declarations themselves hoist. So in the following example, you have a let X. In the source text, function – the function declaration of foo is after let X but the function declaration hoist definition and all to the top of the block. So the binding foo refers to the function and is usable before the definition of let X. +If foo escapes, you would have – we just have no idea if the use of X inside foo will be called before or after let X is evaluated. This kind of use is in general very difficult to analyze and eliminate because it requires full intraprocedural analysis. We have to know what is ally I can’t say to foo and where it flows to and how it gets called, we just don’t know. +Optimizations in the web browser engines must play for themselves because JavaScript is downloaded and executed end to end if we have an expensive analysis that is able to figure it out, it is not worth it because it is way more expense civil than the actual TDZ checks they eliminate. As a result we don’t try to eliminate this at all outside of the optimizing tier. +And we always take the damage for the performance cost of those TDZ checks up slot of web implementation cannot achieve performance parity with VARS and let and const binding fully require more work. Each check itself is not too bad. This is a death by a thousand cuts kind of thing. My claim is that it cannot achieve performance parity with var in practice for the reasons I’ve been describing and eliminate easy checks up front and eliminate more in optimizing tiers and a lot of code runs one and not hot hot and don’t reach the tiers and full analysis is intraprocedural and too expensive to pay for itself. I have heard from GitHub posters that JSC doesn’t have this problem. I would like to understand more. In reading the web source code I see that JSC has TDZ checks and similar cheap elision analysis in the front end. It seems like they just do more work. RKG: Would you – @@ -1605,46 +1198,24 @@ RKG: So I can’t give a full answer. I can say one thing that’s very interest SYG: Good to know. -SYG: That’s the performance cost. Now moving on to adoption woes. So most JS features are adopted and sprains transpiled and then untranspiled. It is long on the order of five plus years because web properties products want to work everywhere. They want to reach the maximum amount of customers and user and work on older browsers. They want – if they want to use new -features they generally transport them away and code can work on older browsers and general availability of the features available natively take a long time to roll out. So depending on the risk appetite as – of your web app you might want to wait until you there’s a pretty small% percentage of people not on old Safari and Chrome and we are now after how many many -years since ES6 and 7 or 8, I think we are now at an inflection point and more and more people are trying to adopt ES6 features on, on transpiled especially large apps who are the most risk-averse in reaching the largest amount of users with older browsers. - -We learn new things at the inflection point. What are we learning here? Adoption via transpilers of let and const three policy transpilers is Babel and transcript and it does more and transpile after ship. Only talking in that capacity there and closure that is the Google thing that we use internally. They all implement lexical scoping statically for let and const but not the run time TDZ checks that is the seem theme. For Babel the only one that can emit -TDZ checks but off by default only in strict mode. And perhaps someone who is familiar with Babel can speak to why it’s off by default. But I heard it’s for performance reasons because it’s not fast to emit not just for code size but run time checks and more on the code side, it’s bad to emit so many checks. TypeScript compiler does statically check on the intra-easy cases. If you have an obvious before def will complain and it should because you shouldn’t write the code. It doesn’t emit run time TDZ checks and closure case and function -does not emit the TDZ checks and doesn’t emit TDZ checks for the intraprocedural cases. -Closure compiler also checks the easy intraprocedural cases and also does not emit run time TDZ checks. And in private communication with the closure folks internally at Google if let performance consts remain they are likely to transform down to viar of ES6 and we want native adoption of modern features. The adopters of let and const bindings via transpilers have not been getting TDZ semantics in the wild. They are runtime and not static. They are shipping -code that don’t have the semantics. The transpilers have and will remain did adventured from the spec. All things equal it will be good that tooling authors and tools stop being diversion from the spec. Moving on to adoption of untranspiled stuff. There are cases of large applications being unable to ship let and const on transpired due to performance transgression and let script got my attention on this and had an experiment a while back where they found that I guess it’s part of trying to ship modules. They wanted to ship let and const -on transpired and found parsing performance regressions in the parsing performance of TypeScript compiler ranging from single digit to double digit regressions. So they switched back to using vars for a few choice variables. This prompted some V8 opttyizations. I don’t believe we can achieve performance parity with VAR and make it faster but still slower than VA -R. You can follow the links there to see the bugs and to see the performance analysis of the TypeScript did. I don’t have public things I can share in the following one. But there there are large Google from ES5 to ES6 and cannot due to performance regressions. Not all of the regressions are due to let const, some due to classes. I’m not proposing anything to do with classes here. Let and const do contribute. I also talk with some other folks in the industry. It’s small survey of what are the large properties shipping. AirBNB ships ES6 but -performance regressions were known to them at the time when they decided toe stop shipping ES5 and ship ES6 and told that the decision was made based on reduced bundle size and removing the shims was worth the performance regressions. So it was made in combination of tool chain simplification of not having to include shims and bet that over time the ES6 path would get -faster in browsers. Made a lane to simplify complexity. I don’t think that assumption that -ES6 will get faster over time will be born out for let and const. Hopefully not universally true for ES6 features and for let and const I’m skeptical. Twitter ships ES6 and I don’t know the rationale. Facebook continues to ship ES5. - -TDZ what is it good for? To me the complete -picture likely the weapon developers on transpilers have not been getting TDZ semantics and stackover flow has very few questions. I don’t know if that’s indicative of anything. But people haven’t been getting the errors and wonder what they mean. And apps that care about performance cannot migrate. They’re sticking with VAR S and VARS have no run time but have -artificially prolonged lifetimes and function scope and not box scope. Large products in -general are not going to sacrifice user experience in favour of shipping on transpired modern -JS, that is a product choice they make. So from where I’m standing if developers can adopt it -where it matters what is this feature good for? My goals are twofold: Primary gold is enable -everyone including those with performance regression suites to ship modern unsprains spieled JS -and I don’t want people between rock and hard place between choosing between fast and modern. -The browser Chrome I participate in this committee in large part because I want both to be possible. I don’t want to evolve the language but I don’t want performance to be an afterthought. And I certainly don’t want it to preclude adoption of new features. My secondary goal here because mainly it’s not my main constituency but would like to see reduced semantic diversions between transpired and negative. The TDZ gap is one I understand that is not -closed. TypeScript is not going to transpile checks and Babel not turn on by default and closure not going to do anything. So the radical idea here that I’m not officially proposing here but might bring back later is what if we just remove the runtime checks, my proposed semantics are of course let and const are still lexical scope and everyone loves lexical scope. -Nobody arguing otherwise. They hoist the top of the block scope as they already do today. But they are initialized undefined like VARS. So what does this look like if there’s some before stuff and after stuff. Let X equals initializer and equivalent to let X and same before stuff and it is kept in C 2 before it was two. And used to throw developers get undefined. Same for const. The difference is that the const initializer is actually not just the equals, it’s -going to be some special initialization byte code. The biggest argument that I feel is that const change feels pretty weird. Const are now initialized twice. They no longer feel const. -There’s really no around that. But I guess pragmatically my question is does it matter? Will it be something that the practitioners care about or language care about? It would only notice it when you’re doing use before def that you shouldn’t do and the last point is not that point but I think def may be confused what const actually means. I don’t know if that counts towards -anything. But, yeah, I think the – out of the three bullet points there, I think would – -they would only notice when using use before def they should do that is the strongest one I -have for pragmatically. That’s the conversation of can we talk about what TDZ is good for? +SYG: That’s the performance cost. Now moving on to adoption woes. So most JS features are adopted and sprains transpiled and then untranspiled. It is long on the order of five plus years because web properties products want to work everywhere. They want to reach the maximum amount of customers and user and work on older browsers. They want – if they want to use new features they generally transport them away and code can work on older browsers and general availability of the features available natively take a long time to roll out. So depending on the risk appetite as – of your web app you might want to wait until you there’s a pretty small% percentage of people not on old Safari and Chrome and we are now after how many many years since ES6 and 7 or 8, I think we are now at an inflection point and more and more people are trying to adopt ES6 features on, on transpiled especially large apps who are the most risk-averse in reaching the largest amount of users with older browsers. + +We learn new things at the inflection point. What are we learning here? Adoption via transpilers of let and const three policy transpilers is Babel and transcript and it does more and transpile after ship. Only talking in that capacity there and closure that is the Google thing that we use internally. They all implement lexical scoping statically for let and const but not the run time TDZ checks that is the seem theme. For Babel the only one that can emit TDZ checks but off by default only in strict mode. And perhaps someone who is familiar with Babel can speak to why it’s off by default. But I heard it’s for performance reasons because it’s not fast to emit not just for code size but run time checks and more on the code side, it’s bad to emit so many checks. TypeScript compiler does statically check on the intra-easy cases. If you have an obvious before def will complain and it should because you shouldn’t write the code. It doesn’t emit run time TDZ checks and closure case and function does not emit the TDZ checks and doesn’t emit TDZ checks for the intraprocedural cases. +Closure compiler also checks the easy intraprocedural cases and also does not emit run time TDZ checks. And in private communication with the closure folks internally at Google if let performance consts remain they are likely to transform down to viar of ES6 and we want native adoption of modern features. The adopters of let and const bindings via transpilers have not been getting TDZ semantics in the wild. They are runtime and not static. They are shipping code that don’t have the semantics. The transpilers have and will remain did adventured from the spec. All things equal it will be good that tooling authors and tools stop being diversion from the spec. Moving on to adoption of untranspiled stuff. There are cases of large applications being unable to ship let and const on transpired due to performance transgression and let script got my attention on this and had an experiment a while back where they found that I guess it’s part of trying to ship modules. They wanted to ship let and const on transpired and found parsing performance regressions in the parsing performance of TypeScript compiler ranging from single digit to double digit regressions. So they switched back to using vars for a few choice variables. This prompted some V8 opttyizations. I don’t believe we can achieve performance parity with VAR and make it faster but still slower than VA R. You can follow the links there to see the bugs and to see the performance analysis of the TypeScript did. I don’t have public things I can share in the following one. But there there are large Google from ES5 to ES6 and cannot due to performance regressions. Not all of the regressions are due to let const, some due to classes. I’m not proposing anything to do with classes here. Let and const do contribute. I also talk with some other folks in the industry. It’s small survey of what are the large properties shipping. AirBNB ships ES6 but performance regressions were known to them at the time when they decided toe stop shipping ES5 and ship ES6 and told that the decision was made based on reduced bundle size and removing the shims was worth the performance regressions. So it was made in combination of tool chain simplification of not having to include shims and bet that over time the ES6 path would get faster in browsers. Made a lane to simplify complexity. I don’t think that assumption that ES6 will get faster over time will be born out for let and const. Hopefully not universally true for ES6 features and for let and const I’m skeptical. Twitter ships ES6 and I don’t know the rationale. Facebook continues to ship ES5. + +TDZ what is it good for? To me the complete picture likely the weapon developers on transpilers have not been getting TDZ semantics and stackover flow has very few questions. I don’t know if that’s indicative of anything. But people haven’t been getting the errors and wonder what they mean. And apps that care about performance cannot migrate. They’re sticking with VAR S and VARS have no run time but have artificially prolonged lifetimes and function scope and not box scope. Large products in general are not going to sacrifice user experience in favour of shipping on transpired modern JS, that is a product choice they make. So from where I’m standing if developers can adopt it where it matters what is this feature good for? My goals are twofold: Primary gold is enable everyone including those with performance regression suites to ship modern unsprains spieled JS and I don’t want people between rock and hard place between choosing between fast and modern. +The browser Chrome I participate in this committee in large part because I want both to be possible. I don’t want to evolve the language but I don’t want performance to be an afterthought. And I certainly don’t want it to preclude adoption of new features. My secondary goal here because mainly it’s not my main constituency but would like to see reduced semantic diversions between transpired and negative. The TDZ gap is one I understand that is not closed. TypeScript is not going to transpile checks and Babel not turn on by default and closure not going to do anything. So the radical idea here that I’m not officially proposing here but might bring back later is what if we just remove the runtime checks, my proposed semantics are of course let and const are still lexical scope and everyone loves lexical scope. +Nobody arguing otherwise. They hoist the top of the block scope as they already do today. But they are initialized undefined like VARS. So what does this look like if there’s some before stuff and after stuff. Let X equals initializer and equivalent to let X and same before stuff and it is kept in C 2 before it was two. And used to throw developers get undefined. Same for const. The difference is that the const initializer is actually not just the equals, it’s going to be some special initialization byte code. The biggest argument that I feel is that const change feels pretty weird. Const are now initialized twice. They no longer feel const. +There’s really no around that. But I guess pragmatically my question is does it matter? Will it be something that the practitioners care about or language care about? It would only notice it when you’re doing use before def that you shouldn’t do and the last point is not that point but I think def may be confused what const actually means. I don’t know if that counts towards anything. But, yeah, I think the – out of the three bullet points there, I think would – +they would only notice when using use before def they should do that is the strongest one I have for pragmatically. That’s the conversation of can we talk about what TDZ is good for? That’s all the material there is. I’ll now go to queue for discussion. USA: First we have Luca. -LCA: My first question is, like, do you have data on how frequently you can eliminate TDZ checks? +LCA: My first question is, like, do you have data on how frequently you can eliminate TDZ checks? How frequently do you encounter easy cases for TDZ cases versus cases that are not statically analyzable or not quickly statically analyzable? -SYG: Not for data that is representative of the whole web. That analysis was done when we’re optimizing the TypeScript use case. In TypeScript’s particular code base, I think when we try to eliminate more easy to eliminate cases we were – I think we couldn’t eliminate at least 50% of TDZ checks. We could eliminate 50 and the other 50 are in closures or whatever. I think -the particular pattern and someone from TypeScript can correct me if I’m wrong and much more knowledgeable is something that you have – it’s a compiler and you have a global const that’s a lexer and then a bunch of functions that close over the lexer that all use it and those are not going to be easy to I eliminate. +SYG: Not for data that is representative of the whole web. That analysis was done when we’re optimizing the TypeScript use case. In TypeScript’s particular code base, I think when we try to eliminate more easy to eliminate cases we were – I think we couldn’t eliminate at least 50% of TDZ checks. We could eliminate 50 and the other 50 are in closures or whatever. I think the particular pattern and someone from TypeScript can correct me if I’m wrong and much more knowledgeable is something that you have – it’s a compiler and you have a global const that’s a lexer and then a bunch of functions that close over the lexer that all use it and those are not going to be easy to I eliminate. LCA: Okay. And – makes sense, thanks. On the 50%, is that 50% of the time that there’s an access to, for example, the lexer that access has a TDZ check or 50% of the cases in source code where you see that binding you are not able to statically remove that? @@ -1652,8 +1223,7 @@ SYG: Specifically it was I counted the special TDZ check byte code we emit witho LCA: That would also have to be weighed by how frequently those code paths are actually hit. -SYG: Correct. It’s a static check and not dynamic check. We don’t have dynamic counters because -that is not something we can ship. +SYG: Correct. It’s a static check and not dynamic check. We don’t have dynamic counters because that is not something we can ship. LCA: Okay, thank you. @@ -1663,16 +1233,13 @@ JHD: Yeah, I was just curious when you mentioned in your slide the escape foo sl SYG: I’m not sure I understand the question. What is the – -JHD: I guess it’s fine if the answer is let’s talk about it in relation to the other proposal some other time. But like it sounds like you’re saying that having to do checks that happen the first time you touch a variable can be performance prohibitive when it’s – like, when it -can be passed somewhere else. +JHD: I guess it’s fine if the answer is let’s talk about it in relation to the other proposal some other time. But like it sounds like you’re saying that having to do checks that happen the first time you touch a variable can be performance prohibitive when it’s – like, when it can be passed somewhere else. -SYG: No. I’m saying – so the thing that is prohibitive is relative – accessing a binding is very frequent and should be a very fast operation: The thing that is slow is having to do a check on every access of the binding slot cuts into like the budget for it is already very small. So if a large percentage of it is checking if it’s – should throw or not. That is not acceptable. The first access thing is not – I think it’s not a relevant thing here. I think import — so in particular module bindings are like weird live bindings. They just do not have the same performance requirements as locals. So module bindings if they have like an -initialized on first touch thing that like might pull in something... Module bindings I think the -performance is dominated because they’re slow. +SYG: No. I’m saying – so the thing that is prohibitive is relative – accessing a binding is very frequent and should be a very fast operation: The thing that is slow is having to do a check on every access of the binding slot cuts into like the budget for it is already very small. So if a large percentage of it is checking if it’s – should throw or not. That is not acceptable. The first access thing is not – I think it’s not a relevant thing here. I think import — so in particular module bindings are like weird live bindings. They just do not have the same performance requirements as locals. So module bindings if they have like an initialized on first touch thing that like might pull in something... Module bindings I think the performance is dominated because they’re slow. JHD: This won’t apply, is what you’re saying. -SYG: don’t think so. +SYG: don’t think so. NRO: That proposal doesn’t have a relation and property access. @@ -1683,11 +1250,10 @@ USA: Nicolo you’re next. NRO: From the perspective, we have the implementation of the checks and the reason not enabled by default. One is that – well, we have to run time checks and they slow down code the same happens in engines for little added value for the users. -The second reason is that those checks also significantly increase code size because it’s a helper that needs to be called in many places where bindings are used. -And the third reason is that it’s incredibly slow to like emit the code for the checks. We are in a different situation from engines because we have completion and we can afford spending as much as possible while compiling to generate the best possible output. +The second reason is that those checks also significantly increase code size because it’s a helper that needs to be called in many places where bindings are used. +And the third reason is that it’s incredibly slow to like emit the code for the checks. We are in a different situation from engines because we have completion and we can afford spending as much as possible while compiling to generate the best possible output. -But enable TDZ option makes like our let and const basically twice as low. It’s really quite slow because of compiling lexical scoping and loops is incredibly complex, this is just not worth it. And it being disabled by default never cause users to complain. The only reports we get about the implementation is from the education of language and find cases that are static analysis is -wrong and assumes the binding is not in TDZ and might be in TDZ. We never got users asking to enable this option by default. We would like to be as much spec complaint as possible. We – one of the goals is to be the most spec complaint too. But like this is one of the only two cases whereon purpose we deviate from the spec. +But enable TDZ option makes like our let and const basically twice as low. It’s really quite slow because of compiling lexical scoping and loops is incredibly complex, this is just not worth it. And it being disabled by default never cause users to complain. The only reports we get about the implementation is from the education of language and find cases that are static analysis is wrong and assumes the binding is not in TDZ and might be in TDZ. We never got users asking to enable this option by default. We would like to be as much spec complaint as possible. We – one of the goals is to be the most spec complaint too. But like this is one of the only two cases whereon purpose we deviate from the spec. SYG: Thank you for the details. @@ -1699,13 +1265,11 @@ SYG: The ones that are easy as – specifically you said as earlier. We can – JHD: Maybe not earlier but just find another way so that the user will be told that you’re doing a bad thing, don’t do this thing in as many cases as possible even if not all of them as currently spec'd. -SYG: My concerns with that is I’m not sure if it will be compatible. We had issues where we changed runtime behavior to early error behavior. Specifically like the call expressions on the left hand side. That we couldn’t ship. That practical certain. The other concern is that we will be – the easy cases by easy I mean, they’re cheaply analyzable by the engine. I’m not sure they are -easy to spec. That will be like speccing a specific variant of some static analysis and that’s – there’s some – that’s a technical problem that might be worked around. Not something that we have – we have earliers but not to the simplification of data flow analysis. That would be new ground that we would tread. +SYG: My concerns with that is I’m not sure if it will be compatible. We had issues where we changed runtime behavior to early error behavior. Specifically like the call expressions on the left hand side. That we couldn’t ship. That practical certain. The other concern is that we will be – the easy cases by easy I mean, they’re cheaply analyzable by the engine. I’m not sure they are easy to spec. That will be like speccing a specific variant of some static analysis and that’s – there’s some – that’s a technical problem that might be worked around. Not something that we have – we have earliers but not to the simplification of data flow analysis. That would be new ground that we would tread. JHD: The motivation behind my question just for clarification is I prefer to see as few correctness checks as possible punted out to the ecosystem and prefer to see them in the language when it’s feasible. That’s what is driving this question. -SYG: And but I’m skeptical we can basically. It’s the easy cases – I think the easy cases are the ones that would precisely be least valuable to surface in the engine. I think the easy cases are statically analyzable and all are doing admiral job against those already. And the hard ones are, I don’t know. That’s where you get the tricky bugs. In the intraprocedural and get undefined and get another run time error and undefined is not a -function. I think that’s not to debug. I’m not very very optimistic on being able to spec a different kind of check to keep a run time. I haven’t tried it. I don’t know. +SYG: And but I’m skeptical we can basically. It’s the easy cases – I think the easy cases are the ones that would precisely be least valuable to surface in the engine. I think the easy cases are statically analyzable and all are doing admiral job against those already. And the hard ones are, I don’t know. That’s where you get the tricky bugs. In the intraprocedural and get undefined and get another run time error and undefined is not a function. I think that’s not to debug. I’m not very very optimistic on being able to spec a different kind of check to keep a run time. I haven’t tried it. I don’t know. JHD: Thank you. @@ -1715,7 +1279,7 @@ JWK: I remember it was an early error when ES6 was in the early days and the eng LCA: I have another question. If anybody wants to – -LCA: Okay. So what is the amount of TDZ analysis that an engine does versus what Babel or TypeScript do that is reasonable, is it the case that like most of the things that V8 can easily analyze up front is also something that tools analyze upfront right now? Or are there or do tools generally cover more cases or does V8 cover more cases? Do you have data on this? +LCA: Okay. So what is the amount of TDZ analysis that an engine does versus what Babel or TypeScript do that is reasonable, is it the case that like most of the things that V8 can easily analyze up front is also something that tools analyze upfront right now? Or are there or do tools generally cover more cases or does V8 cover more cases? Do you have data on this? SYG; I don’t. @@ -1723,41 +1287,29 @@ LCA: Okay. SYG: No, I haven’t looked too deeply. I just played around and seen very simple use cases and def are reported and I don’t know if I’ve seen warnings around some kind of path sensitivity that warrants that, I just don’t know. -LCA: My background, it would be interesting to know this because it can help inform whether like if the run time stops doing this whether the static analysis tools would be able to cover the majority of these cases any way. And I assume it would not be able to do this. Like I see a reply from Daniel that TypeScript doesn’t do data flow analysis and assume it wouldn’t do it in -the final cases anyway. Maybe V8 would be able to do them? +LCA: My background, it would be interesting to know this because it can help inform whether like if the run time stops doing this whether the static analysis tools would be able to cover the majority of these cases any way. And I assume it would not be able to do this. Like I see a reply from Daniel that TypeScript doesn’t do data flow analysis and assume it wouldn’t do it in the final cases anyway. Maybe V8 would be able to do them? SYG: I don’t know. -NRO: I would expect Babel to perform more static analysis than V8 because we can do more ahead of time. The analysis we do is all within the single file. We track for each usage of the variable, we check if the variable is in the same scope or after or if they’re two different functions we check whether those functions are only called within the module. And if so, like -if the function that uses the banding is called either after the definition of the binding. +NRO: I would expect Babel to perform more static analysis than V8 because we can do more ahead of time. The analysis we do is all within the single file. We track for each usage of the variable, we check if the variable is in the same scope or after or if they’re two different functions we check whether those functions are only called within the module. And if so, like if the function that uses the banding is called either after the definition of the binding. And I would expect V8 to do less than this given the high cost. -SYG: The exception is when you reach the optimizing tier and you do deep inlining you do more visibility -what can be eliminated. Like I said so much, not hot code that doesn’t make a dent in the performance overhead of TDZ checks. - +SYG: The exception is when you reach the optimizing tier and you do deep inlining you do more visibility what can be eliminated. Like I said so much, not hot code that doesn’t make a dent in the performance overhead of TDZ checks. -BSH: [on queue: closure-compiler probably has equivalent coverage] Just to clarify on what I wrote in, we (closure compiler) has -similar coverage to what the engines do. We can probably – we can might be better and could -be better because we can take more time. We do data flow analysis. +BSH: [on queue: closure-compiler probably has equivalent coverage] Just to clarify on what I wrote in, we (closure compiler) has similar coverage to what the engines do. We can probably – we can might be better and could be better because we can take more time. We do data flow analysis. -DRR: I don’t necessarily if data flow analysis is – I’m pulling that out as one example we don’t do. We don’t do any sort of like – we do basic control flow analysis. We don’t go beyond the current procedure. Really we don’t do interprocedural analysis at all. It doesn’t depend on any of that. And so that is a bigger task for us as well. We probably wouldn’t want to go down that path. But I would think we had a broader discussion about that. I think from our -side the bigger thing is really in some sense our type checking actually, you know, assumes as well, you know, for the things that we don’t catch at least the run time will catch it, right? +DRR: I don’t necessarily if data flow analysis is – I’m pulling that out as one example we don’t do. We don’t do any sort of like – we do basic control flow analysis. We don’t go beyond the current procedure. Really we don’t do interprocedural analysis at all. It doesn’t depend on any of that. And so that is a bigger task for us as well. We probably wouldn’t want to go down that path. But I would think we had a broader discussion about that. I think from our side the bigger thing is really in some sense our type checking actually, you know, assumes as well, you know, for the things that we don’t catch at least the run time will catch it, right? We are able to, a little bit, wash our hands of the problem. But that’s not a hundred percent obviously. USA: Next we have WH. -WH: I would like to know whether this problem could be addressed by better coordination between engines and transpilers. I fully see the point that engines have precious little time to do any kind of flow analysis because they need to compile things really fast. Transpilers have a -bit more leeway in doing this kind of analysis and thinking what code they emit. If they turn `let` and `const` into `var`, they must do some analysis; otherwise they would produce buggy code if variables overlap. I think there might be some low-hanging fruit opportunities for transpilers to let engines know that TDZ checks can be elided, for example by turning function statements which hoist into `const` definitions of function expressions which don’t hoist and are therefore entirely dominated by prior `let` and `const` definitions. +WH: I would like to know whether this problem could be addressed by better coordination between engines and transpilers. I fully see the point that engines have precious little time to do any kind of flow analysis because they need to compile things really fast. Transpilers have a bit more leeway in doing this kind of analysis and thinking what code they emit. If they turn `let` and `const` into `var`, they must do some analysis; otherwise they would produce buggy code if variables overlap. I think there might be some low-hanging fruit opportunities for transpilers to let engines know that TDZ checks can be elided, for example by turning function statements which hoist into `const` definitions of function expressions which don’t hoist and are therefore entirely dominated by prior `let` and `const` definitions. -NRO: One easy way to help with this instead of full let const transform we could have some way to transform let and const only in cases where we can prove they’re not easy checks needed and that would mean that the engines could only meet the run time checks and would need to have the first static analysis pass because the only remaining cases are the cases that can be statically proved. I’m not sure if it will want to have this very high coordination between -tools and engines because so far in JavaScript we kind of always act independently by -relying on the language. +NRO: One easy way to help with this instead of full let const transform we could have some way to transform let and const only in cases where we can prove they’re not easy checks needed and that would mean that the engines could only meet the run time checks and would need to have the first static analysis pass because the only remaining cases are the cases that can be statically proved. I’m not sure if it will want to have this very high coordination between tools and engines because so far in JavaScript we kind of always act independently by relying on the language. MM: First of all I need some clarification. I’m confused about something. A lot of the questions we just went through weed into the talk we just heard that the purpose is primarily about the performance of transpiled code but the transpiled code but it doesn’t do the TDZ checks. If the proposal is to remove TDZ checks, we transpiled code doesn’t get safer than it is right now not doing the TDZ checks and it doesn’t get any faster since it’s not doing the TDZ check. The other thing that makes more sense to me about what the purpose of Shu’s proposal is so that the code that had been transpiled could run without a transpiler directly on the language and not suffer performance regression when you avoid the transpiler. So Shu, can you first clarify between those two goals. -SYG: If I understand you correctly, your understanding is correct. The transpiled code today if -they are targeting – if they are transpiling let and const away, they are transpiling them -away into `var`s without TDZ checks so precisely in that case there is no performance overhead but it diverges from the spec’d behavior and as you say it doesn’t have any of the added run time checks. My goal as I had on the slide there that I want people to ship let const untranspiled without the – +SYG: If I understand you correctly, your understanding is correct. The transpiled code today if they are targeting – if they are transpiling let and const away, they are transpiling them away into `var`s without TDZ checks so precisely in that case there is no performance overhead but it diverges from the spec’d behavior and as you say it doesn’t have any of the added run time checks. My goal as I had on the slide there that I want people to ship let const untranspiled without the – MM: Untranspiled. @@ -1775,12 +1327,8 @@ MM: Go back to the last slide. For the code for the second block of code, the co SYG: Yes to V8, I hope yes to the others. -MM: So let’s just assume – let’s just stipulate that for the moment and assume that’s true. -The alternative I want to suggest for untranspiled code is a lint fix rule. That one can have these the most Conservative domination rules that Conservative estimate of what actual engines do, could be linked – linter could check for it, and then when it doesn’t find that it knows that engines will be as fast as the code that you’ve written below the line, then it can suggest moving the let to the beginning of the block as a lint fix rule for a human being to -look at and either approve or not check.depending on what the semantics they want and if they accept the linting rewrite, it’s clear to readers of the code what the semantics of the code are, that what the rewrite does is it corrects the code to properly have the semantics that the current transpilers are giving it without a TDZ That may or may not be the desired for the application and lint fix rules for optional lint rules are to be turned on and off and human inspected and for const especially, the rewrite that the lintier could suggest as a -potential performance improvement would rewrite it to let rather than keeping a const keyword where the variable has two different observer values. I will just say right up front that the idea of removing the decide check for const where the same const variable name can be observed with two different values, I can’t imagine myself agreeing to that. But I want to propose that I think the lint fix rule fits with the actual software engineering process and give mostly out mated way and if people are just willing to accept what you’re proposing -without inspection, then by the same token people should be willing to apply the lint fix rule -I just talked about without inspection. +MM: So let’s just assume – let’s just stipulate that for the moment and assume that’s true. +The alternative I want to suggest for untranspiled code is a lint fix rule. That one can have these the most Conservative domination rules that Conservative estimate of what actual engines do, could be linked – linter could check for it, and then when it doesn’t find that it knows that engines will be as fast as the code that you’ve written below the line, then it can suggest moving the let to the beginning of the block as a lint fix rule for a human being to look at and either approve or not check.depending on what the semantics they want and if they accept the linting rewrite, it’s clear to readers of the code what the semantics of the code are, that what the rewrite does is it corrects the code to properly have the semantics that the current transpilers are giving it without a TDZ That may or may not be the desired for the application and lint fix rules for optional lint rules are to be turned on and off and human inspected and for const especially, the rewrite that the lintier could suggest as a potential performance improvement would rewrite it to let rather than keeping a const keyword where the variable has two different observer values. I will just say right up front that the idea of removing the decide check for const where the same const variable name can be observed with two different values, I can’t imagine myself agreeing to that. But I want to propose that I think the lint fix rule fits with the actual software engineering process and give mostly out mated way and if people are just willing to accept what you’re proposing without inspection, then by the same token people should be willing to apply the lint fix rule I just talked about without inspection. SYG: That doesn't work, because those are the easy cases which I don’t care to eliminate that much anyway. The true cost comes from these intractably hard to eliminate cases that hosting does not fix because function definitions do not hoist. @@ -1794,14 +1342,11 @@ SYG: No. We do not perform any kind of alias or escape analysis in the front whe MM: Okay. I’m puzzled by this and it seems like any variable that is declared at the very top of the block in which it is, it can – it can be in scope cannot be one that needs a runtime TDZ check and I think that’s a trivial static condition. I can’t see how that’s violated. -SYG: It’s violated with function declarations in the same scope that close the binding. Once that happens, to know that if those functions because of their hoisting behavior, to know if they can or cannot be called before the declaration itself is evaluated require intraprocedural and escape analysis that is too expensive to do in the front end. It is not done. So conservatively a TDZ check byte code is always inserted for closed over – for access of closed -over lexical bindings inside inner functions. +SYG: It’s violated with function declarations in the same scope that close the binding. Once that happens, to know that if those functions because of their hoisting behavior, to know if they can or cannot be called before the declaration itself is evaluated require intraprocedural and escape analysis that is too expensive to do in the front end. It is not done. So conservatively a TDZ check byte code is always inserted for closed over – for access of closed over lexical bindings inside inner functions. MM: I think that – I think you can do better. I think I could do better. I think that the – when the variables at the very top of the block then if the function definition is hoisted but the function – there’s no use of the function name until after – you know, until after that variable is declared at the top of the block, I don’t see how it can escape before the variable is initialized. -SYG: Yes, there is, there are sub cases here where we can do better. I don’t think that -precludes that. - +SYG: Yes, there is, there are sub cases here where we can do better. I don’t think that precludes that. SYG: That cannot be – go ahead. @@ -1813,11 +1358,9 @@ MM: The people who want to – the people that are holding off on going untransp SYG: Can you repeat that? I didn’t quite parse it. -MM: Okay. Let’s say there was a lint fix rule and source to course transformation not in the sense of a transpiler and source fix up and the output is the artifact to be maintained from there on, if somebody has a large program that’s currently being transpiled and they want to run it untranspiled with no performance regression, then that kind of source fix up automated source fix up is something that they should be willing to do without having to look at each individual changes and approve them. Because first of all since they’re coming from a transpiler that’s not doing TDZ checks, they’re no less safe after this source – after this source rewrite, and second of all, even for code that’s not coming from a transpiler, applying the source rewrite blind doesn’t make them any less safe than they would be without the source rewrite if the language got rid of TDZ checks. So there’s real – so for all of the -cases you’re concerned about, there’s no reason why the software shops should not be willing to run this source fix up pass blindly. +MM: Okay. Let’s say there was a lint fix rule and source to course transformation not in the sense of a transpiler and source fix up and the output is the artifact to be maintained from there on, if somebody has a large program that’s currently being transpiled and they want to run it untranspiled with no performance regression, then that kind of source fix up automated source fix up is something that they should be willing to do without having to look at each individual changes and approve them. Because first of all since they’re coming from a transpiler that’s not doing TDZ checks, they’re no less safe after this source – after this source rewrite, and second of all, even for code that’s not coming from a transpiler, applying the source rewrite blind doesn’t make them any less safe than they would be without the source rewrite if the language got rid of TDZ checks. So there’s real – so for all of the cases you’re concerned about, there’s no reason why the software shops should not be willing to run this source fix up pass blindly. -SYG: The reason is they have an easy alternative that is just to transpile it. Like, they don’t have a goal to ship modern JS, it is my goal as a browser engine to try to get people to ship modern JS and I don’t want them to choose between fast and modern. For the shops the goal is a working product and they don’t care what they ship. They have heard maybe it be good to ship -ES6 and try it and they hit some hurdles and decide we will just keep shipping ES5. +SYG: The reason is they have an easy alternative that is just to transpile it. Like, they don’t have a goal to ship modern JS, it is my goal as a browser engine to try to get people to ship modern JS and I don’t want them to choose between fast and modern. For the shops the goal is a working product and they don’t care what they ship. They have heard maybe it be good to ship ES6 and try it and they hit some hurdles and decide we will just keep shipping ES5. USA: Just a quick comment. There’s around ten minutes left. @@ -1839,7 +1382,7 @@ USA: Then we have two replies that I believe are related. First we have Shane. SFC: You said that you’re talking with one of the websites that ships ES6 and said maybe TDZ will get faster at some point. What MM is describing seems like an example of something that could actually be done to make the code a little bit faster. Especially if the TypeScript compiler and so forth emitted code that obeyed the invariant that Mark described, that could be a way without making any spec change to improve the performance of existing code. Just an observation. -SYG: I think my response to that I would like there to be a transparent optimization. +SYG: I think my response to that I would like there to be a transparent optimization. Anything that requires humans in the loop to make a transform because it is unsound and can’t be automatically applied has dramatically diminished success of skilling and I think MM’s idea is a good one and disagree to be implemented in engines. If the tooling wants to implement lint and suggest. MM: I’m not suggesting that the engine implement the lint. I’m suggesting only tools implement this lint, and additionally, the only requirement here on the engines is that in cases that the lint tool emits that code, it can eliminate the unnecessary TDZ checks. @@ -1865,34 +1408,35 @@ CM: That’s all. That’s all I’ve got. SYG: Thanks for your time. There’s no official thing I’m asking for here. There’s some new ideas that were raised by a closer coupling with tooling and engines here that might be worthying through. Though I’m skeptical about this and the skill activation aspect of it. If you’re interested, reach out to me and other engines specifically and TypeScript to see where you currently stand. I see some other questions to address and maybe talk after the meeting. [To be continued later in this meeting] + ### Summary -* Years after ES6, let and const still commonly cause performance regressions vs var, and transpilers do not implement TDZ. The result is that let and const are avoided in shipped JS code. + +* Years after ES6, let and const still commonly cause performance regressions vs var, and transpilers do not implement TDZ. The result is that let and const are avoided in shipped JS code. * Generally, if the committee cares about its features being adoptable, these sorts of 5+-year retrospectives will be important. * SYG proposes treating some or all cases of TDZ as simply evaluating to undefined, as var does. * Most of the committee agreed with the goal of ensuring that features like this are adoptable in practice, but there was no consensus on whether semantics changes to support that are needed. + ### Conclusion -* A proposal may be formed on this topic in the future -​​## Stable Formatting for Stage 1 -Presenter: Eemeli Aro (EAO) +A proposal may be formed on this topic in the future -- [proposal](https://github.com/eemeli/proposal-stable-formatting) -- [slides](https://docs.google.com/presentation/d/1p1Xgywv1qfY54gnfHUM6PXQafqgf7wY98znxbolmP2c/edit?usp=sharing) +## Stable Formatting for Stage 1 +Presenter: Eemeli Aro (EAO) -EAO: This is ECMA-402-ish proposal I’m bringing to you and I’m bringing to you a problem that’s kind of coming from ECMA-402 but hopefully you’ll understand why I’m being a bit cagey about this. Fundamentally the issue here is that through the formatters and other functionality you have in Intl you can do a lot of useful things. Almost all of this – no, absolutely all of it is focused on providing something for humans in a locale dependent manner such as formatting numbers, dates, all that and other things. But fundamentally sometimes the things we can do in the scope of ECMA-402 are users who need to use it for programmatic purposes or who are targeting an audience for what they just don’t know the locale effectively. We are in the situation where we have APIs that are being misused in some ways or used in ways that the use cases we have for 402 aren’t really accounting for and are in fact counter to it. This is -effectively setting up a situation where we are telling that users really should not be using the localized output that they get out of 402 functionality because that might break at any time. On the other side, we can’t change the localized shape of the output that we are providing because that might break user code. And this is unfortunate and we’re not going to get rid of this immediately. But we could, you know, do better. So some examples roughly of the sorts of things that I’m talking about here is one if you want to format currently with JavaScript a date using the common YYYY-month-date format, probably before temporal arrives, the easiest and best way to do it is to create a date time formatter in Swedish and use that for this purpose. This is shall we say a bit questionable. Then in another dimension there are capabilities like we have – we are capable of formatting compact notation numbers with NumberFormat. But none of the locales that we are providing provide a way of using the SI suffixes in fact, there’s a typo there for numbers. That would be like 99 K for – and K is a thousand. That specifically works. If you go into the higher exponents, the English ones don’t match and none of the other ones don’t match either. It would be nice for the functionality to be provided for nonlocale-based use. And then there are also the APIs like collation, collator that are working, we effectively not really working, providing a localized output but working with localized input. And on that, we have weird things like if you want to use emoji collation, then you need to pick a – use a U flag sub text on a locale that happens not to customize the root locale and ends up on the root locate and do it on English it works. If I remember right, if you do it on Swedish or Finnish, it won’t because those are a little bit specialized in some certain cases. And then there are places where we have explicit references to default algorithms like for segmenter and recommending implementation should do something better than this and no current way of user land from accessing something that a user can be certain is implementing the specified default algorithm there which if I remember right this is what actually ICU 4 X is using in the implementation correctly rather than custom missing it for each locale. +* [proposal](https://github.com/eemeli/proposal-stable-formatting) +* [slides](https://docs.google.com/presentation/d/1p1Xgywv1qfY54gnfHUM6PXQafqgf7wY98znxbolmP2c/edit?usp=sharing) -This is roughly the problem space we have. And what I’m kind of happy to be coming to you with is the fact that there are two entirely different sorts of directions to go in solving and improving the direction. One is keep on going what we’re doing now and to identify not just the examples I happen to cherry pick for the previous slides but all the sorts of places where we are providing functionality that users are using for programmatic and other purposes even though they shouldn’t and we match those one by one by methods that are appropriate for that data shape and that usage. So, for example, for dates, obviously temporal is providing all or almost all of the solutions that are needed. In this space for numbers we could imagine big have Int as well extending the toString method or adding a new method on the prototype for allowing some custom mazable of the formatting. There are the functionalities that we session meanter and 402 in the separates and couldn’t come with the immediate response and how could they be provided locale independent solutions for. That was a long sentence. But ultimately one really strong benefit of this shape of a solution is that going this route we could keep ECMA-402 explicitly only serving localized use cases as opposed to what is a different sort of solution that’s possible which is to provide a general solution for all the capabilities that are on the Intl to be available in the non locale local. So this would be, for example, the – we could accept where we currently accept string identifies for locale we could accept null and we could notice that internally to zxx that is a valid one technically. But it’s just I haven’t actually found anyone in JavaScript or other places that actually does useful things with it at least. And it stands for Nolin guess tick content, not applicable. And then go on from there and define the behaviour for this that would be nonlocale and would be producing no locale dependent behavior. +EAO: This is ECMA-402-ish proposal I’m bringing to you and I’m bringing to you a problem that’s kind of coming from ECMA-402 but hopefully you’ll understand why I’m being a bit cagey about this. Fundamentally the issue here is that through the formatters and other functionality you have in Intl you can do a lot of useful things. Almost all of this – no, absolutely all of it is focused on providing something for humans in a locale dependent manner such as formatting numbers, dates, all that and other things. But fundamentally sometimes the things we can do in the scope of ECMA-402 are users who need to use it for programmatic purposes or who are targeting an audience for what they just don’t know the locale effectively. We are in the situation where we have APIs that are being misused in some ways or used in ways that the use cases we have for 402 aren’t really accounting for and are in fact counter to it. This is effectively setting up a situation where we are telling that users really should not be using the localized output that they get out of 402 functionality because that might break at any time. On the other side, we can’t change the localized shape of the output that we are providing because that might break user code. And this is unfortunate and we’re not going to get rid of this immediately. But we could, you know, do better. So some examples roughly of the sorts of things that I’m talking about here is one if you want to format currently with JavaScript a date using the common YYYY-month-date format, probably before temporal arrives, the easiest and best way to do it is to create a date time formatter in Swedish and use that for this purpose. This is shall we say a bit questionable. Then in another dimension there are capabilities like we have – we are capable of formatting compact notation numbers with NumberFormat. But none of the locales that we are providing provide a way of using the SI suffixes in fact, there’s a typo there for numbers. That would be like 99 K for – and K is a thousand. That specifically works. If you go into the higher exponents, the English ones don’t match and none of the other ones don’t match either. It would be nice for the functionality to be provided for nonlocale-based use. And then there are also the APIs like collation, collator that are working, we effectively not really working, providing a localized output but working with localized input. And on that, we have weird things like if you want to use emoji collation, then you need to pick a – use a U flag sub text on a locale that happens not to customize the root locale and ends up on the root locate and do it on English it works. If I remember right, if you do it on Swedish or Finnish, it won’t because those are a little bit specialized in some certain cases. And then there are places where we have explicit references to default algorithms like for segmenter and recommending implementation should do something better than this and no current way of user land from accessing something that a user can be certain is implementing the specified default algorithm there which if I remember right this is what actually ICU 4 X is using in the implementation correctly rather than custom missing it for each locale. + +This is roughly the problem space we have. And what I’m kind of happy to be coming to you with is the fact that there are two entirely different sorts of directions to go in solving and improving the direction. One is keep on going what we’re doing now and to identify not just the examples I happen to cherry pick for the previous slides but all the sorts of places where we are providing functionality that users are using for programmatic and other purposes even though they shouldn’t and we match those one by one by methods that are appropriate for that data shape and that usage. So, for example, for dates, obviously temporal is providing all or almost all of the solutions that are needed. In this space for numbers we could imagine big have Int as well extending the toString method or adding a new method on the prototype for allowing some custom mazable of the formatting. There are the functionalities that we session meanter and 402 in the separates and couldn’t come with the immediate response and how could they be provided locale independent solutions for. That was a long sentence. But ultimately one really strong benefit of this shape of a solution is that going this route we could keep ECMA-402 explicitly only serving localized use cases as opposed to what is a different sort of solution that’s possible which is to provide a general solution for all the capabilities that are on the Intl to be available in the non locale local. So this would be, for example, the – we could accept where we currently accept string identifies for locale we could accept null and we could notice that internally to zxx that is a valid one technically. But it’s just I haven’t actually found anyone in JavaScript or other places that actually does useful things with it at least. And it stands for Nolin guess tick content, not applicable. And then go on from there and define the behaviour for this that would be nonlocale and would be producing no locale dependent behavior. This is as far as I got with my presentation and what I’m asking for is recognition that this motivation is sufficient that we ought to do something here and I would very much welcome input on which kind of way we ought to be going with all of this. DLM: I think this is a good idea. Definitely worth investigating. We have definitely seen web compatibility problems in the past where people have been parsing localized output. I do think there might be a little bit of developer education problem here and we failed people not to do dumb things in the past. That’s not a reason to not try to improve things in the future. -JHD: Support that. I mean, it would be nice to find something that’s clearer than ZZX or enough -or something. But that’s a later stage concern. I like the problem this is solving. +JHD: Support that. I mean, it would be nice to find something that’s clearer than ZZX or enough or something. But that’s a later stage concern. I like the problem this is solving. -SFC: One of the motivating examples here is the CLDR non break space that broke a number of websites. We had a discussion about that in the TG2 meeting a couple of months ago. Exactly the use case. Now, that particular use case could have been avoided with Temporal. So if Temporal had existed the developer who wrote the code that word with space may not have broken it and could have used temporal. On the other hand temporal is – – if we can make this something that is accessible for developers, easier for developers to learn and figure out. We can sort of help developers avoid some of these foot guns. I think anything we can do to do that is fine. If a developer uses, for example, no locale solution possibility Number 2, their code is correct if it’s not the best code they could have written, it’s still correct. I think that most that we can do to help developers avoid doing the wrong thing -like using EN when they need to do, you know, processing on the string output and anything we can do to make sure that developers don’t do that is a step in the right direction and definitely is a (inaudible) problem. +SFC: One of the motivating examples here is the CLDR non break space that broke a number of websites. We had a discussion about that in the TG2 meeting a couple of months ago. Exactly the use case. Now, that particular use case could have been avoided with Temporal. So if Temporal had existed the developer who wrote the code that word with space may not have broken it and could have used temporal. On the other hand temporal is – – if we can make this something that is accessible for developers, easier for developers to learn and figure out. We can sort of help developers avoid some of these foot guns. I think anything we can do to do that is fine. If a developer uses, for example, no locale solution possibility Number 2, their code is correct if it’s not the best code they could have written, it’s still correct. I think that most that we can do to help developers avoid doing the wrong thing like using EN when they need to do, you know, processing on the string output and anything we can do to make sure that developers don’t do that is a step in the right direction and definitely is a (inaudible) problem. DE: As SFC was saying, some of these usages have possible alternative APIs to more directly access the information. If we don’t want to define all of those explicit API to access this data, I wonder if these algorithms for stable formatting should be defined at the CLDR level. The Unicode consortium makes all sorts of stability guarantees for various purposes. This would let us avoid being in the business of defining stable format output. @@ -1902,14 +1446,11 @@ DE: Would be interested to investigate that and also the converse of that. The b DE: I don’t think avoiding relying on external bodies for stability should be a goal of ours. If we are working with another body with stability guarantees, if those guarantees make sense, that should be enough. I’m happy with this to go to Stage 1 but I hope before Stage 2 we have kind of a story worked out jointly with the Unicode consortium. I don’t know what zxx means exactly–does Unicode want us to use it this way? -EAO: We can definitely explore that as well. One point to make for the exact behaviour of the -formatters even though I think practically all implementations that currently exist ultimately -rely on CLDR data one way or the other, by explicitly saying that zxx would depend on CLDR data -we would be adding a sort of dependency that I don’t think we currently have from 402 onwards. +EAO: We can definitely explore that as well. One point to make for the exact behaviour of the formatters even though I think practically all implementations that currently exist ultimately rely on CLDR data one way or the other, by explicitly saying that zxx would depend on CLDR data we would be adding a sort of dependency that I don’t think we currently have from 402 onwards. DE: That’s right. Everything is still implementation-defined right now. This would be well-defined. Might be a reference to specific Unicode-defined algorithms, for example. -SFC: Even if we normatively refer to CLDR for this which I think is a perfectly, you know, reasonable thing to consider, it’s still a proposal in ECMA-402 if we want to say if you use locales zxx as an example that you get, you know, a certain type of behavior. That is still a change that we make that we proposal. I think that like the degree to which behavior lives in the CLDR specification in normative reference versus the degree to which we actually put the text into 402 or to 262 is, you know, something that we can explore. +SFC: Even if we normatively refer to CLDR for this which I think is a perfectly, you know, reasonable thing to consider, it’s still a proposal in ECMA-402 if we want to say if you use locales zxx as an example that you get, you know, a certain type of behavior. That is still a change that we make that we proposal. I think that like the degree to which behavior lives in the CLDR specification in normative reference versus the degree to which we actually put the text into 402 or to 262 is, you know, something that we can explore. But ultimately the problem that we’re solving is the same and it’s just a mechanism of which standards body holds which sections of the algorithms. DLM: Thank you. I was just wondering if you could elaborate or explain more on what the stability guarantees are in CLDR go at that because the web compatibility problem was a switch of spaces to narrow spaces in local. @@ -1920,12 +1461,11 @@ MF: So I understand that there is a problem that inspired this research. But I a EAO: If I may reply, I agree it would be great not to have people parsing strings. The issue that we are solving now is that people are parsing strings. -MF: This doesn’t stop people passing the Swedish locale to toString. They can still do that. This is giving them a different locale to use. Why parse the month out of the date representation instead of just accessing the month property on the date? This doesn’t seem like something we should be encouraging. +MF: This doesn’t stop people passing the Swedish locale to toString. They can still do that. This is giving them a different locale to use. Why parse the month out of the date representation instead of just accessing the month property on the date? This doesn’t seem like something we should be encouraging. USA: Shane has a response to that. -SFC: Solution Number 1 is the approach that anything that developers could reasonably want out of402 we have somewhere else in the specification that they can use. That is solution possibility Number 1. If we want to have a discussion of pros and cons of Number 1 versus -Number 2 that are different versions to solve the problem we can have the discussion. +SFC: Solution Number 1 is the approach that anything that developers could reasonably want out of402 we have somewhere else in the specification that they can use. That is solution possibility Number 1. If we want to have a discussion of pros and cons of Number 1 versus Number 2 that are different versions to solve the problem we can have the discussion. MF: I think I just don't fully understand solution 1 and I feel like I oppose solution 2. @@ -1939,13 +1479,11 @@ EAO: So, for example, I’m not deeply familiar myself with collator and segment EAO: But the APIs we are currently providing give no way for a user code to stably be able to access this and know they are accessing this and that future later changes of info formatters without change this fact to give them different results that they’re currently getting. -RGN: Just want to express support for some kind of solution here and recognition of the problem having a reference to stable locale independent algorithms would be really nice. No matter where the solution takes place. Obviously this is spanning a few organizational boundaries -but I think that’s fine. +RGN: Just want to express support for some kind of solution here and recognition of the problem having a reference to stable locale independent algorithms would be really nice. No matter where the solution takes place. Obviously this is spanning a few organizational boundaries but I think that’s fine. -KG: Seconding what MF said. To the extent any part of this is motivated by "I want to output something, I don’t care what the format is, I just need it to be a nice stable format because I’m going to write a parser against that format". I’m opposed to that. Things motivated by something else, like I want to use this particular well defined algorithm and there’s nothing that exposes that currently, I’m happy to expose such an algorithm. For example with using the Swedish locale to get ISO formatted dates, I’m fine with exposing something to give you ISO formatted dates. When there is some particular format that you want to achieve, and we’re adding a way to achieve that particular format and the format is independently motivated as something people would want, I'm fine with all of that. I'm not fine with the feature request, "I just want anything arbitrary that is stable so I can parse it". I don’t think we should be motivating anything by parsing strings even though I know that’s a thing that people do. +KG: Seconding what MF said. To the extent any part of this is motivated by "I want to output something, I don’t care what the format is, I just need it to be a nice stable format because I’m going to write a parser against that format". I’m opposed to that. Things motivated by something else, like I want to use this particular well defined algorithm and there’s nothing that exposes that currently, I’m happy to expose such an algorithm. For example with using the Swedish locale to get ISO formatted dates, I’m fine with exposing something to give you ISO formatted dates. When there is some particular format that you want to achieve, and we’re adding a way to achieve that particular format and the format is independently motivated as something people would want, I'm fine with all of that. I'm not fine with the feature request, "I just want anything arbitrary that is stable so I can parse it". I don’t think we should be motivating anything by parsing strings even though I know that’s a thing that people do. -USA: I support this proposal. Thank you for bringing it. And I prefer the second solution that you proposed. We went through a lengthy process of sort of the pros and cons within the design of Temporal and in the end sort of ended up with this solution of having this null value TimeZone in calendar, UTC and ISO and 861 respectively and we could repeat sort of -this analysis but I feel that the zxx solution is the most optimal one. +USA: I support this proposal. Thank you for bringing it. And I prefer the second solution that you proposed. We went through a lengthy process of sort of the pros and cons within the design of Temporal and in the end sort of ended up with this solution of having this null value TimeZone in calendar, UTC and ISO and 861 respectively and we could repeat sort of this analysis but I feel that the zxx solution is the most optimal one. LCA: Okay. This is short. I have motivation for like – first of all I think the second solution here is very reasonable and I have a motivation which is snapshot testing and would like a way to serialize objects arbitrary, object to stable strings to have cross versions for Snapshot testing. Don’t have a good way of doing that right now. This would help with that. I like this as such. @@ -1971,6 +1509,7 @@ USA: That is perfect. Exactly on time. Thank you everyone. We made a lot of time * Many JS programs rely on Intl algorithms maintaining stable output, but data in CLDR which backs these algorithms is not typically updated with such requirements in mind. This proposal adds a particular API which is guaranteed to give stable output. * We do not consider any use case where this stable output is later processed into its components by a machine to be valid. + ### Conclusion * The proposal advances to Stage 1 diff --git a/meetings/2023-09/september-28.md b/meetings/2023-09/september-28.md index d2490fb2..95402fe3 100644 --- a/meetings/2023-09/september-28.md +++ b/meetings/2023-09/september-28.md @@ -1,11 +1,9 @@ -98th TC39 Meeting -Thursday 28th September 2023 ----- -Delegates: re-use your existing abbreviations! If you’re a new delegate and don’t already have an abbreviation, choose any three-letter combination that is not already in use, and send a PR to add it upstream. +# 28 September, 2023 Meeting Notes -You can find Abbreviations in delegates.txt +----- + +**Remote and in person attendees:** -**Attendees:** | Name | Abbreviation | Organization | | -------------------- | ------------ | ----------------- | | Pablo Gorostiaga | PGO | Bloomberg | @@ -35,197 +33,89 @@ You can find Abbreviations in delegates.txt | Daniel Ehrenberg | DE | Bloomberg | | Philip Chimento | PFC | Igalia | | your name here -## Uint8Array-Base64: + +## Uint8Array-Base64 + Presenter: Kevin Gibbons (KG) - [proposal](https://github.com/tc39/proposal-arraybuffer-base64) -- [slides]() - -KG: Okay, so the Base64 proposal is at Stage 2. I’ve been working on it for a while. Last time I -presented this set of slides, I’m not going to go through the entire set of slides again, but -just to recap briefly, there is a relatively uncontroversial single shot method for encoding to -and from a Base64 string. A static method to give you a Uint8Array and a prototype method to give you a Base64 string and similarly for hex. Then there are in addition these streaming methods, which I’m -not going to go through in great detail, but the basic idea is that you have a fromPartialBase64 method and fromPartialHex methods that take this extra parameter and return a pair of -{results, extra} and you are required as the user to shepherd the extra state around between -calls to fromPartialBase64 until you have called all of your chunks. And then finalize at -the end, potentially. - -KG: And per a request, there was also a couple of methods for writing Base64 into an existing -buffer. That gives you even more stuff. It gives you written and read byte counts or character -and -- sorry, byte and character counts respectively. And this allows you to reuse existing -memory instead of allocating new memory for every chunk. Great, okay. That’s the shape of the -proposal as it stands. - -KG: When I presented this last time, there was uncertainty about whether -the streaming methods were worth it. And the sentiment had discussion on GitHub between myself -and LCA and PHE and others and and LCA has generously written, if I can find the link - https://github.com/lucacasonato/base64_streams - an implementation of streaming encoders and decoders using -the single shot version. So we have an encoder, for example, iterator or generator protocol -based encoder in terms of the toBase64 method that exists in the -proposal, the single-shot toBase64 method. Now, of course, this does require more work to -use than the streaming version that’s in the proposal, and in particular, it requires you to -know the details of the three byte to four -character mapping of Base64, but if you know those things or are just able to use a library that -uses those things, this is reasonably effective. - -KG: So given that there was disagreement about whether it was worth having the streaming methods in -the proposal, I’m hoping we can hash that out now and either unblock the proposal or determine -that it is not possible to unblock. Does anyone have comments? + +KG: Okay, so the Base64 proposal is at Stage 2. I’ve been working on it for a while. Last time I presented this set of slides, I’m not going to go through the entire set of slides again, but just to recap briefly, there is a relatively uncontroversial single shot method for encoding to and from a Base64 string. A static method to give you a Uint8Array and a prototype method to give you a Base64 string and similarly for hex. Then there are in addition these streaming methods, which I’m not going to go through in great detail, but the basic idea is that you have a fromPartialBase64 method and fromPartialHex methods that take this extra parameter and return a pair of +{results, extra} and you are required as the user to shepherd the extra state around between calls to fromPartialBase64 until you have called all of your chunks. And then finalize at the end, potentially. + +KG: And per a request, there was also a couple of methods for writing Base64 into an existing buffer. That gives you even more stuff. It gives you written and read byte counts or character and -- sorry, byte and character counts respectively. And this allows you to reuse existing memory instead of allocating new memory for every chunk. Great, okay. That’s the shape of the proposal as it stands. + +KG: When I presented this last time, there was uncertainty about whether the streaming methods were worth it. And the sentiment had discussion on GitHub between myself and LCA and PHE and others and and LCA has generously written, if I can find the link - https://github.com/lucacasonato/base64_streams - an implementation of streaming encoders and decoders using the single shot version. So we have an encoder, for example, iterator or generator protocol based encoder in terms of the toBase64 method that exists in the proposal, the single-shot toBase64 method. Now, of course, this does require more work to use than the streaming version that’s in the proposal, and in particular, it requires you to know the details of the three byte to four character mapping of Base64, but if you know those things or are just able to use a library that uses those things, this is reasonably effective. + +KG: So given that there was disagreement about whether it was worth having the streaming methods in the proposal, I’m hoping we can hash that out now and either unblock the proposal or determine that it is not possible to unblock. Does anyone have comments? CDA: Yeah, on the queue there is JHD. -JHD: Yeah, so you may have just said this, but I basically -- I was just trying to get a -reminder. This seems feels like it should be a separate proposal, the multishot like the -base -- the regular what are ones, and it just -- I’d love some understanding about why it has -to go together. and if you just said that, and I wasn’t paying attention, I apologize. - -KG: I would be ok with pulling it out, although I personally am unlikely to pursue the streaming -part myself because the single shot is the use case that I care most about. Perhaps, I don’t -know, PHE might be able to say more. - -PHE: Sure. So I mean, it kind of comes down to the need for any of this from our perspective. I -mean, please recall that when this was a Stage 0 proposal, my recommendation was that the -committee not adopt it, not move it to Stage 1. I think the -- and I think the reasons for -that still hold, which is it’s fairly low value. This Base64 has been around for all eternity, -JavaScript has been around for less of eternity, and somehow we’ve gotten this far. Maybe it -just doesn’t need to be in the language. And further, Base64 is not as simple as I think the -current draft of this proposal makes it look, when you dive through the RFCs and the different -places where Base64 is used, it’s pretty complex. So I mean, of course we can, as KG is -doing, we can start with a subset of that and see how it evolves. That’s perfectly reasonable. +JHD: Yeah, so you may have just said this, but I basically -- I was just trying to get a reminder. This seems feels like it should be a separate proposal, the multishot like the base -- the regular what are ones, and it just -- I’d love some understanding about why it has to go together. and if you just said that, and I wasn’t paying attention, I apologize. + +KG: I would be ok with pulling it out, although I personally am unlikely to pursue the streaming part myself because the single shot is the use case that I care most about. Perhaps, I don’t know, PHE might be able to say more. + +PHE: Sure. So I mean, it kind of comes down to the need for any of this from our perspective. I mean, please recall that when this was a Stage 0 proposal, my recommendation was that the committee not adopt it, not move it to Stage 1. I think the -- and I think the reasons for that still hold, which is it’s fairly low value. This Base64 has been around for all eternity, +JavaScript has been around for less of eternity, and somehow we’ve gotten this far. Maybe it just doesn’t need to be in the language. And further, Base64 is not as simple as I think the current draft of this proposal makes it look, when you dive through the RFCs and the different places where Base64 is used, it’s pretty complex. So I mean, of course we can, as KG is doing, we can start with a subset of that and see how it evolves. That’s perfectly reasonable. . -PHE: But, you know, everyone has Base64 support somehow somewhere that they -- if they really need -it they use, and in the embedded space, you know, in the Moddable universe, we do. We in fact -took the expedient approach. It’s a non-streaming API and we needed a streaming API for some -time, if we’re going to go through the work, to do standardization and bring this in, we think -that the standard should support all, you know, runtimes, all use cases, and embedded where -resources are limited, where we can’t -- we don’t have unlimited buffer sizes is very real, and -so if we’re going to do this at all, then it’s our position, and it has been since the start, -that we need to do it in a way that is generally valuable -- generally useful and valuable. -And not just this kind of one very focused case. And from there, it’s worth talking -about the example code that KG cited from LCA. That code, from our -- great that LCA did -it. I appreciate it. It helps bring some things into focus, and one of the things that it -brings into focus is that taking such an approach as he proposes doesn’t -guarantee forward compatibility. As the Base64 options increase in time, which is reasonable -to expect, the way that things are set up, it’s likely that one won’t be able to -continue to do what LCA has done. We already saw one example where he had missed something in -the handling of that requires some changes in the spec or code that are inefficient, and that’s -all well and good, but it’s an example of the fact that it’s not -- that it doesn’t have good -forward compatibility. - -PHE: The usual way to get to a one shot API is to take a streaming a and I do that and use it. So -we’d like to see that. The other thing I’m surprised at, and sorry I’m going long, but I seem -to be a lonely voice here, you know, this API has morphed quite a few times, and the most -recent change is something that is pretty bizarre, to me anyway, which is that it’s now -attached to the Uint8Array object, which is I think it is the first time that this language will have -different support on the different TypedArrays like that. And I mean, it’s not -- I mean, I -get that maybe Uint8Array is a convenient place to have it, but it’s not the only place, and I -think it -- I think we would be better served to keep the Base64 support as its own thing and -not a feature of Uint8Array, which just feels awkward and I mean -- and wrong, frankly. - -PHE: So, sorry, that’s a long statement, and I appreciate your patience in hearing it. But, I mean, -to answer your question, Jordan, in short, if we don’t do streaming support, I don’t think this -proposal brings much to the table, and if we pretend that streaming support can be provided -with -- can be implemented as a wrap around the one shot, I think we’re doing naive in terms of -how this is most likely to evolve. - -JHG: Okay. Thanks. I -- the queue is down so I wasn’t able to add my response. But I -appreciate the explanation. I think we have different perspectives on what is focused versus -general. To me, I find the streaming thing to be esoteric and niche and the one shot to be the -thing that is actually quite common. But it’s okay that we have different perspectives there. - -KG: The change to Uint8Array was like three meetings ago. I’m happy to discuss that elsewhere, -but I want to keep the discussion as to whether we should do streaming as part of this proposal -and whether we should do this proposal at all. Conditional on the outcome of the first -question, I think the details of where exactly it lives are less important than those -questions. I agree with JHG, though, 100%. Like, streaming is useful, I agree. But I -have needed the one shot version, like, 99 times in the last couple of years. And I have -needed streaming once, if I’m being generous. I just don’t see why it needs to be part of this -proposal. Like, I get that there are different domains where the streaming is the important -part, but the specific claim that I am making is that the one shot version is useful on its -own. +PHE: But, you know, everyone has Base64 support somehow somewhere that they -- if they really need it they use, and in the embedded space, you know, in the Moddable universe, we do. We in fact took the expedient approach. It’s a non-streaming API and we needed a streaming API for some time, if we’re going to go through the work, to do standardization and bring this in, we think that the standard should support all, you know, runtimes, all use cases, and embedded where resources are limited, where we can’t -- we don’t have unlimited buffer sizes is very real, and so if we’re going to do this at all, then it’s our position, and it has been since the start, +that we need to do it in a way that is generally valuable -- generally useful and valuable. +And not just this kind of one very focused case. And from there, it’s worth talking about the example code that KG cited from LCA. That code, from our -- great that LCA did it. I appreciate it. It helps bring some things into focus, and one of the things that it brings into focus is that taking such an approach as he proposes doesn’t guarantee forward compatibility. As the Base64 options increase in time, which is reasonable to expect, the way that things are set up, it’s likely that one won’t be able to continue to do what LCA has done. We already saw one example where he had missed something in the handling of that requires some changes in the spec or code that are inefficient, and that’s all well and good, but it’s an example of the fact that it’s not -- that it doesn’t have good forward compatibility. + +PHE: The usual way to get to a one shot API is to take a streaming a and I do that and use it. So we’d like to see that. The other thing I’m surprised at, and sorry I’m going long, but I seem to be a lonely voice here, you know, this API has morphed quite a few times, and the most recent change is something that is pretty bizarre, to me anyway, which is that it’s now attached to the Uint8Array object, which is I think it is the first time that this language will have different support on the different TypedArrays like that. And I mean, it’s not -- I mean, I get that maybe Uint8Array is a convenient place to have it, but it’s not the only place, and I think it -- I think we would be better served to keep the Base64 support as its own thing and not a feature of Uint8Array, which just feels awkward and I mean -- and wrong, frankly. + +PHE: So, sorry, that’s a long statement, and I appreciate your patience in hearing it. But, I mean, +to answer your question, Jordan, in short, if we don’t do streaming support, I don’t think this proposal brings much to the table, and if we pretend that streaming support can be provided with -- can be implemented as a wrap around the one shot, I think we’re doing naive in terms of how this is most likely to evolve. + +JHG: Okay. Thanks. I -- the queue is down so I wasn’t able to add my response. But I appreciate the explanation. I think we have different perspectives on what is focused versus general. To me, I find the streaming thing to be esoteric and niche and the one shot to be the thing that is actually quite common. But it’s okay that we have different perspectives there. + +KG: The change to Uint8Array was like three meetings ago. I’m happy to discuss that elsewhere, +but I want to keep the discussion as to whether we should do streaming as part of this proposal and whether we should do this proposal at all. Conditional on the outcome of the first question, I think the details of where exactly it lives are less important than those questions. I agree with JHG, though, 100%. Like, streaming is useful, I agree. But I have needed the one shot version, like, 99 times in the last couple of years. And I have needed streaming once, if I’m being generous. I just don’t see why it needs to be part of this proposal. Like, I get that there are different domains where the streaming is the important part, but the specific claim that I am making is that the one shot version is useful on its own. DE: I wanted to understand PHE’s feedback better, but not the part about streaming: You mentioned evolution of base64, maybe this proposal lacks additional options, as well as error handling. Could you elaborate on that? -PHE: Base64 has been around since forever, -right and, it’s used in many different places, and there are, as a result, a bunch of different -- a bunch of different variations in terms of padding, in terms of alphabet, in -terms of white space handling, and this affects both encoding and decoding. I spent some time -earlier this week just scanning through the different RFCs related to this, and I won’t say I -have a thorough understanding of it, but it’s fairly baffling. And then you -- I mean, you -have things -- you also have details like whether a decoder is permissive or strict and what it -accepts and what the does with unrecognized characters. And so all of those things, you know, -eventually potentially come into the scope of this API. You know, obviously not all initially, -but over time. It’s easy enough to imagine that. So, you know, it’s very -- I mean, basically -it’s impossible in the general case to achieve an efficient implementation of a streaming for -all those features if you’re relying on the one-shot API. And so I mean, that’s very -- yeah, -and so that’s a concern. Does that answer your question, Daniel, sorry? - -DE: I just want to continue the thread of clarifying a little bit more. Sometimes when there’s -multiple RFCs, one of them is outdated and one of them is current, even in the absence of formal deprecation. In your experience, in Moddable, have you needed to expose APIs or implement things for other options besides the ones implicitly -adopted here? - -PHE: I mean, we certainly have some Base64 behaviors which are different. But there’s things we -just haven’t done yet, which we need. You know, I think in the RFC case, specifically to your -point, I don’t think I’m looking at obsolete RFCs, I think what you’ll find if are to do the -survey, if you have, I don’t mean to suggest otherwise, but what I found is that the variations -were in different domains that use Base64. So it’s not that it evolved over time. It’s that, -you know, the miming coding here thing uses it differently than this other thing over there, so -it’s not that one is, you know, sadly out of date. These things are co-existing today. - -DE: Okay, thanks for explaining. Did you give a concrete example of a use case that doesn’t -match the semantics in this proposal? Just because I’m new to this area, I don’t know which flags end up being important. - -PHE: Right. The problem is that, you can as a one-shot, you could eventually -support anything by having enough options in the options bag. That’s for sure -the case. But what is being put forward by KG and LCA is that one could implement -streaming using the one shot, and that’s simply not the case, because - -DE: Peter, I’m asking a more basic question. Given that this proposal doesn’t include all the options in the world, like, what’s an example of an option that’s missing? Leaving aside streaming, just the one shot API, you said that there is more modes that get added over time, presumably there’s some missing feature that would just be useful now. So I’d like an example of that, because I don’t understand the area thoroughly. +PHE: Base64 has been around since forever, +right and, it’s used in many different places, and there are, as a result, a bunch of different -- a bunch of different variations in terms of padding, in terms of alphabet, in terms of white space handling, and this affects both encoding and decoding. I spent some time earlier this week just scanning through the different RFCs related to this, and I won’t say I have a thorough understanding of it, but it’s fairly baffling. And then you -- I mean, you have things -- you also have details like whether a decoder is permissive or strict and what it accepts and what the does with unrecognized characters. And so all of those things, you know, +eventually potentially come into the scope of this API. You know, obviously not all initially, +but over time. It’s easy enough to imagine that. So, you know, it’s very -- I mean, basically it’s impossible in the general case to achieve an efficient implementation of a streaming for all those features if you’re relying on the one-shot API. And so I mean, that’s very -- yeah, +and so that’s a concern. Does that answer your question, Daniel, sorry? + +DE: I just want to continue the thread of clarifying a little bit more. Sometimes when there’s multiple RFCs, one of them is outdated and one of them is current, even in the absence of formal deprecation. In your experience, in Moddable, have you needed to expose APIs or implement things for other options besides the ones implicitly adopted here? + +PHE: I mean, we certainly have some Base64 behaviors which are different. But there’s things we just haven’t done yet, which we need. You know, I think in the RFC case, specifically to your point, I don’t think I’m looking at obsolete RFCs, I think what you’ll find if are to do the survey, if you have, I don’t mean to suggest otherwise, but what I found is that the variations were in different domains that use Base64. So it’s not that it evolved over time. It’s that, +you know, the miming coding here thing uses it differently than this other thing over there, so it’s not that one is, you know, sadly out of date. These things are co-existing today. + +DE: Okay, thanks for explaining. Did you give a concrete example of a use case that doesn’t match the semantics in this proposal? Just because I’m new to this area, I don’t know which flags end up being important. + +PHE: Right. The problem is that, you can as a one-shot, you could eventually support anything by having enough options in the options bag. That’s for sure the case. But what is being put forward by KG and LCA is that one could implement streaming using the one shot, and that’s simply not the case, because + +DE: Peter, I’m asking a more basic question. Given that this proposal doesn’t include all the options in the world, like, what’s an example of an option that’s missing? Leaving aside streaming, just the one shot API, you said that there is more modes that get added over time, presumably there’s some missing feature that would just be useful now. So I’d like an example of that, because I don’t understand the area thoroughly. PHE: Yeah, sorry, I didn’t come prepared to answer that precise a question. -KG: Maybe I can give some illustration of the kinds of options. The ones that I am -aware of - one of the ways in which Base64 encoders and decoders differ is the choice of -alphabet, specifically whether you’re using the web-safe variant or not. Then there’s the handling -of whitespace, as PHE mentioned, the mime base64 spec says things about white space has to -be stripped. Other things say white space has to be an error, and there’s handling of padding. -There’s in fact two different axes on which handling the padding can vary. There’s whether you -require, allow, or forbid the presence of the trailing equal signs, and then there’s the 2-4 additional bits in the last character -for certain strings, which should, according to the RFC, be enforced to be zero, but no one -actually enforces that there’s zero. I’m not aware of any variations other than that, but it’s -certainly conceivable that there’s some out there. Those are the kinds of variations that -exist, though. Hopefully that’s illustrative. - -DE: Yeah, thanks. Could you briefly go over those which you make hookable and which additions you might expect? - -KG: Because the proposal isn’t settled, I’m not completely settled on all of these, but the -current plan is that you can pass in a choice of alphabet as either the web-safe or the base -variant. White space is unconditionally stripped and not generated in the output, and -padding is unconditionally generated in the output, and much to my dismay, not enforced in the -input. But open to changing any of those that the proposal is still open for tweaks of that -kind. - -DE: Okay, are you aware of any future-proofing risk for these sort of options with -respect to the stateless streaming API that you have? - -KG: There is some complexity around handling of streaming and padding, but it’s, like, -doable. LCA has done it. The white space, again, if you have very strict rules about where -the white space must appear, then streaming is more complicated in handling those, although, I -don’t think anyone actually enforces those. Otherwise, no, not aware of any issues. +KG: Maybe I can give some illustration of the kinds of options. The ones that I am aware of - one of the ways in which Base64 encoders and decoders differ is the choice of alphabet, specifically whether you’re using the web-safe variant or not. Then there’s the handling of whitespace, as PHE mentioned, the mime base64 spec says things about white space has to be stripped. Other things say white space has to be an error, and there’s handling of padding. +There’s in fact two different axes on which handling the padding can vary. There’s whether you require, allow, or forbid the presence of the trailing equal signs, and then there’s the 2-4 additional bits in the last character for certain strings, which should, according to the RFC, be enforced to be zero, but no one actually enforces that there’s zero. I’m not aware of any variations other than that, but it’s certainly conceivable that there’s some out there. Those are the kinds of variations that exist, though. Hopefully that’s illustrative. + +DE: Yeah, thanks. Could you briefly go over those which you make hookable and which additions you might expect? + +KG: Because the proposal isn’t settled, I’m not completely settled on all of these, but the current plan is that you can pass in a choice of alphabet as either the web-safe or the base variant. White space is unconditionally stripped and not generated in the output, and padding is unconditionally generated in the output, and much to my dismay, not enforced in the input. But open to changing any of those that the proposal is still open for tweaks of that kind. + +DE: Okay, are you aware of any future-proofing risk for these sort of options with respect to the stateless streaming API that you have? + +KG: There is some complexity around handling of streaming and padding, but it’s, like, +doable. LCA has done it. The white space, again, if you have very strict rules about where the white space must appear, then streaming is more complicated in handling those, although, I don’t think anyone actually enforces those. Otherwise, no, not aware of any issues. DE: Okay, are we aware of any brewing proposed extensions for base64 that could affect this in? KG: I am not aware of any proposed extensions. -DE: Okay. Yeah, I think, PHE, if at some point later in the process of the development of -this, if you could assess whether your survey led to kind of differing results, that would be really useful in making sure that we’re not leaving any of these things out. +DE: Okay. Yeah, I think, PHE, if at some point later in the process of the development of this, if you could assess whether your survey led to kind of differing results, that would be really useful in making sure that we’re not leaving any of these things out. -DE: Okay, my next queue item is just about streaming versus non-streaming. I suspect that most usage of this will be non-streaming. But the streaming API doesn’t seem too complicated. And there’s a kind of logically reasonable case that in general, when we do a calculation of something that’s potentially big, that there should be a streaming version of it. So I think that’s why it logically fits together in the same proposal potentially. That said, I would be okay with the streaming version removed from this proposal. +DE: Okay, my next queue item is just about streaming versus non-streaming. I suspect that most usage of this will be non-streaming. But the streaming API doesn’t seem too complicated. And there’s a kind of logically reasonable case that in general, when we do a calculation of something that’s potentially big, that there should be a streaming version of it. So I think that’s why it logically fits together in the same proposal potentially. That said, I would be okay with the streaming version removed from this proposal. -WH: I am a bit negative on the streaming API because it’s so easy to use -incorrectly. In fact, the examples given in the proposal use it incorrectly where sometimes it -will crash instead of doing the right thing. +WH: I am a bit negative on the streaming API because it’s so easy to use incorrectly. In fact, the examples given in the proposal use it incorrectly where sometimes it will crash instead of doing the right thing. -KG: I agree that there’s definitely some difficulty in using the streaming API, although, I -wasn’t aware that I had any bugs. +KG: I agree that there’s definitely some difficulty in using the streaming API, although, I wasn’t aware that I had any bugs. WH: The bug in the GitHub explanation of how to use the API: if the input length is zero, it doesn’t work. @@ -233,158 +123,69 @@ KG: [scrolls to API usage example] WH: Yeah — do you see the bug? -KG: Yes, because `extra` is undefined here. Yeah. - -KG: That’s true. That’s a bug. I fully agree that at least this design for streaming is a -little bit error prone, although, my hope is that most people would copy/paste snippet that -just does the right thing. - -SYG: I want to better understand PHE’s argument against the utility of the single shot API. So -the arguments I’ve heard so far are there’s a lot of various choices, and actually, I don’t -know what that argument is, I guess because there are a lot of various choices, we shouldn’t -pick a particular thing because there’s not enough utility there. I think I also heard an -argument about specifically Moddable’s IoT environment making it difficult to implement or -something. Did I mishear that? Is there -- I want to tease apart if there’s an -implementability concern versus a utility concern. - -PHE: I don’t -- sure. The utility can certainly be achieved in time with enough options. That’s -not in question. I don’t -- with all due respect, I don’t think we have yet a good -understanding of what all the -- what all the options are. And how complex that -- or not that -gets. But the -- I mean, the implementability, I mean, we can implement this. The problem is -the usefulness of it, which is, you know, there can be very big pieces of Base64 data, you -know, arriving, for example, over the network. And in our environments, we may -not -- I mean, very realistically, may not be able to hold all of that -- all of that Base64 -source text, for example, in memory at one time to be able to accumulate it to then be able to -call the one shot API, so we have to be able to break that up into pieces. We have to be able -to process that in pieces and sync the output as it’s processed. So it has to be streamed to -be able to be used on larger pieces of data. - -SYG: Thanks, I understand the difficulty in leveraging the single shot -- the one-shot API in -Moddable’s particular environment I don’t quite understand why it then follows that the single -shot is not generally useful for most other environments. - -PHE: I have no objection to the existence of the single shot API. I’m sure it’s generally useful -in other environments. I object to only having a one shot API. - -SYG: Right. That’s the part I don’t follow. Why object to only -- Moddable can just ignore it -and use its own streaming? Is it like you don’t want to ship it and that there’s some concerns -there? +KG: Yes, because `extra` is undefined here. Yeah. + +KG: That’s true. That’s a bug. I fully agree that at least this design for streaming is a little bit error prone, although, my hope is that most people would copy/paste snippet that just does the right thing. + +SYG: I want to better understand PHE’s argument against the utility of the single shot API. So the arguments I’ve heard so far are there’s a lot of various choices, and actually, I don’t know what that argument is, I guess because there are a lot of various choices, we shouldn’t pick a particular thing because there’s not enough utility there. I think I also heard an argument about specifically Moddable’s IoT environment making it difficult to implement or something. Did I mishear that? Is there -- I want to tease apart if there’s an implementability concern versus a utility concern. + +PHE: I don’t -- sure. The utility can certainly be achieved in time with enough options. That’s not in question. I don’t -- with all due respect, I don’t think we have yet a good understanding of what all the -- what all the options are. And how complex that -- or not that gets. But the -- I mean, the implementability, I mean, we can implement this. The problem is the usefulness of it, which is, you know, there can be very big pieces of Base64 data, you know, arriving, for example, over the network. And in our environments, we may not -- I mean, very realistically, may not be able to hold all of that -- all of that Base64 source text, for example, in memory at one time to be able to accumulate it to then be able to call the one shot API, so we have to be able to break that up into pieces. We have to be able to process that in pieces and sync the output as it’s processed. So it has to be streamed to be able to be used on larger pieces of data. + +SYG: Thanks, I understand the difficulty in leveraging the single shot -- the one-shot API in Moddable’s particular environment I don’t quite understand why it then follows that the single shot is not generally useful for most other environments. + +PHE: I have no objection to the existence of the single shot API. I’m sure it’s generally useful in other environments. I object to only having a one shot API. + +SYG: Right. That’s the part I don’t follow. Why object to only -- Moddable can just ignore it and use its own streaming? Is it like you don’t want to ship it and that there’s some concerns there? PHE: The benefits -- SYG: I don’t understand what the downside is. -PHE: If we’re going to go through the work of standardizing something, I think we should do it in -a way that’s generally useful. And streaming of Base64 is generally useful. I understand it’s -not -- it’s in the minority, but we’re designing a language to be generally useful, not kind of -cherry picking the most prominent use cases. And so -- - -SYG: Okay. I mean, I think single shot is generally useful. It may not be universally useful. -I think it is -- I think we have pretty good intuition that it is generally useful in a way -that is more so than streaming. I haven’t heard arguments that it is not generally useful. I -don’t quite understand why bundling -- like, I don’t understand the negative implication that -because streaming is -- because streaming is also claimed to be generally useful, it must be -bundled into the same proposal for the whole -- for the one-shot to also be worth it. Like, +PHE: If we’re going to go through the work of standardizing something, I think we should do it in a way that’s generally useful. And streaming of Base64 is generally useful. I understand it’s not -- it’s in the minority, but we’re designing a language to be generally useful, not kind of cherry picking the most prominent use cases. And so -- + +SYG: Okay. I mean, I think single shot is generally useful. It may not be universally useful. +I think it is -- I think we have pretty good intuition that it is generally useful in a way that is more so than streaming. I haven’t heard arguments that it is not generally useful. I don’t quite understand why bundling -- like, I don’t understand the negative implication that because streaming is -- because streaming is also claimed to be generally useful, it must be bundled into the same proposal for the whole -- for the one-shot to also be worth it. Like, that’s -- I just don’t understand that argument. -PHE: I mean, I think I don’t like the framing of the argument, sorry, SYG. I think the question -is if this committee is going to do Base64 support, it should take on the scope of that, which -is used throughout the language and not just picking the most prominent case of that. I think -kind of framing it as a -- you know, single shot is useful, so I mean, we could pick apart lots -of proposals and break them into parts and stage them that way, but we don’t because we’re -trying to deliver a set of functionality that’s useful. And here one shot is convenient, but -streaming -- so, great, we should have that, but streaming is the thing that lets you handle -the broader set of cases. So streaming is foundational. You can always implement a one shot -from streaming, but not the other way around. - -SYG: I think we disagree on that, but we can leave that disagreement, I think. But as a matter -of process, this committee literally does pick apart things and advance them separately. Like, +PHE: I mean, I think I don’t like the framing of the argument, sorry, SYG. I think the question is if this committee is going to do Base64 support, it should take on the scope of that, which is used throughout the language and not just picking the most prominent case of that. I think kind of framing it as a -- you know, single shot is useful, so I mean, we could pick apart lots of proposals and break them into parts and stage them that way, but we don’t because we’re trying to deliver a set of functionality that’s useful. And here one shot is convenient, but streaming -- so, great, we should have that, but streaming is the thing that lets you handle the broader set of cases. So streaming is foundational. You can always implement a one shot from streaming, but not the other way around. + +SYG: I think we disagree on that, but we can leave that disagreement, I think. But as a matter of process, this committee literally does pick apart things and advance them separately. Like, that’s how we have operated. -LCA: Yeah, so I want to start with that ultimately, I would be okay with shipping in proposal -with either streaming or not streaming. I would prefer we do not ship it with streaming. I -think utility of single shot encoding is well understood. And it has, like, implications in -many runtimes. I can also see the argument for why we should -- where there should be some way -do streaming. I think is a much smaller subset of people that would use this, be I agree that -there are use cases. What I am more concerned about is that on the web where the majority of -streaming applications are going to happen and where, like, streaming is particularly useful -because you’re on devices with little memory, you are -- you have network streams, slow -networks, so streaming can be useful there, in those scenarios, you want to have a streaming -API which is very efficient, and web -- and the web platform provides a streaming API for this, -and web streams, which are highly optimizable by engines because they can by pass JavaScript -while doing transforms for natively implemented streams. And this API in 262 where we shuttle -around the extra bytes manually does not fit into that. It means that every project will have -to write a wrapper transferring stream around -- yeah, around these extra bytes, and I have an -example of that in the repo, I think. +LCA: Yeah, so I want to start with that ultimately, I would be okay with shipping in proposal with either streaming or not streaming. I would prefer we do not ship it with streaming. I think utility of single shot encoding is well understood. And it has, like, implications in many runtimes. I can also see the argument for why we should -- where there should be some way do streaming. I think is a much smaller subset of people that would use this, be I agree that there are use cases. What I am more concerned about is that on the web where the majority of streaming applications are going to happen and where, like, streaming is particularly useful because you’re on devices with little memory, you are -- you have network streams, slow networks, so streaming can be useful there, in those scenarios, you want to have a streaming API which is very efficient, and web -- and the web platform provides a streaming API for this, +and web streams, which are highly optimizable by engines because they can by pass JavaScript while doing transforms for natively implemented streams. And this API in 262 where we shuttle around the extra bytes manually does not fit into that. It means that every project will have to write a wrapper transferring stream around -- yeah, around these extra bytes, and I have an example of that in the repo, I think. . -LCA: But, yeah, it’s not great. So really, for the web platform, what we need is a streaming API, -which is based directly on public streams. And yeah, we can ship in 262, but that makes the -utility of the streaming API in 262 even smaller. Like, now the use case is, like, anything -that does not implement what wick streams and cannot use the single shot API, which 1% of 1% of -1%. And I don’t -- like, I just don’t see the value of shipping this in the language. And, -like, implementation complexity that comes with it for such a small subset of users. I would -prefer that those users can just import a helper that wraps around the single shot API. - -PHE: Sure, thanks. LCA, I mean, on one point, we agree strongly, which is I’m not wild about -the way that the streaming API returns the state. You know, in earlier discussion on this, we -had explored briefly options where an instance would manage that state, and it could be quite a -bit more efficient. But that was -- that direction didn’t seem to have traction, so that led -to what we have now. But there I agree with you, we could do better. I think we could have an -API that was easier to use and more efficient if we could have gotten past some of those -objections. - -LCA: Okay. Yeah, I just want to mention that even if we were to go with API, manually -implementing web stream would incur at least two native JavaScript to native native to -JavaScript copies that are involved. - -KG: So concretely, the only optimizable thing on the web -platform is a web stream, so I think if the web platform decides that streaming is worth doing, -even if we have the thing in JavaScript, I expect what would ship a streaming one, like, the -only reason they haven’t because I told them I was going to do this proposal and they wanted to -make sure that the design would line up. But you need the WHATWG streaming one to be efficient -on the web. - -PHE: I mean, I think it’s great. We should actually take into requirements the implementation -limitations of the web and how it optimizes, just as we take into account other environments. +LCA: But, yeah, it’s not great. So really, for the web platform, what we need is a streaming API, +which is based directly on public streams. And yeah, we can ship in 262, but that makes the utility of the streaming API in 262 even smaller. Like, now the use case is, like, anything that does not implement what wick streams and cannot use the single shot API, which 1% of 1% of 1%. And I don’t -- like, I just don’t see the value of shipping this in the language. And, +like, implementation complexity that comes with it for such a small subset of users. I would prefer that those users can just import a helper that wraps around the single shot API. + +PHE: Sure, thanks. LCA, I mean, on one point, we agree strongly, which is I’m not wild about the way that the streaming API returns the state. You know, in earlier discussion on this, we had explored briefly options where an instance would manage that state, and it could be quite a bit more efficient. But that was -- that direction didn’t seem to have traction, so that led to what we have now. But there I agree with you, we could do better. I think we could have an API that was easier to use and more efficient if we could have gotten past some of those objections. + +LCA: Okay. Yeah, I just want to mention that even if we were to go with API, manually implementing web stream would incur at least two native JavaScript to native native to JavaScript copies that are involved. + +KG: So concretely, the only optimizable thing on the web platform is a web stream, so I think if the web platform decides that streaming is worth doing, +even if we have the thing in JavaScript, I expect what would ship a streaming one, like, the only reason they haven’t because I told them I was going to do this proposal and they wanted to make sure that the design would line up. But you need the WHATWG streaming one to be efficient on the web. + +PHE: I mean, I think it’s great. We should actually take into requirements the implementation limitations of the web and how it optimizes, just as we take into account other environments. I have no problem with that. -LCA: I guess I just want to clear up, like, there is no possible API we can design TC39 that will -be as efficient as web streams. It is -- any API we design in TC39 will require bytes to go -through JavaScript that with the web stream implementation do not have to go through -JavaScript, and that is inherently slower. That’s end of my comment. +LCA: I guess I just want to clear up, like, there is no possible API we can design TC39 that will be as efficient as web streams. It is -- any API we design in TC39 will require bytes to go through JavaScript that with the web stream implementation do not have to go through JavaScript, and that is inherently slower. That’s end of my comment. -DLM: We discussed this internally in the SpiderMonkey team and we are -completely convinced about the utility of the one shot variant. We are definitely not as -convinced about the streaming. I feel like the number of iterations that we’ve seen on -different streaming APIs sort of demonstrates that it’s not fully baked. And so I think we -would be very happy to see it this proposal advance with just the one-shot version. And, yeah, -I think that’s all I have to say. Thanks. +DLM: We discussed this internally in the SpiderMonkey team and we are completely convinced about the utility of the one shot variant. We are definitely not as convinced about the streaming. I feel like the number of iterations that we’ve seen on different streaming APIs sort of demonstrates that it’s not fully baked. And so I think we would be very happy to see it this proposal advance with just the one-shot version. And, yeah, +I think that’s all I have to say. Thanks. -NRO: This was more reply to -- the reply to original -- JHD’s comments. It was mentioned that -the reason we need the streaming API in this proposal, like, now is so that if in the future we -have more options to the one shot API, this -- like, it might not be possible to polyfill the a -user land. It’s been done in the exam. Could we add the streaming API once we add those -options to Michael impossible to reproduce in user land? +NRO: This was more reply to -- the reply to original -- JHD’s comments. It was mentioned that the reason we need the streaming API in this proposal, like, now is so that if in the future we have more options to the one shot API, this -- like, it might not be possible to polyfill the a user land. It’s been done in the exam. Could we add the streaming API once we add those options to Michael impossible to reproduce in user land? -PHE: But that would require people retrofitting. Deployed code would then have to change to do -that, right? I mean, people have been -- would be shipping this effectively polyfill, as you -describe it, and then it would have to go away. But, I mean, how would anybody know to do -that? It would be -- it would break things, right? +PHE: But that would require people retrofitting. Deployed code would then have to change to do that, right? I mean, people have been -- would be shipping this effectively polyfill, as you describe it, and then it would have to go away. But, I mean, how would anybody know to do that? It would be -- it would break things, right? -NRO: I mean, the code would have to be updated to use the new options of the recent update to do -anyway. +NRO: I mean, the code would have to be updated to use the new options of the recent update to do anyway. -KG: It wouldn’t break anything. It would only -- if you wanted to decode this, like, new kind -of Base64, you would have to update your library to support the new kind of Base64 and use that -in terms of the updated underlying primitive. But, like -- +KG: It wouldn’t break anything. It would only -- if you wanted to decode this, like, new kind of Base64, you would have to update your library to support the new kind of Base64 and use that in terms of the updated underlying primitive. But, like -- -PHE: I mean, that’s -- I mean, that’s slightly -- I mean, that’s -- I wouldn’t agree with that. -Like, if what you believe as a user of code is that you’re using a streaming version of the -Base64 API that’s the language, and then the language updates, you wouldn’t necessarily assume -that the code you’ve been using to stream would be broken. +PHE: I mean, that’s -- I mean, that’s slightly -- I mean, that’s -- I wouldn’t agree with that. +Like, if what you believe as a user of code is that you’re using a streaming version of the Base64 API that’s the language, and then the language updates, you wouldn’t necessarily assume that the code you’ve been using to stream would be broken. -PHE: I mean, if you had implemented it, you might, but if were just using some code from -somebody, you wouldn’t. +PHE: I mean, if you had implemented it, you might, but if were just using some code from somebody, you wouldn’t. JHD: But it wouldn’t be broken. @@ -392,143 +193,75 @@ PHE: And that’s true of any polyfill. JHD: It would be true if you used any of the options, it would be broken. -KG: Yes, generally speaking, you can’t use new options with old things, but I don’t regard that -as a serious problem. +KG: Yes, generally speaking, you can’t use new options with old things, but I don’t regard that as a serious problem. -PHE: Sorry, I feel like -- I feel like you’re talking past the problem. If the user has a piece -of code that they’re using that they didn’t write, they don’t fully understand it, they just -know, hey, I can do streaming Base64 with this using the same options as the JavaScript -language spec and then the JavaScript language spec upgrades, the -- why would they expect that -the streaming thing would break? There’s no good reason for that. They don’t know. +PHE: Sorry, I feel like -- I feel like you’re talking past the problem. If the user has a piece of code that they’re using that they didn’t write, they don’t fully understand it, they just know, hey, I can do streaming Base64 with this using the same options as the JavaScript language spec and then the JavaScript language spec upgrades, the -- why would they expect that the streaming thing would break? There’s no good reason for that. They don’t know. -KG: PHE, that happens all the time, and it’s just not a big deal. Like, many people have -shipped the APIs that are vaguely modeled after underlying JavaScript APIs and then the -underlying JavaScript APIs update and the libraries shipped on top of them don’t and it just -doesn’t matter. You update the library eventually. This is not a serious problem. +KG: PHE, that happens all the time, and it’s just not a big deal. Like, many people have shipped the APIs that are vaguely modeled after underlying JavaScript APIs and then the underlying JavaScript APIs update and the libraries shipped on top of them don’t and it just doesn’t matter. You update the library eventually. This is not a serious problem. -JHD: I’ll jump in. Peter, I’ve shipped hundreds of polyfills that have had new features added -in the language and I have to update the polyfills and this is concretely and objectively and empirically not a problem in practice. This is how every polyfill works. That’s just how it works. That’s an unavoidable fact. +JHD: I’ll jump in. Peter, I’ve shipped hundreds of polyfills that have had new features added in the language and I have to update the polyfills and this is concretely and objectively and empirically not a problem in practice. This is how every polyfill works. That’s just how it works. That’s an unavoidable fact. -PHE: Yeah, I mean, we -- anyway, I -- I will take your word on it, JHD:. I really don’t see it -that way. But thank you. +PHE: Yeah, I mean, we -- anyway, I -- I will take your word on it, JHD:. I really don’t see it that way. But thank you. -SFC: Yeah, all I have to say here is that use cases that I’ve encountered, especially when -shepherding data around between different clients is that, like, JSON streaming API, JSON -parsing streaming API would be quite useful and this seems like it would go very well with -that. I just, you know, wanted to throw that out there in case maybe there’s interest in sort -of pursuing Base64 that’s own proposal and having another proposal that’s all streaming parsing -including JSON and other things that might also be useful in the context of the web platform. +SFC: Yeah, all I have to say here is that use cases that I’ve encountered, especially when shepherding data around between different clients is that, like, JSON streaming API, JSON parsing streaming API would be quite useful and this seems like it would go very well with that. I just, you know, wanted to throw that out there in case maybe there’s interest in sort of pursuing Base64 that’s own proposal and having another proposal that’s all streaming parsing including JSON and other things that might also be useful in the context of the web platform. That’s all. -KG: Okay, great. So we’ve heard from several people, including browsers, that they don’t -believe it’s worth doing these streaming API and we’ve heard from a number of people, myself -included, that the single shot API would be incredibly useful. And while there’s a -philosophical disagreement about whether a proposal needs to expand to meet, like, the fully -general form, several people, myself included, think that it doesn’t need to meet the fully -general form to be useful, at least if the more restricted form is not, like, going to be only -a subset of the bigger form. If the single shot form would be worth doing even in -a world with streaming, then we can just do the single shot version. So I would really like to -go forward with just the single shot version. - so I guess I’d like to ask for that, ask for -consensus to restrict the scope of this proposal to the single shot version. +KG: Okay, great. So we’ve heard from several people, including browsers, that they don’t believe it’s worth doing these streaming API and we’ve heard from a number of people, myself included, that the single shot API would be incredibly useful. And while there’s a philosophical disagreement about whether a proposal needs to expand to meet, like, the fully general form, several people, myself included, think that it doesn’t need to meet the fully general form to be useful, at least if the more restricted form is not, like, going to be only a subset of the bigger form. If the single shot form would be worth doing even in a world with streaming, then we can just do the single shot version. So I would really like to go forward with just the single shot version. +so I guess I’d like to ask for that, ask for consensus to restrict the scope of this proposal to the single shot version. [+1 from LCA, NRO, JHD, DLM, Christian, MF, DE] -CDA: Fantastic. Where there any objections? +CDA: Fantastic. Where there any objections? PHE: Yeah, I'm still not comfortable with this. -KG: Okay. I’ll go do this in WHATWG, I guess. Thanks for the feedback. - -PHE: I mean, KG, I think we should have a conversation about this and see if we can find some -way forward. I think. - -KG: I’ve spent two years on this. I don’t think there’s a way forward. Like, did you -hear the discussion that we just had? People in the room do not want a streaming -version. Some people are okay with it, some people are opposed. We can’t have a streaming -version that’s as efficient as a web stream anyway. The single shot version is independently -useful. The single shot version, like, is 99.9% of my use case, I know that’s true for others. -I just -- I don’t think there’s a path forward here. And I would like to be able to do -Base64 encoding in node and on the web, and I just don’t see a way to make that happen -with this proposal anymore. - -SYG: Can I make a comment? So, like, for people many the room to observe what is happening, -which is that the alternative is not that this doesn’t happen, the alternative is that this -happens in a different standards body. We’re not the gatekeeper of APIs. We’re gate keeps of -the syntax. If there’s a new API that has sufficient demand, it probably finds a way, despite -objections from people in the room, so keep that in mind. - -DE: I want to agree, so we had the UUID proposal here and it ended up moving to a web platform -API. I would really like TC39 to be a good place where we can add standard library features. -And in this case, we should maybe even reconsider our process with respect to, you know, the -single lone objector being a determinant. I think it depends on the nature of the particular -objection to whether it should be blocking. In this case, we just haven’t heard an -argument where others can understand the weight of it. So I think if this goes -to other standards bodies, we know that those other standards bodies are places where most of -us have more trouble participating in a way that has the equal weight that we have in TC39. So -that would be, you know, potentially a worse result. So we should consider whether our -decision-making methods in TC39 are conducive to what our shared committee goals are of -developing a standard library. - -MLS: So I’d like to weigh in here. TC39 does not have a consensus process. We have a lone -dissenter blocking process. And I’ve been subject to that in the past. We have one member of -the committee that is making the point that the API -- the standalone API is not useful, but a -streaming API is. They are part of the larger JavaScript community, not a browser, not Node. -I think -- I don’t see why we’re not willing to allow a streaming API, even though it’s not the -most efficient, we’re not willing to allow this as a give and take in the deliberation process -so that we can reach consensus. - -KG: So I would feel better about that if in fact the claim had been that the single shot API -wasn’t useful. But, as far as I can tell, everyone thinks the one shot API is useful. -And if we can’t advance that, I just don’t see it being worth participating in the -process here. Like, we have a thing that everyone likes. Everyone agrees it’s useful. - -MLS: But you would agree that Base64, since it, the decoding of future letters in a sequence -are based upon the context of prior letters, that a streaming API actually does make sense? +KG: Okay. I’ll go do this in WHATWG, I guess. Thanks for the feedback. + +PHE: I mean, KG, I think we should have a conversation about this and see if we can find some way forward. I think. + +KG: I’ve spent two years on this. I don’t think there’s a way forward. Like, did you hear the discussion that we just had? People in the room do not want a streaming version. Some people are okay with it, some people are opposed. We can’t have a streaming version that’s as efficient as a web stream anyway. The single shot version is independently useful. The single shot version, like, is 99.9% of my use case, I know that’s true for others. +I just -- I don’t think there’s a path forward here. And I would like to be able to do Base64 encoding in node and on the web, and I just don’t see a way to make that happen with this proposal anymore. + +SYG: Can I make a comment? So, like, for people many the room to observe what is happening, +which is that the alternative is not that this doesn’t happen, the alternative is that this happens in a different standards body. We’re not the gatekeeper of APIs. We’re gate keeps of the syntax. If there’s a new API that has sufficient demand, it probably finds a way, despite objections from people in the room, so keep that in mind. + +DE: I want to agree, so we had the UUID proposal here and it ended up moving to a web platform API. I would really like TC39 to be a good place where we can add standard library features. +And in this case, we should maybe even reconsider our process with respect to, you know, the single lone objector being a determinant. I think it depends on the nature of the particular objection to whether it should be blocking. In this case, we just haven’t heard an argument where others can understand the weight of it. So I think if this goes to other standards bodies, we know that those other standards bodies are places where most of us have more trouble participating in a way that has the equal weight that we have in TC39. So that would be, you know, potentially a worse result. So we should consider whether our decision-making methods in TC39 are conducive to what our shared committee goals are of developing a standard library. + +MLS: So I’d like to weigh in here. TC39 does not have a consensus process. We have a lone dissenter blocking process. And I’ve been subject to that in the past. We have one member of the committee that is making the point that the API -- the standalone API is not useful, but a streaming API is. They are part of the larger JavaScript community, not a browser, not Node. +I think -- I don’t see why we’re not willing to allow a streaming API, even though it’s not the most efficient, we’re not willing to allow this as a give and take in the deliberation process so that we can reach consensus. + +KG: So I would feel better about that if in fact the claim had been that the single shot API wasn’t useful. But, as far as I can tell, everyone thinks the one shot API is useful. +And if we can’t advance that, I just don’t see it being worth participating in the process here. Like, we have a thing that everyone likes. Everyone agrees it’s useful. + +MLS: But you would agree that Base64, since it, the decoding of future letters in a sequence are based upon the context of prior letters, that a streaming API actually does make sense? KG: I agree -CDA: Sorry, I’ve got to interrupt. We are at-time for this item. I would ask that PHE, if you -are withholding consensus on this item, can you please articulate your objection for the notes. +CDA: Sorry, I’ve got to interrupt. We are at-time for this item. I would ask that PHE, if you are withholding consensus on this item, can you please articulate your objection for the notes. -PHE: My objection is that this, to be useful in our environment, which is a standard -JavaScript environment, that streaming is a necessary feature, and so we would like to see that -advance in parallel with the one shot capability. +PHE: My objection is that this, to be useful in our environment, which is a standard JavaScript environment, that streaming is a necessary feature, and so we would like to see that advance in parallel with the one shot capability. KG: That’s not an objection. PHE: That is an objection. -KG: I personally would not use this in my environment, is not an objection to a thing being -useful. +KG: I personally would not use this in my environment, is not an objection to a thing being useful. PHE: KG KG: Am I going crazy? -PHE: KG, you know what, sorry, it’s a little, I mean seriously, I’m a little frustrated that -you, in particular, but the committee in general, really doesn’t take or seem to take seriously -that we have a different set of constraints. We are very respectful of the constraints of web -platform and do a huge amount of work to support those, and we do it happily so we can get -interoperability for our users. But there are some places where we have constraints that can’t -magically evaporate, and one of them is that we do have an infinite buffer space. And if every -time we raise that, you know, the committee’s response is well, but it doesn’t bug us, this big -use case over here is fine, the language, little by little, erodes its usefulness in our -environment, and that’s a real concern. So we would like to see this resolved, and I’d really -appreciate a little bit more respect for the fact that have there is a real technical challenge -here we have to address solely than solely focus on the 1% of the 1% of the 1%. It’s -not helpful to marginalize it in that way. - -KG: I fully accept that moddable has additional constraints and I appreciate why you would want -a streaming API. But what I have asked for is for the single-shot API, which is useful for -many people, including Moddable. I very frequently to sufficiently small Base64 decoding that -it would be useful on an embedded platform, and I have not heard an objection to advancing -that. I genuinely do not understand what the objection to advancing that item is. +PHE: KG, you know what, sorry, it’s a little, I mean seriously, I’m a little frustrated that you, in particular, but the committee in general, really doesn’t take or seem to take seriously that we have a different set of constraints. We are very respectful of the constraints of web platform and do a huge amount of work to support those, and we do it happily so we can get interoperability for our users. But there are some places where we have constraints that can’t magically evaporate, and one of them is that we do have an infinite buffer space. And if every time we raise that, you know, the committee’s response is well, but it doesn’t bug us, this big use case over here is fine, the language, little by little, erodes its usefulness in our environment, and that’s a real concern. So we would like to see this resolved, and I’d really appreciate a little bit more respect for the fact that have there is a real technical challenge here we have to address solely than solely focus on the 1% of the 1% of the 1%. It’s not helpful to marginalize it in that way. + +KG: I fully accept that moddable has additional constraints and I appreciate why you would want a streaming API. But what I have asked for is for the single-shot API, which is useful for many people, including Moddable. I very frequently to sufficiently small Base64 decoding that it would be useful on an embedded platform, and I have not heard an objection to advancing that. I genuinely do not understand what the objection to advancing that item is. [break] -KG: There’s just an update to say, we have the GitHub comment from PHE that if in fact the one-shot APIs are sufficient to implement streaming with reasonable efficiency and without future compatibility concerns, he will withdraw his objection. So I am intending to work towards demonstrating that and flushing out the spec text and writing up with all the ROCs and labour and so on. I believe it is possible to do a streaming implementation that is fine. So conditional on that. I will come back later, if that is not going to satisfy anyone else in the room, please let me know before I do all of this work. Thanks very much. +KG: There’s just an update to say, we have the GitHub comment from PHE that if in fact the one-shot APIs are sufficient to implement streaming with reasonable efficiency and without future compatibility concerns, he will withdraw his objection. So I am intending to work towards demonstrating that and flushing out the spec text and writing up with all the ROCs and labour and so on. I believe it is possible to do a streaming implementation that is fine. So conditional on that. I will come back later, if that is not going to satisfy anyone else in the room, please let me know before I do all of this work. Thanks very much. + ### Summary + - KG raised the question, once again: Should the ArrayBuffer base64 proposal have built-in support for streaming? - The committee generally agreed that the single-shot API is quite useful and should become part of the JS standard - PHE raised additional concerns about other options or flags being relevant to base64, but neither he nor KG were aware of any missing details. They will research this before the next meeting. @@ -538,102 +271,67 @@ KG: There’s just an update to say, we have the GitHub comment from PHE that if - WH opposed the streaming API because it is currently designed in a confusing way - PHE argued that streaming was essential for embedded platforms, and this proposal should not advance without it. - SYG and KG remarked that, if this is blocked in TC39, it will be standardized in WHATWG instead. + ### Conclusion + - PHE blocked the proposal from advancing to Stage 3 because, in embedded platforms such as Moddable, some use cases require a streaming approach to base64 encoding, and this proposal does not provide that built-in - The appropriateness of this block was contested by multiple committee members. - Further discussion in a future meeting of TC39 is expected given the follow-on in https://github.com/tc39/proposal-arraybuffer-base64/issues/13 ## Negated in and instanceof operators for Stage 1 + Presenter: Pablo Gorostiaga Belio (PGO) - [proposal](https://github.com/gorosgobe/proposal-negated-in-instanceof) - slides -PGO: All right. My name is Pablo. I’m a new delegate from Bloomberg and today I’m going to present my proposal, negated in and instanceof operators for Stage 1. So -currently, if you have an in or instanceof expression and you need to negate those, you -need to wrap the whole expression in parentheses with the grouping operator and then you need -to negate that with the logical operator, the exclamation mark. Now, this has several issues. -The first issue with negating in and instanceof expressions this way is you may forget to -parenthesise the expression. As a result, if you apply the not operator on the -left-hand side operand of the expression, that expression, except for some niche cases, will -evaluate to false. So for the code on the screen there, the body of those if statements will not -execute. And the correct usage is obviously to parenthesise that properly. +PGO: All right. My name is Pablo. I’m a new delegate from Bloomberg and today I’m going to present my proposal, negated in and instanceof operators for Stage 1. So currently, if you have an in or instanceof expression and you need to negate those, you need to wrap the whole expression in parentheses with the grouping operator and then you need to negate that with the logical operator, the exclamation mark. Now, this has several issues. +The first issue with negating in and instanceof expressions this way is you may forget to parenthesise the expression. As a result, if you apply the not operator on the left-hand side operand of the expression, that expression, except for some niche cases, will evaluate to false. So for the code on the screen there, the body of those if statements will not execute. And the correct usage is obviously to parenthesise that properly. . -PGO: There are tools that detect these, this scenario, so TypeScript does produce errors, as you -can see there on the left-hand side. There’s also an ESlint rule that is called no-unsafe-negation that would detect this pattern statically. However, we wanted to find out whether that was enough and see if code in the wild had these sorts of problems. And in particular, we wanted to sort of answer two questions here. So are in and instanceof ever used in negated expressions in the first place, and if so, are there any bugs in these negated expressions. And we looked at open source code through Sourcegraph. We found for in and, we found 7 thousand negated expressions through Sourcegraph, 10,000 for instanceof. And we also looked at those expressions that had the bug where the left-hand side had the not operator as opposed to the entire expression. And for in, we found 2,000 hits. For instanceof, 19,000, so those queries are there on the right if you want to run them. +PGO: There are tools that detect these, this scenario, so TypeScript does produce errors, as you can see there on the left-hand side. There’s also an ESlint rule that is called no-unsafe-negation that would detect this pattern statically. However, we wanted to find out whether that was enough and see if code in the wild had these sorts of problems. And in particular, we wanted to sort of answer two questions here. So are in and instanceof ever used in negated expressions in the first place, and if so, are there any bugs in these negated expressions. And we looked at open source code through Sourcegraph. We found for in and, we found 7 thousand negated expressions through Sourcegraph, 10,000 for instanceof. And we also looked at those expressions that had the bug where the left-hand side had the not operator as opposed to the entire expression. And for in, we found 2,000 hits. For instanceof, 19,000, so those queries are there on the right if you want to run them. -PGO: We also looked at some examples within those queries to see what sort of code was affected by -these bugs. And the reality is that we found a lot of high traffic, well-known repositories had -these bugs. So on the left-hand side, you see a list of 15 examples of repositories with bugs -in negated in expressions and on the right-hand side, you see another 15 examples of bugs in -negated instanceof expressions. Separately from the open source analysis, we also run our own -internally at Bloomberg. We looked at the AST of a large set of internal projects and we found that around one in seven in expressions are negated. For instanceof around one in eight. Out of those negated expressions, 1% of negated in had bugs of the form that I described earlier and 6% for instanceof had bugs. This is out of the total of negated expressions. +PGO: We also looked at some examples within those queries to see what sort of code was affected by these bugs. And the reality is that we found a lot of high traffic, well-known repositories had these bugs. So on the left-hand side, you see a list of 15 examples of repositories with bugs in negated in expressions and on the right-hand side, you see another 15 examples of bugs in negated instanceof expressions. Separately from the open source analysis, we also run our own internally at Bloomberg. We looked at the AST of a large set of internal projects and we found that around one in seven in expressions are negated. For instanceof around one in eight. Out of those negated expressions, 1% of negated in had bugs of the form that I described earlier and 6% for instanceof had bugs. This is out of the total of negated expressions. PGO: Another issue here is that there’s an inconsistency in the language. We have some operators that have a negated version. Example here is triple equals has not double equals. However, with in and instanceof, we don’t have such equivalent, the negated counterpart. And that makes it quite unintuitive and a bit confusing for developers. And here are two examples of stack overflow questions that have been asked relating to negated in and negated instanceof operators within the language. You’ll notice that these were asked 11 years ago and have been viewed hundreds of thousands of times, with the top one specifically modified very recently. So this is something that people are still searching for. -PGO: There are other issues with these negated expression, readability suffers when negating in and -instanceof expressions in this way. If you read the examples there on the left, we have not A -and B, not A instanceof C, which doesn’t flow in English. You’d expect something more like A not in -B or A not instanceof C. And perhaps this is also a reason why these bugs occur, is that mental association between the not operator and the left-hand side operand that happens when you read expressions this way. Finally, developer experience is also impacted if you want to negate an expression, you can’t simply just negate the operator. You just have to wrap it with parentheses every time. +PGO: There are other issues with these negated expression, readability suffers when negating in and instanceof expressions in this way. If you read the examples there on the left, we have not A and B, not A instanceof C, which doesn’t flow in English. You’d expect something more like A not in B or A not instanceof C. And perhaps this is also a reason why these bugs occur, is that mental association between the not operator and the left-hand side operand that happens when you read expressions this way. Finally, developer experience is also impacted if you want to negate an expression, you can’t simply just negate the operator. You just have to wrap it with parentheses every time. -PGO: So the proposed solution is to introduce a negated in and a negated instanceof operators into the language. This is an example of what it could look like. You could use not the exclamation mark and -in exclamation mark of the instance as the on rates raters. You can see at the bottom how that -would simplify what we have in the language. There has been a separate proposal by JHD to -use explicitly the keyword not, “not”, instead of the exclamation mark here. Those are -definitely things that we can look into after Stage 1. I also looked at how all the languages, to see what sort of syntax other languages use for infix negation. And it looks like for the most part, languages use “not” or the exclamation mark, namely you have Python, C# as examples that use “not”, and Kotlin, for example, uses the bang, the exclamation mark token. +PGO: So the proposed solution is to introduce a negated in and a negated instanceof operators into the language. This is an example of what it could look like. You could use not the exclamation mark and in exclamation mark of the instance as the on rates raters. You can see at the bottom how that would simplify what we have in the language. There has been a separate proposal by JHD to use explicitly the keyword not, “not”, instead of the exclamation mark here. Those are definitely things that we can look into after Stage 1. I also looked at how all the languages, to see what sort of syntax other languages use for infix negation. And it looks like for the most part, languages use “not” or the exclamation mark, namely you have Python, C# as examples that use “not”, and Kotlin, for example, uses the bang, the exclamation mark token. -PGO: So that’s it. Thank you, and I’d like to ask for Stage 1. +PGO: So that’s it. Thank you, and I’d like to ask for Stage 1. -CDA: We have a lot of people in the queue. First up, JHD. +CDA: We have a lot of people in the queue. First up, JHD. JHD: I very much support the proposal. I have a strong preference for using the word “not”, as you mentioned. There’s a few other comments on the queue later that I think strengthen that. But either way, we should look into solving this problem, which would be Stage 1. CDA:JWK. -JWK: I also plus one for this proposal. But we cannot use the ! symbol because it will -be interpreted as `A! in B`, which means the non-null assertion in TypeScript and the older -version will not interpret it right. I also want this proposal can match with pattern matching, which is using `not` as the pattern. +JWK: I also plus one for this proposal. But we cannot use the ! symbol because it will be interpreted as `A! in B`, which means the non-null assertion in TypeScript and the older version will not interpret it right. I also want this proposal can match with pattern matching, which is using `not` as the pattern. PGO: Thank you for the feedback. CDA: RBN? -RBN: Yeah, and I’ll first reiterate what JWK said. There is, there would be an issue with -TypeScript in that post-fix exclamation is used for non-null assertion. So that would be a -very complicated issue for us. I don’t think we would have another way of addressing that -other than having to error on cases where that might exist without a space today. But the -other thing, is and this isn’t an objection to this proposal, but just something to consider, one of the things that we’ve been considering as part of the pattern matching proposal is either immediately or as a future addon is the potential for what are frequently called relational patterns, which generally include things like greater than, less than, equals in a pattern, but also could include things like in. So with the concept, or with pattern matching having the ability to do negation, one of the things that we plan to present in the -future is the use of an instanceof operator to do pattern matching there a Boolean expression, which -would give you the ability to say X not in Y or not in instance of Y, because we might not need -instance of, because the other thing we are considering with pattern matching is X is Y, and if -Y is a class that would be using the instance of or instance functionality. anyway. So in -pattern matching, you might be able to express as X is in the in Y in the negated case and X is -not in Y for the negated instance case. There might be press tense for this or a capabilities -to do this in pattern matching and as JWK saidings it would be useful to have consistency with -the not keyword cases if both exist. +RBN: Yeah, and I’ll first reiterate what JWK said. There is, there would be an issue with TypeScript in that post-fix exclamation is used for non-null assertion. So that would be a very complicated issue for us. I don’t think we would have another way of addressing that other than having to error on cases where that might exist without a space today. But the other thing, is and this isn’t an objection to this proposal, but just something to consider, one of the things that we’ve been considering as part of the pattern matching proposal is either immediately or as a future addon is the potential for what are frequently called relational patterns, which generally include things like greater than, less than, equals in a pattern, but also could include things like in. So with the concept, or with pattern matching having the ability to do negation, one of the things that we plan to present in the future is the use of an instanceof operator to do pattern matching there a Boolean expression, which would give you the ability to say X not in Y or not in instance of Y, because we might not need instance of, because the other thing we are considering with pattern matching is X is Y, and if Y is a class that would be using the instance of or instance functionality. anyway. So in pattern matching, you might be able to express as X is in the in Y in the negated case and X is not in Y for the negated instance case. There might be press tense for this or a capabilities to do this in pattern matching and as JWK saidings it would be useful to have consistency with the not keyword cases if both exist. CDA: WH? -WH: I just wanted to correct one the slides in the presentation, which made the claim that all -the comparison operators except `in` and `instanceof` have negated versions. This is actually -incorrect. The only operators which have currently negated versions are the first two: `==` and `===`. -`!<` is not the same thing as `>=`. And `!<=` is not the same thing as `>`. There are actually 14 -possible non-trivial operators comparing two numbers, out of which we only have 6 in the -language at the moment. +WH: I just wanted to correct one the slides in the presentation, which made the claim that all the comparison operators except `in` and `instanceof` have negated versions. This is actually incorrect. The only operators which have currently negated versions are the first two: `==` and `===`. +`!<` is not the same thing as `>=`. And `!<=` is not the same thing as `>`. There are actually 14 possible non-trivial operators comparing two numbers, out of which we only have 6 in the language at the moment. -DE: This is my fault. An earlier draft of these slides had another column that said it doesn't work with NaN. And I asked Pablo to take it out because it was just a distraction. So I think this is all very well known by everybody here. And it doesn’t really make sense to repeat that. Like, it’s negated in some higher logical sense. But we all understand the NaN caveat. +DE: This is my fault. An earlier draft of these slides had another column that said it doesn't work with NaN. And I asked Pablo to take it out because it was just a distraction. So I think this is all very well known by everybody here. And it doesn’t really make sense to repeat that. Like, it’s negated in some higher logical sense. But we all understand the NaN caveat. WH: Okay. My point is, there is room for adding the negated versions if we want to. -DE: What does that mean for this proposal? +DE: What does that mean for this proposal? -WH: Stage 1 is exploring the problem space. The problem space of negating operators is bigger than just `in` and `instanceof`. +WH: Stage 1 is exploring the problem space. The problem space of negating operators is bigger than just `in` and `instanceof`. DE: Ah OK, sounds good to me. NRO: So I was surprised by these numbers, by like the amount of mistakes that people made according to data. I checked how they work, and none of them help make the mistake more obvious. I have not A and B. It remains as this. But like we, a bunch of repositories and maintainers had parenthesis, if you write not A and B that is parenthesis, not A instanceof B. That is the mistake is more obvious. Not everybody uses tools. But given how popular formatters are, this would probably help produce the mistake without necessarily needing to change the language. -DE: I was initially skeptical when I heard of the proposal. Adding syntax has a cost. Peter said about the other proposal, we have been living without this for a long time. The analysis of how people get this wrong, mostly in tests, but also mostly in projects that use TypeScript and linters, which do check for these things (and correct them, at least hopefully will correct them in the future), the fact this is so common seems to indicate not that this proposal will immediately solve all the problems that wouldn’t make sense. But it shows a mismatch in the mental model of people, causing them to not write the right syntax. We don’t have a comparison for Python or the other languages that have this feature, but I suspect that it’s just easier to remember the `not in` form. So I think this proposal makes sense. The next step would be to work out this potential TypeScript grammar conflict issue. +DE: I was initially skeptical when I heard of the proposal. Adding syntax has a cost. Peter said about the other proposal, we have been living without this for a long time. The analysis of how people get this wrong, mostly in tests, but also mostly in projects that use TypeScript and linters, which do check for these things (and correct them, at least hopefully will correct them in the future), the fact this is so common seems to indicate not that this proposal will immediately solve all the problems that wouldn’t make sense. But it shows a mismatch in the mental model of people, causing them to not write the right syntax. We don’t have a comparison for Python or the other languages that have this feature, but I suspect that it’s just easier to remember the `not in` form. So I think this proposal makes sense. The next step would be to work out this potential TypeScript grammar conflict issue. DRO [on queue]: Huge +1 to other forms. Preference for “not”. @@ -645,39 +343,39 @@ RGN: We support the proposal, with a preference for `!`-prefixing. DRR: Yeah. I will be honest, I am skeptical of this. I don’t think that, I feel like you are adding a new way to do it, which is helpful for people who know about the new way. But this old form, if you introduce a new one, is going to stick around and people are going to do this. And so you have added two new solutions. So I am not going to block Stage 1. I try to keep an open mind. But I think that I don’t know. There may be better ways to tackle this. -DRR: And also, if we do in the end with a negation in pattern matching, I think I would be okay with something like this, where it falls out, and we just get it, we need it or get it for free in some sense out of grammar additions. On its own, I am a little skeptical. +DRR: And also, if we do in the end with a negation in pattern matching, I think I would be okay with something like this, where it falls out, and we just get it, we need it or get it for free in some sense out of grammar additions. On its own, I am a little skeptical. JRL: I made this mistake a week and a half ago, I forgot to put the parenthesis around the no and got the completely incorrect code. I debugged for an hour to figure out what went wrong. Some solution is needed and I would love to do it. -WH: Yeah. The numbers in the presentation were interesting, but I don’t see how this proposal will prevent people from writing `!` in front of the first argument. +WH: Yeah. The numbers in the presentation were interesting, but I don’t see how this proposal will prevent people from writing `!` in front of the first argument. PGO: Sorry. You don’t see the proposal for what? WH: How will this prevent people from writing bugs like on the screen right now? -PGO: Yeah. So it definitely does not prevent them from writing what is, you know, being the correct negated expression. The hope is that by providing a more ergonomic version of not in, and not instanceof. Let’s go to the slide I want to show here. This one. +PGO: Yeah. So it definitely does not prevent them from writing what is, you know, being the correct negated expression. The hope is that by providing a more ergonomic version of not in, and not instanceof. Let’s go to the slide I want to show here. This one. -PGO: People are looking for these types of operators. And I think the issue here is that they do not find them. +PGO: People are looking for these types of operators. And I think the issue here is that they do not find them. PGO: And so they are led to believe that not applied to the left-hand side, because they make a mistake, would produce the correct output. So the hope is not obviously to prevent that from happening because we can’t prevent them. You can still write that. But the hope is that they would use the new way purely from, you know, from other languages where it is possible and natural and reach out for. If we make it available to them, these bugs will not appear. -WH: Okay. My other concern is, while `! in` works well with the ECMAScript grammar, `not in` would complicate parsing a fair bit. There may be cases where it’s confused with something else. +WH: Okay. My other concern is, while `! in` works well with the ECMAScript grammar, `not in` would complicate parsing a fair bit. There may be cases where it’s confused with something else. -PGO: Could you elaborate this? +PGO: Could you elaborate this? -WH: You may run into issues with `not` similar to the `async of` confusion. It’s hard for me to come up with these in real time, but we’ve had troubles like this with the grammar in the past. We have not added any infix operators which use an identifier as the operator name. +WH: You may run into issues with `not` similar to the `async of` confusion. It’s hard for me to come up with these in real time, but we’ve had troubles like this with the grammar in the past. We have not added any infix operators which use an identifier as the operator name. -PGO: I think we can definitely explore other options there for the syntax. Yeah. +PGO: I think we can definitely explore other options there for the syntax. Yeah. -CDA: All right. On the queue we have – + 1 on these operators getting negated. Definitely natural in other languages. And JWK with support for Stage 1 of ergonomics. All right. Any other, that’s it for the queue. Are there any other thoughts? +CDA: All right. On the queue we have – + 1 on these operators getting negated. Definitely natural in other languages. And JWK with support for Stage 1 of ergonomics. All right. Any other, that’s it for the queue. Are there any other thoughts? CDA: Okay. I believe, PGOis asking for Stage 1 for this proposal. There were many + 1s. Are there any objections? Whoever supported, are those easily scrapable so we can have folks who supported consensus in the summary and conclusion or alternatively, can we reaffirm your support for this proposal for Stage 1? CDA: I am not hearing anything and I don’t see anything on the queue. -WH: I wanted to follow up with my comment of an example of what I am concerned about. For `let not in`. +WH: I wanted to follow up with my comment of an example of what I am concerned about. For `let not in`. -JHD: Can you even use the in operator in that position anyway? +JHD: Can you even use the in operator in that position anyway? WH: Open (let not in) followed by something else. So that becomes ambiguous whether it’s a let, it’s a let binding of something called not or whether it’s a binding of let, not in some, I guess you could have used not in, in that case. @@ -689,12 +387,12 @@ CDA: RBN? RBN: To WH’s comment, not instance would be legal in a place where you could otherwise already have a binary expression and in the case of for `let not in`, any use of that side, wouldn’t that require to be an assignment investigation, which it wouldn’t pass? LeftHandSideExpresion -WH: My comment was incorrect. +WH: My comment was incorrect. -CDA: I am looking for people to explicitly support this for Stage 1 for consensus. +CDA: I am looking for people to explicitly support this for Stage 1 for consensus. Explicit support for stage 1 from: -JWK, +JWK, JRL, CZW, Hax, @@ -706,23 +404,26 @@ DE, EAO, ### Speaker's Summary of Key Points -* Proposal was presented for Stage 1 -* This proposal adds `!in` and `!instanceof` operators to avoid the confusion of an extra set of parentheses in this common case -* Split preference between `!` and `not`. -* Some committee members argued that the syntax should use `not` instead of `!`, for an analogy with pattern matching -* It was pointed out that `!` could cause compatibility issues with TypeScript’s non-null assertion, and would be difficult to address from TypeScript’s side. -* DRR expressed skepticism about the value of adding such an operator + +- Proposal was presented for Stage 1 +- This proposal adds `!in` and `!instanceof` operators to avoid the confusion of an extra set of parentheses in this common case +- Split preference between `!` and `not`. +- Some committee members argued that the syntax should use `not` instead of `!`, for an analogy with pattern matching +- It was pointed out that `!` could cause compatibility issues with TypeScript’s non-null assertion, and would be difficult to address from TypeScript’s side. +- DRR expressed skepticism about the value of adding such an operator + ### Conclusion -* Proposal achieves Stage 1 with widespread committee support +- Proposal achieves Stage 1 with widespread committee support ## Locale Extensions for Stage 1 Presenter: Ben Allen (BAN) + - proposal: https://github.com/ben-allen/locale-extensions - slides -BAN: All right. So this is a proposal where, how can I put it? The appeal to it is fairly straightforward. But the thing that I will talk about are potential problems with it. Because mitigating those problems is the thing that is necessary to make the proposal work. +BAN: All right. So this is a proposal where, how can I put it? The appeal to it is fairly straightforward. But the thing that I will talk about are potential problems with it. Because mitigating those problems is the thing that is necessary to make the proposal work. BAN: So the positive thing that we are looking for, the problems to solve are received to localization. Related to people wanting to be able to request content that differs from their default locale. Whichever localized version of browser, they prefer them to be localized differently. The three interrelated problems that we are considering are, oftentimes and I think this is the most important one, there are a number of regions with different competing number systems. And without a way to specify which numbering system you want, users could easily get content that’s actually just unintelligible to them because the numbering system is one they don’t read. @@ -732,24 +433,24 @@ BAN: Also, some users have combinations of preferences that differ from the defa BAN: The next slide. You might have noticed there is an elephant in this room, which is all stuff that directly touches on users. And there’s, no concept of user here in TC39. -BAN: It is in fact actually more directly related to other standards organizations advancing through the W3C process. There is a possibility that the solutions might require touching Intel, adding support for extension tags. We discovered a couple days ago that 402 is a context where fingerprint is a real concern. So this proposal could serve as a locus for discussing fringe printing red lighting in general. I don’t want to stress, we are only asking for Stage 1 to explore the problem space. We could decide not to advance to Stage 1 or other standard groups. +BAN: It is in fact actually more directly related to other standards organizations advancing through the W3C process. There is a possibility that the solutions might require touching Intel, adding support for extension tags. We discovered a couple days ago that 402 is a context where fingerprint is a real concern. So this proposal could serve as a locus for discussing fringe printing red lighting in general. I don’t want to stress, we are only asking for Stage 1 to explore the problem space. We could decide not to advance to Stage 1 or other standard groups. BAN: So here is problem number 1. And this is the corner of the problem that is most important to me. As I said at the start, there are locales where there are multiple competing numbering systems. And like the ones that are most curable, a lot of middle eastern regions where both Latin referred to and eastern aerobic numbers are in use. Also, this shows up in HI as well. Which defaults to Latin numbers even though people requesting that locale might prefer Deva. A word I typed out thousands of times. BAN: The problem number 2. So this is the most important one. Problem number 2 is users will have content tailoring desires that differ from the defaults used in the locale the content they’re [vee]ing it in the a plurality of sites only offer content in English, and US is translated in the web and that’s a region with just highly idiosyncratic defaults of hours of the day, 12 hours cycle, instead of 24. Temperature measurement, Fahrenheit instead of Celsius, and the US uses Sunday as the first date of the week rather than Monday. And users might want to view these things in a Morley globally common way. This is an example of if you look up the temperature in San Jose, on the BBC’s website, if you don’t know, America can look at this and see that’s a cold day for San Jose. I am not sure it gets down to that cold there. American weather sites will often default to showing temperatures in Fahrenheit which is very, very confusing. And annoying for people who are expecting to see Celsius. So one of the things we want to do is provide a means for users to request a number system they want. Another thing we want to do is provide a way here, in sites where like wouldn’t necessarily want to make a log in for this. But where you would nevertheless prefer to see content localized in a way to understand. -BAN: And the third problem is, sometimes like for this one, this problem is solved by saying, okay. I want a way to specify that I would prefer this to be in celsius or Fahrenheit. Give these, is tailored for the UK or US, which is accomplished with the UR PTag. There’s a third problem which is that sometimes users might want something that differs from both the locale, the content is in, and their local locale as a specified weather browser. It might be fairly common for people to request content in ENUS, with celsius is the temperature and nothing else changed because more or less, like, for example, the Mexico region, largely uses tailoring that resembles the US except for Celsius. It’s possible to have that, I have downloaded the ENUS on the browser. I would nevertheless, set the system to display temperatures in C and I would like that preference to be honoured on the web. +BAN: And the third problem is, sometimes like for this one, this problem is solved by saying, okay. I want a way to specify that I would prefer this to be in celsius or Fahrenheit. Give these, is tailored for the UK or US, which is accomplished with the UR PTag. There’s a third problem which is that sometimes users might want something that differs from both the locale, the content is in, and their local locale as a specified weather browser. It might be fairly common for people to request content in ENUS, with celsius is the temperature and nothing else changed because more or less, like, for example, the Mexico region, largely uses tailoring that resembles the US except for Celsius. It’s possible to have that, I have downloaded the ENUS on the browser. I would nevertheless, set the system to display temperatures in C and I would like that preference to be honoured on the web. BAN: These are all things that would be useful to have. These are things that would make the ambient experience of the web better. There is a problem within the problem. This is a problem that is sort of pervasive across internationalization. If we were to directly expose, for example, the user’s operating system preferences directly as servers, this would make users with nondefault settings especially users with idiosyncratic settings identifiable. This is sort of like a particular problem in the the condition [T*EBS] of internationalization because when you’re asking for localization customization ace, you are saying deep about who you are. BAN: So, for example, if you’re requesting, you could, by requesting, indicate you’re part of a politically disadvantaged minority or something like that. It’s a case where fingerprinting reduces the person’s anonymity to a small level that they are identifiable by servers is a serious problem. -So the goal is to let users express their consent fully as possible. It’s something we want to be tremendously careful with. While prioritizing tailorings that might seriously impact the content of illegal if ignored. We want people to be able to get content that’s intelligible to them with little effort adds possible leaving a small fingerprinting surface as possible. +So the goal is to let users express their consent fully as possible. It’s something we want to be tremendously careful with. While prioritizing tailorings that might seriously impact the content of illegal if ignored. We want people to be able to get content that’s intelligible to them with little effort adds possible leaving a small fingerprinting surface as possible. -BAN: And the goal that I have set for this is, the fingerprinting surface established through whatever mechanism we choose, should be actually smaller than the surface offered by one entry and accept language. Also all fingerprinting that happens must be detectable. +BAN: And the goal that I have set for this is, the fingerprinting surface established through whatever mechanism we choose, should be actually smaller than the surface offered by one entry and accept language. Also all fingerprinting that happens must be detectable. -BAN: Allowing users to express arbitrary preferences. We don't want to expose things to servers because, well, that immediately identifies that person. Not interested in making web applications that are flexible as native applications. You can expose things to your own computer that you don’t want to expose to the Internet as a whole. And not finding information at all because you have to review information to reveal localization. I am like going to glance off of these now +BAN: Allowing users to express arbitrary preferences. We don't want to expose things to servers because, well, that immediately identifies that person. Not interested in making web applications that are flexible as native applications. You can expose things to your own computer that you don’t want to expose to the Internet as a whole. And not finding information at all because you have to review information to reveal localization. I am like going to glance off of these now -BAN: One solution is, and this is the thing, most immediately impact it because it requires supporting a tag, supporting the UR did the tag. It allows users to surprise the concept that whatever the locale of the content they receive, they would match the first language and accept language. Even if you’re giving EN-US. Give me temperatures and Celsius on Monday of the first day of the week. This doesn’t reveal anything more than what is revealed by accept language. But current privacy best practices say that this is already revealed elsewhere in the stack is not a valid defense that adds features that provide fingerprinting vectors. How do we provide less of this, less fine grade information about the user than one entry in accept language? +BAN: One solution is, and this is the thing, most immediately impact it because it requires supporting a tag, supporting the UR did the tag. It allows users to surprise the concept that whatever the locale of the content they receive, they would match the first language and accept language. Even if you’re giving EN-US. Give me temperatures and Celsius on Monday of the first day of the week. This doesn’t reveal anything more than what is revealed by accept language. But current privacy best practices say that this is already revealed elsewhere in the stack is not a valid defense that adds features that provide fingerprinting vectors. How do we provide less of this, less fine grade information about the user than one entry in accept language? BAN: So this is again a proposed solution. This is exploring the problem phase rather than something that is necessarily what we want to end up with. @@ -777,117 +478,117 @@ BAN: So during implementation, implementers determine what combination of refere BAN: During use, the browser will read OS preferences from the system. Which is why the system is of interest. The browser determines by pick your favourite algorithm which these are preferences through the strings, the combinations of preferences logically safe in each locale. And only those preferences are revealed to the server. The ones in the version of the proposal that is currently up on GitHub, these are the ones we are considering. -BAN: Again, NU is important, it impacts the content intelligibility. Hour cycle and temperature measurement unit. They don’t impact to the extent that NU does. Getting the wrong numbering system. But I am sure people here are familiar with the frustration involved in verifying temperatures. FirstDayOfWeek. Common. It’s this one selected because it seems there is a calendar or a ticket purchase site where you don’t necessarily want to log in. +BAN: Again, NU is important, it impacts the content intelligibility. Hour cycle and temperature measurement unit. They don’t impact to the extent that NU does. Getting the wrong numbering system. But I am sure people here are familiar with the frustration involved in verifying temperatures. FirstDayOfWeek. Common. It’s this one selected because it seems there is a calendar or a ticket purchase site where you don’t necessarily want to log in. -BAN: But you would like to get things displayed in a way that is immediately comprehensible to you. Calendar is a tricky one, because nearly every locale uses Gregorian calendar. For example, the Thai solar calendar might be something that you could do in certain locales without necessarily revealing who you are and immediately individually identifiable. +BAN: But you would like to get things displayed in a way that is immediately comprehensible to you. Calendar is a tricky one, because nearly every locale uses Gregorian calendar. For example, the Thai solar calendar might be something that you could do in certain locales without necessarily revealing who you are and immediately individually identifiable. -BAN: So we have got some mechanisms we are proposing. These mechanisms are dead simple. So, for example, if we end up going with the 5 tags on the previous slide, there will be a client int header for each. Servers using the Clint int architecture would request each one. +BAN: So we have got some mechanisms we are proposing. These mechanisms are dead simple. So, for example, if we end up going with the 5 tags on the previous slide, there will be a client int header for each. Servers using the Clint int architecture would request each one. BAN: This is important because if these were just broadcast to servers, then that would be an opportunity for passive fingerprinting. Servers would get information without necessarily having to ask for it. And as a result, they would use more of the information to identify you without telling. Because the client hint headers require you to advertise the ones they are using, a server that tries to fingerprint, we want to stop it, but at least we know it’s going on. BAN: The server is requesting more data than it needs to individually identify users, we can see it request more information. -BAN: And also to go along with that. The server side sited is client hints architecture on the client side JavaScript API that can be used to discover sets for each tag. Key thing is like with the client who have API, which is kind of dead simple. Would require the settings being requested individually. So there is no way to say, okay. Give me all of the tailorings. A way of saying, okay. Give me your numbering system or give me your proposed measuring unit to address that something is going on in the chain. MU is the key in this case because essentially, MU as currently implemented, the only thing it does is temperature measurement system. It’s frustrating. +BAN: And also to go along with that. The server side sited is client hints architecture on the client side JavaScript API that can be used to discover sets for each tag. Key thing is like with the client who have API, which is kind of dead simple. Would require the settings being requested individually. So there is no way to say, okay. Give me all of the tailorings. A way of saying, okay. Give me your numbering system or give me your proposed measuring unit to address that something is going on in the chain. MU is the key in this case because essentially, MU as currently implemented, the only thing it does is temperature measurement system. It’s frustrating. BAN: Okay. So that’s solution 1. Number 1, determine what sets of alternative settings are safe in each locale and allow those. A problem with this particular solution is that the smaller you are in your locale, the less information that you can reveal without making yourself potentially identifiable. BAN: Also, it would require a fair amount of user research to determine what is safe in each locale. Another look that we are considering is one that is basically dead simple. Provide a small number of tags in this case, hour cycle measurement unit and numbering system. Provide a small number of settings. For example, for measurement unit, the only settings are auto, celsius and Fahrenheit. Number system, Latin and if there is a native numbering system, whatever that is. And then auto is whatever default is. -BAN: This would actually provide locales to identify 3 different numbering systems. Latin, some locales support native. And some have a default that is neither Latin or native. Here, we are providing a few tags. And a limited number of settings for them, such that whatever information servers get out of this is fairly fine grained. +BAN: This would actually provide locales to identify 3 different numbering systems. Latin, some locales support native. And some have a default that is neither Latin or native. Here, we are providing a few tags. And a limited number of settings for them, such that whatever information servers get out of this is fairly fine grained. BAN: Again, to return to the elephant in the room here. This is something that we are advancing through other standard organizations. If it’s like a solution URG is the best, it would involve Intl. Also, we don’t necessarily anticipate advancing this past Stage 1 for this particular organization. -BAN: So what we are asking for is simply Stage 1 to explore this problem space to see what is possible. And also, sort of maybe I am more interested in others, it might be a good sort of locus for discussing the approach within intl or within 402 with fingerprinting problems in general. Thank you. +BAN: So what we are asking for is simply Stage 1 to explore this problem space to see what is possible. And also, sort of maybe I am more interested in others, it might be a good sort of locus for discussing the approach within intl or within 402 with fingerprinting problems in general. Thank you. -CDA: All right. We have Daniel Minor in the queue. +CDA: All right. We have Daniel Minor in the queue. -DLM: Yes. Thank you for the presentation. This is something we have discussed quite a bit internally with the SpiderMonkey team and the broader standard organizations in Mozilla. So we acknowledge this is a real problem and worth investigating. We consider this to be a web platform wide problem. Not just TC39. That’s something you acknowledged and we encourage you to investigate instead of imperative solutions. What is done at the HTML and CSS rather than just JavaScript. +DLM: Yes. Thank you for the presentation. This is something we have discussed quite a bit internally with the SpiderMonkey team and the broader standard organizations in Mozilla. So we acknowledge this is a real problem and worth investigating. We consider this to be a web platform wide problem. Not just TC39. That’s something you acknowledged and we encourage you to investigate instead of imperative solutions. What is done at the HTML and CSS rather than just JavaScript. DLM: We are concerned about increasing the fingerprinting surface. You have done a good job of addressing that in the presentation. -DLM: But another concern we have is that this could facilitate tracking and ethnic groups, but (??) of a group and that’s something we need to bear in mind. +DLM: But another concern we have is that this could facilitate tracking and ethnic groups, but (??) of a group and that’s something we need to bear in mind. DLM: So to summarize, I would say we are neutral on Stage 1 for this. But unlikely to support Stage 2 -BAN: Thank you. And I definitely hear the final concern there. For me, like I said, the most important one for this is making sure that people can get content in a number system they actually understand. But that’s specifically, the one that could allow people to be most quickly identified as a specific ethnic group. And essentially, what I would say with this is that people are already allowed to, for example, request specific scripts, which like a numbering system, reveals who you are. +BAN: Thank you. And I definitely hear the final concern there. For me, like I said, the most important one for this is making sure that people can get content in a number system they actually understand. But that’s specifically, the one that could allow people to be most quickly identified as a specific ethnic group. And essentially, what I would say with this is that people are already allowed to, for example, request specific scripts, which like a numbering system, reveals who you are. -SFC: I have a reply to Dan and a separate agenda item. What is our timebox looking like? +SFC: I have a reply to Dan and a separate agenda item. What is our timebox looking like? -CDA: 10 more min? +CDA: 10 more min? -SFC: I will go ahead with my second agenda item. I don’t think the intelligibility is very clear. I think that it’s a very fuzzy line to draw and I am not necessarily excited about putting the numbering system in a separate class than the other items which are important for intelligibility and understandability. I think understandability is kind of more the right thing here in the sense that, a lot of users, for example, in places like India and many other places, have English as their user interface language and don’t necessarily speak English well, but understand enough to get by, and this is likely how users feel about the number systems. When it comes to temperature unit, that’s also really important for the understandability of Web pages, if conversions and things are not necessarily clear to users. So I don’t necessarily agree with using Intelability as a metric here. +SFC: I will go ahead with my second agenda item. I don’t think the intelligibility is very clear. I think that it’s a very fuzzy line to draw and I am not necessarily excited about putting the numbering system in a separate class than the other items which are important for intelligibility and understandability. I think understandability is kind of more the right thing here in the sense that, a lot of users, for example, in places like India and many other places, have English as their user interface language and don’t necessarily speak English well, but understand enough to get by, and this is likely how users feel about the number systems. When it comes to temperature unit, that’s also really important for the understandability of Web pages, if conversions and things are not necessarily clear to users. So I don’t necessarily agree with using Intelability as a metric here. SFC: Because the line is fuzzy and it’s important to do what we said in the presentation, look at what are the axis where users differ from what their regional locale would otherwise focus on that and the unicode has specified for a very long time, are a really great place to start there. -SFC: What is the timebox? +SFC: What is the timebox? CDA: We have a few minutes left -SFC: Okay. I will reply to DE in the queue. Actually, the other DE has – has a question. I will let the queue go forward +SFC: Okay. I will reply to DE in the queue. Actually, the other DE has – has a question. I will let the queue go forward CDA: SYG? -SYG: So as an nonexpert, could you explain to a young child the actual additions for 402 to this proposal? +SYG: So as an nonexpert, could you explain to a young child the actual additions for 402 to this proposal? -BAN: So this may not involve fetching 402. If it does 402 it will involve support for additional locale extension tags. So URG or something roughly equivalent do it. +BAN: So this may not involve fetching 402. If it does 402 it will involve support for additional locale extension tags. So URG or something roughly equivalent do it. SYG: What about 262? BAN: No -SYG: So then the doing TC39 part is because of what again? +SYG: So then the doing TC39 part is because of what again? -BAN: Because whichever solution ends up being best or at lowest bad may involve at like simply supporting more tags in intl. +BAN: Because whichever solution ends up being best or at lowest bad may involve at like simply supporting more tags in intl. SYG: Okay. -BAN: We are asking for Stage 1 to explore the problem space without any specific solution in mind. +BAN: We are asking for Stage 1 to explore the problem space without any specific solution in mind. -DE: I don’t know whether it makes sense to consider this as a topic for discussion or a Stage 1 proposal. This problem space of exposing locale-related user preferences has been under investigation for years, and being or not being Stage 1 didn’t block that. And the biggest issue is the privacy issue that Daniel Minor raised. It is quite a serious privacy issue. DLM, could you elaborate on what you thought of the privacy mitigations that were included here? There was a declarative thing, Client Hints which Mozilla opposes. What other declarative solutions do you think should be examined? +DE: I don’t know whether it makes sense to consider this as a topic for discussion or a Stage 1 proposal. This problem space of exposing locale-related user preferences has been under investigation for years, and being or not being Stage 1 didn’t block that. And the biggest issue is the privacy issue that Daniel Minor raised. It is quite a serious privacy issue. DLM, could you elaborate on what you thought of the privacy mitigations that were included here? There was a declarative thing, Client Hints which Mozilla opposes. What other declarative solutions do you think should be examined? DLM: First the fingerprinting as a nonprivacy expert, I think the fingerprinting mitigations that BAN presented are quite reasonable. And I know he’s put a lot of work into this and partly in response to feedback from Mozilla and I believe the other implementers as well. So I think that looks good. DLM: I do think even clumping things together like that does still have the risk of identifying someone’s a member of an ethnic group. Whether that’s worse than using font data like BAN said, I don’t feel confident to speak on that. -DLM: In terms of declarative solution, the feedback from the broader web platform group of Mozilla was to see if these things could be done through HTML or CSS rather than through an API. And I can’t comment because that was my personal opinion, but feedback I received. We made a commitment to at least put together like straw person examples of what those could look like, which would would like to do and provide to the champions. +DLM: In terms of declarative solution, the feedback from the broader web platform group of Mozilla was to see if these things could be done through HTML or CSS rather than through an API. And I can’t comment because that was my personal opinion, but feedback I received. We made a commitment to at least put together like straw person examples of what those could look like, which would would like to do and provide to the champions. -DE: That sounds excellent. I hope those people will be in touch with BAN. +DE: That sounds excellent. I hope those people will be in touch with BAN. -BAN: And I want to interject to say, without the client hints, architecture this is useful for the JavaScript API, which could still be useful for implementers who want to implement client hints. +BAN: And I want to interject to say, without the client hints, architecture this is useful for the JavaScript API, which could still be useful for implementers who want to implement client hints. -SFC: My first thing is, some things that I have discussed previously here and also that BAN has I think mentioned at some point are macro-region-based solutions. But these are based on mark row regions. For example, western Europe or something like that. And we can create larger groups to not identify individual users or not even countries or script or languages. But macro relations. The second thing, we mentioned we are neutral. Can you clarify the concerns with Stage 2 that we have not addressed in the proposal presentation? +SFC: My first thing is, some things that I have discussed previously here and also that BAN has I think mentioned at some point are macro-region-based solutions. But these are based on mark row regions. For example, western Europe or something like that. And we can create larger groups to not identify individual users or not even countries or script or languages. But macro relations. The second thing, we mentioned we are neutral. Can you clarify the concerns with Stage 2 that we have not addressed in the proposal presentation? DLM: It’s just the choice of venue.This is feedback from other parties at Mozilla. There was a strong opinion that the W3C. -DE: Sorry. That seems consistent with what BAN is saying. It might add tags here and other things would be in the W3C right? +DE: Sorry. That seems consistent with what BAN is saying. It might add tags here and other things would be in the W3C right? BAN: Yes. We are trying to advance to W3C -DLM: I am just stating. I wanted to clarify. +DLM: I am just stating. I wanted to clarify. BAN: We are asking for Stage 1 to explore the problem space here. -DE: I want to suggest that we consider this a discussion topic rather than a staged proposal. Once you have figured out which extension tags make sense to add to Intl locale, we will bring it to committee. Until then, investigation should take place mostly in the W3C where this privacy investigation could be done in a more detailed way or also in 402 meetings. It’s fine. I don’t think there’s more stuff to bring back to plenary until there’s a concrete set of tags that should be added. +DE: I want to suggest that we consider this a discussion topic rather than a staged proposal. Once you have figured out which extension tags make sense to add to Intl locale, we will bring it to committee. Until then, investigation should take place mostly in the W3C where this privacy investigation could be done in a more detailed way or also in 402 meetings. It’s fine. I don’t think there’s more stuff to bring back to plenary until there’s a concrete set of tags that should be added. DE: I am not opposed to, if other people want to discuss it in committee further. -SFC: If I may, it’s good to get explicit comments on it from Apple or other implementers in the room. I have talked with DLM a lot about this. But like, I have heard a lot of crickets from other implementers like Apple, etc. One of the reasons we are bringing this to committee is to get the feedback from those other bodies. +SFC: If I may, it’s good to get explicit comments on it from Apple or other implementers in the room. I have talked with DLM a lot about this. But like, I have heard a lot of crickets from other implementers like Apple, etc. One of the reasons we are bringing this to committee is to get the feedback from those other bodies. CDA: We are out of time. As for Ben, it’s your call, if you hear Dan’s comment do you want to ask for Stage 1? -BAN: I would like to ask for Stage 1. +BAN: I would like to ask for Stage 1. DE: Sorry. I know we are over time, but is MLS on the call? Can he give any comment on this proposal? -MLS: I am on the call but focussing on responding to an earlier issue. I think I am in line with others on this. I am not sure we are the right venue for it or not. +MLS: I am on the call but focussing on responding to an earlier issue. I think I am in line with others on this. I am not sure we are the right venue for it or not. -DE: Do you have any recommendations for getting in touch with the appropriate people in Apple, in this other venue? That’s been the challenge +DE: Do you have any recommendations for getting in touch with the appropriate people in Apple, in this other venue? That’s been the challenge -MLS: Isn’t the 402 committee the right place to discuss this? +MLS: Isn’t the 402 committee the right place to discuss this? -DE: Have you gotten engagement with Apple there in 402? +DE: Have you gotten engagement with Apple there in 402? -MLS: We have Apple attendees at every meeting, SFC, correct me if I am wrong. +MLS: We have Apple attendees at every meeting, SFC, correct me if I am wrong. SFC: It has been raised there. Yes, but. @@ -901,7 +602,7 @@ SFC: It’s been that there’s more Apple people who come to this call, so I wa DLM: Just if I can quickly, there are a few meetings and I shared some of the fingerprinting concerns earlier on. I am not sure if he looked over BAN’s proposal. -MLS: Fingerprinting is important for us at Apple. Or blocking fingerprinting. +MLS: Fingerprinting is important for us at Apple. Or blocking fingerprinting. CDA: Okay. Unless something is changed, BAN is asking for consensus for Stage 1. Do we have any explicit support for Stage 1? @@ -911,26 +612,28 @@ DE: Okay. If this is a Stage 1, define the scope, with respect to the feedback f BAN: It’s certainly agreeable to me. -DE: With the understanding that the privacy investigation is done outside of TC39 but the results could be fed back, if there is some positive path forward, could be fed back in the Stage 1 proposal. DLM or MLS? Do you have thoughts on this? +DE: With the understanding that the privacy investigation is done outside of TC39 but the results could be fed back, if there is some positive path forward, could be fed back in the Stage 1 proposal. DLM or MLS? Do you have thoughts on this? -DLM: Yeah. We have no objections to this going to Stage 1. +DLM: Yeah. We have no objections to this going to Stage 1. -MLS: I don’t think I have any objection going to Stage 1. +MLS: I don’t think I have any objection going to Stage 1. -CDA: Okay. We have support from SFC. Any other support for Stage 1? +CDA: Okay. We have support from SFC. Any other support for Stage 1? DE: +1 -CDA: Support from SFC. And from DE and sounded like no objections but last call for any objections. Okay. You have Stage 1. Congratulations. +CDA: Support from SFC. And from DE and sounded like no objections but last call for any objections. Okay. You have Stage 1. Congratulations. + ### Summary -- To + +- To ### Conclusion Stage 1 for the scope, “adding extension tags to Intl.Locale to support the broader effort of exposing user locale preferences in a privacy preserving way.” - ## Withdrawing finalization registry cleanupSome + Presenter: Daniel Ehrenberg (DE) - [proposal](https://github.com/tc39/proposal-cleanup-some) @@ -946,35 +649,35 @@ DE: And so the claim was that for WebAssembly, we should make synchronous APIs. DE: History of this proposal: Initially, Mozilla proposed this. There was initially a focus on Wasm games. Then, the Wasm CG considered coroutines as a way to generalize a solution. This became JavaScript promise integration (JSPI). It makes it so that you can call something which you can suspend and resume with JavaScript Promises. It should be possible to hook JSPI up with FinalizationRegistry to allow WebAssembly programs to call out to finalization callbacks during their execution. -DE: Apple raised legitimate concerns about whether we want to encourage long tasks, and the consensus is we don’t want to encourage long tasks. They are bad for performance. I am glad that Apple raised this. This API was split out and left at Stage 2. I have not heard any complaints about the lack of cleanupSome on the web. I don’t think any browser is shipping it either. +DE: Apple raised legitimate concerns about whether we want to encourage long tasks, and the consensus is we don’t want to encourage long tasks. They are bad for performance. I am glad that Apple raised this. This API was split out and left at Stage 2. I have not heard any complaints about the lack of cleanupSome on the web. I don’t think any browser is shipping it either. -DE: So next steps? Can we have consensus on withdrawing? +DE: So next steps? Can we have consensus on withdrawing? -DE: And then if somebody feels like contributing to Test262 to remove the apparent use of cleanupSome in garbage collection tests, because that was included despite the fact this was split out a long time ago into a separate proposal. This work would be good, but it is not a precondition to withdrawing this proposal. Any thoughts? +DE: And then if somebody feels like contributing to Test262 to remove the apparent use of cleanupSome in garbage collection tests, because that was included despite the fact this was split out a long time ago into a separate proposal. This work would be good, but it is not a precondition to withdrawing this proposal. Any thoughts? -DLM: SpiderMonkey strongly supports withdrawing this proposal, and thank you for bringing this to the committee. +DLM: SpiderMonkey strongly supports withdrawing this proposal, and thank you for bringing this to the committee. MM: So I strongly support withdrawing it, except that from the previous conversation about withdrawal, I don’t know what withdrawing means. So do we have a, if withdrawal simply means acknowledging that the champions don’t wish to advance this, and nobody else does, so we might as well remove it from the record, I am perfectly fine with that. -MM: If “withdrawal” means there’s some kind of consensus, this is from previous conversations, but withdrawal means there’s some kind of statement of consensus, that this must not come back or not want to come back or that, on this one, I am actually fine with that. But I want clarity on what it means. Some of the other withdrawals I would not be fine with. And that stronger statement is unnecessary anyway +MM: If “withdrawal” means there’s some kind of consensus, this is from previous conversations, but withdrawal means there’s some kind of statement of consensus, that this must not come back or not want to come back or that, on this one, I am actually fine with that. But I want clarity on what it means. Some of the other withdrawals I would not be fine with. And that stronger statement is unnecessary anyway -DE: In the process document, I don’t think there’s any particular need for withdrawal to signify something permanent. But I think it’s important it’s consensus-seeking. The position of the committee right now that we have agreed on not doing this proposal. I don’t think it’s something that the champion would just withdraw. A proposal can be downgraded to an early stage or withdrawn. Consensus of the committee is necessary for these transitions. The downgrade/withdrawal must be accompanied by reason. +DE: In the process document, I don’t think there’s any particular need for withdrawal to signify something permanent. But I think it’s important it’s consensus-seeking. The position of the committee right now that we have agreed on not doing this proposal. I don’t think it’s something that the champion would just withdraw. A proposal can be downgraded to an early stage or withdrawn. Consensus of the committee is necessary for these transitions. The downgrade/withdrawal must be accompanied by reason. MM: So for this one, I think that the feature is in fact a misfeature and the language is improved by never having it. I am fine with the stronger implications. But for operator overloading, I would like to maintain the option to pick that back up and try to advance it at a later point. I am okay with it being demoted by zero, erased by the proposals. But with the stated reasons simply being that nobody is currently interested in advancing. -MM: Is that consistent with this document? +MM: Is that consistent with this document? DE: There are further reasons for operator overloading’s withdrawal, which we can discuss when that is scheduled. It is consistent with this document that we can withdraw a proposal for a reason, and we come to consensus on it, and then later we come to consensus on introducing that proposal again, for a reason. -DE: By default, we’re thinking this until we establish consensus that we are thinking another thing. +DE: By default, we’re thinking this until we establish consensus that we are thinking another thing. -MM: Okay. That means we might have consensus on withdrawal, but only be able to agree on a weaker reason for withdrawal, like the lack of energy of champions. +MM: Okay. That means we might have consensus on withdrawal, but only be able to agree on a weaker reason for withdrawal, like the lack of energy of champions. -DE: I don’t think lack of energy of champions might be the reason for some proposals, but not for operator overloading. +DE: I don’t think lack of energy of champions might be the reason for some proposals, but not for operator overloading. MM: Okay. That clarifies. Thank you. We are into lunchtime. -CDA: JHD, can you be brief? +CDA: JHD, can you be brief? JHD: Yeah. So this is not impeding this. Stage 2, we discussed, like, planning to not depend on it in those tests, and withdrawing, we will cement that further. Again, I think it’s reasonable to withdraw. But I wanted to make folks aware there will be Test262 changes because this does not advance, not that advancing was on the table. @@ -982,7 +685,7 @@ KG: You can have a host or harness hook for cleaning up that can replace it, yes JHD: I believe that’s the intended direction. Yeah. I am not personally doing that work, but that sounds right to me. -DE: Yeah. Withdrawing this proposal doesn’t change particularly whether those tests need to be redone. +DE: Yeah. Withdrawing this proposal doesn’t change particularly whether those tests need to be redone. SYG: It doesn’t change the implementations because clean up some calls to do the asynchronous cleanup.You still have to do clean up, but no longer callable from user code. @@ -990,343 +693,189 @@ DE: It has not been callable from user code already SYG: In terms of the code being there, we are not removing anything from implementations. It’s needed for internal implementation and now needed to be exposed by a harness hook for test 262. -DE: Sorry. Just a comment. I didn’t realize that’s how V8 is, but sure. +DE: Sorry. Just a comment. I didn’t realize that’s how V8 is, but sure. CDA: All right. -DE: So it sounds like we have consensus on withdrawal? Or do you want to call for that, Chris? +DE: So it sounds like we have consensus on withdrawal? Or do you want to call for that, Chris? CDA: Your call. DE: I feel like we have consensus on withdrawing the proposal. -CDA: Okay, folks. Any objections to withdrawing cleanupSome? All right. 3, 2, 1. Enjoy lunch. +CDA: Okay, folks. Any objections to withdrawing cleanupSome? All right. 3, 2, 1. Enjoy lunch. ### Summary -- The FinalizationRegistry.prototype.cleanupSome API was created to enable long Wasm tasks to observe garbage collection without yielding to the web’s event loop. + +- The FinalizationRegistry.prototype.cleanupSome API was created to enable long Wasm tasks to observe garbage collection without yielding to the web’s event loop. - This need is now satisfied by Wasm JSPI, and browsers are not pushing to ship this API right now. - Given a shared goal in the committee on minimizing observability of garbage collection and avoiding long tasks, this proposal is withdrawn. - The committee was in complete agreement, and discussion was just around clarifications of what that means. + ### Conclusion - cleanupSome is withdrawn + ## Stop coercing things pt 2 Presenter: Kevin Gibbons (KG) + - Slides: https://docs.google.com/presentation/d/1VwHSzNOAjR6nZkO2DMOAkoyIwaVcjqhT7VOaNiWm8ho/edit#slide=id.g106f4536d9_0_109 +KG: Hello. Welcome, thanks for coming to my TED talk. Okay, stop coercing things. So we talked about this previously. We got through some of the items. I want to get through more. So just to briefly recap what we’re talking about, passing something of the wrong type is almost always a bug and it is my opinion that bugs should generally be loud and not quiet. Which is to say it is almost always better to get an exception rather than silently having the wrong behavior. And, you know, concretely, we recently had added this new API that several people have observed you can request `arr.at('start')`, and this will in fact successfully give you the first item of the array through a series of mishaps and type coercion. + +KG: We don’t have to keep doing this. Like, this is what we have been doing for the entire existence of the language, but we don’t have to. Precedent is good, but for sufficiently bad ideas, it’s worth breaking with precedent, and I think that this willingness to coerce arbitrary values to arbitrary other types is a precedent that it is worth breaking with. And, +in fact, last time we talked about this, we got agreement on some of those, so concretely, we got agreement to not coerce NaN to zero and instead throw a RangeError and also when there is a required argument where undefined is not a valid value for that argument, do not coerce undefined to whatever type is expected here. So, you know, dot at `.at` with no arguments would throw an exception because the argument to `.at` is required. -KG: Hello. Welcome, thanks for coming to my TED talk. Okay, stop coercing -things. So we talked about this previously. We got through some of the items. I want to get -through more. So just to briefly recap what we’re talking about, passing something of the -wrong type is almost always a bug and it is my opinion that bugs should generally be loud and -not quiet. Which is to say it is almost always better to get an exception rather than silently -having the wrong behavior. And, you know, concretely, we recently had added this new API that -several people have observed you can request `arr.at('start')`, and this will in fact -successfully give you the first item of the array through a series of mishaps and type -coercion. - -KG: We don’t have to keep doing this. Like, this is what we have been doing for the entire -existence of the language, but we don’t have to. Precedent is good, but for sufficiently bad -ideas, it’s worth breaking with precedent, and I think that this willingness to coerce -arbitrary values to arbitrary other types is a precedent that it is worth breaking with. And, -in fact, last time we talked about this, we got agreement on some of those, so concretely, we -got agreement to not coerce NaN to zero and instead throw a RangeError and also when there is a -required argument where undefined is not a valid value for that argument, do not coerce undefined to whatever type is expected here. So, you know, dot at `.at` with no arguments would throw an exception because the argument to `.at` is required. - -KG: Also, I want to emphasize these are not hard and fast rules. If you want to come to the -committee and say “in my proposal we are not following the rules that we’ve talked about in this -[stop coercing things] presentation”, you should have a concrete reason to do so. That reason might be as simple as, "this API is basically a clone of an existing one and I want to make it work like the existing API". +KG: Also, I want to emphasize these are not hard and fast rules. If you want to come to the committee and say “in my proposal we are not following the rules that we’ve talked about in this +[stop coercing things] presentation”, you should have a concrete reason to do so. That reason might be as simple as, "this API is basically a clone of an existing one and I want to make it work like the existing API". That’s fine. It just needs to be a reason. -KG: I have a pull request up with these two rules. Today I want to talk about three other things. I’m going to go through these in order and unlike last time, I want to get to discussion of each of these in order, before moving on. So I have ordered these carefully and hopefully not controversial such that I consider -important and then those I consider less important and maybe less controversial. +KG: I have a pull request up with these two rules. Today I want to talk about three other things. I’m going to go through these in order and unlike last time, I want to get to discussion of each of these in order, before moving on. So I have ordered these carefully and hopefully not controversial such that I consider important and then those I consider less important and maybe less controversial. -KG: So I want to start with this first one. I would like us to stop rounding non-integral -numbers. If you expect an integer, then if someone gives you something that is not an integer, -we should throw. Fun observation, the array constructor actually does this. It is the only -place currently in the language that does this. When Temporal lands, it will have more. -Temporal has very good reason, which is that, for example, if you are making a Duration and you -say `seconds: 1.5`, that should certainly not give you a Duration of 1 second or 2 seconds. So in -Duration’s case, it was like really, really clearly necessary that you should throw a RangeError, but I think in almost all cases you should throw a range error. +KG: So I want to start with this first one. I would like us to stop rounding non-integral numbers. If you expect an integer, then if someone gives you something that is not an integer, +we should throw. Fun observation, the array constructor actually does this. It is the only place currently in the language that does this. When Temporal lands, it will have more. +Temporal has very good reason, which is that, for example, if you are making a Duration and you say `seconds: 1.5`, that should certainly not give you a Duration of 1 second or 2 seconds. So in Duration’s case, it was like really, really clearly necessary that you should throw a RangeError, but I think in almost all cases you should throw a range error. -KG: These are some examples of current silliness. Notably the TypedArray constructors, TypedArrays -are usually more strict than arrays but they are less strict in this particular case, they will round arguments. You can ask for a length 1.5 Float64Array and it will not give you a Float64Array that is backed by 12 bytes. It will give you an array that is backed by 8 bytes. Why should we let you do this? We should not let you do this. Does anyone have thoughts on this? +KG: These are some examples of current silliness. Notably the TypedArray constructors, TypedArrays are usually more strict than arrays but they are less strict in this particular case, they will round arguments. You can ask for a length 1.5 Float64Array and it will not give you a Float64Array that is backed by 12 bytes. It will give you an array that is backed by 8 bytes. Why should we let you do this? We should not let you do this. Does anyone have thoughts on this? CDA: There is Shane. -SFC: Yeah, so for example, when looking at indexes into arrays, it makes a lot of sense, because -there is no possible situation where a non-integral number would make sense at that position. -In the case of Temporal.Duration, Temporal made the choice that fractional digits and fractional second digits should instead be represented as integral numbers of milliseconds/microseconds/nanoseconds, so the Temporal champions chose integral numbers. There could, however, be other cases, and I believe I raised some of these at the last time, that this was on the floor at one of previous meetings, where -requiring integral numbers not necessarily because the context in which they are used necessarily always requires an integral number, but because there is still design space yet to be solved in accepting fractional digits. -One example of this coming up is, for example, in the Intl.DurationFormat proposal, you know, there may be a desire to, for example, at some point support formatting of fractional hours and fractional minutes, which is not currently supported in the integral format duration proposal but is not necessarily because of some external variance or requirement that those be integral numbers. And I tried to make the argument last time that having that, you know, at least integral formatting we try to take the angle on all of these cases as being, as coming from the angle of doing a best effort and, you know, having a best effort, that we can in the future relax to make better is not necessarily a bad position to be in. +SFC: Yeah, so for example, when looking at indexes into arrays, it makes a lot of sense, because there is no possible situation where a non-integral number would make sense at that position. +In the case of Temporal.Duration, Temporal made the choice that fractional digits and fractional second digits should instead be represented as integral numbers of milliseconds/microseconds/nanoseconds, so the Temporal champions chose integral numbers. There could, however, be other cases, and I believe I raised some of these at the last time, that this was on the floor at one of previous meetings, where requiring integral numbers not necessarily because the context in which they are used necessarily always requires an integral number, but because there is still design space yet to be solved in accepting fractional digits. +One example of this coming up is, for example, in the Intl.DurationFormat proposal, you know, there may be a desire to, for example, at some point support formatting of fractional hours and fractional minutes, which is not currently supported in the integral format duration proposal but is not necessarily because of some external variance or requirement that those be integral numbers. And I tried to make the argument last time that having that, you know, at least integral formatting we try to take the angle on all of these cases as being, as coming from the angle of doing a best effort and, you know, having a best effort, that we can in the future relax to make better is not necessarily a bad position to be in. So I’m fine with the idea of saying that, like, when the integral number is used in a situation where there is an external variant enforcing that this is always going to definitely be an integral number, that we can stop coercing and do what KG describes here. But I think it’s important to have that qualification instead of making a blanket everywhere. -KG: Okay. I think two things. First, I think that that argument is a reasonable argument to make for why to make an exception to this rule for a particular API. Like I was saying, you should have a reason to make an exception, but if the reason is, like, you are concretely trying to make a best effort and we might change the behavior later, that’s fine. +KG: Okay. I think two things. First, I think that that argument is a reasonable argument to make for why to make an exception to this rule for a particular API. Like I was saying, you should have a reason to make an exception, but if the reason is, like, you are concretely trying to make a best effort and we might change the behavior later, that’s fine. I guess I had three things. It sounds like duration format doesn’t require you to pass an integer. It’s a reasonable thing to do, to pass a non-integer value, so a rule I have written down about only taking integral numbers just wouldn’t apply if in fact you intentionally want to operate on non-integral numbers. But then also separately, like I think if you’re intending to change the behavior for non-integral numbers later, it is probably a better idea to throw. Like, I’m not going to tell you what to do, but usually we find that people start relying on behavior fairly quickly, and so if you want to leave space for treating certain inputs differently later, it’s generally best to reject them, not to make a best effort. But I guess that’s not always how 402 APIs work. I hear you and I think that does work with this. When you want to accept non-integral numbers, you should say why you’re doing so. -CDA: Okay, I think I’m next. And maybe you already covered this, but it’s probably worth -pointing out for completion. I remember this from last time, and I’m not putting words in your mouth, so please feel free to clarify, but I recall that the goal of what you’re proposing here is just to change the default treatment for new APIs, and there can still be exceptions where you might want to not follow the guidance on what you’re proposing if there’s a good reason to do it. But it’s not to say that we can never do coercion in situations where it makes sense. +CDA: Okay, I think I’m next. And maybe you already covered this, but it’s probably worth pointing out for completion. I remember this from last time, and I’m not putting words in your mouth, so please feel free to clarify, but I recall that the goal of what you’re proposing here is just to change the default treatment for new APIs, and there can still be exceptions where you might want to not follow the guidance on what you’re proposing if there’s a good reason to do it. But it’s not to say that we can never do coercion in situations where it makes sense. KG: Yeah, definitely. CDA: SYG? -SYG: Yeah, I wanted to -- first I wanted to respond to Shane. I want to better understand -what -- because the gestures of what I understood was you would like to have the option to put -accept non-integral stuff later. If that is the case, we can go from throw to no throw, so -what is the down I’d to throwing today and then change it to no throwing once you add -non-integral support? - -SFC: A few things here. I’ll respond. I’ll start by responding to Kevin can then respond to -Shu. So one thing I don’t completely -- I’m not completely clear on here is we already have -mixed precedent in the standard for this as Kevin has pointed out. That the array constructor -has different behavior than certain other APIs. So it’s not clear to me necessarily -- so -necessarily that we’re changing precedent. In fact, we’re actually creating a new rule that -didn’t exist before. It’s not necessarily clear why we’re creating that rule. Then to respond -to the question about, well, can we relax exceptions later, the -- there’s the different -perspectives that can be taken on this question, and, you know, I’m not going to derail this -discussion right now to have that discussion about, like, you know, situations where relaxing -exceptions is better, but there’s also definitely cases where, you know, we can have best -effort behavior now, and then another -- and then, you know, continue improving on that best -effort behavior in the future. That’s exactly how locales work. That’s exactly how user -preferences work. When we have more information and we are able to accept more information, we -can improve the behavior. +SYG: Yeah, I wanted to -- first I wanted to respond to Shane. I want to better understand what -- because the gestures of what I understood was you would like to have the option to put accept non-integral stuff later. If that is the case, we can go from throw to no throw, so what is the down I’d to throwing today and then change it to no throwing once you add non-integral support? + +SFC: A few things here. I’ll respond. I’ll start by responding to Kevin can then respond to Shu. So one thing I don’t completely -- I’m not completely clear on here is we already have mixed precedent in the standard for this as Kevin has pointed out. That the array constructor has different behavior than certain other APIs. So it’s not clear to me necessarily -- so necessarily that we’re changing precedent. In fact, we’re actually creating a new rule that didn’t exist before. It’s not necessarily clear why we’re creating that rule. Then to respond to the question about, well, can we relax exceptions later, the -- there’s the different perspectives that can be taken on this question, and, you know, I’m not going to derail this discussion right now to have that discussion about, like, you know, situations where relaxing exceptions is better, but there’s also definitely cases where, you know, we can have best effort behavior now, and then another -- and then, you know, continue improving on that best effort behavior in the future. That’s exactly how locales work. That’s exactly how user preferences work. When we have more information and we are able to accept more information, we can improve the behavior. . -SFC: And it’s often easier for -- I don’t want to necessarily have a debate about this right here, -but one advantage of having a behavior that continually improves, especially in the Intl space -is that users can -- or developers can deploy code that runs on both older and newer systems -and has, you know, the improved behavior on newer systems and has fallback behavior on older -systems. And that just works and solves their problems. We can have a debate about is the -case I described with formatting of fractional minutes, if that gets added in the future, is -that a place we should -- you know, where which behavior is better or not. We can have that -discussion. It could be the case that we want to inform users loudly in that particular case. -But I think that as general rule, you know, we should leave open the option for proposals to -take that other position of, you know, of having best effort behavior. +SFC: And it’s often easier for -- I don’t want to necessarily have a debate about this right here, +but one advantage of having a behavior that continually improves, especially in the Intl space is that users can -- or developers can deploy code that runs on both older and newer systems and has, you know, the improved behavior on newer systems and has fallback behavior on older systems. And that just works and solves their problems. We can have a debate about is the case I described with formatting of fractional minutes, if that gets added in the future, is that a place we should -- you know, where which behavior is better or not. We can have that discussion. It could be the case that we want to inform users loudly in that particular case. +But I think that as general rule, you know, we should leave open the option for proposals to take that other position of, you know, of having best effort behavior. . SFC: Yeah, and KG has another item on the queue. . -SYG: I want to respond. Well, I want to respond to that. So I think perhaps locales -- not -locales per se, but the internalization API space has a different like impolice contract from -over aist, because I have the counts -- I have the opposite intuition that general rule should -be that we do not have APIs whose behavior changes over time, because as Kevin said the pattern -that we have seen very often is people depend on behavior today very quickly. So perhaps the -internationalization is a special enough space that there’s an expectation that behavior does -vary over time and they’ll write their code today with that in mind, but that does not match my -intuition for the rest of language APIs. And I think the general rule ought to be for APIs -that do not already have the understanding today that their behavior is likely to vary over -time, that they do throw. Like, that seems the right general thing to me, and if we need to -carve out a different precedent for internationalization because the social contract around how -people code internationalization stuff is just different, that seems warranted. But that’s not -my expertise. +SYG: I want to respond. Well, I want to respond to that. So I think perhaps locales -- not locales per se, but the internalization API space has a different like impolice contract from over aist, because I have the counts -- I have the opposite intuition that general rule should be that we do not have APIs whose behavior changes over time, because as Kevin said the pattern that we have seen very often is people depend on behavior today very quickly. So perhaps the internationalization is a special enough space that there’s an expectation that behavior does vary over time and they’ll write their code today with that in mind, but that does not match my intuition for the rest of language APIs. And I think the general rule ought to be for APIs that do not already have the understanding today that their behavior is likely to vary over time, that they do throw. Like, that seems the right general thing to me, and if we need to carve out a different precedent for internationalization because the social contract around how people code internationalization stuff is just different, that seems warranted. But that’s not my expertise. . -KG: Yeah, so two things. First, I do want to explicitly affirm that I’m intending to leave room -for proposals to say that in some particular case, it makes sense to round non-integers. So if you -want to make that argument on any proposal, like, absolutely. I explicitly want to leave room -for that. The second thing you said you weren’t clear on, why do we need a rule given there’s -already precedent. Empirically it is the case that that the new APIs we have been adding round -integers and I’m trying to change what we do in the future. My proposal is: let’s do a -different thing in the future. It doesn’t need to be a rule per se, but, like, that seems like -the way to go. Guideline, not a rule. Okay. +KG: Yeah, so two things. First, I do want to explicitly affirm that I’m intending to leave room for proposals to say that in some particular case, it makes sense to round non-integers. So if you want to make that argument on any proposal, like, absolutely. I explicitly want to leave room for that. The second thing you said you weren’t clear on, why do we need a rule given there’s already precedent. Empirically it is the case that that the new APIs we have been adding round integers and I’m trying to change what we do in the future. My proposal is: let’s do a different thing in the future. It doesn’t need to be a rule per se, but, like, that seems like the way to go. Guideline, not a rule. Okay. . -KG: I think we’re done with this queue item, then. Let’s go through the rest of the queue. Shu? +KG: I think we’re done with this queue item, then. Let’s go through the rest of the queue. Shu? . -SYG: Just, yeah, sounds great. The current exception that we just discussed notwithstanding, I -strongly support this as a general thing for future APIs. +SYG: Just, yeah, sounds great. The current exception that we just discussed notwithstanding, I strongly support this as a general thing for future APIs. -KG: Okay. LCA? +KG: Okay. LCA? LCA: I think this seems very reasonable and we should do it. -KG: Thanks. TAB? +KG: Thanks. TAB? -TAB: Yes, generally, strongly agree with all this, and as I said in my message, literally -the duration constructor not allowing non-integers said me a bug two days ago, so let’s do more -of that when reasonable. +TAB: Yes, generally, strongly agree with all this, and as I said in my message, literally the duration constructor not allowing non-integers said me a bug two days ago, so let’s do more of that when reasonable. -KG: Okay. And then we have strong agreement with this from RGN and thumbs up from RKG and -a plus 1 from JHX and an observation that arr.at(x) behavior is already different from index array -indexes where array indexes doesn’t round, which a good observation and a good reason that such -an API in the future ought to throw. Plus 1 from Philip. Plus 1 from Daniel. Plus 1 from -Chris. SFC asks what the language is for exceptions. Yeah, that’s a good question. Let me -open up the pull request. What I have written for the previous rules, new features generally -should follow these rules, none of these rules are inviolable, but you should have a good reason -for any particular feature to deviate. So it’s very open. You just need to have a good -reason. Does that answer your question, or do you want to also speak? +KG: Okay. And then we have strong agreement with this from RGN and thumbs up from RKG and a plus 1 from JHX and an observation that arr.at(x) behavior is already different from index array indexes where array indexes doesn’t round, which a good observation and a good reason that such an API in the future ought to throw. Plus 1 from Philip. Plus 1 from Daniel. Plus 1 from Chris. SFC asks what the language is for exceptions. Yeah, that’s a good question. Let me open up the pull request. What I have written for the previous rules, new features generally should follow these rules, none of these rules are inviolable, but you should have a good reason for any particular feature to deviate. So it’s very open. You just need to have a good reason. Does that answer your question, or do you want to also speak? -SFC: Thanks for pulling up that text. Yeah, "good reason" is a little bit -- I mean, it’s vague on -purpose. I’m more worried that, like, I don’t want to be spending a lot of time, you know, in having these types of debates about future Intl APIs, you know, do we throw or do we coerce. You know, like, which is better for best-effort behavior. I think it would make me a little bit more warm and fuzzy if we -could list out that as an example in addition to the one about close cousin of an existing -feature. I would feel a little bit more warm and cozy if we said something along the lines of -what I had been describing earlier, but, yeah. +SFC: Thanks for pulling up that text. Yeah, "good reason" is a little bit -- I mean, it’s vague on purpose. I’m more worried that, like, I don’t want to be spending a lot of time, you know, in having these types of debates about future Intl APIs, you know, do we throw or do we coerce. You know, like, which is better for best-effort behavior. I think it would make me a little bit more warm and fuzzy if we could list out that as an example in addition to the one about close cousin of an existing feature. I would feel a little bit more warm and cozy if we said something along the lines of what I had been describing earlier, but, yeah. -KG: Sure, yeah, I’ll try to workshop something in there. And, yes, intentionally vague. WH? +KG: Sure, yeah, I’ll try to workshop something in there. And, yes, intentionally vague. WH? WH: Things that currently do truncations include ToUint32 and to ToInt32. In addition to truncation to an integer, they do modulo 2**32. What is your recommendation regarding those? -KG: Yeah, that's a good question. I kind of intentionally didn’t cover them because I wasn’t sure -that I was going to be able to get agreement on them. What I am currently proposing is that for an -API that would do ToUint32, you would do toNumber, though see later about that, and throw if the result is not integral, and then do ToUint32. I think there’s room to -also make a rule that says these things should restrict the domain of their input and throw for -anything that they would do a non-trivial modulus for. Didn’t suggest that because -you didn’t expect us to come to agreement on it and I thought the integer one we were more -likely to agree to. +KG: Yeah, that's a good question. I kind of intentionally didn’t cover them because I wasn’t sure that I was going to be able to get agreement on them. What I am currently proposing is that for an API that would do ToUint32, you would do toNumber, though see later about that, and throw if the result is not integral, and then do ToUint32. I think there’s room to also make a rule that says these things should restrict the domain of their input and throw for anything that they would do a non-trivial modulus for. Didn’t suggest that because you didn’t expect us to come to agreement on it and I thought the integer one we were more likely to agree to. . WH: Okay. . -KG: Now that it’s been brought up, does anyone have opinions about whether things that currently do -ToUint32 ought to throw for things outside of their domain rather than performing modulo? +KG: Now that it’s been brought up, does anyone have opinions about whether things that currently do ToUint32 ought to throw for things outside of their domain rather than performing modulo? . -WH: My opinion is it depends on the context. There are things which do ToUint32 or ToInt32 for -which we’re interested in the mathematical value of the number and we should not be doing modulo. On the other hand, there are things that do ToUint32 or ToInt32 that treat -integers as bit maps for which the modular behavior is pretty much essential. +WH: My opinion is it depends on the context. There are things which do ToUint32 or ToInt32 for which we’re interested in the mathematical value of the number and we should not be doing modulo. On the other hand, there are things that do ToUint32 or ToInt32 that treat integers as bit maps for which the modular behavior is pretty much essential. . KG: Yeah. . -WH: It depends on whether you’re interested in the number as a bit pattern or whether you’re -interested in a number for its numeric value. +WH: It depends on whether you’re interested in the number as a bit pattern or whether you’re interested in a number for its numeric value. . -KG: So I think I’m not going to propose any new rules regarding ToUint32, but suggest to the -committee that in the future, if you are designing an API which would in the current world do -ToUint32, you should think hard about whether it makes sense to perform Modulo. But I’m not -going to propose a rule around that. Okay, great. +KG: So I think I’m not going to propose any new rules regarding ToUint32, but suggest to the committee that in the future, if you are designing an API which would in the current world do ToUint32, you should think hard about whether it makes sense to perform Modulo. But I’m not going to propose a rule around that. Okay, great. . -KG: Before moving on, I would like to ask for explicit consensus for this thing up here with the -caveat that it’s only intended to be a guideline, not actually a hard and fast rule and I’ll -try to workshop some wording around SFC’s concrete case for when Intl APIs may want to go -against this guideline. +KG: Before moving on, I would like to ask for explicit consensus for this thing up here with the caveat that it’s only intended to be a guideline, not actually a hard and fast rule and I’ll try to workshop some wording around SFC’s concrete case for when Intl APIs may want to go against this guideline. . CDA: Before we ask for consensus, there is one more question from Andreu. . -API: You called out explicitly NaN to zero, but negative zero and undefined, I assume you would want -those to three as well. +API: You called out explicitly NaN to zero, but negative zero and undefined, I assume you would want those to three as well. . -KG: Negative zero is an excellent question. I think not negative zero. I think most places -that accept zero should accept negative zero. You generally don’t want to regard those as -different. And undefined is a separate question that last time we got agreement not to coerce -undefined to anything. +KG: Negative zero is an excellent question. I think not negative zero. I think most places that accept zero should accept negative zero. You generally don’t want to regard those as different. And undefined is a separate question that last time we got agreement not to coerce undefined to anything. . RPR: CDA? . -CDA: Sorry, I just was seeking clarification on you were asking for consensus for your -- you -referred to something, Peter. I was confused, is there something different than. +CDA: Sorry, I just was seeking clarification on you were asking for consensus for your -- you referred to something, Peter. I was confused, is there something different than. . -KG: This is what you were plus-one-ing. I have heard a great deal of support for it. I’m -formally calling for consensus on a new guideline, which I realize is a weird thing to call for -consensus for. +KG: This is what you were plus-one-ing. I have heard a great deal of support for it. I’m formally calling for consensus on a new guideline, which I realize is a weird thing to call for consensus for. . -KG: Okay, having heard a great deal of support and no objections, I will take this as consensus and -update the pull request later. +KG: Okay, having heard a great deal of support and no objections, I will take this as consensus and update the pull request later. . RPR: And explicit support from EAO. . RPR: I explicitly support. . -KG: Okay, moving on to an almost certainly more controversial one, I would like us to -stop coercing objects to primitives. If your API takes a string and someone gives an object or -a function, you should throw. They have given you the wrong thing. You should not invoke -user code in the middle of your execution of this function; that’s not the right thing to -do. If the user wants to do coercion, they can just do the coercion. Also, I -have to point out that this would remove one of the largest sources of side effects in the -language and a ridiculously large class of engine bugs because user code can have side -effects and the violate invariants, and it’s just generally bad. I think that usually, -when you have passed a function to something that doesn’t expect a function, that’s a bug, or -like an object to something that expects a string. That’s a bug. You know, you shouldn’t be -able to join an array of an empty object. Like, "a[object Object]b" is just not the outcome that -you wanted here. If you are passing a date to Math.max, probably you were expecting to get a -date out, not a number. If you are padding a string with number `'x'.padStart(4, Number)`, I don’t know what you were expecting, but you weren’t expecting the letters “fun”. That’s not fun. - -KG: We should stop doing this. Now, I recognize -there are significantly more reasonable reasons to want this. But I do think that use cases -for it would universally be better served by explicitly doing the coercion yourself. Coercing -to string is trivial. Coercing to number is trivial. It’s just -`''+x` or just `+x`. Boolean is `!!`, I’m less certain about coercing to -Boolean, if someone wants to make an argument that this should only apply to things other than -Boolean, I’m open to that argument, but, yeah, we should stop doing this. Thoughts? +KG: Okay, moving on to an almost certainly more controversial one, I would like us to stop coercing objects to primitives. If your API takes a string and someone gives an object or a function, you should throw. They have given you the wrong thing. You should not invoke user code in the middle of your execution of this function; that’s not the right thing to do. If the user wants to do coercion, they can just do the coercion. Also, I have to point out that this would remove one of the largest sources of side effects in the language and a ridiculously large class of engine bugs because user code can have side effects and the violate invariants, and it’s just generally bad. I think that usually, +when you have passed a function to something that doesn’t expect a function, that’s a bug, or like an object to something that expects a string. That’s a bug. You know, you shouldn’t be able to join an array of an empty object. Like, "a[object Object]b" is just not the outcome that you wanted here. If you are passing a date to Math.max, probably you were expecting to get a date out, not a number. If you are padding a string with number `'x'.padStart(4, Number)`, I don’t know what you were expecting, but you weren’t expecting the letters “fun”. That’s not fun. + +KG: We should stop doing this. Now, I recognize there are significantly more reasonable reasons to want this. But I do think that use cases for it would universally be better served by explicitly doing the coercion yourself. Coercing to string is trivial. Coercing to number is trivial. It’s just +`''+x` or just `+x`. Boolean is `!!`, I’m less certain about coercing to Boolean, if someone wants to make an argument that this should only apply to things other than Boolean, I’m open to that argument, but, yeah, we should stop doing this. Thoughts? . -SYG: So I’m -- unsurprisingly, I like the idea and I support it. But my intuition is that I -think the economic cost is more than just engine bugs. Even though that is certainly a large -class. Both performance bugs and, well, performance issues, I suppose, and security bugs. -Security bugs are by far worse when unexpecting user code runs. But even for performance -stuff, this happens often because if, as part of argument coercion, it -- you change thing that -invalidates a fast path that you’re currently on, you just now have fallen off the fast path. -So that’s bad. Also, I think everybody in this room spends a lot of collective time writing -tests for these corners, like, an inordinate amount of time for these corners. That does not -seem like a good use of our time. It would be good if we stopped doing that. I think on every -level of the JS ecosystem, I think there’s some economic cost attached to this. It would be -nice if we could stop doing this for new APIs. Also, just going to my next topic, which is I’m -wondering what TypeScript does as a non-typeScript writer. If you pass objects to something -that expects a primitive, does it warn by default, error by default? +SYG: So I’m -- unsurprisingly, I like the idea and I support it. But my intuition is that I think the economic cost is more than just engine bugs. Even though that is certainly a large class. Both performance bugs and, well, performance issues, I suppose, and security bugs. +Security bugs are by far worse when unexpecting user code runs. But even for performance stuff, this happens often because if, as part of argument coercion, it -- you change thing that invalidates a fast path that you’re currently on, you just now have fallen off the fast path. +So that’s bad. Also, I think everybody in this room spends a lot of collective time writing tests for these corners, like, an inordinate amount of time for these corners. That does not seem like a good use of our time. It would be good if we stopped doing that. I think on every level of the JS ecosystem, I think there’s some economic cost attached to this. It would be nice if we could stop doing this for new APIs. Also, just going to my next topic, which is I’m wondering what TypeScript does as a non-typeScript writer. If you pass objects to something that expects a primitive, does it warn by default, error by default? . -KG: Yeah, TypeScript doesn’t have warnings. That’s just a violation. +KG: Yeah, TypeScript doesn’t have warnings. That’s just a violation. . SYG: Okay, thanks. . -MF: Can I get further clarification to that answer? Is that because the TypeScript types -for these APIs are more restrictive than reality? +MF: Can I get further clarification to that answer? Is that because the TypeScript types for these APIs are more restrictive than reality? . KG: Yes. . MF: Okay, thank you. . -KG: And I believe the TypeScript team has previously expressed that they tried to keep to the -spirit of APIs and, like, get annoyed by bug reports about people passing the wrong thing. +KG: And I believe the TypeScript team has previously expressed that they tried to keep to the spirit of APIs and, like, get annoyed by bug reports about people passing the wrong thing. . RPR: We can hear more about the spirit from DRR himself. . KG: Excellent. . -DRR: Yeah, it’s exactly this. Like, for all intents and purposes, you really did want to say -this should be a number, this should be a string, and then people say, oh, well, technically it -hasn’t -- anything that has a `toString` and, really, I don’t think most people on this -committee -- maybe I shouldn’t say that, but I mean, this is the points of the presentation, -right? Like, it was really never the intent, right? And hopefully you’re not running into -code that does that sort of thing either. So if we have more cases where we can just say, no, -this is is what the actual behavior is, that aligns better, I think, what most type checkers -would want, including ourselves. +DRR: Yeah, it’s exactly this. Like, for all intents and purposes, you really did want to say this should be a number, this should be a string, and then people say, oh, well, technically it hasn’t -- anything that has a `toString` and, really, I don’t think most people on this committee -- maybe I shouldn’t say that, but I mean, this is the points of the presentation, +right? Like, it was really never the intent, right? And hopefully you’re not running into code that does that sort of thing either. So if we have more cases where we can just say, no, +this is is what the actual behavior is, that aligns better, I think, what most type checkers would want, including ourselves. . -RPR: GCL has a plus one. And message. On to EAO. +RPR: GCL has a plus one. And message. On to EAO. . -EAO: Yeah, so I support this, but also the first thing I’m going to do is kind of look for an -exception for it. In that the Intl message format proposal I’m championing, there is, I think, -a valid use case for wrapped primitive values in the compound -- to deal with compound values, -but I think I would -- when championing this and explaining it, I think it is up to me to -explain why do we need to allow for this weird thing rather than being able to assume by -default this is okay. +EAO: Yeah, so I support this, but also the first thing I’m going to do is kind of look for an exception for it. In that the Intl message format proposal I’m championing, there is, I think, +a valid use case for wrapped primitive values in the compound -- to deal with compound values, +but I think I would -- when championing this and explaining it, I think it is up to me to explain why do we need to allow for this weird thing rather than being able to assume by default this is okay. . -KG: So I want to ask, would your use case be that, for example, this first thing on the screen -ought to invoke the `toString` method on your message format objects or that you would have a -new API which would accept things and then do coercion? +KG: So I want to ask, would your use case be that, for example, this first thing on the screen ought to invoke the `toString` method on your message format objects or that you would have a new API which would accept things and then do coercion? . -EAO: So it would be a new API where the new API -- for example, when formatting a number, would -in most cases expect there to be just a number, but would be okay with, for instance, a `new -Number(...)` instance with an options bag attached to that and for stuff to happen with this. But -specifically, I am expecting that in order to get that to pass, I need to explain myself and -why this particular thing needs to be done. +EAO: So it would be a new API where the new API -- for example, when formatting a number, would in most cases expect there to be just a number, but would be okay with, for instance, a `new Number(...)` instance with an options bag attached to that and for stuff to happen with this. But specifically, I am expecting that in order to get that to pass, I need to explain myself and why this particular thing needs to be done. -KG: That sounds great. And just as with the previous item, yes, I think that when there are -exceptions, that’s fine. We just need to have a good reason. +KG: That sounds great. And just as with the previous item, yes, I think that when there are exceptions, that’s fine. We just need to have a good reason. -PFC: SYG already touched on this, but I can confirm that this object-to-primitive coercion behavior is a big source of lots of lines of code of tests in test262 that don’t actually test situations that occur in the real world. There are loads of tests where, if you have a number argument to a function, it passes in an object with a `toString` method and a `valueOf` method. And we don’t even test all of the code paths there usually. We’ll test that, for example, if you’re coercing to a number, that will call `valueOf` over `toString` and vice versa when coercing to a string. I think normally we don’t test `Symbol.toPrimitive` in test262. And we also don’t test the case where your `valueOf` method returns another object that itself has a `valueOf` method, for example, so that you can go around in circles indefinitely. So who knows if implementations are even getting those right. So, I strongly support not doing this anymore. +PFC: SYG already touched on this, but I can confirm that this object-to-primitive coercion behavior is a big source of lots of lines of code of tests in test262 that don’t actually test situations that occur in the real world. There are loads of tests where, if you have a number argument to a function, it passes in an object with a `toString` method and a `valueOf` method. And we don’t even test all of the code paths there usually. We’ll test that, for example, if you’re coercing to a number, that will call `valueOf` over `toString` and vice versa when coercing to a string. I think normally we don’t test `Symbol.toPrimitive` in test262. And we also don’t test the case where your `valueOf` method returns another object that itself has a `valueOf` method, for example, so that you can go around in circles indefinitely. So who knows if implementations are even getting those right. So, I strongly support not doing this anymore. -DE: I’m +1 on this proposal in general. About the particular MessageFormat use case, I -guess I would want to review that more. But in general, I think we’ve been assuming that -primitives that are wrapped get unwrapped when they’re in parameter positions in this kind of -uniform way. I’m okay with removing this because I’m not convinced that that’s especially -useful behavior. But I wanted to kind of be explicit that if we’re considering making that -decision. +DE: I’m +1 on this proposal in general. About the particular MessageFormat use case, I guess I would want to review that more. But in general, I think we’ve been assuming that primitives that are wrapped get unwrapped when they’re in parameter positions in this kind of uniform way. I’m okay with removing this because I’m not convinced that that’s especially useful behavior. But I wanted to kind of be explicit that if we’re considering making that decision. -KG: Yes, that’s a good call-out. I do intend this to be a typeof check, just like you would -write in user code, and of course typeof a boxed primitive does not, like -- `typeof new -Number` does not give you “number”. It’s an object, so my intention is to reject those along with -everything else. +KG: Yes, that’s a good call-out. I do intend this to be a typeof check, just like you would write in user code, and of course typeof a boxed primitive does not, like -- `typeof new Number` does not give you “number”. It’s an object, so my intention is to reject those along with everything else. DE: That sounds good to me. I kind of want to ask JHD because you expressed interest in coercion performing unwrapping of boxed primitives in the past. . -JHD: I would say that I will be thinking about it as these cases come up. But I still think that a general default of don’t coerce stuff is the right place to start. And so even though I didn’t put myself on the queue, but I support everything that Kevin is saying here. But I am -- I will -- you know, how can I say this without sounding antagonistic? I reserve the right to brings up boxed primitives in the future, but I can’t at the moment conceive of when I would have a strong opinion about it. +JHD: I would say that I will be thinking about it as these cases come up. But I still think that a general default of don’t coerce stuff is the right place to start. And so even though I didn’t put myself on the queue, but I support everything that Kevin is saying here. But I am -- I will -- you know, how can I say this without sounding antagonistic? I reserve the right to brings up boxed primitives in the future, but I can’t at the moment conceive of when I would have a strong opinion about it. -DE: Okay, that’s great. So boxed primitives, we might enable them for certain proposals, but -you’d be okay with the blanket general rule being default be, we don’t support boxed primitives? +DE: Okay, that’s great. So boxed primitives, we might enable them for certain proposals, but you’d be okay with the blanket general rule being default be, we don’t support boxed primitives? JHD: Yes, that’s right (we don’t support them as arguments). @@ -1334,21 +883,17 @@ DE: I’m happy to hear that. JHD: I don’t have a concrete opinion at the moment. -DE: You mean by proposal by proposal basis, which we confirmed already, as opposed to leaving -the option over to overturn the rule in general or something? +DE: You mean by proposal by proposal basis, which we confirmed already, as opposed to leaving the option over to overturn the rule in general or something? JHD: Correct. I think EAO expressed earlier as well that it’s the correct thing to do is be as strict as possible by default and explicitly agree for any exceptions, as long as we are open to reasonable exceptions. -DE: Perfect. I’m really glad that we agree about that. +DE: Perfect. I’m really glad that we agree about that. -WH: I’m on board with this, except for boolean. I’m not ashamed to say that I write +WH: I’m on board with this, except for boolean. I’m not ashamed to say that I write `if` statements using integers as the condition. I use `&&` or `||` -with arguments that are not booleans and sometimes rely on them actually -carrying the uncoerced value through. One of the things that can happen with booleans is that you’re interested in whether the argument is truthy or falsy, and, depending on which one it is, you’re actually interested in the uncoerced value of the argument. That’s what `&&` does, for example. +with arguments that are not booleans and sometimes rely on them actually carrying the uncoerced value through. One of the things that can happen with booleans is that you’re interested in whether the argument is truthy or falsy, and, depending on which one it is, you’re actually interested in the uncoerced value of the argument. That’s what `&&` does, for example. -KG: Yeah. I agree that Booleans are both more useful and also significantly less problematic -because coercing to Boolean does not invoke user code. So, yeah, I’m happy to say that -coercing to Boolean specifically continues to be fine. I’ve done the same thing myself. +KG: Yeah. I agree that Booleans are both more useful and also significantly less problematic because coercing to Boolean does not invoke user code. So, yeah, I’m happy to say that coercing to Boolean specifically continues to be fine. I’ve done the same thing myself. RPR: I think SFC is going to agree. @@ -1358,15 +903,12 @@ RPR: And PFC. PFC: KG already said what I was going to say. -RPR: Got it, yeah, does not call user code. TAB? +RPR: Got it, yeah, does not call user code. TAB? -KG: Sorry, I was reminded of one more thing on this front, which is that we have in the past run -into cases where we had an API which took a boolean and we then wanted to expand it and we -couldn’t, which leads to one of my favorite sentences in all of our specifications in ECMA 402, that is like 'for historical reasons, the string value “false” is treated as `true`', -which, like… I gues we will continue to have issues with expanding APIs from -Booleans to a larger domain of types. But, yeah, it’s plausible worth it. +KG: Sorry, I was reminded of one more thing on this front, which is that we have in the past run into cases where we had an API which took a boolean and we then wanted to expand it and we couldn’t, which leads to one of my favorite sentences in all of our specifications in ECMA 402, that is like 'for historical reasons, the string value “false” is treated as `true`', +which, like… I gues we will continue to have issues with expanding APIs from Booleans to a larger domain of types. But, yeah, it’s plausible worth it. -TAB [on the queue]: plus 1 to everything. Maybe keep allow bools, but `!!obj` is fine. +TAB [on the queue]: plus 1 to everything. Maybe keep allow bools, but `!!obj` is fine. RKG [on the queue]: +1 modulo the Booleans. @@ -1376,61 +918,30 @@ RKG: Yeah, I think I would -- I would favor allowing boolean coercion. KG: Cool. -SFC: Yeah, I have the next two items. I want to switch the order of them and do the second one -first. So GetOption is the -- is an abstract operation used very widely in Intl, in Temporal, -in 262. And like, this is -- seems like the biggest case that, like, this change would impact. -And I think that the -- you know, the status quo of GetOption behavior is definitely, I think, -something that developers are accustomed to, that spec authors like myself and others, are -accustomed to. And I don’t necessarily think we’re in a position right now to basically say, -like, oh, we’re going to make GetOptionV2, which has a different type of behavior. I think -we have GetOption and GetOption works the way it works, and we should keep using GetOption. +SFC: Yeah, I have the next two items. I want to switch the order of them and do the second one first. So GetOption is the -- is an abstract operation used very widely in Intl, in Temporal, +in 262. And like, this is -- seems like the biggest case that, like, this change would impact. +And I think that the -- you know, the status quo of GetOption behavior is definitely, I think, +something that developers are accustomed to, that spec authors like myself and others, are accustomed to. And I don’t necessarily think we’re in a position right now to basically say, +like, oh, we’re going to make GetOptionV2, which has a different type of behavior. I think we have GetOption and GetOption works the way it works, and we should keep using GetOption. . -KG: You can say more about why we can’t just make GetOption strict? That’s the explicitly the -thing I’m asking for. I really don’t want to coerce values from options bags where you look up -the value and it’s an object and you coerce that to a number. That is explicitly what I want -us to not do. Why can’t we just stop doing that in new things? +KG: You can say more about why we can’t just make GetOption strict? That’s the explicitly the thing I’m asking for. I really don’t want to coerce values from options bags where you look up the value and it’s an object and you coerce that to a number. That is explicitly what I want us to not do. Why can’t we just stop doing that in new things? . -SFC: I think that -- would you consider it to be an -- a reasonable exception that, like, all -other options in this options bag do GetOption V1, we add a new option to the option bag and -continue the use GetOption V1, is that a case of -- +SFC: I think that -- would you consider it to be an -- a reasonable exception that, like, all other options in this options bag do GetOption V1, we add a new option to the option bag and continue the use GetOption V1, is that a case of -- . -KG: Yes, I think when you already have an existing API that coerces, you know, five of its -arguments and you’re adding a sixth, also coercing that one is fine. That is a reasonable -exception. +KG: Yes, I think when you already have an existing API that coerces, you know, five of its arguments and you’re adding a sixth, also coercing that one is fine. That is a reasonable exception. . -SFC: Okay. Yeah, another thing here is like, GetOption and options bag is quite a different -beast than, like, you know, coercing arguments or coercing the callee. I think -those are quite different things, because options bags are by their nature, like, something -that, you know, has certain types of rules. So I guess what I’m trying to argue -- what I’m -trying to say is that the mental model that goes -- that is behind basically named arguments -and options bags is fundamentally different than the mental model that goes into positional -arguments. For example, if you’re writing, like, a named argument, you have to name the -argument in your call site. And then, like, you know, it’s really -- it’s much easier when -reading and reviewing code that, like, this thing is expected to be a string, I’m passing -anything that’s not a string, it’s going to be coerced to a string. That’s much more clear. -Now, positional arguments, I think there’s definitely a very strong argument from the side of -readability. +SFC: Okay. Yeah, another thing here is like, GetOption and options bag is quite a different beast than, like, you know, coercing arguments or coercing the callee. I think those are quite different things, because options bags are by their nature, like, something that, you know, has certain types of rules. So I guess what I’m trying to argue -- what I’m trying to say is that the mental model that goes -- that is behind basically named arguments and options bags is fundamentally different than the mental model that goes into positional arguments. For example, if you’re writing, like, a named argument, you have to name the argument in your call site. And then, like, you know, it’s really -- it’s much easier when reading and reviewing code that, like, this thing is expected to be a string, I’m passing anything that’s not a string, it’s going to be coerced to a string. That’s much more clear. +Now, positional arguments, I think there’s definitely a very strong argument from the side of readability. . -KG: I guess I just don’t share that intuition. I think that if I end up constructing an options -bag and, like I do, you know, measurement unit V and I have accidentally messed things up such -that V is holding an object, I would prefer to get an exception rather than calling to ToString -on that. I just don’t have the intuition that, like, you want to do coercion for arguments and options bags. +KG: I guess I just don’t share that intuition. I think that if I end up constructing an options bag and, like I do, you know, measurement unit V and I have accidentally messed things up such that V is holding an object, I would prefer to get an exception rather than calling to ToString on that. I just don’t have the intuition that, like, you want to do coercion for arguments and options bags. . -SYG: Yeah, I think I’m next on the queue. I agree with KG here. I also don’t -- I think it -is true that options bags have different rules. Namely they have names. But I think it would -be harmful to explicitly say that name parameters ought to coerce by default but positional -arguments do not. I think the -- the engine costs and the test stuff, like, I think all of -those arguments also directly apply to named arguments and options bags. I don’t quite -understand what the categorical difference is with respect to coercion, so I would strongly -prefer that we do not coerce. +SYG: Yeah, I think I’m next on the queue. I agree with KG here. I also don’t -- I think it is true that options bags have different rules. Namely they have names. But I think it would be harmful to explicitly say that name parameters ought to coerce by default but positional arguments do not. I think the -- the engine costs and the test stuff, like, I think all of those arguments also directly apply to named arguments and options bags. I don’t quite understand what the categorical difference is with respect to coercion, so I would strongly prefer that we do not coerce. . CDA: Shane? . -SFC: I mean, I just wrote a little example code. Like, that’s fine to coerce, string to number -in that case. Like -- +SFC: I mean, I just wrote a little example code. Like, that’s fine to coerce, string to number in that case. Like -- . -KG: Yeah, the coercing string to number is the next item. Right now we’re only talking about -coercing object to number. +KG: Yeah, the coercing string to number is the next item. Right now we’re only talking about coercing object to number. . SFC: Okay. . @@ -1438,168 +949,80 @@ SYG: Yes, specifically the cost around invoking user hook points like value of a . KG: There’s less value there, because GetOption does a property lookup, which is hookable. . -SFC: Okay, so let’s go ahead to my other agenda item, then, which is the one that’s currently -says it’s topic. 15 minutes remain. So we have Symbol.toStringTag and Symbol.toPrimitive. -Like, the -- I mean, we’ve referenced that user code earlier in this conversation, but isn’t -the whole point of having that user code specifically so that, you know, library developers can -design objects that coerce into a way that makes sense for those objects? Like -- - -KG: Yeah. Well, no, actually, as far as I am aware, the only reason that `Symbol.toStringTag` -- -well, toStringTag is kind of irrelevant, because toStringTag is only used for Object.prototype.toString. But `Symbol.toPrimitive`, yes. The reason for that is it was thought to be -good idea to let library code customize how they would coerce to primitives. My understanding -is this was part of a larger effort in ES6 to explain the behavior of existing things in the -language in terms of user definable hook points and in particular, Date happens to have -different toPrimitive behavior from everything else. I don’t particularly share that -rationale, and this is explicitly a rejection of the goal of allowing people to, like, make -things that coerce to primitives in interesting ways. - -JHD: I just want to clarify, this change wouldn’t affect that goal, this just says that if you -want to make things coerced in interesting ways, the users will just have to do the coercion -before they pass it into an API. +SFC: Okay, so let’s go ahead to my other agenda item, then, which is the one that’s currently says it’s topic. 15 minutes remain. So we have Symbol.toStringTag and Symbol.toPrimitive. +Like, the -- I mean, we’ve referenced that user code earlier in this conversation, but isn’t the whole point of having that user code specifically so that, you know, library developers can design objects that coerce into a way that makes sense for those objects? Like -- + +KG: Yeah. Well, no, actually, as far as I am aware, the only reason that `Symbol.toStringTag` -- +well, toStringTag is kind of irrelevant, because toStringTag is only used for Object.prototype.toString. But `Symbol.toPrimitive`, yes. The reason for that is it was thought to be good idea to let library code customize how they would coerce to primitives. My understanding is this was part of a larger effort in ES6 to explain the behavior of existing things in the language in terms of user definable hook points and in particular, Date happens to have different toPrimitive behavior from everything else. I don’t particularly share that rationale, and this is explicitly a rejection of the goal of allowing people to, like, make things that coerce to primitives in interesting ways. + +JHD: I just want to clarify, this change wouldn’t affect that goal, this just says that if you want to make things coerced in interesting ways, the users will just have to do the coercion before they pass it into an API. KG: There actually isn’t a way for a user to coerce to primitive in general. JHD: Yeah, they can plus it or String it. -KG: There’s a way to coerce to a particular type of primitive. But that’s also toString and -valueOf. The thing that toPrimitive adds on top of toString and valueOf is if you are -just coercing to primitive without specifying either string or value. +KG: There’s a way to coerce to a particular type of primitive. But that’s also toString and valueOf. The thing that toPrimitive adds on top of toString and valueOf is if you are just coercing to primitive without specifying either string or value. -JHD: It takes a hint. So it always is doing one of the two and there a default hint, but it’s -- -those are the two mechanisms. You’re always either coercing to string or to number, so -if you want to do that as a user. +JHD: It takes a hint. So it always is doing one of the two and there a default hint, but it’s -- +those are the two mechanisms. You’re always either coercing to string or to number, so if you want to do that as a user. KG: Yes. -JHD: Or Boolean or whatever. But those are the two hints you’re providing, so you can still -- +JHD: Or Boolean or whatever. But those are the two hints you’re providing, so you can still -- this change that you’re advocating for, KG’s will not affect the ability to define to custom behavior and when users do the coercion themselves instead of doing it inside API, that same customization will apply, so moving where the magic conversion happens. -KG: That’s exactly right. If the user wants to coerce the values that a library gave them, they -should coerce the values before passing them somewhere and expecting the language to do the -coercion. - -SFC: Yeah I guess as a general rule for objects, since objects are things that library authors -can customize the coercion behavior of already, it’s just not clear to me that, you know -- and -also the fact that these objects are already, you know -- can already have the custom coercion -behavior in all other existing APIs. It’s just not clear to me that it’s necessarily a wise -choice to sort of make APIs that were defined before 2023 use the custom -- the library -author’s custom coercion functions and APIs introduced after 2023 need the explicit coercion -code at the call site. And I’m just not convinced about that. - -KG: So we heard from engine authors that this would help a lot with eliminating bugs and -engines. We heard from test authors that this would save a huge amount of efforts for tests. -Is your belief that this is useful enough to outweigh that? I feel like eliminating a -large source of bugs is very, very valuable, and even acknowledging that there is value in this -for some cases, it just doesn’t seem remotely close to comparable in value. - -SYG: I would find that counterargument more persuasive if we had empirical evidence today of -library authors taking advantage of the power given how long it’s been around. I haven’t seen -much of it. But happy to be persuaded otherwise. I mainly see it abused as an attack vector. - -RPR: Ten minutes remaining. SFC? - -SFC: In terms of, you know, order of constituencies, you know, my understanding is that we -usually respect or users more than engines more than tests, so if this affects engines and tests but -harms users that’s not really an argument that -- - -KG: Users then developers then implementation complexity then test. Users is the users -of websites and they are directly harmed when there’s an exploitable vector in an engine. -Eliminating a source of engine bugs that leads to Chrome having a zero day is of direct -benefit to users, who are a higher priority than the developers. - -SFC: Sure. To respond to SYG’s point, I’m not the person who proposed this and I haven’t -actually gathered the data. - -SYG: You’re making a counterargument that this is a power that library authors enjoy today and -you don’t want to take that away. I would like -- I’m not sure if it -- okay, I don’t want to -get into this. If anybody has data, I want to like to see. - -KG: I think it’s worth talking about TypeScript, because if you’re shipping a library that relies -on this, TypeScript will say your user value is not a string, so I think in practice, this is -not a thing that it is easy to rely on right now. Because doing so means cutting off a large -fraction of your users. - -WH: SFC’s point brings up the larger point that behavior of similarly-looking APIs -will depend on *when* they were standardized by TC39. I’m concerned about shipping our -process which confuses users unfamiliar with our history. Now, that’s a larger discussion, so I’d like to know if there’s a way to get users to stop doing coercions in existing APIs? Maybe TypeScript or -something? - -KG: TypeScript, yes, TypeScript is the solution. I agree, I actually have that concern and -that’s why I have this parenthetical about close cousins of existing APIs. For example when we added findLastIndex, that is close enough to findIndex that it -makes sense to copy it exactly, "bug-for-bug compat" as we sometimes say. But also, I think -a thing we did in ES6 was add some new array methods that treat holes as undefined. And -this has occasionally been confusing but I think worthwhile. So, yeah, it’s definitely a -concern, but also I think separately, TypeScript makes it so that most of the time, you’re not -doing this if you are using TypeScript. TypeScript isn’t completely sound, so most of the -time that you do end up doing this in TypeScript, it’s a bug, and I think users will be happier -if we can catch that bug at runtime in at least some cases, even though we can’t in older APIs. - -TAB: Yeah, I’ll be quick. As a program author, in Python, which is real relatively strict about -not allowing coercions, I usually find this a benefit to me, to I do have to be explicit about -“turn this into a string for me, turn this into a number for me” because it avoids bugs in my own -code, so plus 1 as an author helper for this. As opposed to it being an occasional convenience -that I’d be losing. Then related to that, on the topic of the inflection points of shifting -author behavior, in addition to TypeScript probably being useful there, just the fact that we -have -- we will begin to have increasing numbers of APIs that don’t coerce will change author -behavior all on its own and have them start leaning towards eagerly coercing when necessary, -even in APIs that don’t require it. So I think in general, this -- the amount of -- as -strictness goes up, author behavior itself will shift to accommodating that strictness. +KG: That’s exactly right. If the user wants to coerce the values that a library gave them, they should coerce the values before passing them somewhere and expecting the language to do the coercion. + +SFC: Yeah I guess as a general rule for objects, since objects are things that library authors can customize the coercion behavior of already, it’s just not clear to me that, you know -- and also the fact that these objects are already, you know -- can already have the custom coercion behavior in all other existing APIs. It’s just not clear to me that it’s necessarily a wise choice to sort of make APIs that were defined before 2023 use the custom -- the library author’s custom coercion functions and APIs introduced after 2023 need the explicit coercion code at the call site. And I’m just not convinced about that. + +KG: So we heard from engine authors that this would help a lot with eliminating bugs and engines. We heard from test authors that this would save a huge amount of efforts for tests. +Is your belief that this is useful enough to outweigh that? I feel like eliminating a large source of bugs is very, very valuable, and even acknowledging that there is value in this for some cases, it just doesn’t seem remotely close to comparable in value. + +SYG: I would find that counterargument more persuasive if we had empirical evidence today of library authors taking advantage of the power given how long it’s been around. I haven’t seen much of it. But happy to be persuaded otherwise. I mainly see it abused as an attack vector. + +RPR: Ten minutes remaining. SFC? + +SFC: In terms of, you know, order of constituencies, you know, my understanding is that we usually respect or users more than engines more than tests, so if this affects engines and tests but harms users that’s not really an argument that -- + +KG: Users then developers then implementation complexity then test. Users is the users of websites and they are directly harmed when there’s an exploitable vector in an engine. +Eliminating a source of engine bugs that leads to Chrome having a zero day is of direct benefit to users, who are a higher priority than the developers. + +SFC: Sure. To respond to SYG’s point, I’m not the person who proposed this and I haven’t actually gathered the data. + +SYG: You’re making a counterargument that this is a power that library authors enjoy today and you don’t want to take that away. I would like -- I’m not sure if it -- okay, I don’t want to get into this. If anybody has data, I want to like to see. + +KG: I think it’s worth talking about TypeScript, because if you’re shipping a library that relies on this, TypeScript will say your user value is not a string, so I think in practice, this is not a thing that it is easy to rely on right now. Because doing so means cutting off a large fraction of your users. + +WH: SFC’s point brings up the larger point that behavior of similarly-looking APIs will depend on *when* they were standardized by TC39. I’m concerned about shipping our process which confuses users unfamiliar with our history. Now, that’s a larger discussion, so I’d like to know if there’s a way to get users to stop doing coercions in existing APIs? Maybe TypeScript or something? + +KG: TypeScript, yes, TypeScript is the solution. I agree, I actually have that concern and that’s why I have this parenthetical about close cousins of existing APIs. For example when we added findLastIndex, that is close enough to findIndex that it makes sense to copy it exactly, "bug-for-bug compat" as we sometimes say. But also, I think a thing we did in ES6 was add some new array methods that treat holes as undefined. And this has occasionally been confusing but I think worthwhile. So, yeah, it’s definitely a concern, but also I think separately, TypeScript makes it so that most of the time, you’re not doing this if you are using TypeScript. TypeScript isn’t completely sound, so most of the time that you do end up doing this in TypeScript, it’s a bug, and I think users will be happier if we can catch that bug at runtime in at least some cases, even though we can’t in older APIs. + +TAB: Yeah, I’ll be quick. As a program author, in Python, which is real relatively strict about not allowing coercions, I usually find this a benefit to me, to I do have to be explicit about +“turn this into a string for me, turn this into a number for me” because it avoids bugs in my own code, so plus 1 as an author helper for this. As opposed to it being an occasional convenience that I’d be losing. Then related to that, on the topic of the inflection points of shifting author behavior, in addition to TypeScript probably being useful there, just the fact that we have -- we will begin to have increasing numbers of APIs that don’t coerce will change author behavior all on its own and have them start leaning towards eagerly coercing when necessary, +even in APIs that don’t require it. So I think in general, this -- the amount of -- as strictness goes up, author behavior itself will shift to accommodating that strictness. That’s it for me. -SFC: So there’s been other comments just in this week’s meeting where talk about TypeScript, and -what we often say in these situations, and I can name them if you want me to, “we’re not -standardizing TypeScript, we’re standardizing ECMAScript” which has constraints that are -different than TypeScript. I do agree that TypeScript can really help with, you know, making -it so that, like, library authors maybe don’t take advantage of ECMAScript language coercion. -But there are ways to get it sorted in; it can be written in TypeScript -definitions. Like, you know, TypeScript has some flexibility in it. We don’t need to typically -belabor that point. But I definitely take the points that -TypeScript helps here; it's just that I don’t take the point that TypeScript is the panacea for the -problem. - -JHD: So I would be the last person to say that we should use TypeScript as evidence to do a thing -in TC39, but what I would say is what it does do here is indicate that in fact users simply -don’t use this feature. Period. Because there have been -- I am probably one of the few -people that have ever filed a TypeScript bug for the types not accepting coercible things. +SFC: So there’s been other comments just in this week’s meeting where talk about TypeScript, and what we often say in these situations, and I can name them if you want me to, “we’re not standardizing TypeScript, we’re standardizing ECMAScript” which has constraints that are different than TypeScript. I do agree that TypeScript can really help with, you know, making it so that, like, library authors maybe don’t take advantage of ECMAScript language coercion. +But there are ways to get it sorted in; it can be written in TypeScript definitions. Like, you know, TypeScript has some flexibility in it. We don’t need to typically belabor that point. But I definitely take the points that TypeScript helps here; it's just that I don’t take the point that TypeScript is the panacea for the problem. + +JHD: So I would be the last person to say that we should use TypeScript as evidence to do a thing in TC39, but what I would say is what it does do here is indicate that in fact users simply don’t use this feature. Period. Because there have been -- I am probably one of the few people that have ever filed a TypeScript bug for the types not accepting coercible things. KG: It happens more than it should. -JHD: Sorry, the -- people pass things and -- in that need -- that get implicitly coerced a lot. -What I mean is when users are forced to do the coercion, they simply do the coercion because -that’s how a type TypeScript user would solve things: “oh, I put in a string that isn’t a string, -I’ll make it into a string”, problem solved. I think that serves as ample evidence it’s not -going to hurt anyone to give them this warning in the language instead of just in TypeScript, -and I think it’s much more valuable to provide this strictness in the language than to do it -for the subset of language users that use TypeScript no matter how large or small that subset -is. - -LCA: Yeah, a comments on this, I thought of this because of the comment you made, JHD, based -on the TypeScript issues. A lot of web API -- web APIs generally do this object to -primitive coercion, and whereas it is much more strict about things like accepting integers or -clamping or sort of doing -- being more strict around those things, it is very loose about -coercion of objects to primitives. And this would sort of desync us from WebIDL, which -maybe is okay, but I wanted to bring up that this is something that will definitely happen. - -KG: Yeah, we don’t specify WebIDL but my intention is to follow up there and concretely my -intention is to introduce a legacy web attribute and add it to every API and then change the -behavior for things that lack that attribute so they don’t coerce. Remains to be seen if -that’s something that web and W3C will be on board with although I brought it up and have not -gotten shut down out of hand. So definitely agreed. Plan is to do that. +JHD: Sorry, the -- people pass things and -- in that need -- that get implicitly coerced a lot. +What I mean is when users are forced to do the coercion, they simply do the coercion because that’s how a type TypeScript user would solve things: “oh, I put in a string that isn’t a string, +I’ll make it into a string”, problem solved. I think that serves as ample evidence it’s not going to hurt anyone to give them this warning in the language instead of just in TypeScript, +and I think it’s much more valuable to provide this strictness in the language than to do it for the subset of language users that use TypeScript no matter how large or small that subset is. + +LCA: Yeah, a comments on this, I thought of this because of the comment you made, JHD, based on the TypeScript issues. A lot of web API -- web APIs generally do this object to primitive coercion, and whereas it is much more strict about things like accepting integers or clamping or sort of doing -- being more strict around those things, it is very loose about coercion of objects to primitives. And this would sort of desync us from WebIDL, which maybe is okay, but I wanted to bring up that this is something that will definitely happen. + +KG: Yeah, we don’t specify WebIDL but my intention is to follow up there and concretely my intention is to introduce a legacy web attribute and add it to every API and then change the behavior for things that lack that attribute so they don’t coerce. Remains to be seen if that’s something that web and W3C will be on board with although I brought it up and have not gotten shut down out of hand. So definitely agreed. Plan is to do that. . LCA: Okay, happy to hear that. . -SYG: It is not pre--- we didn’t coordinate this with KG, but if you need any help, I’d be -happy to provide any assistance, organizational, that kind of thing, inside to try to make that -happen. Because I think it would be good for all browsers. I was going to -- we can talk -offline about user hook points, but I think in the interest of time, maybe you want to ask for -consensus. +SYG: It is not pre--- we didn’t coordinate this with KG, but if you need any help, I’d be happy to provide any assistance, organizational, that kind of thing, inside to try to make that happen. Because I think it would be good for all browsers. I was going to -- we can talk offline about user hook points, but I think in the interest of time, maybe you want to ask for consensus. . -KG: I would like to ask for consensus for - not quite this thing up here. It is specifically -things which take primitives other than boolean, so bigint, symbol - I don’t think anything -explicitly takes null - should throw a TypeError rather than -invoking toPrimitive or toString or valueOf. Same caveats as last time, if you want -that in a new proposal, it’s perfectly reasonable to make a new case for it if you have a -reason to. I’ve heard several bits of support. Any objections? +KG: I would like to ask for consensus for - not quite this thing up here. It is specifically things which take primitives other than boolean, so bigint, symbol - I don’t think anything explicitly takes null - should throw a TypeError rather than invoking toPrimitive or toString or valueOf. Same caveats as last time, if you want that in a new proposal, it’s perfectly reasonable to make a new case for it if you have a reason to. I’ve heard several bits of support. Any objections? . WH: What about coercion functions? . @@ -1607,533 +1030,517 @@ KG: I think coercion functions are a clear case where you want to do coercion. RPR: SFC? -SFC: I raised several points and I think a lot of the points have been addressed, but I am uneasy about the named argument and thing as well as the, you know, library author bifurcation thing. These are things that I believe the committee is undervaluing. +SFC: I raised several points and I think a lot of the points have been addressed, but I am uneasy about the named argument and thing as well as the, you know, library author bifurcation thing. These are things that I believe the committee is undervaluing. -KG: So we talked about all of those and I recognize the library author's concern. I felt the response was compelling. The cost to users of the browsers from the bugs that happen is quite substanding and the existence of TypeScript demonstrates in fact library authors are not doing this because any library author doing that, it doesn’t work with TypeScript. We are not shipping TypeScript or standardizing it, but I think that the fact is that many people are using it and so the fact that TypeScript does do this is good evidence that library authors don’t rely on that. I felt this was a compelling response to your point. +KG: So we talked about all of those and I recognize the library author's concern. I felt the response was compelling. The cost to users of the browsers from the bugs that happen is quite substanding and the existence of TypeScript demonstrates in fact library authors are not doing this because any library author doing that, it doesn’t work with TypeScript. We are not shipping TypeScript or standardizing it, but I think that the fact is that many people are using it and so the fact that TypeScript does do this is good evidence that library authors don’t rely on that. I felt this was a compelling response to your point. -SYG: Yeah. I think there is actually – the counter-arguments given to your concerns are more hard than soft and I would like to understand why you have found them uncompelling. +SYG: Yeah. I think there is actually – the counter-arguments given to your concerns are more hard than soft and I would like to understand why you have found them uncompelling. -SFC: I would find it compelling if – one thing I heard SYG mention, for example, is that like, you know, users are harmed by security exploits. That’s mentioned in words. I know I sometimes read posts about things like that. It’s good to sort of, you know, quantify that and make it more clear. This is the problem we are solving. I hear the developer ergonomics-type questions for like users of libraries. I totally understand that. And I also appreciate that as a developer. I am talking about taking the angle of – I write a lot of ECMAScript libraries. And as a library author, it’s the angle that I am taking this from. This is basically what I do for a living. And like you’re taking power away from me. And I want to sort of understand more if – are users being harmed by this? Taking that for granted? I want to see that written down more clearly. And yeah. I mean, I don’t like taking the unpopular position on a committee, but I am – it’s likely that I can be compelled with time and evidence and discussions about this. +SFC: I would find it compelling if – one thing I heard SYG mention, for example, is that like, you know, users are harmed by security exploits. That’s mentioned in words. I know I sometimes read posts about things like that. It’s good to sort of, you know, quantify that and make it more clear. This is the problem we are solving. I hear the developer ergonomics-type questions for like users of libraries. I totally understand that. And I also appreciate that as a developer. I am talking about taking the angle of – I write a lot of ECMAScript libraries. And as a library author, it’s the angle that I am taking this from. This is basically what I do for a living. And like you’re taking power away from me. And I want to sort of understand more if – are users being harmed by this? Taking that for granted? I want to see that written down more clearly. And yeah. I mean, I don’t like taking the unpopular position on a committee, but I am – it’s likely that I can be compelled with time and evidence and discussions about this. -SYG: Hard evidence, users are unequivocally harmed by this. We can work with Project Zero to pull up stuff that has come up in the past. We have paid out thousands of hundreds of dollars to things like user code, detaching or ArrayBuffers in built-ins that did not expect argument coercion to Deattach an ArrayBuffer. Object hurts this because it offers a surprising attack vector; you can see implementers are forgetting to really check. If you want hard-cash numbers, we can work to get that. I feel confident saying, they are most harmed +SYG: Hard evidence, users are unequivocally harmed by this. We can work with Project Zero to pull up stuff that has come up in the past. We have paid out thousands of hundreds of dollars to things like user code, detaching or ArrayBuffers in built-ins that did not expect argument coercion to Deattach an ArrayBuffer. Object hurts this because it offers a surprising attack vector; you can see implementers are forgetting to really check. If you want hard-cash numbers, we can work to get that. I feel confident saying, they are most harmed -KG: We are at time. We can come back with this next meeting. Deciding this now doesn’t affect anything. I want to briefly mention, I didn’t get to the third thing, which is fine, which is that I do want to discuss maybe we stop coercing string to number and conversely. Be prepared for that next time. -And I reduce the scope of this particular item to not encompass Booleans. Not asking for consensus because Shane has objected. And I would like more discussion, which I am happy to have. Look for this item to come back. Thanks, all +KG: We are at time. We can come back with this next meeting. Deciding this now doesn’t affect anything. I want to briefly mention, I didn’t get to the third thing, which is fine, which is that I do want to discuss maybe we stop coercing string to number and conversely. Be prepared for that next time. +And I reduce the scope of this particular item to not encompass Booleans. Not asking for consensus because Shane has objected. And I would like more discussion, which I am happy to have. Look for this item to come back. Thanks, all -RPR: Thank you. We have support from RGN and EAO. +RPR: Thank you. We have support from RGN and EAO. ### Summary + - KG explained the various problems caused by coercion, and raised several concrete questions to the committee about which aspects of coercion we should limit for future proposals. - SYG supports this program, noting that Google Project Zero has found several security issues due to coercion. - Most speakers were supportive of these changes. - SFC defended certain kinds of coercion for various detailed reasons. - The committee generally supported *maintaining* ToBoolean coercion, which is quite different from other kinds (e.g., it doesn’t have side effects, and is very well-known due to its use in if statements). + ### Conclusion + - Unless there’s a particular reason for a particular API, future integer-taking APIs should throw if given non-integer inputs - No consensus reached on whether objects should be coerced to primitives, or primitives between each other + ## reducing wasted effort due to proposal churn (continued) + Presenter: Michael Ficarra (MF) - [slides](​​https://docs.google.com/presentation/d/1HtcFY98qWy-LPJLawRIkYzhDEjuEeyArMiNXbCOFcrk/view) - -MF: So we talked about this at Bergen, and we did not come to a conclusion but seemed to be getting close. So I think we can continue this discussion and I will start just by briefly reminding everyone what I am asking for. +MF: So we talked about this at Bergen, and we did not come to a conclusion but seemed to be getting close. So I think we can continue this discussion and I will start just by briefly reminding everyone what I am asking for. MF: So if you look at this graph, this is a very loosely drawn graph on the different things we do, and their relative effort. Designing a proposal is much less effort than the spec text, which is less effort than writing all the test262 tests, considering all the paths that must be covered, which is less effort than the implementation effort when you consider them in aggregate. -MF: So the thing that I think we should do is do these in this strict order. We should do the design and only once the design is done, write the spec text and when that is fully written, write the test262 tests and only once the test262 tests are as complete as we can make them, start on implementation. +MF: So the thing that I think we should do is do these in this strict order. We should do the design and only once the design is done, write the spec text and when that is fully written, write the test262 tests and only once the test262 tests are as complete as we can make them, start on implementation. -MF: So here is my proposal laid out. You will see that stage 2, the meaning is completely unchanged as well as all of the things we do during Stage 2. +MF: So here is my proposal laid out. You will see that stage 2, the meaning is completely unchanged as well as all of the things we do during Stage 2. -MF: The meaning of stage 3 is unchanged. We add a new stage between stage 2 and stage 3, where we do some of the things that today we are doing during Stage 3: writing test262 tests. +MF: The meaning of stage 3 is unchanged. We add a new stage between stage 2 and stage 3, where we do some of the things that today we are doing during Stage 3: writing test262 tests. MF: I have a note over here that the purpose of this stage is that once we reach this stage, the design of this proposal is as final as we can make it without any feedback from tests and implementations. MF: So after this point, we wouldn’t make arbitrary preference changes that would affect the design. -MF: Okay. So concretely, the problem that we have is that there’s a lot of proposal churn during stage 3, leading to repeated effort of some of the higher effort things: writing test262 tests and implementation. +MF: Okay. So concretely, the problem that we have is that there’s a lot of proposal churn during stage 3, leading to repeated effort of some of the higher effort things: writing test262 tests and implementation. MF: The proposed solution is adding this new stage as I have described, and having the entrance criteria for Stage 3 be just that we have sufficient experience and tests. MF: It’s important to note that Stage 3 as it is today, will remain the readiness signal for the implementers and an important public signal as well. -MF: If we achieve this consensus, I will do the explicit changes to the process document and come back with a PR that we can approve, but I hope that that would be pro forma because I will as accurately capture our preferences as possible. That’s where I want to stop with the presentation and open for discussion. +MF: If we achieve this consensus, I will do the explicit changes to the process document and come back with a PR that we can approve, but I hope that that would be pro forma because I will as accurately capture our preferences as possible. That’s where I want to stop with the presentation and open for discussion. -DE: I support this proposal. And in particular, I think there’s some subtlety around the strict ordering that you mentioned. It’s good to develop tests and implementations and specs while in the design phase, and but those things can be pipelined. It’s important to develop tests that are available for implementation and unreasonable to expect implementations to start doing too much before there are tests. Tests can often be developed against polyfills or transpiled versions or early implementation. So there’s nothing blocking implementation from getting started before Stage 3. It’s a question of when we wanted to declare, this is, you know, full steam ahead, ready for everybody to maybe start implementing. +DE: I support this proposal. And in particular, I think there’s some subtlety around the strict ordering that you mentioned. It’s good to develop tests and implementations and specs while in the design phase, and but those things can be pipelined. It’s important to develop tests that are available for implementation and unreasonable to expect implementations to start doing too much before there are tests. Tests can often be developed against polyfills or transpiled versions or early implementation. So there’s nothing blocking implementation from getting started before Stage 3. It’s a question of when we wanted to declare, this is, you know, full steam ahead, ready for everybody to maybe start implementing. DE: So I think separating out the testing from the engine implementation will be very productive thing in the stage process -MF: Thank you, DE. That’s a good point. I didn’t mean to imply we might be prohibiting getting started on implementation early. Thank you. +MF: Thank you, DE. That’s a good point. I didn’t mean to imply we might be prohibiting getting started on implementation early. Thank you. -DE: But also, expect that there will be more wrangling over the wording of this when you make a PR. We can do that async. But writing the document unfortunately won’t be pro forma; everybody will have opinions. +DE: But also, expect that there will be more wrangling over the wording of this when you make a PR. We can do that async. But writing the document unfortunately won’t be pro forma; everybody will have opinions. MF: Okay JHD: I love this. This is great. We shouldn’t be sending the public signal of Stage 3 until we have a sufficient set of tests. This is awesome. A bunch of stuff we will bikeshed, like the wording of this, and the name of the new stage and so on, but that’s the fun part. I think that this is a very good change for our process. -EAO: There was EAO on that. But the stage `e` is clearly the right choice, short for test. +EAO: There was EAO on that. But the stage `e` is clearly the right choice, short for test. -MLS: This will slow things down because as an implementer, I am not sure I am inclined to write the Test262 test and things like that. So now there’s this waiting game of who will write the test before. I also think that we have to be very careful that we – I don’t necessarily buy in that we are sending the – accepted sending to the community when we get to stage 3. I don’t think that will revert back. Often types, the things we find, we already have Test262, we already have implementations and find something out and that is what causes to revert. I don’t think this will basically do what it’s intended to do. +MLS: This will slow things down because as an implementer, I am not sure I am inclined to write the Test262 test and things like that. So now there’s this waiting game of who will write the test before. I also think that we have to be very careful that we – I don’t necessarily buy in that we are sending the – accepted sending to the community when we get to stage 3. I don’t think that will revert back. Often types, the things we find, we already have Test262, we already have implementations and find something out and that is what causes to revert. I don’t think this will basically do what it’s intended to do. -DE: So about the responsibility for the tests, many committee members have shared that the proposal author, champion should write the tests. This doesn’t always happen. Maybe half the time or so. I don’t know the numbers. +DE: So about the responsibility for the tests, many committee members have shared that the proposal author, champion should write the tests. This doesn’t always happen. Maybe half the time or so. I don’t know the numbers. -DE: But engine authors are free to contribute. And so I am not quite sure what you mean by a waiting game. We should definitely not repeat the pattern of something being at this new stage and just sitting for listening time without tests. We have done that with some Stage 3 proposal and the intention of this is to specifically incentivize that. Reverting to lower stages, it’s established that this is an important and sometimes good process, to do. +DE: But engine authors are free to contribute. And so I am not quite sure what you mean by a waiting game. We should definitely not repeat the pattern of something being at this new stage and just sitting for listening time without tests. We have done that with some Stage 3 proposal and the intention of this is to specifically incentivize that. Reverting to lower stages, it’s established that this is an important and sometimes good process, to do. -DE: So this might decrease the frequency of reverting to lower stages sometimes. Or the granularity of the stage decreases. But it shouldn’t be role of eliminating those. The goal is to derisk stage 3 somewhat. But this will not derisk web compatibility issues completely. So we should expect that there may be downgrades when these occur. +DE: So this might decrease the frequency of reverting to lower stages sometimes. Or the granularity of the stage decreases. But it shouldn’t be role of eliminating those. The goal is to derisk stage 3 somewhat. But this will not derisk web compatibility issues completely. So we should expect that there may be downgrades when these occur. -MLS: If we have downgrades, they will be double, from stage 3 not to stage 2.5, but back to stage 2 because now you have to probably change tests. +MLS: If we have downgrades, they will be double, from stage 3 not to stage 2.5, but back to stage 2 because now you have to probably change tests. -DE: Yeah. Probably. Depending on the case. We can do double downgrades. We have done that with, stage 1, before: SIMD was downgraded from 3 to 1, before later being withdrawn. +DE: Yeah. Probably. Depending on the case. We can do double downgrades. We have done that with, stage 1, before: SIMD was downgraded from 3 to 1, before later being withdrawn. DE: JHD gives the example, numeric literals went from stage 3 and then 1. But I don’t want to hold that example up, because that was an unfortunate case [where they were delayed without real benefit due to my error]. -MF: I think DE covered the thing I wanted to say. This is not meant to accomplish that goal at all. So . . . +MF: I think DE covered the thing I wanted to say. This is not meant to accomplish that goal at all. So . . . -WH: For some types of proposals, the hard part is figuring out a design which is web-compatible. And applying this process to those may slow things down because you have to bounce between disparate stages to try to come up with possible options for web-compatible design and figuring out which ones don’t break anything. +WH: For some types of proposals, the hard part is figuring out a design which is web-compatible. And applying this process to those may slow things down because you have to bounce between disparate stages to try to come up with possible options for web-compatible design and figuring out which ones don’t break anything. -MF: I don’t think I understood what you were saying. Can you rephrase? +MF: I don’t think I understood what you were saying. Can you rephrase? -WH: The graph in this proposal assumes that coming up with a design is easy and then implementing it is harder and so on. But that’s flipped for some proposals, where, to come up with the design, you need to know what is web-compatible, so you spend a lot of effort trying to figure out which alternatives are web-compatible. +WH: The graph in this proposal assumes that coming up with a design is easy and then implementing it is harder and so on. But that’s flipped for some proposals, where, to come up with the design, you need to know what is web-compatible, so you spend a lot of effort trying to figure out which alternatives are web-compatible. -DE: I am having a little trouble as well understanding it. I guess there are multiple classes of web compatibility. One of the different strategies, the last resort is ship it and see if it breaks things. +DE: I am having a little trouble as well understanding it. I guess there are multiple classes of web compatibility. One of the different strategies, the last resort is ship it and see if it breaks things. -DE: Browsers today have the policy that they won’t ship things unless tests. They might be a staging quality rather than a Test262, main director quality. But still, tests are writing complete tests is in the loop for this, for this – testing things again process. So I think this proposal should be pretty neutral with respect to that +DE: Browsers today have the policy that they won’t ship things unless tests. They might be a staging quality rather than a Test262, main director quality. But still, tests are writing complete tests is in the loop for this, for this – testing things again process. So I think this proposal should be pretty neutral with respect to that WH: Are you saying writing Test262 tests will tell you whether the proposal is web compatible? How? -DE: If you’re in a loop reshipping things to see if they are compatible, you have written tests as a precondition to shipping it. This will not change the length of such a loop. +DE: If you’re in a loop reshipping things to see if they are compatible, you have written tests as a precondition to shipping it. This will not change the length of such a loop. -WH: You mentioned that test-shipping something is the last resort of figuring out web compatibility. +WH: You mentioned that test-shipping something is the last resort of figuring out web compatibility. -DE: Shipping it and seeing whether that breaks the web is the last resort. Testing is like a first thing and a best practice. You can’t just conflate these. +DE: Shipping it and seeing whether that breaks the web is the last resort. Testing is like a first thing and a best practice. You can’t just conflate these. WH: So how does testing fit — -DE: You can’t write unit tests. They’re unrelated things. +DE: You can’t write unit tests. They’re unrelated things. -WH: I don’t understand your response. +WH: I don’t understand your response. -DE: So what do you mean by web compatible? +DE: So what do you mean by web compatible? -WH: We have seen many examples of proposals failing because they break some websites. +WH: We have seen many examples of proposals failing because they break some websites. -DE: Right. So when those breakages happen, it’s because, first, someone has written an implementation as well as tests because nobody will ship anything without a ship. It ships, and then an error was discovered in bug reports filed by people. These are just separate different flows. +DE: Right. So when those breakages happen, it’s because, first, someone has written an implementation as well as tests because nobody will ship anything without a ship. It ships, and then an error was discovered in bug reports filed by people. These are just separate different flows. WH: So everybody uses the last-resort technique of shipping and figuring out if anything breaks? -DE: We do our best beforehand to not do things that are not web compatible. +DE: We do our best beforehand to not do things that are not web compatible. -WH: That’s what I am trying to figure out. Where does this “do our best beforehand” slot into the process? +WH: That’s what I am trying to figure out. Where does this “do our best beforehand” slot into the process? -SYG: Can I interject here? So I think you’re confusing a few things. Test262 does not do anything about web compat. It’s about ensuring interop among new features and when we say web incompatibility, it’s usually about incompatibility in code that has shipped without the feature. It didn’t react well with the new feature. No Test262 test that checks for interop. There are best effort things we can do, like chrome doing statistic analysis, if it’s a syntax related feature. Otherwise zero we don’t know after like 3 decades how to can he being other than to [sthip] to stable populations and look for bugs. That is a reality, I admit, but that’s how it is. If you have on ideas how to do that, we don’t know +SYG: Can I interject here? So I think you’re confusing a few things. Test262 does not do anything about web compat. It’s about ensuring interop among new features and when we say web incompatibility, it’s usually about incompatibility in code that has shipped without the feature. It didn’t react well with the new feature. No Test262 test that checks for interop. There are best effort things we can do, like chrome doing statistic analysis, if it’s a syntax related feature. Otherwise zero we don’t know after like 3 decades how to can he being other than to [sthip] to stable populations and look for bugs. That is a reality, I admit, but that’s how it is. If you have on ideas how to do that, we don’t know -WH: That’s exactly what I thought the answer was. Which is why I found DE’s claim about tests to be so confusing. +WH: That’s exactly what I thought the answer was. Which is why I found DE’s claim about tests to be so confusing. -SYG: So to – I support this, first of all. So to expand on the reality today is that different browser shipping policies differ, but for Chrome, having interoperable tests because Chrome would like some sensible of confidence that new feature we ship is interoperable out the gate. So before we ship any feature, we require there exists some tests, that other engines run. So for web tests that’s WPT. For ecmascript that’s test262. So even though stage 3 entrance today does not require Test262 test Chrome doesn’t not ship anything until 262 tests are landed. +SYG: So to – I support this, first of all. So to expand on the reality today is that different browser shipping policies differ, but for Chrome, having interoperable tests because Chrome would like some sensible of confidence that new feature we ship is interoperable out the gate. So before we ship any feature, we require there exists some tests, that other engines run. So for web tests that’s WPT. For ecmascript that’s test262. So even though stage 3 entrance today does not require Test262 test Chrome doesn’t not ship anything until 262 tests are landed. -SYG: I don’t think that is true for all browsers but it’s true for Chrome. What happens is, things get to Stage 3 and we don’t ship because – there could be a waiting game today and if there’s independent interest to get that shipped sooner than later, there is now the stage in Test262 where implementers can directly upstream some tests. For the to the left of spec coverage that 262 writers write. But some interoperable is better than none. We have that directory. I think the Chrome shipping criteria is the right one. I think we want some semblance of confidence that features we ship are interoperable out the gate. And I think codifying that here would be net plus. +SYG: I don’t think that is true for all browsers but it’s true for Chrome. What happens is, things get to Stage 3 and we don’t ship because – there could be a waiting game today and if there’s independent interest to get that shipped sooner than later, there is now the stage in Test262 where implementers can directly upstream some tests. For the to the left of spec coverage that 262 writers write. But some interoperable is better than none. We have that directory. I think the Chrome shipping criteria is the right one. I think we want some semblance of confidence that features we ship are interoperable out the gate. And I think codifying that here would be net plus. -WH: Yeah. I agree with everything you just said. +WH: Yeah. I agree with everything you just said. -RPR: All right. The queue is empty. +RPR: All right. The queue is empty. -MF: Okay. Given the queue is empty, it’s sounds like the only remaining negative feedback we received was the concern from MLS that this could possibly slow the process. I don’t believe that will be the case. We can jump multiple stages, if somebody is willing to front load that work and take the risk that they will have wasted or duplicated work. But that basically ends up making it like today. +MF: Okay. Given the queue is empty, it’s sounds like the only remaining negative feedback we received was the concern from MLS that this could possibly slow the process. I don’t believe that will be the case. We can jump multiple stages, if somebody is willing to front load that work and take the risk that they will have wasted or duplicated work. But that basically ends up making it like today. -MF: So I would like to – well, I guess it’s not strictly necessary that I do today ask for consensus because I will come back and formally ask for consensus as well for a PR, but trying to codify what I have on the slide and we discussed today. +MF: So I would like to – well, I guess it’s not strictly necessary that I do today ask for consensus because I will come back and formally ask for consensus as well for a PR, but trying to codify what I have on the slide and we discussed today. -RPR: All right. So Michael is asking for any objections with this in principle? +RPR: All right. So Michael is asking for any objections with this in principle? RPR: And Dan has a point. -DE: I am not objecting, but I wanted to comment on the concern about how this proposal might slow things down. If it did slow proposals, that might not be a bad thing. It reduces the wasted work of having to produce the test redundantly. Implementers could produce Test262 tests if they want to. Slowing down isn’t bad if it leads to increased quality. And precision and a better outcome, it’s a good thing. That’s why we don’t set goal dates for proposals. We take our time until things are done. So I would like to ask MLS, following all the discussion, how do you feel about this overall, MLS? +DE: I am not objecting, but I wanted to comment on the concern about how this proposal might slow things down. If it did slow proposals, that might not be a bad thing. It reduces the wasted work of having to produce the test redundantly. Implementers could produce Test262 tests if they want to. Slowing down isn’t bad if it leads to increased quality. And precision and a better outcome, it’s a good thing. That’s why we don’t set goal dates for proposals. We take our time until things are done. So I would like to ask MLS, following all the discussion, how do you feel about this overall, MLS? -MLS: Well, I think it’s the wrong approach. But because I believe in consensus, I am not going to block it. +MLS: Well, I think it’s the wrong approach. But because I believe in consensus, I am not going to block it. -DE: I want to propose that we ask for consensus on this particular program, as MF is saying. We will work out the wording later and that will come back to committee. But if we can have consensus on this goal, that would be, I think, helpful. +DE: I want to propose that we ask for consensus on this particular program, as MF is saying. We will work out the wording later and that will come back to committee. But if we can have consensus on this goal, that would be, I think, helpful. -RPR: DE is pointing at the slide we are looking at. +RPR: DE is pointing at the slide we are looking at. -CDA: I think I know the answer to this question, but I want to be absolutely clear, this would formally change what is now Stage 3 to Stage 2.5. Or whatever we are calling it. And – +CDA: I think I know the answer to this question, but I want to be absolutely clear, this would formally change what is now Stage 3 to Stage 2.5. Or whatever we are calling it. And – -MF: I am not – Stage 3 remaining as it is and some of the things we do during Stage 3 being added to a new stage, prestage 3. It’s important to do it that way for reasons we will get to later. +MF: I am not – Stage 3 remaining as it is and some of the things we do during Stage 3 being added to a new stage, prestage 3. It’s important to do it that way for reasons we will get to later. -CDA: The slide says ‘this is the entrance criteria for the current Stage 3’. +CDA: The slide says ‘this is the entrance criteria for the current Stage 3’. -DE: So if you have more presentation Michael, that explains this, maybe that – +DE: So if you have more presentation Michael, that explains this, maybe that – -MF: I think – +MF: I think – -RPR: Yeah. The answer to CDA’s question is yes. This will introduce a new stage in between. +RPR: Yeah. The answer to CDA’s question is yes. This will introduce a new stage in between. -MF: This will introduce a new stage between what is today stage 2 and today stage 3. +MF: This will introduce a new stage between what is today stage 2 and today stage 3. DE: That stage will have a name -MF: That is not a renaming of current stage 3 because they – the stages have both names and meanings. And Stage 3’s meaning is unchanged. That’s the important part. +MF: That is not a renaming of current stage 3 because they – the stages have both names and meanings. And Stage 3’s meaning is unchanged. That’s the important part. -MF: Stage 3 means "recommended for implementation". That’s the signal for implementers, javascript engines and tooling, and other outside implementers. That’s why that formulation is important. +MF: Stage 3 means "recommended for implementation". That’s the signal for implementers, javascript engines and tooling, and other outside implementers. That’s why that formulation is important. -CDA: That’s fair. The idea is that a proposal could come for advancement for stage 2.5 and 2 months later (or more), come back for stage 3. +CDA: That’s fair. The idea is that a proposal could come for advancement for stage 2.5 and 2 months later (or more), come back for stage 3. -MF: That’s correct. Also, a proposal could advance directly from stage 2 to stage 3 by front loading the testing effort. +MF: That’s correct. Also, a proposal could advance directly from stage 2 to stage 3 by front loading the testing effort. -CDA: Right. Yeah. That is what I expected. I wanted to be super clear on that. Thank you. +CDA: Right. Yeah. That is what I expected. I wanted to be super clear on that. Thank you. -RPR: EAO has a question. +RPR: EAO has a question. -EAO: Yeah. The particular slide you had as a criteria for getting to the – from the new stage to stage 3 to how sufficient tests/experience, could you expand a little bit on what sufficient experience would mean? +EAO: Yeah. The particular slide you had as a criteria for getting to the – from the new stage to stage 3 to how sufficient tests/experience, could you expand a little bit on what sufficient experience would mean? -MF: I cannot. For good reason, that will be subjective per proposal and the committee will use their judgment to determine if a proposal is particularly risky, has a large impact, whether we need – how extensive that testing and experience might need to be. +MF: I cannot. For good reason, that will be subjective per proposal and the committee will use their judgment to determine if a proposal is particularly risky, has a large impact, whether we need – how extensive that testing and experience might need to be. -MF: This might be that we would like polyfill experience or tooling or something. We might want data based on code search or use counters, or try to test the waters with web compatibility. Anything like that +MF: This might be that we would like polyfill experience or tooling or something. We might want data based on code search or use counters, or try to test the waters with web compatibility. Anything like that EAO: So experience here would be relating to polyfill or tooling experience for examples, but not exactly to that. -MF: Yes. +MF: Yes. -RPR: Shane? +RPR: Shane? -SFC: Yeah. I was just wondering what the impact of this type of change would be on ShadowRealm which needs more tests. We made it to stage 2. With this – is that an example of the type of proposal that with this change would instead go to Stage 2 to have . . . ? +SFC: Yeah. I was just wondering what the impact of this type of change would be on ShadowRealm which needs more tests. We made it to stage 2. With this – is that an example of the type of proposal that with this change would instead go to Stage 2 to have . . . ? -DE: ShadowRealm in particular is a subtle case. One of the asks was for tests on the web platform side and an audit of which APIs are supported. There was a design which APIs were supported, it didn’t have the appropriate validation. In this case, it would be continuing at Stage 2. +DE: ShadowRealm in particular is a subtle case. One of the asks was for tests on the web platform side and an audit of which APIs are supported. There was a design which APIs were supported, it didn’t have the appropriate validation. In this case, it would be continuing at Stage 2. -MF: We will also later get to a discussion of what to do about currently in-flight proposals. Okay. Now that that discussion has commenced, I would like to ask the same thing I asked earlier, for consensus on moving forward with this approach and coming back with a PR that formally encodes it. +MF: We will also later get to a discussion of what to do about currently in-flight proposals. Okay. Now that that discussion has commenced, I would like to ask the same thing I asked earlier, for consensus on moving forward with this approach and coming back with a PR that formally encodes it. -RPR: All right. It looks like there are no objections. +RPR: All right. It looks like there are no objections. -MF: Okay. Great. +MF: Okay. Great. -RPR:We have consensus. +RPR:We have consensus. -MF: We still have time in my – how much time do I have in the timebox? +MF: We still have time in my – how much time do I have in the timebox? -RPR: Half an hour. +RPR: Half an hour. -MF: Half an hour? Okay. So there’s two things I want to – +MF: Half an hour? Okay. So there’s two things I want to – RPR: Longer actually. -MF: Great. Thank you. So one of the things I want to cover now is what do we do about stage numbers or names. This is not a simple bikeshed process like I think this name is better. Naming here is unfortunately important. The stage names are not an entirely internal thing. The names signal the meaning of the stage, so we have options depending on how to signal to the community. +MF: Great. Thank you. So one of the things I want to cover now is what do we do about stage numbers or names. This is not a simple bikeshed process like I think this name is better. Naming here is unfortunately important. The stage names are not an entirely internal thing. The names signal the meaning of the stage, so we have options depending on how to signal to the community. -MF: And something to note is at the top there, we cannot just renumber the stages. We need some stability in that communication. So if we ever say something is stage 3, at this point, that term already means something in the community. We cannot ever change that or reuse it. Right now, that means recommended for implementation. +MF: And something to note is at the top there, we cannot just renumber the stages. We need some stability in that communication. So if we ever say something is stage 3, at this point, that term already means something in the community. We cannot ever change that or reuse it. Right now, that means recommended for implementation. -MF: So here are the options that I see. Maybe there are others. One, we can choose some non-integral number between 2 and 3. Some people used such a name during this discussion without prompting. +MF: So here are the options that I see. Maybe there are others. One, we can choose some non-integral number between 2 and 3. Some people used such a name during this discussion without prompting. -MF: Another option is that we could transition to descriptive names. This has at least two distinct benefits. One, it’s more resilient to future changes, if we want to make more process changes. We will not run into the same issue again. And 2, it’s even better communication to the community. For a long time the community didn’t always understand what we meant when we said something advanced to Stage 2 or 3. If it has a self-descriptive name, that will help enforce that in the community. +MF: Another option is that we could transition to descriptive names. This has at least two distinct benefits. One, it’s more resilient to future changes, if we want to make more process changes. We will not run into the same issue again. And 2, it’s even better communication to the community. For a long time the community didn’t always understand what we meant when we said something advanced to Stage 2 or 3. If it has a self-descriptive name, that will help enforce that in the community. -MF: Option 3 is just the new stage could have a descriptive name. But the others are still numbers. It’s not great – a weird inconsistency. It’s an option. And option 4 is – since a lot of people have been conceptualizing this new stage as 2, but also you have tests, name it something that calls it Stage 2, but with tests or something. +MF: Option 3 is just the new stage could have a descriptive name. But the others are still numbers. It’s not great – a weird inconsistency. It’s an option. And option 4 is – since a lot of people have been conceptualizing this new stage as 2, but also you have tests, name it something that calls it Stage 2, but with tests or something. -MF: So that’s the paths I see. I am willing to – open on this topic. Let’s go the queue +MF: So that’s the paths I see. I am willing to – open on this topic. Let’s go the queue -JHD: The existing stage numbers – all the stages are named, in the process document. But the numbers are what – I think, all of the developer community that knows anything about the stages, is a small percentage, knows them by for example and we should preserve those numbers period. I have a less – I don’t have a strong opinion on what the new stage will be called. But 2.5 or something similar. But the new stage like the existing ones, need a descriptive name. It’s just that – I think it’s unlikely that based on the experience with the existing stages will be how people refer to them +JHD: The existing stage numbers – all the stages are named, in the process document. But the numbers are what – I think, all of the developer community that knows anything about the stages, is a small percentage, knows them by for example and we should preserve those numbers period. I have a less – I don’t have a strong opinion on what the new stage will be called. But 2.5 or something similar. But the new stage like the existing ones, need a descriptive name. It’s just that – I think it’s unlikely that based on the experience with the existing stages will be how people refer to them -NRO: I agree with JHD. Numbers are – known in the community, like, people don’t – you don’t have to follow how it works to be aware of the stages. As I mentioned, whenever there are articles of proposals, we should keep the numbers and keep the numbers exactly the same meaning. It’s okay with another description. It makes things more easier for newcomers to understand what the numbers mean. We should not replace with words +NRO: I agree with JHD. Numbers are – known in the community, like, people don’t – you don’t have to follow how it works to be aware of the stages. As I mentioned, whenever there are articles of proposals, we should keep the numbers and keep the numbers exactly the same meaning. It’s okay with another description. It makes things more easier for newcomers to understand what the numbers mean. We should not replace with words -JHD: It is not named on the process document, it seems. But the compatibility table, it has names for them and that’s what was stuck in my head. They are not currently named. Only numbered. +JHD: It is not named on the process document, it seems. But the compatibility table, it has names for them and that’s what was stuck in my head. They are not currently named. Only numbered. MF: Is that a well-known resource in the community? -JHD: The kangax compatibility table, yes. +JHD: The kangax compatibility table, yes. -MF: Not just among nerds? +MF: Not just among nerds? -JHD: Anything around TC39, including the process is known by a subset of developers. So I think among the group that knows about it, I think that it is pretty well known. +JHD: Anything around TC39, including the process is known by a subset of developers. So I think among the group that knows about it, I think that it is pretty well known. MF: Okay -NRO: It was well known in the past, with ES6. Now, with people mostly using data and the compatibility table gaining much less usage. +NRO: It was well known in the past, with ES6. Now, with people mostly using data and the compatibility table gaining much less usage. RPR: And the people who knows the names from the document is even fewer -DE: JHD, I am looking at the kangax website. Where are the names? +DE: JHD, I am looking at the kangax website. Where are the names? -JHD: Um I think the names are – I have to look. +JHD: Um I think the names are – I have to look. -JHD: At one point in the past there were names. +JHD: At one point in the past there were names. -CDA: It’s in the – sorry. I am going to interrupt because somebody posted https://github.com/tc39/process-document/pull/31 in the delegates room in Matrix. The names were: strawperson, proposal, draft, candidate, and finished. +CDA: It’s in the – sorry. I am going to interrupt because somebody posted https://github.com/tc39/process-document/pull/31 in the delegates room in Matrix. The names were: strawperson, proposal, draft, candidate, and finished. -JHD: Thank you. Yes, they were there and removed from the process document 2 or 3 years ago. I stamped the PR, apparently. The names used to be there and we removed them because nobody uses them. +JHD: Thank you. Yes, they were there and removed from the process document 2 or 3 years ago. I stamped the PR, apparently. The names used to be there and we removed them because nobody uses them. -It does seem like the names were not the kinds of names that I am listing here. The names I am listing here are supposed to be self-descriptive, whereas the names you can’t really figure out, what this stages meant. -Fair. Just from the name. There’s the slight difference. +It does seem like the names were not the kinds of names that I am listing here. The names I am listing here are supposed to be self-descriptive, whereas the names you can’t really figure out, what this stages meant. +Fair. Just from the name. There’s the slight difference. JHD: I think either way my point stands. I am fine adding names, if we like. People will continue to refer by number, and it seems prudent to find a new number. -RPR: Dan. +RPR: Dan. -DE: When I added the queue numbers, I thought I was disagreeing. I am agree. Keep the current numbers. Call this 2 and 7 8ths or something if we add a new stage. But I really like the short names that you have up there. They are more descriptive than what was previously in the process document. I think if we refer to things as stage your idea, in parenthesis, Stage 1, (every time we refer to a stage) it gives people a clear idea. There’s sometimes misconceptions that stage 2 proposals are more complete than they are. Or across the whole stage process. People overestimate what each stage means +DE: When I added the queue numbers, I thought I was disagreeing. I am agree. Keep the current numbers. Call this 2 and 7 8ths or something if we add a new stage. But I really like the short names that you have up there. They are more descriptive than what was previously in the process document. I think if we refer to things as stage your idea, in parenthesis, Stage 1, (every time we refer to a stage) it gives people a clear idea. There’s sometimes misconceptions that stage 2 proposals are more complete than they are. Or across the whole stage process. People overestimate what each stage means MF: Maybe we should make a pull request to re-add names that are self descriptive -DE: It seems we are agreeing. We should add good names. +DE: It seems we are agreeing. We should add good names. -LCA: On the names, giving names is nice. I think to your point that we will actually use those names, I am less sure of because saying stage 0 parenthesis idea, you wouldn’t say the parenthesis, but you get the point. Like nobody will do that. People will say, this is stage 0. Stage 2. This is not stage 2 solution chosen. Idea stage? Yeah. Maybe that. But the number is missing that the community knows. I don’t know. I think we should have names because having names is good. But I don’t think anybody will use them. At least in speech. +LCA: On the names, giving names is nice. I think to your point that we will actually use those names, I am less sure of because saying stage 0 parenthesis idea, you wouldn’t say the parenthesis, but you get the point. Like nobody will do that. People will say, this is stage 0. Stage 2. This is not stage 2 solution chosen. Idea stage? Yeah. Maybe that. But the number is missing that the community knows. I don’t know. I think we should have names because having names is good. But I don’t think anybody will use them. At least in speech. -SFC: Yeah. I just – since we are bikeshedding, it feels like this is slightly more close to a Stage 3 than Stage 2. Having something that is a modifier on 3 seems like it might relay the sentiment of the stage better. So I said, call 3-staging for example. Do we have consensus to stage 3 staging? Like, it sounds okay. Or 3 - - or something like that. +SFC: Yeah. I just – since we are bikeshedding, it feels like this is slightly more close to a Stage 3 than Stage 2. Having something that is a modifier on 3 seems like it might relay the sentiment of the stage better. So I said, call 3-staging for example. Do we have consensus to stage 3 staging? Like, it sounds okay. Or 3 - - or something like that. -WH: My comment is very similar to Shane’s. I would like clarification: how are the entrance criteria for the new stage different from those of the existing Stage 3? +WH: My comment is very similar to Shane’s. I would like clarification: how are the entrance criteria for the new stage different from those of the existing Stage 3? MF: They are not -WH: OK; they are the same as existing Stage 3. So my suggestion would be to either call the new stage “Stage 3 minus minus” or bifurcate Stage 3 into Stage 3A and 3B. +WH: OK; they are the same as existing Stage 3. So my suggestion would be to either call the new stage “Stage 3 minus minus” or bifurcate Stage 3 into Stage 3A and 3B. -RPR: Shu? +RPR: Shu? -SYG: I hear the argument on toed fiction of stage 3 instead of 2. I have had the intuition for communities that are used to turning on stage 3 polyfills or whatever. Having a modifier on Stage 3 can confuse those users. +SYG: I hear the argument on toed fiction of stage 3 instead of 2. I have had the intuition for communities that are used to turning on stage 3 polyfills or whatever. Having a modifier on Stage 3 can confuse those users. JHD: It’s important that we don’t have 3 in the name. Because 3 sends a signal, and that is the signal we are trying not to send for this new stage - which is that it’s ready to implemented and used once you see it, and this new stage is very much not in that bucket. So I think since it’s closer to 3 than 2, it’s useful to have 2 in it because that avoids the 3 signal. -MF: Yes. I 100% agree. From the internal perspective, it is considered much closer to 3, but from the messaging we want to do, we want to stay far away from 3. I don’t think we should have 3 in the name unfortunately. +MF: Yes. I 100% agree. From the internal perspective, it is considered much closer to 3, but from the messaging we want to do, we want to stay far away from 3. I don’t think we should have 3 in the name unfortunately. -WH: I want to avoid having “2” in the name, just because the entrance criteria is so similar to what Stage 3 is now. And — +WH: I want to avoid having “2” in the name, just because the entrance criteria is so similar to what Stage 3 is now. And — -MF: WH, can you explain why the entrance criteria matters? +MF: WH, can you explain why the entrance criteria matters? -WH: Stage 2 has the connotation of a proposal still being fluid. I want to make sure that is not misunderstood. So anything with a 2 in the name has a connotation that there are some i’s to be dotted and t’s to be crossed. +WH: Stage 2 has the connotation of a proposal still being fluid. I want to make sure that is not misunderstood. So anything with a 2 in the name has a connotation that there are some i’s to be dotted and t’s to be crossed. -SYG: Can I not – Waldemar, how do you feel about the argument of yes, we agree with you. Logically. But given what Stage 3 means to the larger population of non-TC39 delegates, 60 people, given that Stage 3 means a thing that is decoupled from what it means to us, but something to the public, it behooves us to favor their perception over ours. We are much more actively engaged. +SYG: Can I not – Waldemar, how do you feel about the argument of yes, we agree with you. Logically. But given what Stage 3 means to the larger population of non-TC39 delegates, 60 people, given that Stage 3 means a thing that is decoupled from what it means to us, but something to the public, it behooves us to favor their perception over ours. We are much more actively engaged. -WH: I am not really sure what the argument there is in response to what I just stated. Why would those people insist on having 2 in the name? +WH: I am not really sure what the argument there is in response to what I just stated. Why would those people insist on having 2 in the name? -SYG: No. They do not insist of having 2 in the name. 3 means a thing and we want to not change the meaning of 3. +SYG: No. They do not insist of having 2 in the name. 3 means a thing and we want to not change the meaning of 3. -DE: You’re saying that if 2 is in the name, it will make people feel like they – I’s needed to be dotted and T’s crossed. That’s incorrect when they are tests. That is part of doing that. This is why we want to encourage people outside the committee to be a little skeptical of it. While in this stage, 2 and 3/4s or whatever, we have achieved consensus on a stage internally as a committee. We are not – we have that stability that can be used to incompetent the tests. We are not ready to send a signal that this should be treated as such. +DE: You’re saying that if 2 is in the name, it will make people feel like they – I’s needed to be dotted and T’s crossed. That’s incorrect when they are tests. That is part of doing that. This is why we want to encourage people outside the committee to be a little skeptical of it. While in this stage, 2 and 3/4s or whatever, we have achieved consensus on a stage internally as a committee. We are not – we have that stability that can be used to incompetent the tests. We are not ready to send a signal that this should be treated as such. -NRO: Yes. So like I was thinking we should call this stage as like almost 3. Because from a delegate perspective or champion, the work to this stage is used to get to Stage 3. But like as I said before we should keep numbers. Numbers and are part of zero you are like public communication. We should like put the meanings according to community in front of how we internally think of these numbers. We can leave with something and say, almost 3. But knowing that it’s what we – to get there, we need to do what we used to do to get to Stage 3. +NRO: Yes. So like I was thinking we should call this stage as like almost 3. Because from a delegate perspective or champion, the work to this stage is used to get to Stage 3. But like as I said before we should keep numbers. Numbers and are part of zero you are like public communication. We should like put the meanings according to community in front of how we internally think of these numbers. We can leave with something and say, almost 3. But knowing that it’s what we – to get there, we need to do what we used to do to get to Stage 3. -RPR: Dan? +RPR: Dan? -DE: Very minor comment, but I feel like 2.5 is sort of too low as a number. Because we want to communicate that we are almost there. 2.5 is too unstable to me. That’s just bikeshedding. +DE: Very minor comment, but I feel like 2.5 is sort of too low as a number. Because we want to communicate that we are almost there. 2.5 is too unstable to me. That’s just bikeshedding. -RPR: Which is what we are doing right now. MLS? +RPR: Which is what we are doing right now. MLS? -MLS: Well, it seems since we are splitting Stage 3 into two pieces. 3A and B. I line with Waldemar with this +MLS: Well, it seems since we are splitting Stage 3 into two pieces. 3A and B. I line with Waldemar with this -MF: MLS, did you – were you there during the previous conversation? We said it fails to communicate to the community if we have 3 in the name? +MF: MLS, did you – were you there during the previous conversation? We said it fails to communicate to the community if we have 3 in the name? -MLS: We have to teach the community there’s a new stage. +MLS: We have to teach the community there’s a new stage. -MF: We cannot teach the community. That’s not a thing we have the power to do. +MF: We cannot teach the community. That’s not a thing we have the power to do. -MLS: In my mind, stage 4 is when people should adopt this wholeheartedly. They should play with it in stage 3 with whatever implementation they have. If the people are unteachable or whatever, I don’t fully get that. But it’s part of current Stage 3 we are talking about this new stage. +MLS: In my mind, stage 4 is when people should adopt this wholeheartedly. They should play with it in stage 3 with whatever implementation they have. If the people are unteachable or whatever, I don’t fully get that. But it’s part of current Stage 3 we are talking about this new stage. MF: The reason I say that MLS: Buying that, I actually like your 2A proposal, which is you have a short one or two-word name with a stage number and I would say old stage 0 zero, say, 1 and so forth in parenthesis. -MLS: But you are teaching them something new. If we want do that, then why would you make that proposal of 2A? +MLS: But you are teaching them something new. If we want do that, then why would you make that proposal of 2A? -MF: Yeah. I should – that’s fine. I should clarify what I meant by we cannot teach the community. -We did not teach the community these stage numbers in the first place. Our internal process naming leaked to the community and spread naturally. We don't have the power to control it intentionally. +MF: Yeah. I should – that’s fine. I should clarify what I meant by we cannot teach the community. +We did not teach the community these stage numbers in the first place. Our internal process naming leaked to the community and spread naturally. We don't have the power to control it intentionally. -MLS: We can communicate in various venues including our staging document having – it has to be rewritten with this. It seems to me that it will leak out, though we have new stage names or numbers whatever +MLS: We can communicate in various venues including our staging document having – it has to be rewritten with this. It seems to me that it will leak out, though we have new stage names or numbers whatever JHD: The issue here is and this is something I know you personally differ with many on the committee about, you said stage 3 is not the time to use something. That is not what most of the community thinks. Most of the community thinks that stage 3 is the time to use something. Stage 4 is when it lands in the spec which is not what the community cares about. JHD: It’s okay to disagree with that, you would like to believe they shouldn’t think that. That’s a discussion we don’t need to have today. But objectively, they do. They have already learned that. We will not teach them that something different is the case. And so if stage 3 is there in any way, my belief is that it will signal you can use this - because Stage 3 already signals that. -MLS: Lets say we call it 3A. There’s no limitation they can use. +MLS: Lets say we call it 3A. There’s no limitation they can use. JHD: 3A feels like a subset of 3. I can do the same thing as Stage 3, I can use it MLS: You can’t because there’s no implementation -DE: You can through polyfills and transpilers and engines that ship things before Stage 4. Such as +DE: You can through polyfills and transpilers and engines that ship things before Stage 4. Such as DE: [inaudible] -JHD: They will ship when stage 3, and 3A looks like 3. They are a few implementations that wait to Stage 4 to ship anything. +JHD: They will ship when stage 3, and 3A looks like 3. They are a few implementations that wait to Stage 4 to ship anything. -MLS: Okay. The argument you making is counterintuitive to the proposal, which that implementers won’t start until the tests are written. If we believe that during this let’s call it 2.5, so not 3. During the 2.5, tests are underdevelopment, and implementation ship this proposal, why do we need this new stage? +MLS: Okay. The argument you making is counterintuitive to the proposal, which that implementers won’t start until the tests are written. If we believe that during this let’s call it 2.5, so not 3. During the 2.5, tests are underdevelopment, and implementation ship this proposal, why do we need this new stage? -DE: Sorry. So the strong expectation is that nobody will ship before Stage 3. +DE: Sorry. So the strong expectation is that nobody will ship before Stage 3. -MLS: Okay. So then that opens up that we can call it 3A because someone can try to use it and they will not find an implementation that has it. And so they will learn real quick. +MLS: Okay. So then that opens up that we can call it 3A because someone can try to use it and they will not find an implementation that has it. And so they will learn real quick. -MF: MLS, there is tooling that exists that implements Stage 2, Stage 1 proposals. Babel and like – +MF: MLS, there is tooling that exists that implements Stage 2, Stage 1 proposals. Babel and like – -MLS: Sure. And people can try that. But they are completely aware to do that with Stage 1 and 2 proposals, they are trying things out. But not shipping the products with that. +MLS: Sure. And people can try that. But they are completely aware to do that with Stage 1 and 2 proposals, they are trying things out. But not shipping the products with that. -MF: That’s Stage 3A things. +MF: That’s Stage 3A things. -MLS: So the community needs to learn what this new stage means. +MLS: So the community needs to learn what this new stage means. -NRO: So we tend to ship all Stage 2 proposals. We try to do Stage 1, but when there is like strongly marked. – [inaudible] many have an opportunity to say, I want to use the proposal as it was on this meeting to make sure people don’t have break in changes. But people use them. People and specifically for Stage 3 proposals, people use them in production. If we don’t implement . . . and people that do this, like, do this because they know the Stage 3 is almost ready and expect to not change too much. So adopt the small changing. And like changing – having the previous stage of 3A, when things are still not as stable as in the current 3. This makes the user start using them before +NRO: So we tend to ship all Stage 2 proposals. We try to do Stage 1, but when there is like strongly marked. – [inaudible] many have an opportunity to say, I want to use the proposal as it was on this meeting to make sure people don’t have break in changes. But people use them. People and specifically for Stage 3 proposals, people use them in production. If we don’t implement . . . and people that do this, like, do this because they know the Stage 3 is almost ready and expect to not change too much. So adopt the small changing. And like changing – having the previous stage of 3A, when things are still not as stable as in the current 3. This makes the user start using them before -MLS: Let’s be clear. The current stage number 3 is where we are developing tests. And so people will start using it even if there’s not – even if there’s one implementation. We are not changing when people will start using it, if we call the new stage, Stage 3A. At all. It’s part of the old Stage 3. There’s no change. +MLS: Let’s be clear. The current stage number 3 is where we are developing tests. And so people will start using it even if there’s not – even if there’s one implementation. We are not changing when people will start using it, if we call the new stage, Stage 3A. At all. It’s part of the old Stage 3. There’s no change. -DE: MLS the goal is to get people to be more conservative. You share that goal, but I think people shouldn’t use it until Stage 4. Working on getting people part of the way there. It’s not what you are suggesting. But there’s so much adoption in the ecosystem of this shipping Stage 3 things that it’s something this we say, it’s not Stage 3 yet, it’s ties into the existing policies and that’s a benefit to us. We can teach people things. It’s less work to tie into the existing expectations. +DE: MLS the goal is to get people to be more conservative. You share that goal, but I think people shouldn’t use it until Stage 4. Working on getting people part of the way there. It’s not what you are suggesting. But there’s so much adoption in the ecosystem of this shipping Stage 3 things that it’s something this we say, it’s not Stage 3 yet, it’s ties into the existing policies and that’s a benefit to us. We can teach people things. It’s less work to tie into the existing expectations. -MLS: I made my point. I think I support what Waldemar is suggesting. +MLS: I made my point. I think I support what Waldemar is suggesting. -RPR: Shu has a comment on teaching. +RPR: Shu has a comment on teaching. -SYG: Like okay. Just leave logic at the door. Think of this as implementation detail foroutlining the committee operating. Parts of the committee process has leaked. We can try to teach people that the stuff that leaked has changed. But it seems just so much easier to teach ourselves. So I don't understand the effort here. Even if you are logically correct, and I agree you are logically correct, it’s easier to each ourselves because that’s a set of double digit set of people and we all engaged and like pretty good at learning things of how we ourselves operate. So just like pure practically speaking, it seems we should just do that. +SYG: Like okay. Just leave logic at the door. Think of this as implementation detail foroutlining the committee operating. Parts of the committee process has leaked. We can try to teach people that the stuff that leaked has changed. But it seems just so much easier to teach ourselves. So I don't understand the effort here. Even if you are logically correct, and I agree you are logically correct, it’s easier to each ourselves because that’s a set of double digit set of people and we all engaged and like pretty good at learning things of how we ourselves operate. So just like pure practically speaking, it seems we should just do that. -RPR: JHD? -JHD: Yes. So MLS was talking about teaching the community. Let’s just say something “surprising” happens and we are unable to teach people something, and they learn nothing. I would want them to not confuse 3 and 3A and unless they learn something, that they will in fact be confused by those things. I am hoping that my irony can conveyed that we _will_ fail to teach people things. +RPR: JHD? +JHD: Yes. So MLS was talking about teaching the community. Let’s just say something “surprising” happens and we are unable to teach people something, and they learn nothing. I would want them to not confuse 3 and 3A and unless they learn something, that they will in fact be confused by those things. I am hoping that my irony can conveyed that we *will* fail to teach people things. -RPR: Shane? +RPR: Shane? -SFC: Yeah. So Stage 3 communicates multiple different things. And we have been talking a lot about communicates "ready to use this thing." But that’s not the only thing it communicates to developers. -I think something that has been valuable a lot with Stage 3, it gets the attention of more developers. People take it seriously and submit more tutorials and polyfills of their own. Those are things that are beneficial at the new stage. +SFC: Yeah. So Stage 3 communicates multiple different things. And we have been talking a lot about communicates "ready to use this thing." But that’s not the only thing it communicates to developers. +I think something that has been valuable a lot with Stage 3, it gets the attention of more developers. People take it seriously and submit more tutorials and polyfills of their own. Those are things that are beneficial at the new stage. SFC: Like, anything that gets the community to sort of take this more seriously and do the work with it, even not using in production is totally fine to retain. -RPR: EAO, I thought yours was a joke suggestion before. You were serious with stage E +RPR: EAO, I thought yours was a joke suggestion before. You were serious with stage E -EAO: Given we have gone over with some objecting to any references ToNumber 2 and objected to the number 3, a reasonable mathematically reasonable surprise to with the E, 2 point 7 something, I don’t remember what. And have a stage name with an explicit identity that is different from stage 2 or stage 3. I asked specifically here, would anyone actually object to this? And I would be Michael – interested in hearing exactly why this and whether the objection is specifically to the E as a letter to be used here or whether it’s generally to a letter being used +EAO: Given we have gone over with some objecting to any references ToNumber 2 and objected to the number 3, a reasonable mathematically reasonable surprise to with the E, 2 point 7 something, I don’t remember what. And have a stage name with an explicit identity that is different from stage 2 or stage 3. I asked specifically here, would anyone actually object to this? And I would be Michael – interested in hearing exactly why this and whether the objection is specifically to the E as a letter to be used here or whether it’s generally to a letter being used -MF: First, Stage E sounds like Stage 3. Sorry. Second, if we are going to be using names, use a descriptive name. Most people will not consider its numeric value. They're going to consider it to be a letter and it may as well be a word which has self-descriptive properties. It’s no better than the alternatives. No, we should not do that. +MF: First, Stage E sounds like Stage 3. Sorry. Second, if we are going to be using names, use a descriptive name. Most people will not consider its numeric value. They're going to consider it to be a letter and it may as well be a word which has self-descriptive properties. It’s no better than the alternatives. No, we should not do that. -RPR: Shane? We have got a few agreements with EAO from Michael Ficarra, from SFC, from William. And then -To clarify there was no agreement with Michael Ficarra there, but from the others there. +RPR: Shane? We have got a few agreements with EAO from Michael Ficarra, from SFC, from William. And then To clarify there was no agreement with Michael Ficarra there, but from the others there. Sorry. -RPR: There was an yes to the objection. Sorry. Sorry. +RPR: There was an yes to the objection. Sorry. Sorry. CDA? -CDA: I think MLS captured the point. I think without prior knowledge of what it represents, it’s not going to be clear to somebody where E is going to fit in, in the stage process, and ideally you can figure out, for example, currently Stage 0, 1, 2, 3, 4, besides the direction. (We count up, but sometimes stage gates count down). But throwing E in the mix, you don’t know intuitively where that fits without prior knowledge. +CDA: I think MLS captured the point. I think without prior knowledge of what it represents, it’s not going to be clear to somebody where E is going to fit in, in the stage process, and ideally you can figure out, for example, currently Stage 0, 1, 2, 3, 4, besides the direction. (We count up, but sometimes stage gates count down). But throwing E in the mix, you don’t know intuitively where that fits without prior knowledge. -RPR: Shane? +RPR: Shane? -SFC: I think that the what we are kind of after here is, we want a new concept because the people who are in favor of Stage 3, it has the connotations that we don’t have. Stage 2 has the connotations we don’t have. Introducing a new concept seems to solve the problem. We belaboured when bikeshedding the names in Temporal and Intl, the way that you sort of avoid people coming in with preassumptions is a completely new name and learn from scratch what the thing means. And I think Stage E or something like that is – could do that for us. +SFC: I think that the what we are kind of after here is, we want a new concept because the people who are in favor of Stage 3, it has the connotations that we don’t have. Stage 2 has the connotations we don’t have. Introducing a new concept seems to solve the problem. We belaboured when bikeshedding the names in Temporal and Intl, the way that you sort of avoid people coming in with preassumptions is a completely new name and learn from scratch what the thing means. And I think Stage E or something like that is – could do that for us. -RPR: DLM agrees with Shane. Ross has a new suggestion. +RPR: DLM agrees with Shane. Ross has a new suggestion. -RKN: There’s traction on the chat, *e* had the advantage of being a constant that’s between 2 and 3, and I was thinking, well, if this stage is primarily for Test262 afterall, consider 2.62. Anyway, I am saying that out loud. +RKN: There’s traction on the chat, *e* had the advantage of being a constant that’s between 2 and 3, and I was thinking, well, if this stage is primarily for Test262 afterall, consider 2.62. Anyway, I am saying that out loud. -RPR: All right. We have spent at least half an hour bikeshedding. On to Eemeli. +RPR: All right. We have spent at least half an hour bikeshedding. On to Eemeli. -EAO: Just thought I was mention, I personally would be okay with renumbering 1, 2, 3, 4, 5, changing the meanings of the later stages. I understand that others will object to this as well. But I just wanted to voice that I at least support such a change. +EAO: Just thought I was mention, I personally would be okay with renumbering 1, 2, 3, 4, 5, changing the meanings of the later stages. I understand that others will object to this as well. But I just wanted to voice that I at least support such a change. -RPR: MLS supports that renumbering. Back to MF? +RPR: MLS supports that renumbering. Back to MF? -MF: Okay. I don’t personally think that’s viable, but feedback is heard. I wanted to change topics. We don’t need to figure out the naming or numbering scheme by the end of this meeting. This is all feedback used to inform when I come back in 2 months. Reach out and I'll do the best with the feedback I receive -The other topic is should we apply it retroactively. What about in-flight Stage 3 proposals? Are we going to review and possibly demote them? +MF: Okay. I don’t personally think that’s viable, but feedback is heard. I wanted to change topics. We don’t need to figure out the naming or numbering scheme by the end of this meeting. This is all feedback used to inform when I come back in 2 months. Reach out and I'll do the best with the feedback I receive The other topic is should we apply it retroactively. What about in-flight Stage 3 proposals? Are we going to review and possibly demote them? -MF: I don’t know if we advanced any proposals during this meeting but those would probably be the place to start and then going back basically in reverse chronological order from when we advanced -them to do that review. Is it worth doing the review? Should we leave existing proposals where they are? Does anyone have an opinion on that? +MF: I don’t know if we advanced any proposals during this meeting but those would probably be the place to start and then going back basically in reverse chronological order from when we advanced them to do that review. Is it worth doing the review? Should we leave existing proposals where they are? Does anyone have an opinion on that? -RPR: We have two agreements on the queue. Three maybe. +RPR: We have two agreements on the queue. Three maybe. JHD: Essentially as I said multiple times during this meeting and others, I think it should be very frictionless to move proposals up and down so that they accurately reflect where they are. That’s a mistake that I have made and I don’t want to see us repeat. And so if we have a new stage, we should put whatever belongs there, there. SFC: Yes, I can think of one or two proposals that should be in the new middle stage and we should do that. -DE: Yeah, agree. I think we have a current process which is not freely moving things up and down but rather seeking consensus on advancement and retraction. I think we can apply that meeting with more preparation to get these things perfected. +DE: Yeah, agree. I think we have a current process which is not freely moving things up and down but rather seeking consensus on advancement and retraction. I think we can apply that meeting with more preparation to get these things perfected. -RPR: Okay. End of the queue. More you want to talk about Michael? +RPR: Okay. End of the queue. More you want to talk about Michael? -MF: Okay, that was incredibly straightforward. I wasn’t expecting that to be so easy. If we had remaining time, we could use it for more discussion about the names. I’m not sure how productive it would be at this point. I would probably prefer to yield my time to any other overflow item or something we might have. Please do talk to me, though, about naming. You know where to get in contact with me. +MF: Okay, that was incredibly straightforward. I wasn’t expecting that to be so easy. If we had remaining time, we could use it for more discussion about the names. I’m not sure how productive it would be at this point. I would probably prefer to yield my time to any other overflow item or something we might have. Please do talk to me, though, about naming. You know where to get in contact with me. -DE: KG put on the chat the idea of consensus on design. The idea that this new stage is actually just an internal thing for us. It’s just to keep us from revisiting the design too much when we’re trying to have stability for tests. If we just say consensus on the design, and it’s not even quite a stage, we just add test use as a Stage 3 entrance requirement, that’s, you know, the notion of consensus on design being earlier. Any way, no need to conclude now. If anybody has feedback. +DE: KG put on the chat the idea of consensus on design. The idea that this new stage is actually just an internal thing for us. It’s just to keep us from revisiting the design too much when we’re trying to have stability for tests. If we just say consensus on the design, and it’s not even quite a stage, we just add test use as a Stage 3 entrance requirement, that’s, you know, the notion of consensus on design being earlier. Any way, no need to conclude now. If anybody has feedback. WH: “Consensus on design” has a very different meaning than working out every detail of the spec, not just the design. DE: Could be consensus on details or something. + ### Summary + - MF proposed that we add an additional stage between 2 and 3, where stage 3 entrance requires test262 tests. The new stage would have current stage 3 entrance requirements. Maintaining the name “stage 3” while requiring tests would give a clearer signal for when implementers and the community should see proposals at a certain maturity level justifying more intense implementation and experimentation. - MLS expressed skepticism about the benefits, with concern that this would slow down the committee without accomplishing its goals. However, he did not want to block consensus on this proposal. + ### Conclusion + - Consensus in principle with the idea of creating an additional stage - Name of the new stage tbd! But it will be numbered, and existing stages will probably retain their current numbers. - Once the new stage is set up, we’ll survey Stage 3 proposals, and propose demotion to the new stage (by consensus) for qualifying proposals. - In a future meeting or perhaps async on GitHub, we’ll nail down the exact wording in the process document to describe the new stage. + ## Throw expression (continued) Presenter: Ron Buckton (RBN) -[proposal](https://github.com/tc39/proposal-throw-expressions) -[slides]() ?? +- [proposal](https://github.com/tc39/proposal-throw-expressions) -RBN: So I’ll try to keep some of this brief because I want to get back to the discussion we were having in the queue on day 1. I’ve added a couple slides to the slide deck just to provide some description about some – the comments that were raised to make sure we can address them properly. So again these were added after day 1 but they are primarily to discuss those specific issues. +RBN: So I’ll try to keep some of this brief because I want to get back to the discussion we were having in the queue on day 1. I’ve added a couple slides to the slide deck just to provide some description about some – the comments that were raised to make sure we can address them properly. So again these were added after day 1 but they are primarily to discuss those specific issues. -RBN: One issue that was discussed or brought up was a request from Waldemar to pick a precedence. The precedence for throw expressions is currently specified as unary expression. That’s because it satisfies the majority of primary use cases and the champions preference remains unary expression and the next might be strong and my discussion of KG indicated if not a preference, at least an agreement that Unary expression is correct and the primary goal is to ban ambiguous cases. I also described in the past that the ambiguous cases could be handled by a linter but preference within TC39 recently to be a bit more prescriptive in the language such as requiring parentheses to disambiguate logical and knowledge coalesce. +RBN: One issue that was discussed or brought up was a request from Waldemar to pick a precedence. The precedence for throw expressions is currently specified as unary expression. That’s because it satisfies the majority of primary use cases and the champions preference remains unary expression and the next might be strong and my discussion of KG indicated if not a preference, at least an agreement that Unary expression is correct and the primary goal is to ban ambiguous cases. I also described in the past that the ambiguous cases could be handled by a linter but preference within TC39 recently to be a bit more prescriptive in the language such as requiring parentheses to disambiguate logical and knowledge coalesce. -RBN: The primary goal on day 1 is emphasize that we’re trying to avoid ambiguity but still believe the preference is correct. So with that said, one of the things that WH brought up which was very helpful to recognize was that the approach that we were talking to perform this ban on these to avoid this confusion around precedence was unfortunately resulted in ASI hazard with plus, minus, less than and less than equals. Notably that prefix plus minus on the following line becomes an issue. The division and division -assignment is also possibly the beginning token for regular expression. Therefore, we would need to avoid that ASI hazard in some way. We previously have handled in the specification that an ASI hazard in a similar case could be handled via a static semantics rule. We do this currently for optional chain. We use the specific rule that states that if this production exists, then it is a syntax error and it’s primarily to specifically avoid automatically semicolon assertion rules. So some of the discretions we had in the chat and that I investigated over the past two days resulted in two alternatives. +RBN: The primary goal on day 1 is emphasize that we’re trying to avoid ambiguity but still believe the preference is correct. So with that said, one of the things that WH brought up which was very helpful to recognize was that the approach that we were talking to perform this ban on these to avoid this confusion around precedence was unfortunately resulted in ASI hazard with plus, minus, less than and less than equals. Notably that prefix plus minus on the following line becomes an issue. The division and division assignment is also possibly the beginning token for regular expression. Therefore, we would need to avoid that ASI hazard in some way. We previously have handled in the specification that an ASI hazard in a similar case could be handled via a static semantics rule. We do this currently for optional chain. We use the specific rule that states that if this production exists, then it is a syntax error and it’s primarily to specifically avoid automatically semicolon assertion rules. So some of the discretions we had in the chat and that I investigated over the past two days resulted in two alternatives. -RBN: One alternative is that we -maintain Urnary expression precedence disallow conceptual ambiguity for throw statement. This is for punctuators, the ones you see here and expression with conditional expression just as discussed on day 1 and consignment operators aren’t necessary because existing grammar rules disallow them because assignment operators only have left hand side expression that is a higher precedence than Unary and so not allowed. So instead, we can handle plus minus, I have times in here and that’s not incorrect. And division in the grammar and restrict their use via static semantics to avoid A schism I like approach used optional chain template expression and special case with throw expression with the compound assignment and also ban using ASI and -concern too complicated in the grammar to be worth it. Turns out this is not complicated. We only need to add three of these static semantic rules to additive expression of plus minus and multiplicative expression for division and special rule for assignment to handle the division assignment. These would use a – could use a syntax directed operation called contains through on right that is relatively simple as well that is primarily motivated to find cases of the -right associative exponential operator to find a throw expression nested within. These are much less complicated than one of the other directions that Waldemar suggested to do this directly in the grammar. +RBN: One alternative is that we maintain Urnary expression precedence disallow conceptual ambiguity for throw statement. This is for punctuators, the ones you see here and expression with conditional expression just as discussed on day 1 and consignment operators aren’t necessary because existing grammar rules disallow them because assignment operators only have left hand side expression that is a higher precedence than Unary and so not allowed. So instead, we can handle plus minus, I have times in here and that’s not incorrect. And division in the grammar and restrict their use via static semantics to avoid A schism I like approach used optional chain template expression and special case with throw expression with the compound assignment and also ban using ASI and concern too complicated in the grammar to be worth it. Turns out this is not complicated. We only need to add three of these static semantic rules to additive expression of plus minus and multiplicative expression for division and special rule for assignment to handle the division assignment. These would use a – could use a syntax directed operation called contains through on right that is relatively simple as well that is primarily motivated to find cases of the right associative exponential operator to find a throw expression nested within. These are much less complicated than one of the other directions that Waldemar suggested to do this directly in the grammar. -RBN: My investigation into that shows that would be extremely difficult to -do without heavy changes to the grammatical rules that I think would break a lot of intuitions about what certain grammar parts do what and this is actually not only the simplest approach, it’s more consistent with what we already do within the specification. The other alternative that I looked into and discussed with Kevin off line was that to maintain unary expression and precedence and disallow ambiguity throw in parentheses and allow unary express is the correct -precedence and I believe if the proposed solution for alternative 1 is not considered viable, that I would still prefer that we leave it open to find other interpretations or other ways to -address this within the specification that would not require changing the precedence of throw -expressions to the point where we could not relax the restriction at some point. I’m not -particularly interested in changing throw expression to something like expression precedence -next to comma because if we ever wanted to make the change to change precedence we would never -be able to because it would suddenly become incompatible. I would still prefer not having -parentheses if possible. Those are the statements I wanted to kind of get out there and start -talking to folks on the queue to see A, if is this first alternative that I discussed a viable -option and if so, I’d like to have some feedback please. +RBN: My investigation into that shows that would be extremely difficult to do without heavy changes to the grammatical rules that I think would break a lot of intuitions about what certain grammar parts do what and this is actually not only the simplest approach, it’s more consistent with what we already do within the specification. The other alternative that I looked into and discussed with Kevin off line was that to maintain unary expression and precedence and disallow ambiguity throw in parentheses and allow unary express is the correct precedence and I believe if the proposed solution for alternative 1 is not considered viable, that I would still prefer that we leave it open to find other interpretations or other ways to address this within the specification that would not require changing the precedence of throw expressions to the point where we could not relax the restriction at some point. I’m not particularly interested in changing throw expression to something like expression precedence next to comma because if we ever wanted to make the change to change precedence we would never be able to because it would suddenly become incompatible. I would still prefer not having parentheses if possible. Those are the statements I wanted to kind of get out there and start talking to folks on the queue to see A, if is this first alternative that I discussed a viable option and if so, I’d like to have some feedback please. RPR: Michael is on the queue. -MF: Thank you for doing this work. Looks like from what I understand of the alternatives, I prefer alternative 2. But the presentation as you laid it out is very spec focused and didn’t have many examples of what a user experience would be and how the user experience would be different between these cases. I would like to see those examples that show the differences between these cases and all of the boundary cases where they’re like similar precedence things. So to better consider it that way. +MF: Thank you for doing this work. Looks like from what I understand of the alternatives, I prefer alternative 2. But the presentation as you laid it out is very spec focused and didn’t have many examples of what a user experience would be and how the user experience would be different between these cases. I would like to see those examples that show the differences between these cases and all of the boundary cases where they’re like similar precedence things. So to better consider it that way. -RBN: So I showed this slide on the day 1 presentation which showed cases where we had differences in where the precedence is different versus what you expect the throw statement. So in the first example, the throw expression here with no coalesce and A equals B question question throw C, this is legal because it’s in the unary expression condition and no ambiguous and second considered illegal and A equals in front of it a throw statement would throw B or C and whether B or C is null or undefined and people who are familiar with throw statements might have written code that has this would be possibly confused if they saw a throw expression and didn’t have the same capabilities. +RBN: So I showed this slide on the day 1 presentation which showed cases where we had differences in where the precedence is different versus what you expect the throw statement. So in the first example, the throw expression here with no coalesce and A equals B question question throw C, this is legal because it’s in the unary expression condition and no ambiguous and second considered illegal and A equals in front of it a throw statement would throw B or C and whether B or C is null or undefined and people who are familiar with throw statements might have written code that has this would be possibly confused if they saw a throw expression and didn’t have the same capabilities. -RBN: Therefore, the way to disambiguate this is to add parentheses. If you wanted to have the throw be on the left side, you would parentheses throw B and throw B or C case you parentheses either B or C case. The main difference in what I was describing in the second alternative is that you would essentially require parentheses in both cases where if you wanted to throw B or throw C or D or even if this just said A equals throw C or D you would -have to parentheses all the time. And I’m not a huge fan of this. But I – it would be necessary if we do not have these rules to give us the ability to find a different way to restrict it in the future. +RBN: Therefore, the way to disambiguate this is to add parentheses. If you wanted to have the throw be on the left side, you would parentheses throw B and throw B or C case you parentheses either B or C case. The main difference in what I was describing in the second alternative is that you would essentially require parentheses in both cases where if you wanted to throw B or throw C or D or even if this just said A equals throw C or D you would have to parentheses all the time. And I’m not a huge fan of this. But I – it would be necessary if we do not have these rules to give us the ability to find a different way to restrict it in the future. -MF: Sorry. I’ll get back on the queue. +MF: Sorry. I’ll get back on the queue. RPR: Waldemar. -WH: None of the simple alternatives I had proposed was explored. The presented alternatives both are over-complicated and neither one offers a simple description of what the precedence of `throw` actually is. Some possible simple ways of doing this without the complex grammar and rules that are currently in the proposal are to: -* have `throw` be a unary expression, just like `void` or `delete` -* have `throw` be a magic function with unary expression precedence which takes a parenthesized expression as a single parameter: `throw(expr)` -* the third option is similar to alternative 2 on the slide `(throw expr)` except that the throw could throw an arbitrary expression so you would not need to parenthesize line 4 on the current slide. +WH: None of the simple alternatives I had proposed was explored. The presented alternatives both are over-complicated and neither one offers a simple description of what the precedence of `throw` actually is. Some possible simple ways of doing this without the complex grammar and rules that are currently in the proposal are to: + +- have `throw` be a unary expression, just like `void` or `delete` +- have `throw` be a magic function with unary expression precedence which takes a parenthesized expression as a single parameter: `throw(expr)` +- the third option is similar to alternative 2 on the slide `(throw expr)` except that the throw could throw an arbitrary expression so you would not need to parenthesize line 4 on the current slide. -RBN: So the first thing that I will say is that all of the – all of the alternatives I presented are to maintain throw as unary expression. The third suggestion that you provided which is to have throw just be throw expression would change its precedence to a precedence that I am not comfortable with. It basically makes throw essentially at the same level as high as comma or +RBN: So the first thing that I will say is that all of the – all of the alternatives I presented are to maintain throw as unary expression. The third suggestion that you provided which is to have throw just be throw expression would change its precedence to a precedence that I am not comfortable with. It basically makes throw essentially at the same level as high as comma or RBN: if you had throw A comma B you would have to be able to consume that and not confused with throw comma A comma B and not enthusiastic about that direction. -WH: Can I respond to that? +WH: Can I respond to that? RBN: Yes, please. -WH: Okay. So in the example that’s currently on the slide, as far as the other expression is concerned, throw is inside parentheses and a parenthesized expression binds -very, very tightly. As far as the inside of it is concerned, throw can just throw an expression -and there’s no reason to require only unary expressions as an argument to throw. +WH: Okay. So in the example that’s currently on the slide, as far as the other expression is concerned, throw is inside parentheses and a parenthesized expression binds very, very tightly. As far as the inside of it is concerned, throw can just throw an expression and there’s no reason to require only unary expressions as an argument to throw. -RBN: Yes, I understand that. This is specifically pointing out that if we were to do that, I could not ever make throw into a unary expression which is where I would prefer it to be. The alternative to syntax is the most restrictive case that is neither at the expression level that you’re describing nor is it as simple as a unary express that doesn’t require parentheses specifically so that we have the option to continue to potentially as a future proposal investigate loosening that restriction so this is alternative to that is listed here is a more restricted syntax than normally unary expression or having it at the level where it can throw -any expression intentionally so that we have more flexibility because I still would strongly prefer it remain unary. +RBN: Yes, I understand that. This is specifically pointing out that if we were to do that, I could not ever make throw into a unary expression which is where I would prefer it to be. The alternative to syntax is the most restrictive case that is neither at the expression level that you’re describing nor is it as simple as a unary express that doesn’t require parentheses specifically so that we have the option to continue to potentially as a future proposal investigate loosening that restriction so this is alternative to that is listed here is a more restricted syntax than normally unary expression or having it at the level where it can throw any expression intentionally so that we have more flexibility because I still would strongly prefer it remain unary. -RBN: I would like to go to the second suggestion you provided have it be a -magic function. I don’t think that is viable. If it is a magic function that is still at the unary expression level all of those tokens that happen on the right could still happen and it would still have the same ambiguity with the throw statement and throw parentheses with the infix notation that follows it. If you said magic function you can write code that looks the same. +RBN: I would like to go to the second suggestion you provided have it be a magic function. I don’t think that is viable. If it is a magic function that is still at the unary expression level all of those tokens that happen on the right could still happen and it would still have the same ambiguity with the throw statement and throw parentheses with the infix notation that follows it. If you said magic function you can write code that looks the same. -WH: Okay. I don’t understand the example. +WH: Okay. I don’t understand the example. RBN: See if I can – what you’re describing is – -NRO: On the queue. +NRO: On the queue. -RBN: If you said throw A as a statement today, that has a meaning. If you make throw into a magic function at a unary expression level that meaning is ambiguous conceptually and not ambiguous but conceptually and not pass the specific requirements that provided by Kevin as to what his concerns were. A magic function would not solve that concern. +RBN: If you said throw A as a statement today, that has a meaning. If you make throw into a magic function at a unary expression level that meaning is ambiguous conceptually and not ambiguous but conceptually and not pass the specific requirements that provided by Kevin as to what his concerns were. A magic function would not solve that concern. -WH: `function` works the same way. You cannot start an expression statement with a function expression -because it turns into a function declaration. It’s the same problem. +WH: `function` works the same way. You cannot start an expression statement with a function expression because it turns into a function declaration. It’s the same problem. -RBN: The difference is that the developer community has had a long time to get used to function and expression declaration. Adding new throw expressions with different precedence is a new thing and it does not have that same knowledge and perspective. While I would – my personal preference is that throw is just unary expression and I don’t really – I’m not that concerned -about the tokens, so again the token restrictions that I presented are to meet a specific requirement that this avoids the ambiguity in the few cases that will actually come up. +RBN: The difference is that the developer community has had a long time to get used to function and expression declaration. Adding new throw expressions with different precedence is a new thing and it does not have that same knowledge and perspective. While I would – my personal preference is that throw is just unary expression and I don’t really – I’m not that concerned about the tokens, so again the token restrictions that I presented are to meet a specific requirement that this avoids the ambiguity in the few cases that will actually come up. WH: We survived adding function expressions and I think we would – we could survive adding throw expressions with the same restriction as function expressions have that an expression statement cannot start with a function expression or a throw expression. -RBN: Yeah, this already has at the statement level – the grammar already forbids throw in the expression as function expression so it isn’t at odds with what we have been discussing. +RBN: Yeah, this already has at the statement level – the grammar already forbids throw in the expression as function expression so it isn’t at odds with what we have been discussing. Specifically meet those requirements for the demand related to avoiding that ambiguity, again, the whole point of this is to essentially adopt what a linter might otherwise adopt to avoid those – -KG: The comma at the beginning of the last line - I think that will just make it clearer. +KG: The comma at the beginning of the last line - I think that will just make it clearer. RBN: Can you say it again. -KG: On the line you just typed, can you put a `0, ` at the beginning. I want to make it clear we’re definitely talking about the expression case. WH, this specific thing I really don’t want this to throw a – like, we shouldn’t do that. We should not throw A in this case. +KG: On the line you just typed, can you put a `0,` at the beginning. I want to make it clear we’re definitely talking about the expression case. WH, this specific thing I really don’t want this to throw a – like, we shouldn’t do that. We should not throw A in this case. -WH: I disagree. I mean, this is a perfectly fine thing to do. And throw has a precedence of -unary operator — +WH: I disagree. I mean, this is a perfectly fine thing to do. And throw has a precedence of unary operator — KG: I appreciate — @@ -2141,110 +1548,91 @@ WH: Especially since you could reverse the order and write `y || throw(a)`. JHD: But if you wrote throw A or Y – -WH: You wouldn’t in this case. You would write `y || throw(a)`. Because that’s more useful. +WH: You wouldn’t in this case. You would write `y || throw(a)`. Because that’s more useful. -JHD: The or Y will never be hit if the throw binds to the A. So no one would ever want that semantic and that’s why no one would ever write that code. If they write that code because they want to throw either A or Y. +JHD: The or Y will never be hit if the throw binds to the A. So no one would ever want that semantic and that’s why no one would ever write that code. If they write that code because they want to throw either A or Y. -WH: You’re assuming something that’s not true in this example. If they want to throw either a or y, they’d write `throw(a || y)`. +WH: You’re assuming something that’s not true in this example. If they want to throw either a or y, they’d write `throw(a || y)`. -RBN: WH, if I could, that’s part of the reason why Kevin is – has suggested this ban as an option is that if the idea is that no one should write that because you don’t really want that to happen, then this ban actually guides you towards the right direction. It says you -shouldn’t write throw A or Y because that’s going to not do what you expect it to do. You -should parentheses the A or Y to get right semantics or rebalance the operator so it’s Y or -throw A. That’s what this does. +RBN: WH, if I could, that’s part of the reason why Kevin is – has suggested this ban as an option is that if the idea is that no one should write that because you don’t really want that to happen, then this ban actually guides you towards the right direction. It says you shouldn’t write throw A or Y because that’s going to not do what you expect it to do. You should parentheses the A or Y to get right semantics or rebalance the operator so it’s Y or throw A. That’s what this does. -WH: As I pointed out earlier, there exist other examples where it does make sense to follow -the throw expression with `||`. +WH: As I pointed out earlier, there exist other examples where it does make sense to follow the throw expression with `||`. -RBN: I’m not sure where it makes sense to follow the throw expression with bar bar. +RBN: I’m not sure where it makes sense to follow the throw expression with bar bar. -WH: Anyway, this is way too complicated to explain to users what this thing is doing. The rules are too complicated. I want just a single – a simple precedence for throw and so I’m really concerned with the usability of the complex rules that are being proposed. +WH: Anyway, this is way too complicated to explain to users what this thing is doing. The rules are too complicated. I want just a single – a simple precedence for throw and so I’m really concerned with the usability of the complex rules that are being proposed. -RBN: So I also personally want a single precedence for throw and I think it should be unary -expression. I think the other ones don’t make sense and they require – every place you’re -going to want to use it directly is in the unary expression position. +RBN: So I also personally want a single precedence for throw and I think it should be unary expression. I think the other ones don’t make sense and they require – every place you’re going to want to use it directly is in the unary expression position. WH: I agree. RPR: To Kevin on the queue waiting for quite a while. -KG: So Waldemar, I agree that we should be concerned with the experience of developers. -However, I really, really do not think that the experience of developers is solely determined by the simplicity of the rules. I think simple rules can have unintuitive outcomes and in particular, `throw A ? B : C` throwing A is so unintuitive that even though it follows from simple rules it is worse to have that experience than to make the rules more complicated as an either alternative one or alternative two. Sometimes simple rules are not the best developer experience and I think this case is very overwhelmingly such a case. +KG: So Waldemar, I agree that we should be concerned with the experience of developers. +However, I really, really do not think that the experience of developers is solely determined by the simplicity of the rules. I think simple rules can have unintuitive outcomes and in particular, `throw A ? B : C` throwing A is so unintuitive that even though it follows from simple rules it is worse to have that experience than to make the rules more complicated as an either alternative one or alternative two. Sometimes simple rules are not the best developer experience and I think this case is very overwhelmingly such a case. -WH: Okay. I already presented an example of simple rules which solve this case. Let’s go to — +WH: Okay. I already presented an example of simple rules which solve this case. Let’s go to — -KG: The parentheses do not solve this case. The throw A – the example that Ron has at the bottom of the screen does not – like, if that throws A, the case is not solved. +KG: The parentheses do not solve this case. The throw A – the example that Ron has at the bottom of the screen does not – like, if that throws A, the case is not solved. -MM: I think my reply to WH helps clarify Kevin’s position. I hope it helps clarify -Kevin’s position. You can let me know. WH has made the analogy of function where function if it appears as the first token of a statement is a function declaration and not a function expression. The reason why that analogy does not justify the last line on the current slide is that the meaning to the programmer of a function declaration and a function expression -are much, much more similar. That’s why, for example, you can evaluate any function declaration as an expression and get a function that has the same call behavior, that is essentially the same meaning. The only difference is between the declaration and expression are the scope of the name and the hoisting in the block. But for most purposes, if you take a function declaration as written and then you turn it into a function expression by putting something to its left, the function itself still means the same thing in terms of its call behavior. I think that invariant between statement form and expression form that are -otherwise identical is really important for programmer ergonomics. And I think that the last line on RBN’s slide and what KG is saying about that follows the soul of this invariant. It means that taking a throw statement and putting something to its left completely changes the meaning of what is on the right. +MM: I think my reply to WH helps clarify Kevin’s position. I hope it helps clarify Kevin’s position. You can let me know. WH has made the analogy of function where function if it appears as the first token of a statement is a function declaration and not a function expression. The reason why that analogy does not justify the last line on the current slide is that the meaning to the programmer of a function declaration and a function expression are much, much more similar. That’s why, for example, you can evaluate any function declaration as an expression and get a function that has the same call behavior, that is essentially the same meaning. The only difference is between the declaration and expression are the scope of the name and the hoisting in the block. But for most purposes, if you take a function declaration as written and then you turn it into a function expression by putting something to its left, the function itself still means the same thing in terms of its call behavior. I think that invariant between statement form and expression form that are otherwise identical is really important for programmer ergonomics. And I think that the last line on RBN’s slide and what KG is saying about that follows the soul of this invariant. It means that taking a throw statement and putting something to its left completely changes the meaning of what is on the right. -WH: I understand your point. I agree with it. Unfortunately neither alternative 1 nor 2 on the slides satisfies your invariant. The alternative I proposed `(throw expr)` would satisfy this invariant. But other people are rejecting it. +WH: I understand your point. I agree with it. Unfortunately neither alternative 1 nor 2 on the slides satisfies your invariant. The alternative I proposed `(throw expr)` would satisfy this invariant. But other people are rejecting it. -MM: I’m sorry. I need – just wanted to – can you repeat the statement what would satisfy the objective. +MM: I’m sorry. I need – just wanted to – can you repeat the statement what would satisfy the objective. WH: `(throw expr)` MM: Okay. -KG: You’re correct that neither alternatives satisfy it as stated, but they satisfy a weaker property that is most important part of the property, which is that in legal programs, the meaning will be the same. I think it’s okay if some additional cases are illegal in expression position because you will write that and then you will get an error and you will be a little bit annoyed that you now have to add some parentheses. But you will get a nice error message that tells you you have to add some parentheses. You will go on with your life. All future -readers of the code will not be confused. That’s the most important property to preserve. +KG: You’re correct that neither alternatives satisfy it as stated, but they satisfy a weaker property that is most important part of the property, which is that in legal programs, the meaning will be the same. I think it’s okay if some additional cases are illegal in expression position because you will write that and then you will get an error and you will be a little bit annoyed that you now have to add some parentheses. But you will get a nice error message that tells you you have to add some parentheses. You will go on with your life. All future readers of the code will not be confused. That’s the most important property to preserve. Both of these alternatives preserve that property. MM: I agree with Kevin on that with regard to the intent of having raised this property, yes. WH: But it’s unnecessary to use divergent syntaxes for those since this would work if you kept them the same. It would work just fine and be simpler and less confusing. -KG: Other people have expressed they don’t like that for other reasons. I think the -semantics preserves the useful property and avoids ambiguity is the best option. +KG: Other people have expressed they don’t like that for other reasons. I think the semantics preserves the useful property and avoids ambiguity is the best option. RPR: Can we move the queue on to Nicolo? -NRO: Yes. Want to mention that even if alternative 1, I still have my preference for not having commata due to the difference of parentheses and all parameters except for the last one. I prefer one without the comma. I find alternative 2 better than alternative 1 with the comma there. +NRO: Yes. Want to mention that even if alternative 1, I still have my preference for not having commata due to the difference of parentheses and all parameters except for the last one. I prefer one without the comma. I find alternative 2 better than alternative 1 with the comma there. -EAO: I’ve been on this queue from Tuesday. Hi. So question briefly are do expressions still potentially a thing because from where I’m looking at this, they would provide a relatively ergonomic general purpose solution for the same thing. If do expressions are completely dead, this becomes a much more interesting thing to consider. +EAO: I’ve been on this queue from Tuesday. Hi. So question briefly are do expressions still potentially a thing because from where I’m looking at this, they would provide a relatively ergonomic general purpose solution for the same thing. If do expressions are completely dead, this becomes a much more interesting thing to consider. -KG: As I said in chat, they are not dead. But they are generally not considered an alternative by most of the people in the committee. +KG: As I said in chat, they are not dead. But they are generally not considered an alternative by most of the people in the committee. -RBN: That was discussed in the July meeting which is the reason why this was brought forward. Do expressions for five years having considered to be the main blocking reason that this hadn’t advanced, the syntax concern is something that we could have addressed. But now it was considered in the July meeting that do expressions were no longer considered to be the main -blocker for this proposal’s advancement and the syntax concern is something that we were attempting to address. +RBN: That was discussed in the July meeting which is the reason why this was brought forward. Do expressions for five years having considered to be the main blocking reason that this hadn’t advanced, the syntax concern is something that we could have addressed. But now it was considered in the July meeting that do expressions were no longer considered to be the main blocker for this proposal’s advancement and the syntax concern is something that we were attempting to address. -MF: The question I put on the queue was answered by KG in chat. But I just wanted to voice my support for alternative 2 as long as it is – it permits us to move forward with something more permissive in the future and seems taking the first step is the best idea. +MF: The question I put on the queue was answered by KG in chat. But I just wanted to voice my support for alternative 2 as long as it is – it permits us to move forward with something more permissive in the future and seems taking the first step is the best idea. -RBN: The specific reason this is proposed as an alternative is it gives us the flexibility to go either direction. We can either weaken the unary expression requirement for the argument – for the upper end to throw or we could strengthen the unary requirement for the throw expression itself and remove the parentheses and it givers us the flexibility to go either direction. I’m not the happiest with this approach because it requires in places where I don’t -think they should be required. The majority use case 95% and I apologize for being a bit – there’s no data to back this up and other things from other languages sharp with the flexibility the places you use this is unary at the end of nullish coalesce in conditional operators and potentially initializers. That’s the main cases where you see these, those are the cases that – at least everything but the argument case or the cases that don’t require parentheses if it is unary expression even with this ban. +RBN: The specific reason this is proposed as an alternative is it gives us the flexibility to go either direction. We can either weaken the unary expression requirement for the argument – for the upper end to throw or we could strengthen the unary requirement for the throw expression itself and remove the parentheses and it givers us the flexibility to go either direction. I’m not the happiest with this approach because it requires in places where I don’t think they should be required. The majority use case 95% and I apologize for being a bit – there’s no data to back this up and other things from other languages sharp with the flexibility the places you use this is unary at the end of nullish coalesce in conditional operators and potentially initializers. That’s the main cases where you see these, those are the cases that – at least everything but the argument case or the cases that don’t require parentheses if it is unary expression even with this ban. -RBN: With this ban the parameter case -becomes more complicated because of comma that Nicolo also brought up. And requiring parentheses around throw I feel to be unfortunate for the 95%ish use case where it is normally and regularly and legally used within the language. So my main reason for suggesting alternative 2 is that it will eventually give us the flexibility to remove the parentheses around throw if we find the different acceptability solution for the syntax but at the very least would allow this proposal to move forward because it’s valuable on its own. +RBN: With this ban the parameter case becomes more complicated because of comma that Nicolo also brought up. And requiring parentheses around throw I feel to be unfortunate for the 95%ish use case where it is normally and regularly and legally used within the language. So my main reason for suggesting alternative 2 is that it will eventually give us the flexibility to remove the parentheses around throw if we find the different acceptability solution for the syntax but at the very least would allow this proposal to move forward because it’s valuable on its own. -RPR: Mark is on the queue with one person on the queue and couple minutes left. Go ahead mark. +RPR: Mark is on the queue with one person on the queue and couple minutes left. Go ahead mark. -MM: Okay. Just a weird idea, might be completely bogus. The juxtaposition of Waldemar’s position of putting the parentheses around the throw and Nicolo raising the do expression makes me wonder if most statements begin with the keyword that can only be at the beginning of a statement. So what if the do expression proposal spelled instead of do expression open curly it was open -parenthesis with the corresponding closed being closed parenthesis and the open parenthesis before the throw is generalized to do the open parenthesis before if or switch or all things. +MM: Okay. Just a weird idea, might be completely bogus. The juxtaposition of Waldemar’s position of putting the parentheses around the throw and Nicolo raising the do expression makes me wonder if most statements begin with the keyword that can only be at the beginning of a statement. So what if the do expression proposal spelled instead of do expression open curly it was open parenthesis with the corresponding closed being closed parenthesis and the open parenthesis before the throw is generalized to do the open parenthesis before if or switch or all things. -RBN: If I could interject. It’s not a good idea, it’s a suggestion that I expressed on the throw expression issue tracker five years ago. +RBN: If I could interject. It’s not a good idea, it’s a suggestion that I expressed on the throw expression issue tracker five years ago. MM: Great. RBN: It did not seem to gain traction. -KG: The specific problem with that proposal is that many of the use cases of do expressions are introducing a scope. Introducing a scope requires having a block. But braces inside of parentheses is already – +KG: The specific problem with that proposal is that many of the use cases of do expressions are introducing a scope. Introducing a scope requires having a block. But braces inside of parentheses is already – MM: Got it. KG: And so since we already would have to have some syntax to introduce a block, that gives us do expressions already. -MM: Got it. Thanks. +MM: Got it. Thanks. RPR: In the last remaining minute, Ron, do you want to propose anything? -RBN: First I would like to see – I think WH’s biggest concern around the complexity of this or I shouldn’t say the biggest concern but one concern that Waldemar raised is how much this adds to the specification. This does not add that much to the specification aside from the editor’s note around what it’s intending to represent, it requires only three static semantic rules in the same vein of what we already do for optional chain to handle ASI and the rest is -still handled by the look ahead ban. This isn’t that complicated. It essentially does what a linter would do and in the past it’s been my preference that this was just handled by a linter if you were concerned about these ambiguities and again this ban is specifically to address in my opinion intended to be compromised to address the concern about this in the same vain that -we also address the parentheses around – or parentheses necessary to disambiguate between double bar and double question for those tokens. I also opposed needing parentheses for those because it can be enforced by a linter. +RBN: First I would like to see – I think WH’s biggest concern around the complexity of this or I shouldn’t say the biggest concern but one concern that Waldemar raised is how much this adds to the specification. This does not add that much to the specification aside from the editor’s note around what it’s intending to represent, it requires only three static semantic rules in the same vein of what we already do for optional chain to handle ASI and the rest is still handled by the look ahead ban. This isn’t that complicated. It essentially does what a linter would do and in the past it’s been my preference that this was just handled by a linter if you were concerned about these ambiguities and again this ban is specifically to address in my opinion intended to be compromised to address the concern about this in the same vain that we also address the parentheses around – or parentheses necessary to disambiguate between double bar and double question for those tokens. I also opposed needing parentheses for those because it can be enforced by a linter. -RBN: That was the direction for the – that the plenary went through. Again, this is specifically to enforce a ban that a linter might otherwise also enforce. Otherwise, I don’t feel this adds that much complexity to the specification to -support. I am not – my preference is still not to make this the throw keyword followed by expression because it forces parentheses in cases that it shouldn’t. Alternative 2 is the worst of all worlds because it requires parentheses in both cases but the only thing it provides is flexibility. I would like to try to see if I could gain consensus on alternative 1 first. I know that Waldemar has concerns. I would hope that those concerns are possibly remediated by the discussion or possibly lifted somewhat by the interest and discussion that we -also had here. So I would like to try to start with that. +RBN: That was the direction for the – that the plenary went through. Again, this is specifically to enforce a ban that a linter might otherwise also enforce. Otherwise, I don’t feel this adds that much complexity to the specification to support. I am not – my preference is still not to make this the throw keyword followed by expression because it forces parentheses in cases that it shouldn’t. Alternative 2 is the worst of all worlds because it requires parentheses in both cases but the only thing it provides is flexibility. I would like to try to see if I could gain consensus on alternative 1 first. I know that Waldemar has concerns. I would hope that those concerns are possibly remediated by the discussion or possibly lifted somewhat by the interest and discussion that we also had here. So I would like to try to start with that. RPR: Do we have consensus for alternative 1? @@ -2254,16 +1642,15 @@ RBN: All right. I will first make an attempt to make – get consensus on altern RPR: Do we have consensus on alternative 2? -MF: I feel like this is a bit sudden. I apologize but this wasn’t how the proposal was structured before this meeting and I would like more time to consider it. I do feel it’s pretty safe. But I don’t know if I can be confident enough in moving forward with it. +MF: I feel like this is a bit sudden. I apologize but this wasn’t how the proposal was structured before this meeting and I would like more time to consider it. I do feel it’s pretty safe. But I don’t know if I can be confident enough in moving forward with it. RPR: DLM is on the queue. -DLM: MF just said what I was going to say. I think we need some more time to think about this. It’s been a pretty contentious discussion so far. And I guess I would like to see, you know, a final – you know spec text ready and time to review it and if it came back in the next plenary. +DLM: MF just said what I was going to say. I think we need some more time to think about this. It’s been a pretty contentious discussion so far. And I guess I would like to see, you know, a final – you know spec text ready and time to review it and if it came back in the next plenary. -RPR: Okay. Any other advice for RBN? +RPR: Okay. Any other advice for RBN? -KG: Waldemar, I know that you don’t like the restriction on the right hand side presented here where it is only unary expression and you’re correct there’s no like reason for it in the sense of nothing in the spec as it is actually requires it and it could simply be relaxed but given various concerns around people have hopes of relaxing this in other directions later, would you -be okay with this as a compromise position? +KG: Waldemar, I know that you don’t like the restriction on the right hand side presented here where it is only unary expression and you’re correct there’s no like reason for it in the sense of nothing in the spec as it is actually requires it and it could simply be relaxed but given various concerns around people have hopes of relaxing this in other directions later, would you be okay with this as a compromise position? WH: Well, if the intent is to turn this into alternative 1 later, then I already stated I would object to alternative 1. @@ -2271,57 +1658,59 @@ KG: The intent is not to turn it into alternative 1, just that there may be a pa WH: We should find out what it is. -KG: No one has such a path forward in mind right now. But requiring the parentheses on the right hand side only restricts relatively few cases and preserves that optionality for the future. So it seems like a reasonable compromise. If that doesn’t seem like a reasonable compromise to you, it would be good to know. +KG: No one has such a path forward in mind right now. But requiring the parentheses on the right hand side only restricts relatively few cases and preserves that optionality for the future. So it seems like a reasonable compromise. If that doesn’t seem like a reasonable compromise to you, it would be good to know. RBN: There is also the potential that the restrictive case in alternative 2 if we find that if this does ship to the ecosystem, does ship and is adopted within the ecosystem and people do become used to throw expressions and used to the precedence of what goes in that argument list, that maybe there’s the potential that Kevin might choose to remove his restriction around that distinguishing character because people will have gotten used to it in an expression position. WH: I don’t know if that would be ever be the case but I — -RPR: It sounds like, RBN, you have some direction on taking this away and to be brought back. Do you want to, I don’t know, give a sentence summary of where we are. +RPR: It sounds like, RBN, you have some direction on taking this away and to be brought back. Do you want to, I don’t know, give a sentence summary of where we are. -RBN: Yeah. At this point, it seems like the main concern that I saw from several has been to need more time to review these alternatives and what impact that would have on the syntax. I do apologize for the rush nature of some of the recent updates in the last two days. Most of this is trying to find ways to address the concerns that were raised on day 1. So I will be happy to come back in the next plenary with updates and I would appreciate feedback on the repo as to any questions or concerns about the alternatives as presented and if other – if there are other suggestions about ways to move forward, I would appreciate those as well. +RBN: Yeah. At this point, it seems like the main concern that I saw from several has been to need more time to review these alternatives and what impact that would have on the syntax. I do apologize for the rush nature of some of the recent updates in the last two days. Most of this is trying to find ways to address the concerns that were raised on day 1. So I will be happy to come back in the next plenary with updates and I would appreciate feedback on the repo as to any questions or concerns about the alternatives as presented and if other – if there are other suggestions about ways to move forward, I would appreciate those as well. ### Summary + - RBN proposed a few concrete alternatives for syntax details around throw expressions, for how to prohibit throw expressions from having visibly differing precedences between statement and expression position. - KG and WH had strong, incompatible preferences for which alternative to choose. + ### Conclusion + - The throw expressions proposal remains at Stage 2 with no conclusion on syntax questions. - RBN will bring this back to committee at a future meeting + ## Incubator Call -RPR: Okay. Thank you RBN. All right. So final agenda item is incubation call chartering. So Shu is no longer running these meetings. If people want to volunteer their proposals for setting up their own calls, do folk have suggestions for calls that they would like to propose? -EAO has one. Intl messageformat. And a second as well stable formatting. Any other suggestions that champions would like to put forward? If not, I’ll pause there. +RPR: Okay. Thank you RBN. All right. So final agenda item is incubation call chartering. So Shu is no longer running these meetings. If people want to volunteer their proposals for setting up their own calls, do folk have suggestions for calls that they would like to propose? +EAO has one. Intl messageformat. And a second as well stable formatting. Any other suggestions that champions would like to put forward? If not, I’ll pause there. SYG: Eemeli weren’t there two? -EAO: Yes, I have two requests. Intl messageformat is one and stable formatting is the second one. I don’t think there’s a third one. +EAO: Yes, I have two requests. Intl messageformat is one and stable formatting is the second one. I don’t think there’s a third one. + +DE: Sometime between this meeting and next meeting a group of people that I’m working with – we aim to have a signal proposal to share with the committee and so maybe that would be, you know, +not sooner than a month from now. If people want to be incubator call beforehand with that group, then I would organize that. -DE: Sometime between this meeting and next meeting a group of people that I’m working with – we aim to have a signal proposal to share with the committee and so maybe that would be, you know, -not sooner than a month from now. If people want to be incubator call beforehand with that -group, then I would organize that. +RPR: So DE is talking about an upcoming proposal about signals and please reach out to him if you would like to be involved in the early calls. Shane is volunteering, locale extensions. -RPR: So DE is talking about an upcoming proposal about signals and please reach out to him if you would like to be involved in the early calls. Shane is volunteering, locale extensions. +SFC: We understand from the discussion earlier today locale discussion is going to definitely involve other work on other bodies like the one that I’m most familiar with and BAN is most familiar with is this body. I don’t know if there’s room for using the incubator call machinery we have in this body to also engage with other bodies that might be relevant. -SFC: We understand from the discussion earlier today locale discussion is going to definitely involve other work on other bodies like the one that I’m most familiar with and BAN is most familiar with is this body. I don’t know if there’s room for using the incubator call machinery we have in this body to also engage with other bodies that might be relevant. +SYG: As I presently used to organize these. Nothing is stopping you from doing that. The main intention of incubator call is to have some sanctioned time set aside for smaller proposals that didn’t already have a working session call that was regularly scheduled for it. I don’t know how big the scope of locale extensions is; maybe it’s somewhat larger. For larger proposals, it’s probably worth it to just schedule your own call. The incubation thing is to normalize the idea of setting some time aside between meetings to hurry up the feedback cycle. -SYG: As I presently used to organize these. Nothing is stopping you from doing that. The main intention of incubator call is to have some sanctioned time set aside for smaller proposals that didn’t already have a working session call that was regularly scheduled for it. I don’t know how big the scope of locale extensions is; maybe it’s somewhat larger. For larger proposals, it’s probably worth it to just schedule your own call. The incubation thing is to normalize the idea of setting some time aside between meetings to hurry up the feedback cycle. +RPR: So I think we have our full list. We have a list of four. So thank you for that. -RPR: So I think we have our full list. We have a list of four. So thank you for that. ## Future meeting planning -All right. So just before we close I did see that Michael Ficarra was asking about the schedule for next year. So far we only publicized the date for the first meeting. We have most of them locked down. There’s just a final European one that we need to get confirmation on. And as I mentioned on Tuesday, we’re still looking for a host in APAC toward the end of -the year. If anyone is able to volunteer as a host for that, that would be very helpful. +All right. So just before we close I did see that Michael Ficarra was asking about the schedule for next year. So far we only publicized the date for the first meeting. We have most of them locked down. There’s just a final European one that we need to get confirmation on. And as I mentioned on Tuesday, we’re still looking for a host in APAC toward the end of the year. If anyone is able to volunteer as a host for that, that would be very helpful. WH: When is the date of the second meeting of 2024? -RPR: I would like to just hundred percent confirm that. We have that effectively confirmed because that will be remote. But I will get back to the notes and be able to send that out -tomorrow. +RPR: I would like to just hundred percent confirm that. We have that effectively confirmed because that will be remote. But I will get back to the notes and be able to send that out tomorrow. -WH: Okay. Because I’m scheduling vacations and other timing. Want to make sure it doesn’t conflict. +WH: Okay. Because I’m scheduling vacations and other timing. Want to make sure it doesn’t conflict. -RPR: Yes. I will make sure you get that tomorrow. +RPR: Yes. I will make sure you get that tomorrow. WH: Okay. -RPR: All right. Then I think we have reached the end of the meeting. So I think particularly for this meeting we’ve been supported by AV team and our local events manager. -That I think, that has been helpful and top quality throughout. And they also supplied the J pop that’s been excellent. So with that, I think we shall close up. Thank you everyone for an excellent meeting in Tokyo. Hopefully we will return here sometime in the future. All right. Bye for now. +RPR: All right. Then I think we have reached the end of the meeting. So I think particularly for this meeting we’ve been supported by AV team and our local events manager. +That I think, that has been helpful and top quality throughout. And they also supplied the J pop that’s been excellent. So with that, I think we shall close up. Thank you everyone for an excellent meeting in Tokyo. Hopefully we will return here sometime in the future. All right. Bye for now.