Remote attendees:
| Name | Abbreviation | Organization |
|---|---|---|
| Robin Ricard | RRD | Bloomberg |
| Shane F. Carr | SFC | |
| Waldemar Horwat | WH | |
| Philip Chimento | PFC | Igalia |
| Ujjwal Sharma | USA | Igalia |
| Mathias Bynens | MB | |
| Jordan Harband | JHD | Coinbase |
| Felienne Hermans | FHS | Leiden University |
| Richard Gibson | RGN | OpenJS Foundation |
| Sergey Rubanov | SRV | Invited Expert |
| Thomas Levy | TLY | Evernote |
| Michael Saboff | MLS | Apple |
| Dave Poole | DMP | Apple |
| Mattijs Hoitink | MHK | Apple |
| Frank Yung-Fong Tang | FYT | |
| Markus W. Scherer | MWS | |
| Chengzhong Wu | CZW | Alibaba |
| Devin Rousso | DRO | Apple |
| Caio Lima | CLA | Igalia |
| Jack Works | JWK | Sujitech |
| Istvan Sebestyen | IS | Ecma |
| Frank Tang | FYT |
Presenter: Frank Tang (FYT)
FYT: My name's Frank Tang, coming from Google and working on V8. Today I have several proposals to bring to you. I think this morning I have three, and the first one to talk about is all about ECMA-402. The first one I'll talk about is the Intl locale info API. This is seeking to advance to stage 3.
FYT: So what's the motivation? The motivation is that we already have a helpful Intl.Locale object in Intl at 402 for a while. And so it basically represents a Locale and what we look to do is try to expose a little bit more information in a Locale which mean we have a Locale that the user gives us but there are certain properties that the system may know about that. So what kind of information? For example, the week data. And and if you need to have some way to render a calendar-like thing in different applications, each locale convention may have a different way to identify what is the first day of the week. For example in the U.S. usually the first day of the week is Sunday, but in Europe it is Monday. And which day is the weekend starting day? In a lot of Western cultures usually is Saturday, but in a lot of Middle East cultures, actually, it's Thursday. The hour cycle is 23 hours or 12 hours cycle, and so on and so forth. Actually the measurement system would decide to take it out.
FYT: So a little history. This proposal was advanced to stage 1 in September last year, and we also advanced into Stage 2 in the January meeting this year. So in order to form a proposal in Ecma-402 we would prefer to have prior art. Here we list the prior art for week data, which means it's in another library. One particular one, which is very interesting is that Mozilla have their internal API, that is JavaScript based, for their internal UI. So this library exists for Mozilla but not open for web platform before and Mozilla has their own UI that the Mozilla code itself uses. And also there are a lot of different libraries, also Java and of course C++ have such information, which tell us that this is important information that a lot of people use. The other information is directionality, which means if you're giving a locale, you usually — particularly if you have a script — usually know, but a lot of times if you have a language without a script like information, how do you derive the text directionality for that particular locale, for example Arabic, from right to left. Of course English, most of the western Latin based, have to write left to right, and so on. And again, all Mozilla how to say (??) and closure or should I Google have this API so there's prior art.
FYT: So we made some changes after stage 2. I mean after we reach Stage 2 during the TC39 meeting in January, we decided to drop the support for unit info. I forgot to change them of the weight and tags. It was thinking about also support matter. Irma unit and we I think both Ecma 402 members and also TC39 the rest of member believe that magma unit in the current shape is nam chores with decide to drop it from the contest over TC39, but after that, we also on what area would talk about on the stage to advancement that is just that part of spec text is not very mature and that's how I talk about default and we eventually decided to change that to bring in two different accessor and a getter. I will say to return different array of the commonly used item for that particular locale. For example calendars - so pay attention here, it is a plural, It's not calendar - calendar for the intl Locale is whatever the user input to that but calendars is the calendar. With a Locale for example in Japanese. The calendars will I think show some examples here. I think this player will show you the changes and you will see the difference later on what kind of thing they will return later.
FYT: the spec text has a draft. You can take a look at that if you want to read it. You can read it right now. So high level parts on changing stage: one, look how quick info will give you an object and tell you something you default value for certain property that the application is doing like a calendar style widget or a calendar different shape of thing. It could be used or some other reason for whatever reason you have to know the information for the week. You're not necessarily doing Text render. Directionality is also similar, of course you that this is just for easy to use so I used case kind of slipped it, but real usage probably you just create a Locale in Europe nations and later on just assets that you won't do this kind of cradle calendars gather info, right? So you'll have one Locale object somewhere and application keep calling keep week info and text info and so on.
FYT: here is an example. I'll say we replace the default and we used to call but with now change it to different getter. So for example, right left hand side. The first one is calendar for Arabic and Arabic Locale have Gregorian centric calendar or Islamic calendar several civil calendars. But if you're using the Arabic Egyptian Locale, which means the Arabic usage in Egypt the calendars - no, the calendars don't change here, but the numbering system is changed to an Arabic script instead of (?) from a lot in script in normal because Egyptian we know there are in the (?) their usage that their number system, but most of the arabic-speaking if you only knows Arabic is not particular region that we still use a lot in script for to let them ring system. And because we tell this the Egypt we can see also in this particular case derived the kind Zone use their so returned in a ray that each only have one time zone which is Africa. Right hand side, this is an example of Japanese in the top and lower one it Japanese in Japan, right? It show you what they return from those thing. similarly, I think just the difference is the last one the because you only tell Japan you don't know which time zone the area but it would specifies Japan in Japan. Not only the language Japanese then we can derive the time zone from there. Sometimes you will have multiple for example in u.s. The time zone could be a lot right because we use multiple times or in the United States.
FYT: Here's spec text, so this is on changing stage one. I believe you can read through it. This is the week info; I think we don't change in the first stage stage things. We get into state the thing. As I mentioned this part is new when I say news new in after stage 2, since January. That's what I mean. It is some part of this syntax is pretty abstract because you have to do with the local object, but anything with syntax we try to make it make it very clear. And again, this is a those all just abstract operation and you eventually we have those getter to access the array. So you see your create a calendar or locales and you see previously or call the all those operational called the create array or list and prefer and basically that one is either calling return an array with one item would prefer or createArrayFromList which is in ecma262.
FYT: Okay, and this is numbering system. Same thing just uses the same pattern. So oops so in Tech and my forward to meeting in Japan April meeting that we I think we could gather together. We have one monthly meeting: what happens there are we agree upon the spec text and SFC and ZB signed out to be the reviewers one mistake I made is last time in some (?) I need to get into say three to guess they threw of they are so We actually asked okay. Well, we're going to come here for Stage 3. We need reviewer and they sign up. If somehow someone volunteered in stage two I forgot. I tried to start the meeting in as I kind of find it. I apologize and we also agree upon the April meeting to support a champion who's me and to bring this proposal to tc39 for stage three advancement.
FYT: and here's the entrance criteria. We believe we completed the spec text. We believe we have that, and a reviewer should sign off editor look at it. We believe there are no further work is impossible without Improvement experimentation experience. Therefore come here and request Community to prove for advancement to stay three. three.
YSV: Yep. Just wanted to chime in and say we're happy to see this go to stage 3 since it standardizes behavior we've already got, that were quite happy with.
RBR: Thank you. Yeah. We liked explicit statements of support.
FYT: Yes, and it's from Mozilla, right?
YSV: Yeah, that was those from Mozilla and
DE: So as one of the co-champions of the Intl.Locale proposal, I'm happy to see this move forward. It serves an important function and something frequently requested and it fits in a clean way to the design of Intl.Locale. Aso the specification seems well written and so I'm also happy to see this advance.
LEO: +1 for stage 3
SFC: +1
RPR: So we've only heard positives. Let's just explicitly ask now, any objections to stage 3? [silence] Congratulations, you have stage 3 .
Okay. thank you.
Stage 3
Presenter: Frank Tang (FYT)
FYT: So this is a second proposal like to talk about in Intl.DisplayNames. We need to stage 3, so give a little bit background history the Intl.DisplayName proposal from August 2020, this V2 called as a version two is created a state to 0 proposal and the reason was that around that time we have passed Intl.DisplayNames to Stage 3, I believe and and also after that I think the V8 is shipping that. In September the stage this proposal Advanced stage one and in January this year again a similar time this advanced to stage 2. so here we proposed to the in stage 3 this timeframe.
FYT: So what is entailed in Intl.DisplayNames? then is there a lot of people in different application localized and translate string and we're not going to touch those things, but there are common items that most of the applications have to deal with - of course not all - in we see they're having a lot of time and it's better to have be able to just, you know, reduce the payload that application has to carry that in the browser therefore, we have a straightforward way API to provide that to to provide this API for display names for commonly used items.
FYT: So what kind of so weird to talk about this in January and so what happened after here's will (?) while app changes after the January meeting? First of all there is the draft text here. You can take a look at it. In there some scope change happens during the January meeting, I believe but currently what we have is we I think that to would decide to drop the time zone because they're little bit more complicated support timezone for display and because you need to figure out like daylight saving time and that kind of thing. So we think this should be a simple model and shouldn't include those as well and so in stage 2 timeframe we believe that one should be support is calendar name. So which means they're different calendars, Japanese calendar, Coptic calendar, and when you localize it to a language how to display that name of that particular calendar. And also unit. We have number, formatting a number with a unit, but the here we have to provide a starting - [audio glitch]. So we have to return a label for that unit for example in certain user interface. They may need it. This means they are not associated with a number but just a standalone name for that particular unit. Also this channel one that I think in the version 1 we have something but later on we'll decide to remove it that time and that's how we have a lot of different things together like weak name, weekday name, month name, and also date time field name in because the complication of the calendar we all agree in the V1 time and also actually before w decided to remove the week week a month then but also that time somehow remove the daytime field name, it has a name mean the label for a particular data feel not that particular day time as for example the name of "year" or "Month" or "week", but think about that localized different languages so that we decide to add it back. Because that's not something you can get from other APIs, any other API one of the reason well, so there's a lot of reason we drop order like week or month itself the name of different week or different month, but date time field in didn't fit that criteria. So after discussion with we decided it is a good idea what I did back here and shouldn't be controversial say it's all the different Locale show have a feel for that.
FYT: Another one is very commonly required. There are several other people asking is to spec out, the dialects support for the language and where see what's that mean. So here's a change. We need to make I say new again. This does not mean the new to the proposed all the thing new to proposal is highlight as green text and the deleted text. So you drove the part. I label "new" mean is new since stage 2. Okay, so this is the change since January. We add this if car if there's a language we have (?) and can step dialect name or dialect standard in and the default dialect in and we do something different and we'll also add a calendar date time field and unit as a new value for the type option. So here for example is time whole what does die like this handling mean and here is showing that there was showing differently to different thing is you see for example en-GB in dialect then it will just show British English, but in standalone it will show English and in parenthesis United Kingdom, so and so forth. So I show a couple other examples here. By the way those data are in CLDR. I show in particular here that there are three new green highlight but also the new one which mean after this H2. added this back in the draft is that date time field names. Here is an example: locale Calendar it may return different kind name for the different calendar and so on. Unit here is showing the Chinese and French for example.
FYT: Yeah, this is the one I'm looking for. You also need to decide a decoding table to the to see whether that data on field name are valid, so this is the only thing we're going to support for the fields, including year, era, quarter, timezone name, or second.
FYT: Here's an example of data field here. Oh, sorry, I didn't include English should be pretty easy to figure out what to call? I've included Spanish and Chinese examples here.
FYT: Of course, we need to change the internal slots. So there's some changes in the internal slots to represent the data. resolvedOptions have the change but not in the algorithm itself, just an additional table entry. And of course an instance have the kit that information the variable.
FYT: So we have three reviewers Shane, Ujjwal, and Richard as an editor and we have a V8 prototype already here. So in the April meeting Shane and Ujjwal signed up for Stage 3 reviewer and with my mistake I somehow just either forgot to ask in the January meeting or I forgot the names and I cannot find it from the notes. So I've asked people to sign up for stage 3 reviewer and they signed up. And they agreed to approve. So we're in that meeting April 9th and all the people gathered together and they approved support us to bring this to TC39 April meeting for stage three advancement, here's the criteria I believe for Stage 3 and we would make that there's one issue I think from Mozilla. Yes, they just our so like 24 hours. suggesting about the changing of the name in the dialect. So I think anba suggest 24 or 26 hours ago about changing the use of the name for the property of dialect handling. He suggest we change to just dialect and standard instead. Just remove the name part. And I think he also asking a question about whether they should have additional support for a new option called menu. Unfortunately this is a very short period time. I saw having to get out the possibility support that so that's the only issue that happened pretty recently I'm being addressed. Beside that I don't think we have any open issue beside that particular thing again, it's relate to that and two thing one is the naming and one is the additional value. Oh, and there is a third one, the third one is the default value for dialect handling because currently we I believe V8's shipping with the dialect as default and Mozilla is shipping with standard as default so we need a clear default standard in pretty important to otherwise will be very different between this two of them taejun as the V1. This is V 1 already issue there. Well, that's something unfortunately bring up pretty recently and I haven't had a chance to resolve it within 26 hour. I apologize for that. I believe we can talk about here today about that issue.
FYT: Beside that I request the committee to approve advancing to stage 3.
DE: I'm kind of uncomfortable with this going to stage 3 before we resolve this semantic issue one way or the other. Maybe I'm misunderstanding it, but it seems like it seems like something about the surface that we should resolve. for stage 3 well if you want to conclude that the issues are wrong and we don't want to make any changes then it might qualify. But if you're saying we might change it later then I think it's not ready for stage 3 yet.
FYT: That's not what I'm saying. What I think is currently without this proposal at all. Okay without this proposal just think about that. We I didn't bring this to forward Mozilla and V8 Behavior are different already. That's pre-proposal. One is showing the dialect one is showing the standard. Terefore there is a need for this proposal because with this proposal there's a standard way for the default. Without his proposal there's a difference. So this difference is the motivation to approve this proposal to make sure there's one standard.
DE: So I'm very happy with display names supporting dialects explicitly. I guess I don't understand this issue enough to know whether it means changes that are kind of things that should be resolved before stage 3.
FYT: So let me explain a little bit more. So because currently we don't have this dialect support option, Mozilla display one way and V8 display another way. I think it should be the same way, it shouldn't be a different way. Right in this proposal we setup option and there is a default value. Therefore it is possible that with the spec text as the first row the caller can decide Behavior which one they want to call the second way is because this proposal we clearly specified what the default should be. My understanding is no person currently objects to what the value should be. Of course, if someone says 'the value should be this,' and there's a disagreement then we can say well there's an issue, but so far no one has a minus ending it… Maybe I didn't read it clearly to only people just say well currently the current behavior is different.
DE: Sorry, are you concluding "no" on the name change? Because I'm about to propose you break it down into three separate issues one was writing the name t edition of minions (??). So you concluding no on those.
FYT: I'm not talking about an inch the ancient people
DE: I'm saying the the whole set of issues. It seems like we should resolve all of those before going to stage 3 even if I agree with you that it was OK wait result here because the Supreme up like 24 hours before.
FYT: I mean, I pose this as 10 days ago and 24 hours before that people bring this up and if we operate this way, there's no way we can advance any proposal.
DE: We have another meeting in a month and a half. So I'm not not sure if it's the end of the world if we need more time offline to resolve this.
FYT: what will happen 24 hours before that meeting someone bring a new battery issue.
DE: I don't know. You've been even pushing a lot of proposals forward successfully. So I'm not I'm not really worried about this kind of stalling forever thing.
FYT: I'm hoping we can address this right now if they are issue over that she's going to
RPR: Do we have a representative who can represent the the issue?
YSV: technically It should be me, but I am also a little blindsided. I didn't see this come up, but I have been reading it. Unfortunately, I didn't sync with ZB before this but my understanding of the issue is anba is raising a question about whether or not we should have also menu supported we have dialect and standard already and he raises sort of a knit around the duplication of the name dialect. I don't see this as web compatibility issue and so far we haven't had any web compatibility reports as Frank mentioned. This is a pre-existing issue but because I'm also a little bit blindsided here and I haven't had enough time and I'm additionally I’m not our internationalisation expert, I can't speak conclusively until I've checked with ZB. However, I suspect that ZB will say this is resolvable and we'll be able that this is resolvable, and be able to do it rather quickly once he's on line. That should be soon, maybe in an hour or two.
RPR: Okay, so do we want to wait for ZB’s availability?
YSV: Also I understand USA already spoke with ZB.
RPR: USA, are you around?
DE: USA seems to be missing on Igalia's matrix.
YSV: Yeah, it looks like it looks like - if you give me until after lunch I can get a concrete answer here. I suspect that this is not a stage three blocking concern, but give me until after lunch and I can report back accurately.
WH: Can you go to the unit slide? When you ask for a translation of units, it seems to give you the plural translation. How can I get the singular one?
FYT: Good question. I don't know. Are these plurals?
RRD: Yes this is plural form in French.
FYT: This is I think this is a stand alone form inside this planean. I don't think we simplify. I believe I see how the CLDR I think this is used to for just showing the particular item. I don't know whether that have a plural form or a singular form in the data. They're That's an interesting question.
WH: Okay, and in languages with multiple plurals, which plural do you get and how do you get the other ones?
FYT: As I say, this is not used in a context of associated with a number right? So the name an associate with a number is supporting a number formatting. So let's say you want to use the meter in the context of a countable item, which is not here. It should be used in the in the in the number format and here I believe the contacts that to get an end is to use this as an item for either for example the label of that particular field or something to mentioned the unit itself.
WH: This slide is the first I've seen I've seen of this issue and I'm curious what the answer is.
FYT: so the pluralization issue is not addressed here, it's addressed in NumberFormat. That's my understanding. SFC, is that your understanding too?
SFC: [mic does not work]
FYT: Yeah, we definitely have the plural information and accurate different form. For example Russian. That's a form, but those are not designed to be accessed, actually we don't want to do that. Those are supposed to be used in the number format. So you put in a number and it will resolve it in when you format the number. We it's definitely not our interest to use the caller to use this API. II to format a number and to resolve the plural of realization that's not intention. We just try to intend in somewhere standalone that we will provide a label for that. That's what this API is for.
SFC: I had a reply to WH's question. All of the results that intl display names returns are the canonical display names from CLDR. CLDR is currently actively working on adding Display contexts to all of the display names which handle not only the pluralization of the display names but also things like capitalization context, grammatical case, grammatical gender and so on. Intl display names already just returns the canonical version of the existing strings that it returns and the behavior for units, calendars, and date fields is similar. It'll just return the canonical version. So I'm hoping that we'll be able to follow up relatively soon, maybe in the next few quarters with a display context proposal that adds more options around these strings. Now, that being said, in terms of plural forms, we already have Intl.NumberFormat, which will select the correct plural form when these strings are associated with numbers, but this is for display name. This is for, for example, a drop-down menu or other contexts where the plural form is not actually relevant.
WH: To clarify, is the default always going to be plural here?
SFC: Not necessarily. It is locale dependent.
FYT: This is usually used for example if you have a table, right and you have table you have me have some okay, here's something and one of the column may have this display and the other column is some number or something else right support those kind of.
WH: I just want to figure out whether this will give you a singular or plural.
FYT: Yeah, I believe the translator whenever in the asking. To to put in the translation. I don't think there are specific clearly stated which formed here after
RRD: I can talk specifically about the French case because we figure when you asked for now the Mark is I would understand the translator would have used the plural form to categorize the unit. So you would categorize the units in a perform if that if that makes sense.
WH: So if the language were English would you get “meter” or “meters”?
FYT: That depends on the English translator.
DE: I think this line of questioning is pretty out of scope for this committee.
WH: I disagree. I want to know what this does.
SFC: I'm looking up the data now in CLDR: English is "kilometers". So it looks like it's plural.
WH: OK. Thank you.
SFC: You can check this link to see the data.
RPR: Have we concluded WH's topic?
WH: Yes.
DE: I wanted to ask, related to the presentation that SFC and ZB gave at a previous meeting about qualifications for things being added to the standard. One of these was that there need to be multiple parties who raised use cases for the features. So in this proposal - and maybe you talked about this at some point and I missed it, but this definitely seems well-motivated, you've gotten requests from many different parties, but I don't understand what the motivation is for the calendar and unit and date fields, for the use cases for them. Do we have multiple parties asking for these for these to be added to the standard?
FYT: I believe we talked about that. I mean the three criteria we have talked about that in the ecma402 meeting. Sorry, SFC, could you help me to dig out the meeting notes? I think in April we discussed that and we reaffirmed.
SFC: I've talked with ZB a lot about this offline. There are a lot of parts of this proposal that we've actually removed. We've removed more parts of this proposal than we've added because of various issues within TG2, and the latest proposal reflects the TG2 consensus which we've discussed multiple times in the TG2 meetings, including with ZB and others. The motivation for calendar display names is largely motivated by Temporal. Both calendar and datetime fields are both very important for calendaring applications when displaying dates in different calendars. This is how you can label what calendar they are in; the datetime field is very important for filling out date forms and date pickers, for example. To be clear, when we say datetime fields we mean the translation of the word "months" or "hours" into other languages, like "Stunde" or "Hora", for example. They also require a fairly small amount of data for a high impact, which helps make their case of broad appeal because one of the conditions for stage advancement is that the larger amount of data, the bigger the use case it requires. And both of these require a fairly small amount of data. The use case for units is for example on unit converters and units pickers that you see, so we've generally been happy with the use case for unit. That one has the weakest use case of the three, but it's but it's also a fairly small amount of data that we already include so it's basically just exposing that. But I'd say calendar and datetime fields are most strongly motivated and unit also has some motivation.
SFC: But also, process-wise, I don't think it's the job of this committee to rule on whether these are motivated. That's the job of the TG2 committee, and we have discussed this extensively in the TG2 meetings. So if you have concerns about the use cases, I would encourage you to file issues in the repository and come to the TG2 meetings when we have these on the agenda.
DE: Yeah, I apologize for missing the TG2 meeting. It's just in your in your presentation in the number format V3 you identified which parties were interested in things and wondering if you had parties interested in the unit display one, the unit picker?
FYT: So your question is whether we have a particular party to mention about that? I need to go back and take it out. But I think that has been asked for several place. There are actually some other field being proposed and asked by multiple party, but we have to decline. One is the Emoji name. There's a Unicode data we have the emoji name. A lot of people, you know, they love to have it because all the cell phone have a lot of emoji picker support, but we just look at the data that was in there. No way we can support that. So there are use case just exactly like question say not only because there are a lot of people use it but the data size too big that we have the decline. One of the reason units got added there is because the unit is already supported in number format, and the data usually comes with it. So it would believe that unless people do really strange thing to filter those data that usually they will not increase the data size and it will be a good accompany with number and the number format support. I think that's probably one of the motivation to support a unit here.
DE: I'm still a little bit worried that people will misunderstand that along the lines of WH's question and misuse the unit names, especially if we don't have a lot of people asking for this support.
FYT: Do you have any suggested actions?
DE: Yeah, again, I apologize for not raising this earlier, but one one action would be to remove the unit from this given that the other ones have stronger use cases and unit runs the risk of the misunderstandings that WH raised.
SFC: Process-wise, I'm a bit uncomfortable with requests like this coming up at this point in proposals like this. We've just been discussing this proposal for almost half a year in TG2; this proposal comes up almost every month, and there's ample opportunity to raise these kinds of concerns. That being said, I am happy to hear this concern. I don't think the question about whether developers would misuse this because maybe they wouldn't discover that the correct way to do unit formatting is a number format. Maybe would that cause a discoverability problem? I mean, I think that's an interesting concern that hasn't been raised before, and that's new. So that's good. I'm glad we're raising those issues. I'm just expressing my disappointment that they come up at this point in the proposals lifecycle given that we've discussed this extensively in TG2, and this is the third time we presented it to TG1 as well. There's already been a chance with Stage 1 and Stage 2.
DE: You're right. I'm raising this too late. Sorry.
RPR: DE are you withdrawing that as a concern?
DE: Yes.
RPR: Okay, Frank, so we still have the outstanding issue of the whether we're okay with conditional advancement
FYT: sure and is there any other issue? So what would be more appropriate that we hold us. So my ask is for stage 3 advancement. I understand Mozilla need to have some discussion and should we talk about this later in the meeting?
RPR: We have got a little bit of extra time.
YSV: I actually have an answer. So very briefly after discussing with my colleagues. Ideally we would have resolved this prior to advancing it to stage three, but it's not a major semantic change and we do not have an objection. I think what we to do here is conditional advancement where we will conditionally Advance this to resolve the issue of display name standard name. It to rename it to display and standard as recommended by anba and for the default to use dialect because it alliance with both V8 and with JSC and Firefox will change its implementation.
DE: So the idea is to conditionally Advance with with all these changes pending?
FYT: es, okay, so let me repeat again. I try to understand so what he's saying is conditionally in just removing the name part.
YSV: That is my understanding of the recommendation.
FYT: Right? And you say you are happy to defaults to being "dialect", right?
YSV: Yes.
FYT: Dialect is the current value in the spec text. So so the only thing my understanding is the change is to is to remove the change the string from dialectName to dialect and stand on the end and our and that's the only change because number also raised the issue about additional support of menu and my understanding that's not required for (?) and we can we can support our later right, you know, if we have a look and have another proposal to support that it is not supporting. It's an additional feature request basically coming in 24 hours ago. We didn't know reason block that right?
YSV: Yeah, so it's not a block on the menu thing. That is an additional request. It's primarily the unnecessary repetition of "name" thing and also our agreement that we can standardize around dialect.
FYT: as the author of this proposal. I am happy to make that change to remove the name I do. And I personally don't see any issue to make a name change of that. So I'm glad that anba brought that up. If he'd brought that a little earlier I'd've already changed it. So I'm pretty happy to comply with that. I don't know what other people think about this. And would that be okay too
SFC: Yeah, so there's a lot of new information in the last 24 hours on this proposal on multiple different fronts. I'm really glad that we're getting all this extra information. I think that a reasonable conclusion here for the committee are (1) what YSV had just stated, and with with that change that we can do conditional advancement to stage three; or (2) say that given the extra information from from Daniel from Anba among others that we'll continue to work on this proposal. It is a bit late for the feedback, but it's not too late because this proposal is still at stage two, and it's not uncommon for stage 3 advancement presentations to result in going back to the drawing board and coming back next meeting, which is in just six more weeks. It's still in the same quarter. So I think that both of those are reasonable conclusions, and I don't mean to play a process card and say that oh, we can't take this feedback because it's too late. I want to make sure that we have a high quality proposal. So I think that it's ready for stage 3, but I also think that maybe it could improve even more if we continue to work on this new feedback that we just got in the last 24 hours.
YSV: That actually echoes also my feeling here. Fundamentally, Mozilla does support this proposal but given the feedback that's come from multiple directions. It feels like the appropriate thing here to do is to defer to next meeting. Although I gave the requirements from our side, because the issue was posted from us, I think it'd be better and we would be more certain of what we're doing if we wait until next meeting.
DE: I also support this proposal. I think it provides useful things and I apologize for not being sufficiently engaged in the past and I'm looking forward to working together in the next month and a half on it.
RPR: Okay, so it seems like there's a lot of positive intent to do the steer towards deferring to next meeting Frank.
FYT: We would you like to decide the Next Step. Yeah. I mean if people feel that we need to change it to next meeting then our preferred to have some action lighting the owning action items so far here is to remove the name which we can just do it by proving here, but I just can't go back in six week coming , but I'm not quite sure of what is the action items is coming it easy prefer me to do. I would rather not go back a six-week do nothing in combat again. Just remove the Nan the chance of man. So if if the come eat again, give me some action item happy to do that.
SFC: Let me summarize what I think the action items are. I think one is to work and verify with Anba and ZB on all the rest of the points in the issue that Anba opened to make sure we're in alignment on all three of the points including whether or not we want to handle the menu display, which it sounds like it's currently inconclusive. And two is to work with DE to verify, you know, whether to continue to include the unit names because of the issues that DE and WH raised here.
FYT: DE already dropped that issue, right?
DE: I'm happy to keep discussing it over the next month and a half. I don't want to be this so objector blocking the whole proposal. So it's in that context that I dropped it.
WH: A correction: I did not raise any issues today. All I was doing was asking clarifying questions. I did not raise issues about the proposal.
RPR: Okay, so I think then that Shane has listed the action items. Okay, happy that concludes this topic, FYT?
FYT: Okay sure. We can move on to the next topic.
proposal does not advance, will discuss further with DE, Anba, and ZB and return next likely at meeting
Presenter: Mathias Bynens (MB) & Markus W. Scherer (MWS)
MB: So yeah, we're here to present an update about the regular expression set notation proposal. We've had a lot of meetings including a TC39 incubator call since last time we presented at TC39 and all those meetings were really good, active, I think. We have a new coherent proposal that also includes the Unicode sequence properties proposal which is now called the Unicode properties of strings proposal. So here's the general direction that we're going in right now. We're not asking for stage advancement today; this is just an update, but we hope to start working on drafting actual spec texts. Currently we only have to do spec text, of course on the way to the next meeting and then potentially next time ask for stage 2, but for now, here's
MB: The proposal is about adding syntax and semantics for difference intersection and nested character classes. Union is already supported in a limited form in current regular Expressions, but it only works within a single character class. And since last time we brought this up at TC39, here's some of the issues we've been discussing. We'll go into detail. We have a slide for each of these with some code examples that I think is easier to follow when we're talking about this stuff. But anyway if you look at the slides they're in the agenda, there's links for everything. So if you want to find the background on the discussion and the Alternatives we could say or you can find it all under the present directory.
MWS: Sure, so we had started the discussion with the suggestion of using a prefix like a \u with curly braces and we were using that for a while but in discussion, especially with WH, we tossed around pros and cons of that and we realize that could be misleading and lead to frustration, in particular because even though that sort of syntax looks like it should work on its own and have the desired effect of the new semantics. It actually would just be matching a literal uppercase U followed by the various characters if the u flag is not specified. So we came back to considering other ways of saying that the character classes have different syntax and semantics and we are now proposing a flag that implies the Unicode mode and builds on top of it. So basically the u semantics would apply when this new flag currently is specified but in addition we would also have the modified syntax in the character classes and also use the same flag to enable the properties of strings that also came out of discussions that we have with WH and other people that it's it's cleaner to have the new semantics go together and enable both the set notation and the properties of strings together with the new flag. We also talked about a modifier, which some Regex engines use but because ecmascript hasn't had any modifiers inside the pattern like (?x, we are not proposing that at this point. We are not totally set on V but V is kind of the next "U" in the alphabet and that makes sense. There is also a limited set of letters available. But we are not totally set in stone on the particular letter.
MB: We actually have a slide with some more details on the flag because we're not just talking about the new letter for a new flag, but we also need the corresponding letter on reg. It's a prototype. We've linked to the bikeshed issue, it's number 14. So if people have any ideas or opinions there, please post them on GitHub. Here's an overview of all the current flags that we have in ecmascript including the latest addition, the d flag. Which has to have a prototype getter. So this is one example where just because the flag name is d, it doesn't mean that's the getter name has to start with D necessarily so we can kind of choose whatever we want. But if people have a better idea than something like "unicode sets". Then yeah, please let us know some other ideas in the thread. There are extended character class or Unicode character class. Yeah, you can do whatever you want basically.
MWS: [next slide] I think most of you have seen this one before pretty much unchanged. We are proposing to use double punctuation characters for the syntax partly because it's more distinct but also partly because we are trying to avoid the need for a new flag for future extensions and there are some reasonable extensions that one could want. For example, some regex engines support a symmetric difference inside the character class, which we are not yet proposing, so we would like the proposed syntax and the reserved syntax to look similar and that's one of the reasons we are proposing the double punctuation. Existing practices mix, there are some regex engines that use the single punctuation in a way with some additional limitations and constraints and some use double punctuation with different constraints. This is what we have in the proposal here also for the - character itself is fairly overloaded and is also used for range and in the existing syntax as a literal character. This should make it more distinct and show that it's not a range of two properties of something.
MWS: [next slide] We do have the reserved syntax as I said, which is basically double versions of most of the other ASCII punctuation. We had also in earlier versions looked at reserving single curly braces, but we actually found in the incubator call that we really needed that for something else I will get to later. In the discussion of that we basically said that something similar could happen with round parentheses, so we should probably reserve these two. So that's basically what we would like to keep reserved, which means that if someone wants these literally in character classes, they need to be escaped.
MWS: [next slide] The dashes. So the dashes in principle have three kinds of meanings. The most natural thing for the set subtraction is the - or hyphen-minus, and we are proposing to use that as a double form and when it's used for a range to just have a single dash as already regex engines do and when those two come together, we require the range to be bracketed so that it doesn't look like a soup of dashes. We originally also had provision for a literal dash in certain positions in the character class and feedback from that, I think in particular from WH, was that that's not really necessary and it's confusing that it works in some places, but not others. And so we modified a proposal to always require a dash to be escaped in order for it to be literally part of the character class.
MWS: And then there's the question of operator precedence. We are all familiar with that for arithmetic expressions in programming languages and in math in general and there are well established standards for how to do that. Sadly, we looked and there are no established standards for the precedence of these kinds of operators in regex engines nor even apparently in math set notation or Boolean operations. At least what I could find, whenever there was a question of which operation to do first, I've only ever seen bracketing or parentheses, in order to clarify that. So we had a long discussion of what we should do for ecmascript regular expressions, and we came up with something that basically avoids the question of precedence. when there is only one type of operator like a first line has basically a union of three items, the second one is a succession of subtractions, there's not really a question of precedence. All we want to do is to specify that it's left binding so that on the second line where it's not an associative operator, it will first do the subtraction of the other controls minus the former controls and then from that you subtract the other control characters. So with this just left binding which is very common in various systems we don't need extra bracket in there, but when you mix operators like in the other examples - here in the second half of the slide is a mix of intersection and Union and then subtraction and union in various combinations - that's where we require brackets. Otherwise, it's a syntax error.
MWS: [next slide] We also had a mandate to figure out how the properties of strings formally sequence properties proposal interacts with the set operators proposal. That's why the properties of strings proposal hasn't progressed any further and we think we have a good solution for that. We do want to have the ability to have properties of strings inside of character classes because it is useful to intersections and subtractions just like with other properties. Where it is useful to have the set operators so that you can make petitions and exceptions for identifier syntax and various other things. The same is true for properties that contain multiple characters strings. For example, on the second line there that's basically all of the Emoji Recommended for General Interchange, (that's what RGI stands for), except for all of the flag sequences so it will match this this girl emoji and The rocket or bicycle and icons of things, but it's not going to to match any kind of flag, for example the flag of France. We also recognize that it's difficult to define What a compliment means when they are multi character strings in a character class. So when a character class contains or looks like it contains syntactically multi character strings, then the complement of that character class is a syntax error. And we came up with a pretty simple way of validating that syntactically just based on the information that we have, the metadata of properties, so we don't need to look at the contents of the properties while parsing the regular expression. We just need to look at the metadata for the property. And they are combinations that are valid, for example when we have an intersection of a property of strings with a property of just code points, like in the first example here, that contain single character strings. So the complement of that is valid. And it's easy to to verify just with metadata. So then there is a more interesting example. This is an approximation of a hashtag regular expression. It's an expression that starts with the various hashtags that Unicode has and then it continues with identifier characters and Emoji characters and then it does the usual (?) some characters but not other characters like hashtags themselves. So we think this is powerful and the combination of these two proposals really solves what but he has was originally trying to solve in reducing those large definitions of fractal expressions and things to get emoji handling and matching.
MWS: We have at least one more slide. Yes, so we had not proposed String literals we have proposed only properties of strings and in the incubator call we had a couple of weeks ago that was felt to be a big hole and incomplete. So we are adding the Syntax for string literals to the proposal. What you see here is basically what the ICU libraries have been using for a very long time for multi character strings in the Unicode set class, which is very similar to a character class in regular expressions and the CLDR project a Locale data project has also been used as ICU syntax. We have an extension of that proposed here for Ecmascript. And that is on the second line on the right side. To reduce the visual clutter when you have several multi character strings, we're proposing that is an abbreviated syntax with a pipe symbol separator. So with that basically we are complete in a way that regular properties of characters go together with literal characters in the character class and the properties of strings go together with the string literals that you can have, so that you can also have additions and exceptions of just a few strings. So you could say that you don't want to exclude all of the flags from the set of emoji, but you do want to remove the Belgian flag from the set from the matching.
RGN: The examples given with the brackets inside of brackets are not currently allowed by the lexical grammar. So I'm wondering what the direction for that will be.
MWS: I'm not sure what that means to be honest.
RGN: The left bracket character only allowed to express a class which cannot itself contain left brackets in the current grammar. The first example under "proposed" here is not allowed lexically right now and I'm wondering what the approach for addressing that will be.
MWS: we don't have spec text yet, but it has always been part of the proposal that we need nested character classes. So we just have to figure out how we can extend that part of the grammar.
WH: That is allowed lexically.
RGN: I just checked and it isn't. I'm not sure what you mean. So there are regular expression class cannot contain a none escaped right bracket. It's it's a left bracket and then a sequence of things in the very first unescape right bracket closes it.
KG: So this seems like not a concern for stage 2.
RGN: Consider it raised and closed.
RBN: this seems like a specific technical question that can be resolved offline.
WH: All I wanted to say is that this has been raised already and resolved.
MS: I think you had a slide that had an example of a property of characters of the property of strings where you take the intersection and then you invert that. Yes, so that fourth example that is valid. I believe it's because when you parse you determine that the intersection ends up being only a property of characters, is that correct?
MWS: Yes and not just based on the actual characters and strings contained in these properties but based on the metadata that the symbol property is a property of code points and therefore the intersection of that with something else can only contain code points.
MS: Is it possible that - let's not call it symbol, but some other property that currently is only property of characters and later becomes a property of characters and strings, that this could initially with a version N of Unicode standard implemented the browser or engine be valid and then in N+1 would no longer be valid because the intersection of would include properties of strings.
MWS: I don't think that's possible because we have discussed that with the Unicode technical committee and there is a strong sense that that would not be an allowed upgrade of a property.
MB: Yeah. I brought this up as part of the properties of strings proposal a year and a half ago or so in a UTC meeting and I believe a stability guarantee was actually added to one of the documents to guarantee that this won't happen. It can happen in the other direction where a property of strings starts to only contain character or match characters, but that is fine.
JHD: My general reaction to this proposal overall has been kind of hesitant because it's a lot of extra stuff. This is sort of a concern that anyone could have about any proposal that had syntax of any kind. It's possible that when I become familiar with all these things it will be fine for me to look at a regular expression using them and understand what it's doing, but regular expressions are already confusing as it is. This is all kind of confusing to me, and it's a lot of stuff, and maybe there's no way to address that while solving the problem but using all of these specific sequence names that I'm seeing on the slide right now. For example, I don't know what those are. I'm not familiar with CLDR or Unicode or wherever they're coming from. But also I have no idea how I would know that unless I went and googled them and did some research, and maybe that's easy - I don't have any idea if this is a hard problem. This is not a hard objection, just my gut reaction. I remember a number of years ago, someone brought up a proposal of a bundle of extended regex features and one of them was comments, and this is something people have asked for a lot. I'm certainly not expecting you, champions, or this proposal to do that - but I was wondering where we're at with that, because I feel like a commented regex no matter how gnarly they otherwise would be, kind of addresses my confusion reaction.
MB: I would be in favor of a proposal that is white space, I think that was one of the things that was discussed, and also then also commenting through the regular expression pattern grammar. That would be awesome. We're currently not pursuing that as part of this proposal. If anyone wants to pick that up, I would be strongly supportive. The other point I want to make in reply to what you said is: I agree there is a cost to anything we add to the language and when it comes to syntax. We believe that in this case the cost is warranted because the functionality is actually useful and if you look at the alternative, what people are doing today without this functionality being present, is basically - well regular expressions are much more unreadable than this because there's no way to represent these things right now other than using very long machine-generated character classes or alternations or combinations of the two. So overall we think it is a solid Improvement.
LEO: Just wanted to support what MB just said. It is already complex and there is more there are other regular expressions are more complex today. It feels like opt-in complexity for existing regular expressions. No one is going to add that. Of course someone who's going to add that like in order that not facilitate communication among teams, but it feels like very opt-in for those who are using it. They seem to be very aware of that.
TLY: Is there a reason that you need it to be a syntax error when you include a negation of a property of string? Could it be a late error, like perhaps a constructor-time or execution-time error? Because it feels like you're adding a bunch of complexity into the parser where it needs to know about every single property class, and what semantics it has.
MB: that is already the case in implementations at least in PA we have a Both the button it actually matches the spec in that sense because the second games list of properties which currently are only properties of characters and so alongside that list engines would have a separate list of properties of strings And so as you're parsing you're parsing the regular expression, you would just look Is this one of the list? Is it the property of strings in that case, you know so you can determine statically what kind of property it is. And also what the results of these sets operations would then be?
TLY: So basically the idea is you want to make an early error because you believe it's easy to do.
MB: Yes, we believe it's easy to do. Also all other errors in regular expression patterns are currently early errors perspective. And so seems nice to match that precedent.
MWS: It also seemed like the direction of where this was too late a discussion post going in previous meetings where we presented this.
MM: All right, I just want to verify that a correct JavaScript lexer before this remains a correct JavaScript lexer after this.
MB: Yes, that is a goal of the proposal. I'm happy to make that an explicit goal. We have been working with WH who's been really helpful, and I know that it's also a very strong concern for him. I'm confident that we can find a solution that works for everyone.
WH: We are not making any changes to 12.8.5 which is the lexer.
MM: Okay. Great. And yes, I would appreciate that being explicit because I was certainly confused about that earlier.
WH: Regarding the issue RGN raised earlier, 12.8.5 allows nested square brackets and it will continue to allow nested square brackets.
RPR: Okay. Thank you. so we're basically the end of the time box Mathias or Markus. Did you to -
MB: This was just a status update. So if anyone has any feedback or ideas about any of what we've shown today, please participate on the github. There's a place in the slides to all the specific issues there. So yeah, we look forward to hearing what you have to say. We’ll start drafting spec text soon. Thank you.
Was not seeking advancement but no expressed objections to the described syntax
Presenter: Frank Tang (FYT)
FYT:this is a proposal for to extend option for the time zone name in date time format and year and the other two this is the curling stage one and we're asking for stage two stage two events that.
FYT: so the motivation is to try to extend timeZoneName, which is already existing in Intl.DateTimeFormat. And currently I think we have two different valid values. We try to add additional for to support more formatting option. Really we intend to change in ecma402 was to add additional valid option for time zone name. this is a change from stage one. We change the mains currently. We are as proposing to change additional for pre-existing have short and long for the time domain, but would like to add a shortOffset, longOffset — we used to call these shortGMT and longGMT and someone pointed out that's not a good name. So at ecma402 we changed it after consensus, we decided to change to shortOffset and longOffset — and also shortWall and longWall. I'll explain to you what this means. So here's one of the code example, so let's say we go through this all six options, what it displays in English. You will see the shortOffset and longOffset examples reference the relation to GMT and the shortWall and longWall refer to PT or Pacific time without identifying whether that's standard time or not Standard time, which is what is actually identified by short and long.
FYT: There's another example in Chinese. I didn't include one other example whose you can find in the repo that actually I think in Russia or in France that the offset may not be using the token GMT. There could be say UTC, it is localized based on that particular Locale, but it's always referring to the GMT offset, but there are different representations of that.
FYT: so again talking about the stage 2 or 3 requirements within 402 that we have additional consideration. One is prior art. First of all CLDR, ICU or the and many others have support those four options. So we believe that establish the prior art. And also we have difficulty in implement (?) issue and pelo issue and what talk over that. So first of all the prop here here is an example. We're not quite sure what kind of Technology they're using but in the webpage or many places there are using this kind of short wall and long wall kind of representation in the formatting of the time zone. For example, NPR news. They were referred to I think ET because they don't want to explicitly which one is that. And there's some other places for example didn't call for financial quarter review meeting. They were just say "eastern time". so there are many places actually in the lab currently probably using Java or some backend technology, probably not JS, but probably there could be JS too to put that in that format. So that tells us that it is important.
FYT: We also consider about the data size increase and as I mentioned to you this one of the concerns early on they are actually several other proposal to option to include one of them is actually I forgot which particular I have something issue of that. So we actually decide to remove, I think it's something related to the time zone city one, so because after we calculated that so as I mentioned that I can afford to one of the things we care about the size. The actual order to filter out to of the proposed items. So this current for is whatever we believe take a balanced and here we showing here that some of them actually only have slight differences from the other. For example for Pacific time in the place have time zone they will be different because that you will have either a Pacific Time, Pacific Daylight Saving time, or Pacific Standard but you many times actual note there. Friends, right? So example Japan do not use daylight saving time. So either option will return the same value. So therefore the size increases not dramatic in because of part of partially because of that, and for the short and long offset, the basically for each Locale is basically have probably two different pattern and that's all. The other things are formatted according to that pattern. So here is the size increase that we calculate this is purely based on just look at the source tags and compressed. We didn't consider any additional data structure issue for that.
FYT: as I mentioned broad peers also very important. So for example additional value that someone suggests to support for ISO 8601 time zone style, which we actually decline even though it would only use a small amount of data. The reason that ISO 8601 formatting is really coming through formatting the datetime form itself, which is not a localized formatting. Right? So there are no use case to just format kind zone for that particular format and mix it with other date-time format. We believe that request is legitimate, but it's not part of ECMA 402 so we suggest the one who requests for such a feature, go back to TG1 to talk about that may be supporting that (?) to do with machine-readable data and format, but not for human readable data format.
FYT: The history is that we advance to stage one in January and so in the April monthly meeting we go over that and we said I think we got received a suggestion to change the name was then change it and they all support come here to support advancement to state two. So here I am. So also I if people agree with that and also have the eight April type you can see in we also if with people here agree to support to advance to stage two that we also like to ask for two stage three reviewers for that. So here's the criteria for stage two, I believe we met that, and so here I come and as for the stage two advancement also to remember for Stage 3 of the course before that will open for questions
RPR: Queue is empty. What about messages of support?
USA: I wanted to support this. This looks great.
SFC: I support this proposal. I think it fills a very important gap in time zone rendering and formatting and I think it does it in a way that mitigates payload size and I'm really happy to see this advance.
USA: I just wanted to point out that I really appreciate the work that was put here to make sure that all the additions had strong use cases and only moving forward with the ones that we knew where they were most important ones. Super happy with this.
RPR: So let's do just a last call - any objections to stage two? [no] No objections, so congratulations you have stage 2.
FYT: May I also ask for reviewers?
PFC: I volunteer to review this.
FYT: It's not that much to review. It is a good way to contribute, and could be good for a new joiner. This is not a 200 pages long spec. It probably changes, I'll say 30 or 40 lines. So it's easier to review.
USA: I'd be happy to help somebody if they want to review.
RBU: I have never reviewed something before but I'll be glad to help.
- Stage 2
- Reviewers:
- Philip Chimento
- Rick Button (assisted by Ujjwal)
Presenter: Shu-yu Guo (SYG)
SYG: So this is resizable array buffers and growable shared array buffers again asking for stage 3. Since last time the three action items that were identified from the last meeting was one to decide on a fixed page size for the implementation defined rounding of Max fight length. This was pushed back that was well taken from the from the Mozilla folks. others as well to as to interrupt concerns about if we let the implementation define what page size to use for this possible rounding of this optional rounding of Max byte length you pass the max byte length into the Constructor that could exacerbate interop issues. So we should fix a page size. And I'll get into that first. There was another item to make some progress on the web assembly integration given that it is one of the main motivations for this proposal to actually go to the wasm folks and to sketch out a technical solution There for having this integrate into the webassembly jsapi. And finally to do a little bit more work and to make a decision on having the Constructor names be Global like resizable array buffer or namespaced like array buffer.shared. And I'll go through each of these in turn.
SYG: So to address the fixed page size issue. The decision is to just remove the implementation-defined rounding and I'll walk through why we waffle here. So the original motivation was when you are making this new buffer, and you are reserving the memory for it implementations may want to round up to a page size multiple anyway. [bot dropped for a second]
SYG: tape size differences observable. You have more fingerprinting. You have possible interop issues. now if we fix the if we address the concern that we do not want to expose implementation defined a page sizes implementation still might want to do the rounding with is on page size, right the original motivation still exists. Now if they do that you now have to still track another length. So now you just have the original problem and more complexity because you allowed this implementation to find Behavior. So the concurrent conclusion is just to remove the implementation defined rounding again, so this goes back to the original proposal where the max fight length is is never rounded whatever you pass in is what you get observably if the implementation chooses to reserve more memory than needed under the hood. The JavaScript programmer will never see that. I reached out to to the Apple folks and the Mozilla folks and think I got positive feedback from both that they are fine with removing the implementation-defined rounding. So that's the first one. The second one, for webassembly integration, I wrote up a integration PR into the webassembly spec; link there, WebAssembly/spec#1300. And the key thing for this specification draft is that the web assembly integration requires. Is that webassembly vended array buffers currently So currently there is a webassembly API called webassembly.memory where you can either from JavaScript make a new webassembly memory or if you already have a web assembly module you get a wrapper around the webassembly memory reflected via an array buffer. So there's currently already a webassembly.Memory API and array buffers that are vended by the webassembly memory API have more restricted behavior than JavaScript user-created buffers. Among other things, for example, they cannot be detached normally. They can only be detached by webassembly APIs. So for example if I transfer webassembly that vended array buffer that actually cannot be detached by web APIs it can only be detached by webassembly APIs. to integrate resizable buffer into the webassembly similarly, the resizable buffers are also more restricted than JavaScript-made buffers. Webassembly memories have more restrictions, such as that they can only be sized in page size of multiples of the webassembly page size, which I think is 64k. They cannot shrink, and if they are resized, if they grow, they can only grow in page size multiples. So to kind of handle that the current specification draft has a kind of HostResizeArrayBuffer host hook where an implementation can provide overriding behavior for how it should handle the resize. Of course there are restrictions like if you successfully resize the requested byte length must be reflected on the buffer and there's this short circuiting return value. So if you return handled and default resizing doesn't happen because the host already Took care of it with the additional restrictions. DE has recommended, or maybe just throwing out an idea, that maybe this just shouldn't be a host hook because this is not a thing that hosts do uniformly across like all implementations if I understood his concern correctly, and perhaps it could be a new pattern like the implementation just writes a custom resize method into some internal slot or something that can be reused. But again, this basically only exists for the webassembly use case. Ostensibly it could be useful for future lower level web APIs that may vend their own kind of buffers with additional size restrictions as well. But currently there are no other use cases except webassembly.
SYG: I presented the integration PR to the webassembly community group it reached phase one. So they have a phase system, for those unfamiliar, that is inspired by our stage system. The difference is that when they advanced phases, they do take a formal vote between five options of strongly favor, favor, neutral, against, and strongly against. Among everyone present the call were either strongly favorable or favorable for this (??) PR and the idea is that they are now waiting for us to advance this proposal to stage 3 after which I will go back to the WASM CG and they are happy to fast-track the pr 2 phase 3, which is also their implementation phase. So the conclusion here is I think there has been good progress made on the web assembly side for us to advance to stage 3 for this proposal.
SYG: and the final update, the final action items is whether we should go with global or namespaced constructors. So a quick recap. Namespaced constructor advantages include things like - some folks, notably JHD, think that it is a tidier way to way to organize things. and I think we heard from moddable last time that new globals do incur a very small memory cost in ROM and namespaced constructors would not. I don't quite understand why, but they have surface this concern. The disadvantages of a namespaced thing is that there is really no precedent for these kind of namespace constructors inside other constructors. We have for constructors inside namespace objects like Atomic and math, but I don't know if we have I don't think we have structures inside math, but we have namespace objects, but we don't namespace constructors inside other constructors, and there is the possibility for confusion therefore whether they should get the same prototype or not. I think the reasons for a global resizable array buffer, I think is this is really just how everything else in JS is organized. We don't have ArrayBuffer.Shared and we don't have Map.Weak and we don't have Error.Syntax Etc. We have SharedArrayBuffer, we have WeakMap and we have SyntaxError. this is a (??), but I after the last meeting I did run a quick poll that I publicized on Twitter and internally with some other Googlers for where the constructors should live. The pie chart there is a little bit confused because I messed up the options in that people were initially confused whether the namespace things were in fact Constructors or static methods that return new instances, so I renamed the options Global Constructors namespace Constructors. So that's why you see four colors. And so there's two colors, but you can still kind of see that so that the global would be the blue slice plus the orange slice namespaced would be the red slice plus the green slice and you do see that overwhelmingly people do prefer the global constructors. There was also a free form response field where I where I said if you know if you want to say why you prefer one or the other please say and I did see some some signal that people were confused and in a way that I thought they would confused, which is that if is that if I have a namespaced constructor such as SharedArrayBuffer.resizable, there is some confusion that, well, it's namespaced under another constructor, so is this supposed to give me a proper subclass? This was to give me the thing that's actually a SharedArrayBuffer, but currently this proposal doesn't. It's not like that kind of properties of my thing is not that special instance of SharedArrayBuffer. That's special configuration. It is a different thing that share some functionality but it is not really like at the language level. Or the implantation of already (?) at implementation model it is but at the language level it is not a shared buffer it is a resizable shared array buffer. So given that, I as the champion prefer that we stick with the global constructors and not go with the the namespaced constructors.
SYG: And finally, I want to highlight this this question that CZW asked recently like a the past they are so on the repo about the length parameter for the transfer so So recall that there is also as part of this proposal a transfer method on the prototype for both resizable array buffers array buffers. And this transfer method what it does is that it takes a new byte length as the sole parameter and then it returns to you a new array buffer of that byte lengths where the contents of those byte length, the contents of the source buffer that you are transferring, the contents of that are preserved in the array buffer that you get back, the source array buffer is detached and you a new array buffer. This is basically realloc for folks familiar with the C API realloc. And (?) ask the question if resizing array buffers are already resizable why this transfer even take at length parameter, and the reasoning there is that we're also adding variable for transfer. And that array buffers obviously cannot be resized. and that the implementation strategy for resizable and transfer could possibly differ from the chained calls of resize and then a transfer that doesn't take a length. Because resizable array buffers are designed to be resized in place and it's designed to allow implementations to have a strategy where the underlying data pointer does not change by reserving virtual memory up front and the transfer semantics are designed to be realloc, where it there are no restrictions on whether needs to be in place or not. It may be in place. It may not be. And there's no allowances on the language side to make it easier for it to be in place. Right? Like you actually get a different array buffer back with the old one detached. So I do think that these two serve different use cases and I don't see any reason any compelling reason to change transfer to be parameter-less, just a transfer of ownership by detaching the old buffer kind of operation. So sticking with the current transfer API as proposed. like the point of resizable array buffers to surface the idea of an In-Place resize where the identity of the array buffer does not change as you need to resize it there exists other use cases where you want to make a different length arrays at different lengths buffer that has the existing content success that because the current one and currently the way you have that is you have to actually copy where you have to actually make a new thing and then you have to you have to copy over the contents that you want. And then you throw away the old one. And transfer is designed for that use case where maybe you can be a little bit more efficient, where if you actually need a new buffer you can have that transfer plus resize in the same same API call/ So tldr there is sticking with the current transfer API.
SYG: All right with that I'll take any queue questions. There hasn't been significant changes. I pointed out the spec changes since last time, which is basically reverting the max size rounding and adding this host hook which only affects webassembly. And that host hook might be changed to another mechanism, but I would judge that to be an editorial concern.
CZW: Yeah. Okay, great. And you just mentioned the size of the new place real locations from the perspective of the language. However, that impresses itself is that ability isn't reflected in the spec text. so the behavior is not observable from JavaScript and we have discussed. So that makes the prominent feature not significantly different from in-place or copying reallocations. That is to say, in the spec, there is no significant difference between what ResizableArrayBuffer and ArrayBuffer transfer can provides.. That makes assumptions array buffer prototype transfer provides a generic resizing feature that is not a very different thing from the resizable array buffer we can provide a generic reallocation feature not orthogonal to resizing purely regarding the spec.
CZW: You mentioned that resizing in place is not enforced in the spec. There is no such assumptions. So that makes the question about the orthogonality theory still there.
SYG: I'm not sure I quite understand the concern there is aspect difference for the in place resizing in that the in place resizing does not change the identity of the source array buffer instance. but the transfer method gives you a new instance back. So there is no - from the observable point of view, the thing you can observe is the array buffer instance and resize doesn't change the instance and transfer changes the instance.
JHD: The freeform survey response. You talked about the naming confusion and you had .growable with a lowercase g, or that was what this the respondent put in, I believe. I would agree that if it was some constructor and got a function name that doesn't start with a capital letter, I would expect that to be some sort of factory that produced a new object. I would expect it to be an instance of the Constructor as if it were a namespace, but if it was a capital G by a very universal convention I would not expect that is a factory method, I would expect it produces something totally different. I see that there's a possibility of confusion with anything we pick but I think that for most people when they see something that starts with a capital letter they’ll think it’s a constructor.
SYG: That's a fair criticism. My initial polling options, I went from your from our thread on the GitHub issue and the poll options did use lower case and that made the signal much weaker right from the pole, but you know, I think my reasoning for sticking with namespaced - this slide is still what I come back to for why I prefer a global. It would just be a break from everything else that we do.
JHD: Would it be? Just curious. What are your what would your thoughts be if in fact like compared to if everything had been built in this way?
SYG: If everything had been built in that way, I would do namespace no questions.
JHD: So to be clear your preferences here is about consistency not about one pattern being inherently better or worse than the other necessarily.
SYG: That's correct. They're the kind of interrelated, right, if we had namespace constructors like Map.Weak which gave you back a WeakMap, which is a completely distinct object from Map, and that was already the convention then I would certainly organize resizable array buffer as ArrayBuffer.resizable, but given that we do not have that and that we would have to make new precedent here. I don't see any compelling reason to do that here for this proposal.
JHD: another follow-up question: if SharedArrayBuffer didn't already exist, and this was the first other kind of ArrayBuffer, even though there wasn't precedent with the rest of the language, would you be more inclined to Nest it?
SYG: So if SharedArrayBuffer did not exist. I think that wouldn't actually change my opinion. This is why I included Map.Weak or Error.Syntax right like that if you know if there were if shared array buffer was kind of the only instance if there's a Singleton right now where it's like we had a thing that could have been named space, but we didn't do it I would think I would be I would feel much more weekly here. But as I looked at the other constructors that we had I found more examples.
JHD: Okay. Thank you.
BFS: I just want to kind of re-emphasize that I agree with Shu here. Consistency has value and merit on its own and I think trying to make unique decisions on everything just makes the language more confusing even if from a standalone perspective might state that a exception is useful, I think doing things based on precedent is in to be easier for learning easier for understanding in general how to find things on your own, that kind of stuff. So yeah, that's all.
PHD: I just quickly wanted to agree with the points each JHD raised before moving on. I want to back up a little bit because I think there's been some misunderstanding about Moddable's position here. And so I'm going to provide a little background before getting into the details. I apologize for the time that takes. Moddable has supported this from the start. It's meaningful for the work that we do in our XS engine, the design here is solid and Shu's work on the proposal is excellent. We supported this despite some of the limitations that are related to implementation rather than language design and that generally expresses itself as the separate prototypes and constructors. The growth of the globals is a concern for us and I'm going to try to explain that briefly. Some engines, I would say all the web engines at this point, have a very strong focus on performance and security. The security concerns of V8 specifically have motivated some of the design here and that's fine. We understand that making certain implementation choices was a blocker for V8 for security reasons, and we didn't challenge that. It's worth understanding or restating that in XS. We certainly care about the performance and we certainly care about security, but our first priority is actually on resource constraints. We run on devices with a tiny fraction of the speed and specifically memory of devices that other engines run on. RAM is a big issue and each built in global that we add takes some additional RAM for each active virtual machine in Shu's slides. He misstates ROM, he said that was confusing and I agree. Everything takes some ROM, but adding globals globals does take RAM whereas as adding a namespace constructor does not. Getting into the details of why that is is out of scope here. And looking ahead to things like compartments which we hope one day will be part of the language also would consume additional RAM for each additional Global. So we see that while each individual global is a small concern, but that the combined impact can be significant. And again, as some perspective we run on devices with as little as 32k of memory. And so really every single one of those bytes is something that we're concerned about. Argument that's been given strongly in favor of global constructors is past precedent. And that's fair. We're also concerned about the future precedent, effectively close the door to namespace Constructors here the doors already been closed. used on bringing new functionality through the use of modules using for example standard Library mechanism. That's unfortunate, but that's reality, but that also means inevitably if we establish this precedent here we are going to see many more globals and we'd really like to have a way to tame those, because it's important to XS to be able to minimize the RAM news. So I'm generally supportive of this proposal, but I'm not at the moment supportive of moving it to stage three until we can address this. There's two options. We can certainly address it through the specification. I understand Shu's preference lies elsewhere, but perhaps. The alternative is we can do what we've done in other cases where browser engines have expressed reservations because of the ability to implement something in a way that's consistent with their goals is we can take some time and we can look into mechanisms in XS that may be able to handle this without the RAM cost. It's not something we've considered, but we're certainly willing to pursue that if that's the most viable path to consensus here.
SYG: Thanks. I hear you on the future precedent part. I have a technical question. My confusion here is, supposed it was namespaced under array buffer. Why would that no longer incurred the ram cost in moddable?
PHD: Good question. I'll give you a short answer and if it's not sufficient, I'm happy to take that up separately in the form of your choosing. Globals are writeable. this as a general rule in so we have to maintain the value of each global for each VM in each compartment in RAM. The properties of objects, the functions hanging off of a Constructor, we're able to keep those were able to freeze those effectively. They're immutable they're stored in ROM, and so they're writable and because those right right like that,
SYG: even if it were namespace did would still be writable.
PHD: No, it would not be right to vote because we freeze those by default and we can't freeze the globals by default. It would be actually an application choice to freeze it.
SYG: and you cannot apply the freezing to globals?
PHD: We do not do that currently as I said, it's possible that we could resolve this through implementation work, but it's not something that's been explored.
SYG: I see. I am uncomfortable with this being a blocking concern. guess given the some of the partly but given that lead time that this discussion of global versus name. has been for a while, and now that I understand the concern better, given that the way that you deal with the RAM verses ROM constraint is to deviate from the specification.
PHD: Anyway, it's not a deviation from the specification, any script can call freeze.
SYG: I see what you're saying.
PHD: As far as process, I mean we've raised this sometime back and I apologized that It wasn't entirely clear to you. But you flag it in your slides and didn't follow up with us to better understand it.
SYG: That's true. All right. Okay, so in terms of next steps here for resolving this issue it also sounded like you want whatever happens here to a precedent for future things.
PHD: Well, I think what I'm saying is it will set a precedent. It will certainly be cited in future conversations. And so, you know, I don't think I don't think it's fair to say that this would be a one-off decision. I think we Took a decision with regards to standard library that pushed us down this road a bit and I think we're now seeing one consequence of that and that that I think we should be a little bit careful in establishing future precedents around that.
SYG: I would like to discuss this more if we have time here because I'm still not sure what the next actionable thing for me is it sounds like I should you know, if Inaudible is is willing to commit some exploration time to see if the freezing thing can can work for them. But yeah, I would like to hear other thoughts here if this no, mean yeah, if this implementation concern for this implementation technique, which is model-specific should inform this larger organizational how we organize our Constructors decision. Yeah.
PHD: I'm not proposing a specific implementation technique you asked why it wasn't an issue. What I'm saying is that there was a RAM cost here, which is a concern for a fundamental aspect of our engine. I don't think that's any different than when Google expresses has a security concern or when Mozilla expresses a performance concern, that in many cases we've been this committee say, okay you need some time to working on the engines to go and look at that and I don't think we're asking for anything more or less than that, and we're doing that in good faith as a way of saying we're actually willing to invest time to try to support your preferred Direction.
SYG: So to be clear, I'm not saying you are saying that we need to do a certain implementation technique. I am pointing out that in that in the past. When performance concerns have come up including from V8. Sometimes when we are the only ones such as in the initial stages when we were trying to implement match indices in recent memory. We hit something that will maybe we could be clever and do better and explicitly held off asking for any changes until it got more widespread issues with implementation until for example Apple confirmed that they ran into similar issues. So well, I think what I'm pointing out is that this that Moddable's implementation technique is unique currently and I would like to hear - I don't know, I guess I'm uncomfortable having this as a blocking concern assuming that it cannot be resolved through implementation exploration here on your part have that a blocking concern for the organization and set a precedent for it. organization of global constructors without additional implementation feedback like if it is a unique problem to your implementation. I find that to be less compelling than if it is a problem for many implementations.
PHD: Well, I think our priorities are different and the fact that there are not as many engines with the same priority I don't think invalidates the concern.
PHD: I don't think there's universal consensus that global constructors are the best choice. I think there hasn't been super strong objections that they're an odious approach. So I think that's another option that would allow this proposal to move forward, but I understand you have a strong preference to move forward with global constructors, and I think we're showing some flexibility in being willing to explore how we can support that and I'm a little bit troubled that I feel like I'm trying to be cornered with the position that well. We're the only engine that has this priority and therefore that's not a valid concern for this committee.
SYG: I'm hoping to hear from other folks here as well.
BFS: So we do actually see these kind of objections not necessarily purely on the VM level but also on just ecosystem impacts or usage of the language itself in things either through the web or through node and that kind of stuff. Moddable is the main representation we have on committee for Internet of Things. So I think stating that an implementation has a problem therefore it shouldn't shouldn't be blocking is little concerning to me. We've identified a real concern that would be a problem in stage 3 so doesn't make sense really to me to go to stage 3 because we know it's already a problem. And so either finding a workaround or giving time so that they can figure out how it won't be a problem in stage 3 makes sense. We've seen this kind of the opposite happen sometimes where we ship things too fast. So like one that is kind of a sore spot for me is how quick dynamic import landed in spec. We've tried to go back and address some, you know, not bugs, but bad behavior of dynamic Import in the committee a couple times due to how in particular node can't do some virtualization of it very well, stuff like that. So I don't think necessarily we should move it to stage three, but it sounds like there's a clear path to stage three either through this research that unblocks your preferred path, Shu, or taking the alternative path seems fine to me either way, but I wouldn't want to go to stage 3 if we already know there's going to be an implementation problem. So like this is something that could prevent apps from being able the ship for Internet of Things devices, that doesn't seem like a small issue. That's it.
SYG: Is that actually true? I've got that'd be great confirmation.
BFS: eating up more RAM can stop stuff. I've got several apps that are right near the ram limit on some ESP 32s.
SYG: Okay. Thanks.
DE: aside from the moddable specific implementation issue, I think it's quite reasonable to have these constructors be namespaced. We have a namespaced constructors already in Intl and Temporal. These would be namespaced a little differently, but I think it would be pretty intuitive for JavaScript developers. I'm not really concerned about setting too strong it will a precedent because still be deciding what to name constructors and where to put them on a case-by-case basis just inevitably and there would be no indication. They can't add any more globals. That doesn't seem like a reasonable thing to take away from any decision here. It is something that comes up in multiple environments that when globals are added it potentially has compatibility problems or upgrade cost. These are pretty unique, but overall I don't think it's unreasonable to make things namespaced. That said, this quite a scoped decision. So I hope that if we don't come to conclusion this meeting then we can come to one next meeting because this is a very well understood problem space. Genuinely I would be okay with either outcome.
SYG: Before we change topics here, other than myself - and I would like to think of myself to swayable person - other than myself, do other delegates have strong feelings about these being global instead of namespaced?
BFS: Not a strong opinion.
KM: I somewhat agree with Shu here. I don't know how to say it exactly, so I may need say it a few times. Since moddable is so different from the other implementations that like it's harder to get the same sort of feedback that we have with the web engines for instance where like, you know, say hypothetically like we [JSC] say something is impossible to do and then some other engine like V8 and spider monkey both say that it's like not an issue It's easier to say well then it's probably just a specific thing to JSC and we should figure out how to make it work, something like that. Since moddable is so different from other web VMs it's a lot harder to say what is an implementation issue without experimentation on their part, if that makes sense. And I think having it block the decision to add the general use of global constructors these bits somewhat concerning I think there are probably inevitably going to be a bunch of APIs over time that just want to be Global Constructors. And so I don't know if that's like avoidable.
MM: So first of all, I want to clarify something and then I'll state my strong opinions. First, the ram cost is of having a global as more complicated because an issue that Peter mentioned but didn't emphasize, which is there is a global variable or global property per compartment her compartment because it's per global, whereas the the something that's namespaced the name space object itself a shared primordial that all of the compartments within one realm share unless it's something like Temporal that has to be per compartment because something powerful was included in the namespace. The strong opinion here is that, we knew that the pollution of the global namespace was going to be an urgent problem, which it is, and that was much of the motivation for trying to introduce built in modules into the language. Once built in modules failed, we are now in the dilemma that was avoidable. and I think that this particular set of global constructors versus namespace. I don't have a strong feeling one way or the other on it, but on the general precedent issue I think we should be open to namespacing things, because having rejected built in modules, to not start namespacing things is to really make the pollution of the global it really painful immodularity issue in the language.
KM: I have a question on that. So what a naive solution for if the property tables are have to be in RAM, it seems like you could just have them be effectively copy-on-write where they all share the same, like I guess that wouldn't work because they're different objects, but I still - if the object is frozen. It's not clear how you could tell the difference anyway.
MM: So with regard to the copy-on-write, I'll leave that for Peter because it has to do with stuff below the JavaScript level of abstraction, I mean below the level of the language definition. Regarding the semantics of multiple compartments, the properties on the global are necessarily own properties. We can't share them by having the globals inherit from a ProtoGlobal or something because the semantics of not-own vs own properties are too different.
KM: I guess I can't see how the namespaced thing could be in ROM, but the global property couldn't be in ROM until someone tries to modify it.
PHD: it's I mean Keith happy to get into that. There's an aliasing mechanism, which is slightly what you described, but it has its own complications to apply in the case of globals. As I said this this may be resolvable through implementation work. And we are open to exploring that as an option.
YSV: I just wanted to say that I do think that it's appropriate what moddable is requesting, which is to delay the decision until they have had time to validate that this is solvable within their domain. We don't have any other engine representing Internet of Things and they bring a unique perspective to the committee. And as far as I understand the course of action here would be to take Shu's preferred approach, which is a new Global, and see if they can integrate it in their engine without significant costs or significantly undermining any future efforts that they may be planning or trying to do. I think that this is actually pretty reasonable. It doesn't put a lot of strain on to the champion, beyond requesting more time to validate something and I would like to see that honored so that say if we move this to stage three, and it is found to be a significant problem, then we don't have to go through the work of you know, we have three implementations that have already implemented it one of them that happens to have a unique setting, a unique host, and they are unable to implement it but this would be needed functionality that is essential we're suddenly throwing one use case under the bus. If we can avoid that I think it would be great. I think also I wouldn't see this necessarily as setting a precedent. I think this is highlighting a larger problem and a very specific case of this problem that we may want to reference later and find a true solution. But rather we can solve this just for this case right now and then see what we do about it in the future.
will overflow to discuss remaining queue items
Presenter: Robin Ricard (RRD)
RRD: Hi, I'm Robin. I'm the delegate for Bloomberg and today I would like to introduce change array by copy for stage 1. So first a little bit of History. Change array by copy is actually derived from the tuples proposal. We wanted to introduce use all of the methods that we added to other prototypes inside of arra dot prototype, and we asked what would be the best way to do so, and we agreed and understood that the solution would be to do a separate proposal. So both proposals could have their own value in the prototype. And just as a quick reminder regarding Tuple, it is immutable data structures in JavaScript that are primitive types so they don't have identity, and being immutable in order to derive a new version of the Tuple you would need to use methods that return a new version of the tuple.
RRD: And so the methods that we actually added to to prototype are the following: popped, pushed, reversed, shifted, sorted, spliced, unshifted, as well with, and we'll go back to with. We would like to add them to array dot prototype and typedarray dot prototype and we all call them call them mutator methods. So essentially if you have a mutator method like push you're going to want to have a non mutator method like pushed but which will represent the state of the array after performing the operation on it. So pushed will not return the element but will return the array we have element, but essentially so hence the naming and hence this past tense. So we already established that On Tuple and basically warm that would support them to array and that array because we found out if you'd be very practical if we can't write functions, for example that are able to manipulate both tuples an array like with is the odd one out. Here is with: with is a way to change a value at an index. essentially replicating an assignment operation but in a non-mutating way and we have a few others that we did forget to put onto the Tuple prototype which are filled and copiedWithin which are the equivalent of fill and copyWithin, those two method we do plan to put them back into Tuple dot prototype for consistency.
RRD: Okay, so to just quickly give you an example right there. Is essentially before would you doing is make some how to copy here, I would use array spread, but you could use dot slice for example, if you wanted to create that copy, and so you use that your cookie operation then you make Actually mutating operation on it. So in the case of sorts sorted action remove the need to make that cookie and in the case of an assignments specifically with with right now, what you can do is also use negative indices in order to assign at the end of the array, so that is already possible with tuples. And so that should be possible with arrays as well. and very similar to the at method that is planned to be added.
RRD: status of this proposal, it is at stage 0 right now is that we have a spec draft that has been started. We know that it's not completed, we know that there are issues with it. Thank you JHD for pointing them out, helpful with your review here. We will hopefully get to those well before stage 2 .then comes the question of the polyfill that we have working for the field that we also have some tests on that then what is more concerned if we were to get to stage one is the web compatibility issue. We are aware that adding methods to arrays and typed arrays can be problematic. And so we talked about it in our regular record and tuple meeting. So we had listed a bunch of propositions. First of all as champion of this I really like the copy + past tense alternative if this different one would not go forward, which would be copyPopped, copyReversed, etc. That being said I'm completely open to any other Alternatives and for the web compat aspect of this. I would like to start engaging with this presentation with the implementers and see if this is possible to talk about it in an incubator call. Then comes the question of sparse array handling. And so that something that also took part in the record and tuple meeting. We would prefer not to preserve holes, even if that not make this these methods not as a drop-in replacement to let's say that slice that sort for example or good slice of three verse which would preserve holes. I would prefer to fill them with undefined. The rationale behind this is that there seemed to be a coherent trend with not handling them recent proposals, es6 array methods ignore holes. Finally the question of species and so as part as what reports so far. We are probably going to keep them because there seemed to be a real from intention to removes then as far as removing the guilty at all suppressing and if anyone wants to disagree on this feel free to reacts.
RRD: then I just want to quickly remind interaction with record into both so you get the idea for this proposal from regarding Tuple, but if you make any change to the name, very very quickly this will be reflected in tuple dot prototype. And so ultimately the complete plan would to ensure alignment as a stationary condition for both sides.
MM: Okay, so I want to say first of all I'm very very much in favor of this proposal and think it's great. Especially like the point you made at the end about keeping the two APIs in sync. There was something that you said that confused me about with being an outlier and you said something about assignment in the same breath. Does Tuple not have a with with the same meaning?
RRD: It does, It has the exact same meaning as in tuple. It's an outlier in the naming, not in the semantic.
MM: Gotcha. No problem then, I'm completely in favor.
RRD: Yeah. Sorry that That was wrong poorly worded. Yes. Sorry for confusion.
MM: Oh, and I also support filling in holes with undefined as of the as the better way to deal with holes going forward.
YSV: All right, so one comment that came up for us is, for some of the methods this really makes sense, it's a great idea. For example, filter, sorted, and reversed come to mind immediately, but those are operations that would have been O(n) anyways and making this copy operation makes a lot of sense. However for some such as popped and others that are effectively O(1), this may in fact introduce a foot gun. Specifically I think that what we all expect is that people will be moving between the mutable forms and immutable forms quite a bit like from array to tuple for example, and one of the reasons why they might switch from tuple to array may be a performance issue and the expectation might be just a we can just globally replace and keep all the methods the same, but in this case they may fact incur costs without realizing it, whereas not having those methods may actually point them to needing to change something in their implementation. So this is a concern that we have, but overall we think that introducing some subset of methods you highlighted makes a lot of sense. I'm wondering if we should be a bit more particular about which methods are selected.
RRD: I see the points and honestly we wanted to do all of the methods mostly for coherence reasons and having an ecosystem that is coherent here, but that is potentially a footgun. That being said, maybe we could explore the avenue of naming for highlighting the footgun, namely if the methods were named "copySomething" that would point out that there is - I wouldn't say danger, but there is an expensive operation going on. So yes, I read this is something we need to think about and I am probably going to open a community issue on this. And because we need to talk about that.
RBU: I think that this is a valid concern in that introducing functions that people would like to use more but isn't doesn't actually satisfy the use case and does more work for no reason it would is not necessarily a good thing. What I will say is that I think it'll be worth investigating during stage one usage patterns of existing mutator methods that are constant time because I imagine that Most cases will- specifically with like push or pop to return values are different between the past tense in the present tense versions. So it's not quite simply a swap and it's a different interaction style like the way you think about using them is different. So I could envision a world in which people start to use pushed because that's what they see and that's what they just like to use, but I don't really think it's going to cause a drastic shift in the ecosystem of people suddenly calling pushed instead of push because push is still convenient if you need to mutate an array, but I think it's definitely worth investigating as part of stage one.
DE: Yeah. I think it's already quite common to do linear time operations on arrays in JavaScript where we have things like the spread operator. While this concern is legitimate. I don't I don't think it really creates a new concern. I really like Robin's idea of naming them to to emphasize the linear time quality of them.
YSV: I just want to clarify this isn't something that will block stage one, for sure. That's not a problem rather. It's something that I wanted to highlight so that we thought about it together and weighed the pros and cons. I like both suggestions that came up explicitly having coffee in the name and also Rick button suggestion that we maybe investigate other ways to to have very similar functionality between array and Tuple maybe with different functions. Melody but maybe that's a problem. I haven't thought about it too much, but I'm very much in favor of an investigation here. Yeah, I will I will continue she afterwards next up. We have Kyle. I can hear me. Yep. Awesome. So I just would like to also be in favor of this proposal. So using the same argument that we have. So right now we have typed arrays and arrays that prototype I landed and at least maybe cannot be the best mental model to have but I think temporary care you. Maybe it's not like a very precise they made some other but I think turbo is kind of an array like a structure that we type that we would need to do some JavaScript so aligning their prototypes sounds like a very idea to me. Besides that, I think some of those methods are actually being used as already by some user libraries. For example, lodash. They already have those of those methods as a tool to be used. So there seems to be also a lead from your point of view. view. But yeah.
RRD: Actually you're raising good points. We also did some research into other languages and I should have put this in the slides but it looks like that Swift is doing a similar naming as we're doing here.
JWK: [via queue] in support of this
SYG: Go ahead. Right, so I could be call sounds great. I was wondering what were your plans any plans you had in mind for investigating compatibility because we know you know, especially a re.prototype out of all the building prototypes. We have had the most amount of trouble with adding things to that outside of kind of ship and see which is unfortunately how we discover ultimately the incompatibilities. and for these many methods that could incur yes cost of the vendors
RRD: I have to admit. I'm not very knowledgeable on this and so where they were strategies you might have done in the past on this. Yeah, I would be happy to read up on this and contrary to devise a strategy that is similar to what has been. I'm doing the best for if there is none. I can try to think about something brand new.
SYG: Okay, sounds good. I would encourage I guess that the for determining the web compatibility the party that's going to bear the most cost is whoever ships it first. Yeah, and I would encourage you to reach out to folks to figure that out. Maybe even the burden somehow.
RRD: I will reach out to implementers in general so I will probably get in touch with you and YSV soon and see what we can do.
DRW: Robin it looks like the queue is about to be empty and I don't see anyone clattering to add themselves at this moment.
RRD: Asking for stage 1.
DRW: any objections? I do not see any objections, so it sounds like you have stage 1. Thank you. Thank you, Robin.
Presenter: Tierney Cyren (TCN)
TCN: This is object.has again we're going for stage 1 so before this proposal are presently to kind of get property on an object. You're going to need to call. This is kind of a common approach to doing this safely is assigning object.prototype.hasownproperty.call then do it using duck call to get that. this ends up kind of being a little bit boilerplate - its repeated throughout the ecosystem in many different places after places after this proposal. Object that has with the objects and the property name, you know a lot less boilerplate ish and overall just a lot cleaner our Our motivation is one that there's a massive amount. There are a number libraries with a massive amount of debt that effectively do this with this exact same API in different ways has The module has is most notable; JHD is one of its maintainers. It has a lot of downloads hundreds of millions of downloads across all of these and the API for them is all effectively the exact same which is what object that has proposal is proposing introduced object are create created objects with know as the as the parameter creates an object that does not parrot has a property from the object prototype, which makes hasownproperty an unreliable tool when you're not in control of the object that's being that it's been called on which is common in library code and this can kind of lead to the aforementioned boilerplate further. You can't always be certain that hasn't property will function as you expected, you know as it is as is as happens with prototypal inheritance. and so, you know again this leads to the aforementioned boilerplate yes lint also has a rule against prototype built-ins. So this is kind of more from TX perspective in the ecosystem. It is a recommended rule in the eslint. So if you import recommendations into any whatever your preferred linter is or if you use the recommended defaults, this will have an error if you're doing the built-in has a property. And it is also an enforced rule in the Airbnb JavaScript style guide which you know still accounts for a large amount of eslint consumption. And so, you know, that rule is relatively widely used in the ecosystem kind of indicating that this is this specific path is again another one that will lead to that aforementioned boilerplate. the MDN documentation reflects similar sentiment around using hadOwnProperty on an object directly. So you it suggests to use an external hasOwnProperty which again leads to that aforementioned boilerplate. The proposal here is to add object.has which you know is the same exact same behaviors that the intent is to have it be the exact same as as calling an external hasOwnPoperty. So each of these code examples would be the same as if you were doing that boilerplate with hasOwnProperty or object.prototype.hasOwnProperty.call with the parameters here. Yeah, so this intentionally exactly the same just with you know, a more direct API that is less confusing or a more direct way to approach it that is less confusing this, you know, there was relative excitement when this was proposed a lot of people were relatively interested in this, so just wanted to give that social proof.
TCN: Some frequently asked questions: why not object.hasOwnProperty with the object in the property? That already exists because object inherits from itself, so that can be actually be susceptible to some of the aforementioned issues. Yeah, so this is kind of not at this is a no op. Why the name has? “Has” is seemingly the most common choice in userland implementations every single implementation on NPM uses has or exports has: the has module itself, lodash, underscore and so on. in addition to smaller implementations all export has. hasOwn is an alternative option so that's a different one that could be used. There is an issue discussing that issue #3, which you will you know that issue. There's an issue in the repo. So in The Proposal repo issue #3, which has discussion around this and discussion around the comparison between object map and set and also I believe reflect reflect.has and some of the intricacies there. But yeah, this this proposal also feel by using object that has it also fills a missing a gap in the comparison of object mapping set as you can see the bottom of the code example here so hasOwn would kind of create an additional gap but object.has been exist, but object that has own wood and then map and set wouldn't have hasOwn. So it also kind of helps round out. The API in that way why have a one-to-one match of has a property semantics and functionality most of the user land Implement libraries that implement in exactly that way. It's all the same. Every single one implements it in this exact way. So that's a pretty good indicator that has is the correct API just that it's not the most perhaps the best way to expose that API there seems to be no deviation from that API in the ecosystem. Details: there is spec text. It's published to GitHub pages on the proposal. You can also find it in the proposal repo. So in the pages of the proposal repo there is spec text; happy to have reviewers on that. I'm sure there's things we can improve. You can also find a polyfill in that repo. It's a relatively straightforward polyfill and we’re seeking stage one. Yeah, and I have some some links to share after that. Yeah, we're seeking stage one on this.
JHD: I am strongly in support of this proposal. There's a bunch of things in the language that care about own-ness, so in is just insufficient (object spread and rest syntax, for example) - so I'm really excited for it. I'm not particularly attached to the name. So I'm comfortable with has or hasOwn; either one is fine with me. I think that it would be really useful to consolidate the entire JavaScript ecosystem of has-like packages or {}.hasOwnProperty.call or Object.prototype.hasOwnProperty.call patterns - to push towards one nice clean pattern.
JRL: So just want to voice support for the fact that the hasOwnProperty being on Prototype requires beginners to Object.prototype.hasOwnProperty.call. All of this is a mouthful and beginners either aren't comfortable with doing it or don't know how to do it. And so this leads a lot to the buggy code where they unknownObject.hasOwnProperty('foo'), even though they don't know it has hasOwnProperty method. We're users of the eslint rule that prevents you from doing .hasOwnProperty because of the bugs its caused. It is much much easier if we have a static method on an object or anywhere else that allows people to do it without the full property prototype.hasOwnproperty.call invocation Style.
YSV: to start I just want to say that I really support this proposal has owned property can be very tricky to use and I love the idea of simplifying it. This is largely about by shedding and before I get into the byte shouting naming stuff. I support stage 1 so the bikeshedding bid is we do have a method on Route the reflect object called has which does a prototype chain look up. And this will be inconsistent and possibly very confusing the other place where we use has in the spec is we have a proxy trap called has so this points towards maybe choosing something like hasOwn but beyond that I don't have a strong opinion about what the name should be. Other than probably we want to choose something else.
TCN: okay, I do just want to say to that in the in the repo there is a relatively lengthy discussion around at various that has and then also mapping other things like entries and stuff like that. You know, it's a relatively lengthy discussion. I would really love more input on that just to get Just to get that kind of flesh out and get make sure we can get consensus on that relatively easily. That's issue #3. but yeah happy to continue working on that and find resolution there.
JHD: [via queue] most people don’t know about Reflect or Proxy at all.
CLA: I just would like to like second what YSV just said about Reflect.has. I am very excited about this proposal. I was just wondering if you ever take a look into compatibility issues Object.has and the environment of user land implementations.
We have not. I am happy to figure out how to do that and to go do that. But yeah, I don't believe we have now.
MM: Yeah, so I want to once YSV pointed out that the conflict with Reflect.has, register that I feel strongly about that. I do not want to right now. There are some methods in common between reflect and static methods on object and for each of the existing ones the semantics are very very close to and understandably will how they understand it, and how they relate to each other the other analogy that Like it was a strong argument for has was Keys values and entry and when you first put that up it seemed compelling to me until you mentioned the thing about enumerablity and symbols and since the proposed operator includes non-enumerable properties and includes symbol name properties, it would be misleading to name it in such way as to suggest that it's part of a group with keys, values, and entries in parallel to the way they relate to each other on collections. So for all of these reasons I think has is disqualified as far as I'm concerned but hasOwn looks great.
MF: I wasn't actually planning on saying much but on the table there when introducing saved one proposals that's phrase them in terms of the problem. We're trying to solve and I see that we're already getting to a point where the current title of the proposal is not looking valid anymore. So lets the both at the time we agree to move it to the stage 1 and at the end in the proposal document let's phrase it in terms of the problem.
TCN: Yeah. Okay. Yeah, I appreciate that input. I will it seems like there's pretty overwhelming support for has owned and quite a few - ones for has so we will We will go ahead and reflect that make sure that's good and then reflect that. Cool. Looks like there's 2 new speaker things. things so go ahead.
LEO: My question is not blocking stage 1 at all. I'm fully supportive to Stage 1 for has proposed for right now or hasOwn it's just showed question where whether we should be having object has on and object has but it should not be we don't have time to answer this in this Milling suggest some button.
JHD (copied from TCQ): there's spec text; is there a reason we can't go right to stage 2 with hasOwn?
TCN: Interesting. Okay. Yeah, I see I see your point. I had to take second to process. Yeah, that makes sense. I think that would probably be good. Is this a proposal to JHD’s question? I do kind of want to go back and look because of sit like because of the gap that and make sure that like this is something that we were okay with skipping and make sure that you know there's not other other areas that are going to conflict with hasOwn or you know, if that's going to introduce anything weird, but go ahead and do you think
JHD: figuring out names is a legitimate concern to figure out during stage 2, before stage 3. Given that everyone seems to be pretty on board with hasOwn for now and given that the shape of the API seems pretty straightforward and given that there's already spec text that is three lines (if I were a reviewer, I would call it reviewed already). Is there a reason we can't just jump to stage 2, and then figure out the name at that point? We can still take as much time as we need before going to stage 3, and before the time people ship it. If that bothers people we can just call it stage 1 obviously, but I just wanted to throw that out there.
TCN: I mean, I'm not going to say no. All right.
AKI: So any objections to Stage 2? All right, cool. I think I'm going to declare it, and congratulations to Object.has Object.hasOwn, I look forward to the new title.
Reached Stage 2 consensus
Presenter: Mark Cohen (MPC)
MPC: Let's Jump Right In so this is pattern matching. This proposal was formerly being authored and championed by Kat Marchán before they left TC39 it achieved stage 1 I believe in 2018. A new group of Champions has taken the proposal back up with a new direction so that group of Champions: myself, TAB, JHD, YSV, DRW, JWK, and RKG. thanks to all of you for your hard work and thoughtful contributions so far and also thank you to Kat for all the hard work. They did before this group took up the proposal before we get too far into this. I just want to state very clearly. This is an update and not a request for stage advancement. So as a Champions group, we're presenting what we think is the best version of this construct it like at the current moment, but we're not married to any particular syntax, spelling, etc. We're not seeking advancement of the examples we present we're just showing you where we are. There is going to a lot of byte shedding. So I'd like to as best we can avoid tons of bikeshedding here in plenary that can take place on GitHub and we can also address those kinds of questions when we do come back for stage advancement in the future.
MPC: All right, so let's jump into priorities. Priority number one is this is pattern matching. So this might seem obvious, but we thought it was worth stating explicitly. This proposal is a entire conditional logic construct. It's more than just patterns. And so we have had to and we'll have to in the future make trade-off decisions involving ergonomics of like different use cases. And so this priority is us saying we want to prioritize the use cases of patterns because the biggest hole that we're filling. Another priority is we want to subsume switch. So first of all, we want there to be zero syntactic overlap with switch to make it more easily google-able. We feel like any overlap with switch will produce confusion and hinder the discoverability and Google-ability of pattern matching. We also want to reduce the reasons to reach for switch. A lot of us feel like switch is pretty confusing, a frequent source of bugs, and generally not the best design. So we'd like there to be really no more reason to reach for switch after pattern matching is in the language. However, switch is pretty ergonomic for working with tagged unions, for example, so we'd like to ensure pattern matching is equally or more ergonomic for those use cases where switch is good. We'd also like to be better than switch. So switch has a lot of footguns, The big one is that fall through is opt out. So if you forget a break statement that's really easy to do but potentially really hard to debug. Additionally omitting curly braces in your case statements hoists declarations to the top which is usually surprising. It's also difficult to work with things like untagged unions in switch. So we'd like that to be ergonomic and pattern matching as ergonomic as we can possibly make it.
MPC: Another priority is expression semantics. So this is drawing on prior art of pattern matching in other languages so you can use in general if you run into this in another language, you can use the construct as an expression so you can do return match or let foo = match we feel this is intuitive and concise and we think it can be achieved in JavaScript.
MPC: So another priority is exhaustiveness and ordering this one is mostly about matching what we believe to be developers expectations. So for exhaustive - if the developer wants to ignore certain possible cases, they should specify that explicitly. Getting a error at development time because you forgot to match a particular case is much less costly than a production time error from an unexpected value getting passed from somewhere further down the stack. Of the developer wants to cases to share logic what we know as like fall through from switch. They should specify it explicitly. So like a parser error reminding you to do so is less harmful than silently accepting buggy code.
MPC: For ordering, matches should always be checked in order. They're written from top to bottom. So if you write three match clauses and they're kind of refinements of one another than they should be written from most refined to least refined. That's the order they should match in.
MPC: And then our last priority is user extensibility. So in a nutshell userland objects and classes should be able to encapsulate their own matching semantics. Now this grew out of thinking around regular expressions, which was basically the following chain first surely it would make sense to use regex as patterns. If you're matching against the string you should be able to put a regex in a match clause, which we'll see, we have some syntax examples coming up and if the regex matches then the string matches and you go into the right hand side. Surely if you can use a regex as a pattern then if the regex has named captured groups, you would want to have those named captured groups available as bindings. So if you match on a regex that has named capture groups in it, then whatever code you're writing on the right hand side should have access to the contents of those named groups. Now, we basically thought we had two options. As TC39 we can treat this as a magic special case and basically make that functionality only available to regex. Or we can provide a generic standard by which developers can integrate userland objects with the language construct. We believe that generics that the generic standard would be a boon to developer ergonomics, especially for libraries and SDKs where if you're providing some API object or response object or like errors or something like that. You can provide matching semantics with it to the (???) All right, briefly going to go to the queue now before we talk syntax examples.
WH: The most important priority is absent, which is avoiding footguns.
MPC: so I think that's basically covered by our by be better than switch like we were explicitly thinking of this as avoiding foot guns many of us feel that switch has tons of foot guns. We want to avoid all them.
WH: Well, unfortunately you added some worse ones in the examples. Let’s resume the discussion after going through the examples.
MPC: All Alright, first example here this is just a kind of basic example, that's not using a ton of new features. This is just some code that's like making an HTTP request and then matching on the responses. We're going to use this one to go through like each individual part of this construct and put names to particular constructs so that we have some vocabulary. So first of all, the whole thing is the match construct. I've already used that a few times within it we have for match clauses and each of those clauses contains a pattern. So you see when and then parenthesis and then the thing inside the parentheses is the pattern, except for the else clause which doesn't contain a pattern that just always matches anything. Patterns can use object or array destructuring. So we see status 200 body.dot rest those things yield bindings just as they would if you were using destructuring. Normally there are other ways to get bindings will discuss that in a bit. first one matches 200 of the second one matches 305 now the second one matches 301 or 304. We'll talk about that as we step through this.
MPC: so at the top of the statement the thing being matched on we're calling the matchable. So in this case the response that you're matching on. That's the (??)now a clause like I said consists of the when keyword a pattern inside parentheses, and then the right hand side. We're considering that to be sugar for a do expression. So you have curly braces and then a list of statements inside of it and we're just going to say that that is exactly a do expression, like you, you know, we originally considered having you write the new keyword, but we ultimately thought it would be nicer if you just had curly braces and then it’s sugar this pattern right here status 200 body rest that uses object restructuring syntax, which we feel pretty strongly should just work. Any object destructuring expression you write should be valid as a pattern. on top of the existing object restructuring syntax. We also can have patterns on the right hand side of a: so in this case “status: 200” is a pattern. Specifically, it's a leaf pattern or a literal pattern. I guess that just matches exactly the number 200 we can talk about semantics of that later. And then yeah patterns like I said can introduce bindings. This one introduces body, and rest to the right hand side. So those two things are available inside the new expression.
MPC: Yeah, then this - so WH, this was the one you were asking about. So this pattern contains pipe which is the logical ‘or’ combinator. It just tests patterns until one of them succeeds. So this one would match if status is 301 or 304. This also means that patterns can be nested, which will see some more examples of later on. One thing worth pointing out destination: url it's effectively a rename, but it's not actually directly renamed. What's happening there is that url is an irrefutable match, which means that it matches any value that destination is set to and binds that value to the name url. effectively performing a rename but it's kind of a byproduct of how irrefutable matches work. So in general bare variable names are irrefutable matches, they'll match anything and just bind whatever is being matched to that name.
MPC: And then lastly we have an else clause. This is a special fallback clause matches anything this is basically default in switch statements. Now one thing to note is a top-level irrefutable match. For example when Foo that's also a fallback clause and so we argue that it should be an early error to have multiple fallback clause or to have any Clauses after the fall back clause. All right going to keep going here. So write a top-level irrefutable match is also a fallback clause and right so if you're you're going to have a fallback clause, it has to either an else or a top-level irrefutable match like when(foo) but not both and then you can't have anything after it. This is you can basically think of this as unreachable code. We're like preventing unreachable clauses.
MPC: Another example here. This is like a bad very simple text Adventure game that's taking in commands as like an array of parameters. So here we see array destructuring. We saw object restructuring earlier. This is how array destructuring works, basically as you'd expect it, and we also see the as keyword here, which we can use that to introduce intermediary bindings. So specifically what's going on here that first clause will match Like go north go east go west or go south and it gives you access to the specific direction that the player chose as the direction binding.
MPC: Next up this is introducing guards so we can have additional conditional logic patterns aren't expressive enough. For example, I guess until number not range lands. There's no way to like in you know, right a pattern that expresses that a number is within a range. So you have to use conditional logic like this to express that and so this is just like you Agents fetching from some page needed and point that first Clause matches if you receive more than one second Clause if you receive exactly one and the third one if you maybe don't receive a page at all, that's just the generic fall back. Another way to write the previous code without a guard and without checking the page count uses nested patterns, which we talked about before. So you can further kind of drill down into that data property and match on it inside of the bigger response object. So the first clause matches if data has exactly one element. The second Clause matches when data has at least one element and gives the first page as a binding you can imagine for like presentational purposes, you display the first page and then you have an array that might be empty and might contain more values for a carousel underneath or something and and yet like I said, this is nesting you can kind of infinitely recursively nest patterns within themselves where appropriate of course.
MPC: Here's an example of using regular expressions in patterns. So this is very terrible, arithmetic expression parser, so regex if you stick a regex inside of a pattern it works basically as you'd expect it just calls match on the on you know, whatever object you passed in presumably we could say it's stringified we haven't, you know, we're not married to any particular semantics around that but yeah, so if the if the regex matches what you projects matches the matchable then you go into the right hand side. It's considered a match. And yeah, this one has named capture groups. We want those to be able to introduce bindings to the right hand side likely bare regex has will still be a bit of a special magic case in that they're they're able to introduce bindings just from the named capture groups. Whereas you will see an expression form later on that allows you to pass a regular expression that you've declared somewhere else to be matched against that form. You'll probably have to explicitly say which bindings you're introducing with an additional keyword. But this case we feel like it'd be nice to be able to introduce bindings just from the named capture groups.
MPC: Now this kind of leads us, like I said earlier, to the matcher protocol, which is the user extensibility, unless we want this to be a completely special case. That's not “replicatable”. have to provide some sort of protocol we get to that kind of by way of another example. So this code sample is a lexer of some kind and this introduces the pin operator, which is that little caret (^). This is this is going to be what enables the protocol which we'll see in the next sample. So the pin operator you can think of it as an escape hatch from irrefutable matches. So if I had just written when LF and CR are without the without the caret then LF + CR would be irrefutable matches that introduce a binding. That shadows the constants that are declared above. With the pin operator LF and CR are evaluated as expressions and since they evaluate to those primitive constants declared at the top matching is performed against those constants. This this Clause will succeed if the token is either 0x0A or 0x0d.
MPC: Here's the protocol. So this code is a declaration at the start. It's a declaration of the matter protocol on some imaginary class. It's a really terrible name parser that just tries to split a string in two and return those two pieces. So then the match statement down below when we have when caret name so name is evaluated and since it turns into or sensitive valuates to a class with this special like symbol.matter method on it that method is then invoked to see if the clause matches now, we were not married to any semantics about like how that matcher symbol that matter method is supposed to be written. But basically it should just tell you if you know if the matchable is matching that particular class. So in this case, it's just going to check if the matchable has exactly two components like it's a string with exactly two space separated substrings. Basically, also see the “with” keyword which is used to pattern match the value returned by the matcher protocol. So in this case the protocol is returning an array of length 2 and so where destructuring that and pulling out the first name and the last name as first and last there's a additional guard on the first one. So like the two clauses are matching hyphenated last names followed by non hyphenated last names this operator. I just want to note this is probably the thing we are least happy with as a Champions group. This turns out to be a pretty hard problem to solve the prior art for, you know matching with a protocol is a bit of a mixed bag. This is Elixir’s approach that was brought into the proposal by Kat. We like it, but it's very much like open to other spellings or other ideas on how to do this, but we think the functionality is very valuable.
MM: Can I jump in with clarifying question while you're on the slide? Yeah, so you wrote this with the method being an instance method, but what creates an instance of name such that you're invoking this on an instance had I only see a mention of the class.
JHD: It's just an error in the code example, the method should be static. There's no magic construction or anything.
MPC: Yeah, sorry about that typo. I'll revise that before we update the repo later on. Okay, so finally we're going to go to the queue right after this. I just want to run through some really quick potential add-ons that we've been discussing as a Champions group. The first is async match. This is the one that we're kind of most jazzed about. This should be pretty simple from a spec and implementation perspective it, you know, effectively just sticks the entire thing inside of an async do so, you can use await anywhere inside the construct inside the module inside a patterns inside the right hand side. and then the whole expression produces a promise we consider doing this on like a branch by Branch basis. So like you would say when pattern and then like a sync do curly brace, but we figured that would inevitably unleash salgo. If you can have like some branches return promises and some not so we figured we would be better off just having like the entire construct is async or the entire construct is sync. Next pattern and combinator so the pipe that we saw earlier the or accommodator tries patterns until one succeeds this tries patterns until ones until one fails. So the semantics on how this works are still a bit up in the air, but it does allow for more expressive match Clauses without having to reach for guards. So in this case, you can see we're matching against an aggregate error where the first error is a type error and then we pull the rest of the errors off as a binding which you know, if we didn't have the the and combinator you'd have to use a guard here to specify like the that that middle Clause we want to match an aggregate error. But only if the first one is the type are you have to go like when aggregate error if you know errors.or errors at position zero instance of type error or something like that.
MPC: Next up, nil matcher. This is from the prior art. Most languages with pattern matching have the concept of a nil matcher. It just fills a hole in a data structure without creating a binding in JavaScript. The primary use case would be skipping spaces in arrays. Fortunately for us, this is already covered in destructuring syntax by just omitting any identifier between commas. So with that in mind with how contentious this underscore identifier is we probably would only pursue this if we saw strong support for it, but, just throwing it out there.
MPC: Last up catch guards. This is also hopefully pretty simple. It's just sugar for catch (error) { match(error) { ... with an extra curly brace and level of indentation there would also be a slight change on the semantics, which is that on a non-exhaustive match we would rethrow the error that's in the catch clause. Rather than generating a new error so that you still have access to it. So there's that kind of default else throw error.
[To the queue]
WH: The new footgun is ^ specifically. It seems to imply negation. Moreover, if you omit the ^, you will assign to LF instead of using the constant LF, and it’s very easy to forget a ^. So right it will try to match against three. Somebody will try to match against bullion or excited to do a bit and instead. Alternation somebody will take too much against infinity and instead assign to Infinity. So right now this is a huge footgun together with the rest of the complexity of this proposal. I feel that this is too complex and am not in favor of this because of this footgun and the complexity of the whole proposal.
TAB: Are you against the spelling of this operator or the idea of a value-based operator at all?
WH: I'm opposed to the confusion that adding or removing a ^ will cause. We have too many operators for escaping expressions. In most places expressions are the default; in some places we use square brackets. I don't want yet another one in the language.
TLY: Yeah, my question was about how exhaustive the matches are for array and array patterns and object patterns. So on slide 19, there is something that confused me. So it looks like that first one is exhaustive. Otherwise, you would never reach the next. And so like it means like everything in the array must be bound in order for that to match right? It's like if the data had two entries, that would not match.
MPC: Yeah, it would match the second one clause in this one. If you don't specify a ...rest parameter or something like that, if you just specify a comma-separated list of bindings with no ellipses anywhere, It'll match arrays with exactly that number of items.
TLY: Okay, and the object one has different semantics where it only cares about whether or not the ones you list exists. I just want to point out the discrepancy. Maybe it's kind of intuitive because it's all done in other languages, but it's a weird kind of mismatch between the semantics of array match bindings and object match bindings.
MPC: Yeah. I can't speak for the entire Champions group, but we might be swayed to kind of make array match up with object in that way. Like I said, this is just a progress update like we're not married to that.
TAB: I would be very loathe to just because there are very obvious patterns that you can write that would been surprisingly match and yeah could be a but I suspect to be a very bad foot gun for people.
TLY: I was just kind of wondering if maybe you would consider reaching parity by having an object have ...rest there, or ..._ something like that to say and I don't care about the rest. So it would by default refuse to match partial object shapes.
MPC: We could also consider that yeah.
JHD: Okay that would be an issue for this object destructuring checks the prototype chain. So, yeah, it's just not feasible to exhaustively check objects in that way, way, I think.
AKI: Alright, and that is time.
JHD: Within the next day or so, I'm going to be updating the actual proposal repo; the proposal repo currently does not contain any of these changes. I will also be closing all issues and pull requests that are no longer relevant. So if you do file a new issue in the meantime, and you think it wouldn’t be immediately obvious to me, please note that it’s based on the presentation from today and I’ll make sure I leave it intact. Thanks everyone!
AKI: And with that we are wrapped for the day. It's 3 p.m. In New York, in Savannah, and in D.C. I hope everyone has a wonderful afternoon or evening or morning and I look forward to seeing you all tomorrow or in hubs right now.