Remote attendees:
| Name | Abbreviation | Organization |
|---|---|---|
| Luca Casonato | LCA | Deno Land |
| Ashley Claymore | ACE | Bloomberg |
| Jordan Harband | JHD | Coinbase |
| Bradford C. Smith | BSH | |
| Waldemar Horwat | WH | |
| Robin Ricard | RRD | Bloomberg |
| Caridy Patiño | CP | Salesforce |
| Jack Works | JWK | Sujitech |
| Sarah Hennigh-Palermo | SHO | Igalia |
| Romulo Cintra | RCA | Igalia |
| Michael Saboff | MLS | Apple |
| Istvan Sebestyen | IS | Ecma International |
Presenter: Justin Ridgewell (JRL)
JRL: Okay, so I'm presenting String.dedent. If you were here at the last meeting, this presentation is essentially exactly the same. I've changed nothing about the proposal. All I've done is removed the syntax discussion from this presentation since we decided not to do it last time and I'm removing the indentable discussion, which is a follow on that I presented the high level details about. So otherwise this proposal is exactly the same, the only change is I have written spec text and so I can actually ask for stage 2 at this meeting. In the interest of time, if you don't need me to present the entire proposal again, I can just skip to the discussion phase. Maybe.
RPR: okay, would anyone like to see the syntax. Any voices in support of that? Anyone would like to skip the syntax and go straight to the discussion? Is anyone awake yet? Okay, no, real feedback from people at the moment.
YSV: I would actually like to see like a really fast run through the slides just to make sure that everything's alright. And yeah, just like super fast.
JRL: Yeah. Okay. Sounds good. So in the same thing as last time, if it's necessary to for clarity, I'm going to display the spaces as mid-dots and tabs as dash characters just so that you can see the white space in the input and output, and have an understanding. Any time you see a dot or a dash it means space or tab, essentially. JRL: The problem is it's extremely difficult to have good formatted input code that logs to in output and there's a couple of more cases where you're trying to do either SQL statements, maybe you're trying to do markdown. Formatting things like that, with the indent of these sources, is important. And the indentation of the output is important. In this example because there are space characters on my line four through seven. There are a bunch of space characters on my output lines, 13 through 17. There's the six leading spaces. There's actually four trailing spaces on line 17, which account for the four spaces that are before the closing tick of my template literal. If I want to have good output, I essentially have to make this extremely ugly input source code. It just does not look fluent with the way that I want to write the code, but this makes the correct output. So my users see something that looks sensible to them. String dedent is intended to solve this. I can have clean input code and clean output text at the same time.
JRL: The way that we do this is by removing common indentation, there are things that we need to know about unfortunately, because there's a lot of moving parts of this proposal. It's simple in the end, but you still have to know a bunch of the terminology. All of the new line characters that are representable as syntax in ecmascript are the same new lines that we're going to talk about. in the template literal, this the dented block then includes new lines, Carriage new lines, paragraph separator, line, separator, everything that's normal, new lines. White space is everything else that's Unicode whitespace, not new lines, but everything else, space characters tabs, vertical tabs, all that kind of stuff. Those are all white space in our discussion here. JRL: The opening line is everything directly to the right of the opening tick Tick of a dedent block. It cannot have anything on it. No white space, no characters. You have to immediately have a trailing new line character. A literal new line character, so that you start the next line. Everything else is invalid. If you have any kind of character on there it's going to be throwing error because improperly created to dedent. The closing line is everything to the left of the closing tick in a dedent block. The closing line is allowed to have white space, any number of whitespace characters. We're going to remove the opening and closing line in the output so that you don't have a new line to start your output text in a new line to end your output text. They are both going to be stripped entirely. So what that leaves us with our the content lines, everything in between the opening line and the closing line. Content lines can have any characters on them. It doesn't matter at all. Empty lines are lines that contain neither white space nor characters. Empty lines do not affect the common indentation that we remove. Whitespace lines are lines which only contain white space, nonempty lines. They have to have some kind of white space char on them. Whitespace lines also do not affect the common indentation of the detent block. And then we have character lines. Character lines are lines that contain any character that's not a white space character. They're non-empty. They contain some character. They can have leading white space and these are the ones that we are concerned with when we're doing dedenting. The common whitespace is the white space that is shared by every character nline. So in this example, there are four space characters on every one of the character lines. Notice that line 7, an empty line, doesn't affect common indentation. Also notice that line 1, a white space line, does not affect the common indentation. Both empty lines and white space lines are ignored when trying to do this calculation. If you have a character line that has no indentation or doesn't share, common indentation with the other character lines, then it shortens the amount of indentation we remove. In this case, your common indentation is 0. In this case, the output would not have any white space removed at all. What we're looking for is exact char matches on every one of the character lines. So, in this case, there are two leading spaces on every line. Notice on my 11. We have two spaces, followed by two tabs. Those tabs don't mix with the spaces on the other character lines. You can't have a space character removed if you have a tab on that same column essentially. So in this case, the common indentation of all four lines just two space characters. And this has some consequences: if you were to have a mismatch on the very first column, that means you have no common indentation at all for all of your lines. You can interchange your space and tab characters for any of your white space as long as every character line contains the exact same sequence of whitespace character then that is used as your common indentation for all your character lines. So, in this case, I can have a space tab space tab and have those removed from every single one of the character lines.
JRL: Empty lines don't actually affect the common indentation. They are preserved in the output. So if you want have a bunch of leading newlines or trailing newlines, you can put a bunch of empty lines between lines, four and five, or something, and those will be maintained in the output. They don't affect the actual indentation that we remove from the two character lines here, lines five and seven. Both are stripped out, they were six space characters.
JRL: Whitespace lines are a little special, we had to decide to do something with them. On line five here. I have a line that is entirely composed of whitespace. The behavior that I'm proposing is to remove all the white space characters from those lines. From that line, essentially becomes an empty line in the output. This follows what python string.dedent, their equivalent - text.dedent I think they call it - this follows the precedent that they have and Is the simplest behavior that gives good results. There are more complicated behaviors, but frankly they're not necessary. Every case that I can think of this behavior is fine if we just rip out the white space from the lines and so we don't have to think about any of the complication anymore.
JRL: You can have the expressions. Expressions will stop the common indentation at the beginning of the dollar sign curly brace mark. So here there are four space characters, shared by the literal text block here, and it doesn't matter that I am interpolating two space characters into my expression. The dedenting happens before the interpolation happens. So we're looking at the literal text block. We're going to remove the four spaces and then will compose or interpolate the output to have the space characters after performing the dedent. So in this case, notice that only for space characters are being removed from line 5 of the "foo" line and so the remaining two characters will remain online 15. The output, the same And 16, which same for bar and equates the Line 6 here will interpolate the two space characters. There's actually another space in between the expression and the word char is here. So that line actually comes out with three space characters after we interpolate everything.
JRL: You can perform tagged expressions by wrapping your tag function, with String.dedent. So this example is a python interpreter, if we were to have a python interpreter in JavaScript somehow. Python is indentation sensitive. If you have four space characters or six space characters on your first line, it's going to throw an error because it's not expecting white space on that line, you can dedent manually the same way that we would have dedented thein the current way. We wanted to fix the output, but it doesn't flow as normal source code. If you want to wrap your python interpreter tag function with the dedent behavior, you can just invoke the string.dedent as a function, and then use the closure that is returned as your tag function. This will remove the white space from the template block before invoking the underlying tag function that you're directing with the dedented template strings array. And because this is a template strings array, it'll be cached and preserve identity between invocations. Everything else that comes with a normal tag template literal.
JRL: And that's basically it. I removed all of the extraneous details from the proposal and this is all that proposing for stage 2.
Thank you for the presentation here. Matthew is one of the queue.
MAH: So, from what I understand from of the presentation this can now be Faithfully implemented a shim in user land, right? There's no, no, yes.
JRL: Yes. there is a proposal for isTemplateArray that we can discuss once that proposal gets presented again, which may not be implementable in userland. We may decide to do a special behavior for String.dedent and that proposal. But everything else, every other behavior is perfectly implementable in userland and I actually have an implementation. It's not a faithful reproduction of the spec text, but the behaviors match exactly.
MAH: Yeah. great presentation. Very clear, and we're supportive of this. Thank you.
KG: +1 to advance
MPC: So, I wanted to ask a quick clarifying question. So the behavior around removing the behavior around, removing my space both for interpolating expressions is that more or less just to make that implementation simpler and we don't really expect people to like, be interpolating white space as in that example.
JRL: So, it is not possible to preserve template identity if we were to interpolate, before we did the dedenting. So this is a necessary part. There was a discussion at the last meeting about dedenting and already interpolated string either through a prototype method or through a function invocation where you pass string literal string as your first parameter to String.dedent, allowing you to dedent an already interpolated template literal string. We decided to do that as a follow-on and there's actually a runtime reservation in the spec text that you cannot pass to string dedent so that we can open that up in the future.
MPC: Got it. Cool. Thanks for that big plus 1. Thanks for the presentation
RBN: Yeah, I just have one question. So if the dedent happens before any type of interpolation occurs, what happens if, you have a line that has no white space but interpolates some expression, would that end up being treating that line as the common white space as being a length of zero?
JRL: Yes, template substitution affect the common indentation. They are considered a character line whenever they appear. So if the template expression's dollar sign was at column 0 in the first column, then your character lines would have a common indentation of zero and so nothing would get removed from your output.
RNB: All right. Thank you.
RPR: The queue is now empty.
JRL: Okay, so I'm asking for stage two, please.
RPR: Any objections to stage two? [silence] okay, no objections and you had three messages of support in chat. So congratulations Justin, you got stage two.
JRL: All right. Thank you.
KG: Ask for reviewers.
JRL: Oh, yeah. Thank you. Can I please have stage three reviewers?
RRD: I'm happy to review.
JHD: I'm happy to review as well.
MPC: I'm happy to review.
JRL: Thank you. The spec text has a bunch of comments in it to help you reason about everything that I did. Hopefully it'll be very straightforward.
- Stage 2
- reviewers: RRD, JHD, MPC, SHO
Presenter: Richard Gibson (RGN)
RGN: Okay, so it's been a while since this was presented, but I'm happy to come back to you with some stable spec text for JSON source text. A little bit of background on this. We've seen these slides before, but the general problem to be solved is the lossiness of JSON.parse. The reviver function that exists gets language values, not the raw Source text and that's particularly an issue for sequences of digits where they get rounded into the Number range before any code has access to them. We also have, relatedly, a deeper lack of context, so that if for instance, you want to revive strings that look like dates into actual dates, all you've really got is the corresponding key and that can be confusing in the absence of a schema. You don’t really know where in the JSON structure any particular value sits, and can be confused by lookalike shapes.
RGN: So the mirror image problem now, that output of the replacer is itself subject to JSON serialization. If you have a long sequence of digits that you want to be a string, That's fine. If you want to preserve them as digits, There's no current capability for that. You cannot natively serialize a bigint to JSON, you get a type error If you try.
RGN: So, this proposal is adding the ability to look at a new argument in the reviver function that will expose the raw source for primitive values. So, here we take this second part here. We take this source text, which is that sequence of nines, convert it to bigint. And now we get the the lossless conversion of the bigint that those digits represented. And on the serialization side. We want to be able to admit that sequence of digits, not as a string, but as a JSON number and we do that by means of a new function, JSON.rawJSON subject to bikeshedding, that returns a token representing the raw JSON text. This was requested during the previous proposal update. There are a handful of what I consider minor open issues mostly around the new context argument provided to a reviver function, like 11 and 10 and 25. We can have keys in it for showing the total position in the JSON structure. We can have input and index for the position in the source text. Both of those were declined unless a significant use case was identified. There were a couple of issue comments on both requesting this data. And both are possible to add later if we want to leave them out now. Number 25 was regarding the context object for non primitive values. I've tentatively decided that the object will always exist, but will have properties only for a primitive value. And number 26 is a bikeshed for what do we want to call the tokens representing raw JSON text? All of these are tentatively answered in the current state of The Proposal, but could obviously be changed at this stage or, potentially, even in stage 3. Which is what I'm requesting now. I don't yet have feedback from the reviewers, but I do have spec text. And with that. I'm ready for questions.
RPR: Okay, nothing on the Queue at the moment. We're having delayed audio here. Shu-Yu was on the Queue. I'll create a topic for you, Keith.
SYG: Am I going before Keith? Okay. yes, this is not a normative feedback is editorial feedback. I'm sorry for not posting an issue. Had a quick look at the spec text. I have some concern about this the kind of spec machinery with which you chose to expose the source text which is passing around actual parse trees. I think it's fine for this use case. I was wondering if you had other ways to expose the source. Text come. I'm worried that we, if we start passing around source trees, which are parsed specifically to the spec grammar. We might accidentally make the spec grammar’s tree-shape normative. I don't think that's the case for this proposal. But as a general, as a general thing to avoid, be good to avoid,
RGN: Yeah, I'm glad you brought that up. It was a little tricky to come up with good spec machinery for this. think it is a special case and representing the structural JSON as we're consuming it into ecmascript as a tree corresponding with the parse make sense to me, but I agree that it shouldn't be taken as a pattern to reproduce in a lot of other places.
SYG: So, you talked about difficulty, does that mean? This is basically the only way you think we could surface the source text.
RGN: It's the only good way that I was able to come up with because the parse itself gives you a tree, but the visiting order of the resulting nodes is bottom up. So so that doesn't leave a lot of options, especially if we want the spec be comprehensible. I'm totally open to anything else but evaluating like, you know, passing the parse nodes versus adding structures to a stack, I feel like this way came out a bit cleaner.
SYG: Okay. Thanks.
WH: I agree with SYG. I definitely do not want the grammar tree shape to be normative or visible in any user code. This is something that we need to refactor from time to time as we change things in the language.
KM: Yeah, I guess I don't know. I'm kind of curious. Do we know how often it is to use the reviver? I guess. I wonder how this is probably solvable with some Machinery in an engine, but I'm wondering like if allocating all of JS, strings. For like to pass through these functions. have a performance thing. I mean, how we might have to just try it and see what happens, but I'm just kind of curious to get that just come up at all. maybe
RGN: We actually discussed this when the proposal was introduced. We basically had consensus from implementations that JSON.parse with a reviver is slow path anyway, and so it would be acceptable.
???: We don't have string slices, or whatever, right? them for GAF. Strings, Only for ref counted strings interesting.
???: I see if that probably wouldn't be outstanding work hard to have it for streams. I don't even actually know why we don't, I guess it's the rest. I don't think there's is there a string Substring function? Yes. There are like I thought they were about to, unfortunately, that sounds very like us.
???: Yeah, okay. I don't know. I guess maybe they just were never hot enough to Warrant adding a special thing for it. I don't think we had said in the car dad though. Does V8 have this out of curiosity?
SYG: Yes, so it's we be character, so we won't be copying character content, but it'll still be extra allocations better. Just be like the object. Robert is just wrapper. the matches, my expectations also, you know, and it's particularly convenient here, be specifically, because the exposed source text is limited to primitives. So slices of the of the input in well-defined and static positions.
Yeah. I'm not even worried about it if it was on a primitive because that's just doesn't really happen. So like everyone was passed as a string. Anyway, introducing person.
SYG: So like, but KM’s this point is a good one. We tried this and there are allocating. She's concerned for performance concerns or whatever. It will probably come back.
KM: Yeah, I just worry cuz JSON.parse is like super crazy important.
SYG: Yeah, it's very it's very optimized code paths like we do. Yeah, we do weird gymnastics.
KM: Yeah, it's like it's the most like hand-tuned. Tell the compiler to get out of your way and do it yourself. Like some of the most like some of that could end like the entire engine.
RGN: That's, that's all I have. So seeing an empty queue. I think I would like to ask for consensus from the committee that this is ready for stage three, pending Whatever commentary comes out the spec text review.
RPR: Right, so you're proposing stage three, which normally would have spec reviewers by now, but this would be a conditional stage 3 and based on those reviews coming in.
RGN: Yes.
SYG: Could you remind the committee who are the reviewers and are they on the call and to the speaker?
RGN: Yeah, let's see. I believe the reviewers are WH and MF. I pinged ten days ago and haven't heard back yet. But I think the actual reviews will be relatively straightforward, and if anyone else wants to review…..
RPR: I can see on the queue that JHD has said +1 for conditional stage 3. Richard are you here?.
RGN: I'm here, Tough crowd.
RPR: Have we had any objections to this conditional stage 3?
RGN: None that I've heard… we have explicit approval from JHD and silence from everyone else.
RPR: Is there any more explicit support for this from anyone? Jack, Michael was on the chat room. Okay. Michael. Yes, and he does not oppose condition advancing. I think we've allowed adequate time for objection to this. So congratulations, you have conditional stage 3 depending on the two reviews from WH and MF.
- Conditional stage 3 (spec review pending)
- Reviewers: WH, MF, RGN
Presenter: Ron Buckton (RBN)
RBN: Yep, I'm here. Alright, so I am Ron Buckton from Microsoft for the next hour. Maybe hopefully less will be talking about the group and auto accessories proposal. Just a quick overview, auto accessories are a feature that we added for classes in the decorators proposal, in decorators for stage 3. We have a keyword accessor, which can be used to annotate any field, and that adds a syntactic transformation behind the scenes into a paired, getter and setter that each access a backing field. This was something that I worked on with the decorators champion, after the stage, one proposal for auto accessories and group successors. And is something that we agreed on semantics for and this expands on that proposal somewhat with some of the syntax here. We'll get into more details here shortly. Group accessors are a novel syntax for ecmascript that logically group individual get, and set declarations into a single group declaration. I'll get a little bit more into that as well here in the upcoming slides. So, auto accessors. Auto accessors were added to the decorator stage, 3 proposal. As a syntactic opt in to turn public fields in to get in set. A the primary reason for this was a performer around performance concerns in engine, implementations around changing a field into an accessor via decorators in the stage 1 and stay true decorators. Proposals. This also is advantageous to work around issues with shadowing of fields, as a field in a subclass can shadow a successor introduced in a superclass. I'm sorry, a field in a superclass can a shadow, a successor added in in a subclass, which makes them somewhat difficult to work with when you want to support any type of subclassing introducing decorators on new decorators and subclassed element. So auto accessors, helped with that. This proposal expands on that a little bit by allowing to introduce individual get and set declarations inside of the accessor block. So, in this example, the first line is what was introduced in the decorator stage 3 proposal, simply accessor in a field and an optional initializer. This expands that to login to have a more explicit declaration of get and set and one of the rationales for this actually how this works with decorators. I'll get a little bit more into the decorator specific part of this later in this proposal. One of the other features that this enables is the ability to have a get only accessor declaration. This allows you to define something that acts like a get accessor that can be overridden in a subclass, but also allows you to still have an initializer, but in this case would not allow you to have or rather with not defined for you a setter to that field. So, as I said before, the shares semantics with the tester keyword, that was introduced in the states through decorators proposal creates the unnamed backing field initializers are evaluated during construction. At the same time, as other field initializers, and the initialized value is assigned directly to the back packing field, so it doesn't pass through any setter that's defined in this proposal and auto accessor. Declaration can only a, get a set or both in any word. So, you wouldn't be allowed to define to get declarations inside of an audio accessory of work to set declarations. This feature is also only used in or can only be used in class declarations. This is because object literals are not currently specified to support private names. It's been something that's been discussed on and off for a while, but since that is not yet a proposal, This is opting for the a minimal approach, Where it does not get support this. And accessor currently in stage 3, is only supported on classes which are in stage 3 decorators. So, some more information on group accessors, the purpose of group accessors is to support certain or to improve certain scenarios such as helping with logical grouping. It's feasible to have getters and setters that are spread across a class journaling, bad practice, but it also allows you to logically group them for tooling such as being able to use code folding in an editor. It has an advantage of Of computed property names for accessor pairs, are only evaluated. Once this isn't usually an issue for cases like using say, user-defined, symbols, or built-in and symbols, but if you try to do anything more complicated than you could possibly result in side effects, when you have individual get sets that have computed property names, and this also provides a convenient location to decorate pairs of accessors. He's rather than individual accessors, again, something more I'll discuss a little bit more when I come down to the decorators part of this discussion. Both auto group, successors have prior art in other languages. C# is the one that I'm using as primary reference here. So, an example of this in tax for a group to excess, is very definition of the accessor keyword followed by the class element name or the class element name, identifier, Etc. Then a block that contains a get declaration and asset declaration. So this is essentially an evolution of the auto accessor syntax where you are able to. In this case, provide a body for the editor in the center. This is something that would be allowed on object literals as the syntax is the same and the capabilities are the same. You're still able to, in an object literal define individual, get this at declarations. And as a result, this would allow you to also group them. Semantically group successors can only have get or a set or both in any order. Just as, with auto accessors. You cannot mix an auto accessor stub declaration with a grouped accessor full-bodied declaration. You can only have an accessor or a grouped accessor, you can't combine. In this case, again, grouped accessors are supported and supported in both classes and object literals and the individual getting set declarations would be defined on the class or object literal in the same way that the individual decorations were have been. So, one of the capabilities that group and auto accessories provide is this concept of mixed accessibility. So, with mixed accessibility again, logical grouping helps with the organization of these elements, but also helps. With the mix accessibility helps with a common pattern of combining private declarations for a field with a public declaration of an accessor. So the example here shows an immutable Point class. On the second line where you have a x and a y public property with a getter, but you want to be able to do a private initialization. So this allows you to in line those two things at once. So in this case, it creates A get declaration whose name is x and a set declaration, whose name is #x. And this again, has some shocking news to decorators. So here's some additional examples wrong again last. Yes.
RPR: Would you like to take the interruptions or take questions as we go to the end?
RBN: I would like to hold off on anything. That isn't a clarifying question until I get through, most of the slides, there's a lot of things that are there's a lot of interplay between some of the various capabilities.
WH: I’d also prefer to hold off on asking the questions I put on the queue until after the presentation.
RBN: All Alright, so here another example of mixed accessibility In this case, The X property has a public debt in and a private set. The private set has the same spelling as the public yet. but with the patch prefix that's used for private identifiers and with mix accessibility these, you can only use the private sector capability. If the name, that is an identifier that doesn't work with computed property names or number literals or string literals. So again, the semantics adding a hash prefect set creates a named private sector with the same spelling as the accessor decoration. Single declaration cannot have both a set and a hash set. You can only have one or the other. This feature can only be used in classes. It isn't supported in object literals again because they do not yet support private names. It can only be used when class element name is an identifier name and decorators that are that are applied to an accessor. Declaration will receive both the public get and private set, which is important for certain cases such as observable decorators. I'll get to that again in the decorator section of this presentation. And now we're at that part - decorators and grouped auto accessors. So these two capabilities kind of come together group the natto accessors, provide significant power to the ability to work with decorators. So in April, 2014 decorators were first presented to TC39. It took quite a while for us to reach consensus for stage 3. There were a lot of changes to the proposal over that time. Some things that we've gained in that time, the ability to add extra initializers and the syntactic transformation. But there are some things that we lost the original decorators proposal worked with property descriptors, which meant that if you decorated a getter setter, then the decorator would actually see the paired, get and set declaration, which is actually important for a number of use cases. If you're writing a at observe decorator, for example, you would want to be able to track the current value of a thing as well. As the value. It might changed to the only way to do that. Currently with the decorator stage 3 proposal is to create an entangled set of decorators, which is not a, our experience that adds a, which is a very poor. lot of additional complexity again, one of the things we gain was the ability to add syntactic Transformations for fields to accessors. group than auto accessories, help to restore some of what was lost and build on what was gained. So in this case, a group successor allows a decorator to see both the get and set Declaration of an accessor pair, something that's again lost as we reach the stage 3 decorators Proposal. It improves the developer experience by making decorator application. more flexible and ergonomic and improves reusability. So, as an example, in the decorator stage, 3 proposal, if have a decorator that works with getters, you can attach it to a get declaration if you have a decorator that works with setters, you can attach it to the set declaration and if you have a decorator that works with accessor fields, you can attach it to an accessor decoration, but there's no mixing and matching if you have an decorator that does something like add observe and you want to use it with a set of X of get and set declaration pairs there’s No mechanism to do that today. So, auto accessors give you that flexibility. You can use a decorator design for getters on the get declaration of the auto accessor on the set declaration and one for accessor on the entire declaration and the same, then it applies to grouped accessors where you have the actual bodies that you can apply to. So to go into more detail Here, auto accessors that use decorator on the getter, when you're working with a field declaration. The definition is defined with the accessor keyword. So again, if you had a getter decorator, you could then apply it to the get of the field accessor. And the same thing applies to set declarations. Grouped accessors, let you use decorators design for an accessor definition, but see both the getter and the setter. So again, if you had an accessor decorator that was working today an accessor field. you would not be able to use it in tandem with a getter Setter pair because there is no way to see the entangled declaration, but with grouped accessor you're able to see both and again, as I mentioned before, if you have a existing decorator and you wanted to be able to observe the public getter and private setter. There is no way to do that with the decorators stage three proposal. So this would then allow you to entangle these things. This is very important for cases. Like, if you are using some type of model view, view model type pattern in a you and you wanted to have some things where you don't want other classes to be able to mutate a value you, but you want to still be able to observe changes. I do see a note from MM that stage one is okay. This proposal is currently at stage one. I'm currently seeking stage two. So now, as far as evaluation application order decorator was on group and auto accessories are evaluated and ocular document order just as any other decorator on the class with however, what is affected is, how decorators are applied. decorators applied. Applied to the get declaration first, then decorators are applied to the set declaration. And then finally decorators on the entire accessor are applied. There are a couple of questions. One is why use the hash set. So ecmascript currently uses the hash key word for private identifiers and class members. A keyword like private would have required static typing class members as there's no way to recognize whether you're you're accessing accessing a private member with an identifier name versus a public member while the hash syntax could be recognized locally. So for this proposal, we chose to use #set over using private For linguistic consistency. We could use instead, but it does seem inconsistent current champion preference. If we move forward with this is to weekly prefer, the is a weak preference for using the #set for easily more easy recognizability for Developers. There was another question about whether or not a hash prefix set should also create a hash prefix get to make as to approve the developer experience when reading and writing that private member currently my preference is to a weak preference for not having the private getter. Just to more clearly illustrate the difference between public and private set. And now is when I'll take a break for questions. I will point that there is a draft specification that is available that has the full semantics. So, now we can go to the queue.
RPR: Okay, thank you, RBN. So we're about to go to the queue. And what I will say is I think we are having audio delays. So I'm just going to ask the speakers. Please. Give a bit of a delay at the end. We're going to sort this later on, but for now, let's just try to go slowly.
WH: I noticed that you allow empty accessor blocks in classes but not in object literals. Why?
RBN: There should be no difference. It should not be allowed. So if that's the case, that is a bug in the draft specification test.
WH: Okay, so the intent is that you do not allow group accessors with {} in either context?
RBN: That is correct.
WH: Okay. There's another bug in which there is a class parameter on AccessorGroup, but it’s never set. Thus the class grammar is not never invoked for grouped accessors.
RBN: I appreciate the review should. when this moves to stage two, I would definitely be looking for reviewers to help me catch more of those types of issues.
WH: Next item: Why is there no #get? And I don't mean to make #set imply #get, I mean just plain #get.
RBN: This is based on some based on experiential feedback within language like C#. It's very rare to see a private getter with the public setter. And if you are going to have a private getter or a private setter, you should instead be using an accessor, that has a private name. This is all so, it's fairly uncommon and generally bad practice to have Set-only declarations in JavaScript. I have, don't think I've ever seen a use case Where that makes sense. So currently the specification currently leans towards the only enabling scenarios that are good practice would be perfectly fine with adding #get if that was deemed valuable enough, by others in the committee, I do not currently believe that it is a scenario that is currently worth pursuing. Please.
WH: I don't feel strongly about it, but generally I prefer us not to make such opinionated decisions for users.
RBN: I'm generally the same.
WH: I'm curious if anybody else has insights on this.
RPR: There's no response. Okay. Well, shall we move on?
WH: [thumbs up]
RPR: I'm interpreting that as WH done. So, moving on to KG.
KG: Yeah, so this is, if I have understood correctly, primarily intended to solve a use case for decorators, it's not a thing that you would particularly care to use without decorators and it's a fairly niche case at that. And decorators, of course, are expected to be written by relatively few people. They are primarily intended for library authors. Although the point that you do have to use a pair of decorators and that affects users is well taken. But given all this, I would personally be a lot more comfortable if we waited a while for decorators to ship and got experience in the real world that led us to believe that in JavaScript this was a case that comes up a lot and is therefore worth adding a bunch of syntax to the language. I would prefer not to advance this until that point, because decorators only just got stage 3 and this is a lot of syntax that we would be adding just to make a small corner of the decorators use case nicer. So I am not excited to move this to stage two right now.
RBN: So, I'd like to speak to that for a moment. The TypeScript language, which is again designed to primarily be a superset of the JavaScript language has had experimental support for decorators for eight years now. so, we have a fair amount of implementation experience on our side and one of the things that we have found is that there are a number of use cases, folks that use decorators in TypeScript today that would like to be able to navigate to native decorators and there are some cases that are not currently supported that would block their being able to advance rather to perform that migration. So part of this, yes, is tied very tightly to decorators in enabling these capabilities. That would be lost. So there are several projects That would not be able to have the full scope of their capabilities with the current decorators proposal, given that, there is no ability to work entangled decorators, some of the key features that this proposed as such as having the public get and private set are designed as a convenience as well as designed to enable working with a decorator on a declaration. where the setter is private, But again, there it is. Primarily a convenience feature. It's designed to improve the developer experience and simplify very common use cases, but isn't core to the decorator capability of working with entangled getters and setters. So the reason that I'm trying to bring this proposal to stage two is specifically to fill in a hole that it would be needed for folks wanting to transition from typescript experimental decorators, based on the stage one proposal. To a do, the current stage 3 proposal with these missing features.
KG: I don't think that the experience from TypeScript is that informative because the decorators in TypeScript are somewhat different from the decorators that actually are going in the language. And so the libraries and conventions that arose around TypeScript decorators are not necessarily the ones that we expect to see with actual decorators. And so, while I acknowledge that there are people currently using TypeScript decorators who would find it hard to migrate to actual decorators, I don't think that alone is enough reason to believe that this is something that will come up a lot for people who are starting out in actual decorators. So I would still be happier waiting a while with decorators as they actually exist to ship before trying to advance this.
RBN: I can't say that I agree with that position in in that it seems to ignore the of folks that rather large population of folks that have had experience using decorators, the TypeScript experimental decorators. Capability has helps to inform the direction of the decorators proposal, and the vast majority of decorators have been written. For TypeScript, be modified to work with the native decorators proposal. It is the very specific corner case of working. with both a getter, and a setter that is lost that we're looking to try to resolve. I can understand wanting to wait. Decorators is currently stage 3. There's engines looking to implement this but I have seen feedback from projects that are concerned about this capability. So, I do believe that it's going to have significant value within the community. Once decorators has shipped that there are projects that will need this, it would be nice to be able to reach a point where once decorators advances. If we get feedback from the community that says this is needed that we are in a position to possibly advance a proposal, this one or another, sooner rather or later if we have reached a point of being able to have something that works or have an implementation that works, one of the reasons. I'm looking to advance this to stage two is to reach a point. That should we decide that this is a feature of the community wants and needs. Stage two means, we have determined that this is a future the community wants and needs that, we are then ready to possibly advance to stage three and look for experience. Stage 2 is from what I understand is, more of a commitment - not exactly commitment, more of a commitment to state that this is something we're definitely interested in pursuing and looking for stability the design. If we don't feel that this is the approach we want to take, or if we feel that there's significant changes to design, we want to make for stage 2. That's fine. I would certainly love to hear additional feedback on the design in design in the proposal repository.
KG: I don't necessarily have problems with the design, except for the size. My problem is more the fundamental stage 2 problem that I'm not yet convinced that this is worth adding to the language. But I've spoken long enough. I'll let other people talk.
RBN: Yeah, I will also state that the auto accessors side, especially the public get private set is heavily used in languages like C# since it was added. I'm certainly excited that the more narrow form of accessor declarations for fields, was able to advance with state with decorators stage 3 because it is a very powerful feature, but I would like it is something that is. So I've seen significant amount of use case in languages like C# since it was added. So, alright, we can move ahead.
SYG: I mostly agree with KG here. I would not like to advance this to stage two because I do not feel appropriate. I personally would not commit to a solution of this shape before shipping decorators.
YSV: yeah, I'm going to effectively concur with what’s been said. We are again stage 2 because decorators has not been shipped yet decorators hasn't yet. Been implemented in most browsers and I would really like to see how they're used in JavaScript before we commit to any design in addition. I don't know if I consider the here strong enough to advance it to stage two yet, given that we don't have that experience. in particular. I find it concerning that our two primary arguments are that it's heavily used in C# and that it's used in TypeScript. One thing I'd like to say is TypeScript is really great. And in fact, I think it's a benefit when we have languages transpiling to JavaScript rather than moving all the features of those languages into JavaScript, so I don't consider that as alone as strong enough motivation. I would I would be very surprised if If libraries that are currently written entirely in TypeScript would be translated into JavaScript. If they were given this feature, they may be transpiled into JavaScript, but be completely rewritten. I think it's unlikely because TypeScript has a number of other benefits that they're benefiting from. So to motivate this proposal going forward without decorator I think it'll be hard. And, as I mentioned, I think we need actual to actually ship decorators before making such a decision and my line for stage two, is that the motivation has to be strong.
RRD: I'm just curious, but an example of what the decorator currently looks like in TS, what it would look like today with the current decorators that are in ecmascript and obviously the the same solution with accessors.
RBN: So something like an @observed decorator is, there are several actually libraries that utilize something like this to implement observability for property changes, which was something that was actually a proposal for ecmascript a number of years ago. And they do this by trapping the getter and the setter to trap with the current value is and to be able to detect when there is a change then use that to emit some type of notification for that object. That's one of the common use cases. There are others. There are ORM frameworks that need to be able to trap the read and the write so they can determine if there are changes. The way that that works in TypeScript today, TypeScript TypeScript decorators are based on the stage one decorators proposal in which the a decorator would receive a property descriptor and then pass back out a possibly mutated property descriptor the decorators applied to a getter or a setter in this proposal, or at the stage one version of the proposal would prompt descriptors. That's right. A decorator on a getter or a setter would be applied to the entire property descriptor. So you would be able to implement this in TypeScript by writing in, observe that it receives the property descriptor, which has the get set replacing that get set and returning the descriptor in the decorator stage three proposal. So you have a decorator that receives an object that has get set and a context and returns an object that has a get set. So you have that same capability. But decorator, stage 3, only works on accessor fields. You cannot use it with existing Getters and setters.
RRD: So if I understand, well, you could combine in one or two clear decorators. The observe end effect of creating a group or auto accessor as well, right? That's the main use case here.
RBN: I'm not sure. I'm clear on what you just stated.
RRD: Yeah, I'm trying to reformulate in a different way because I don't see the TypeScript example on the screen. In any case we can discuss this offline but I would really like to see what that looks like currently in TS.
MM: I don't remember this going to stage one, not disputing it, but I'm not the only person who is surprised. I got a private message - when did this go to Stage 1? So the stage one consideration of this is something that I missed was going on. So some comments, a clarifying question and then I'll State my opinion. First of all, with regard to the issue that WH raises. About opinionated APIs. I am not of the anti-opinionated religion. I believe that as language designers We do opinionated design all the time and we should and that the main place where our opinions are most valuable is in not making the language unnecessarily accident prone. so the the rationale that you, Ron, had about not having a public set and private get, I think that rationale is a good rationale. Whether I agree with that in this case, that's a separate matter, but I don't disapprove of it because it’s opinionated. The other thing I want to compliment you on is in your presentation, your case analysis is quite thorough and led to a much better understanding of the overall rationale, so I want to applaud you on that.
MM: And a clarifying question. Could you go back to the slide that was up just a short while ago where you're showing both the class literal and the object literal? Yes. Yes. Thank you. So in the class case, if I understand this syntax would result in an implicit declaration of a #x variable. Correct?
RBN: No, not this case, grouped accessors Do not create a private backing field because they have bodies. Auto accessors create a private backing field because they have an implicit body. So, in this case, an auto accessor with a stub, get and set method, the get method is replaced with a auto accessor method that accesses a private backing field. The same thing with the second, but the private back in the case of grouped accessors. There is no private backing field.
MM: Okay good. That helps alleviate a concern. Go back to the previous slide, showing the just get semicolon etcetera. You want the case. Where did it create the private backing field? Okay, so the first case access to resolve you. Yes, the private back. Yeah, that dislike. Yes. The in that first case accessor
RBN: The private backing field is not named. There is no, that's implicitly declared by that. It's an anonymous. That is correct. Correct.
MM: I thought I saw somewhere in your proposal that there was some case where an accessor X resulted in an implicit declaration of a #X.
RBN: yes, that is with the mixed accessibility. One moment. That's the example here. So in this case, it's not creating a named private backing field. It is creating a named public getter and named private Setter that both access and unnamed private backing field. and this is so that you can perform additional initialization logic in the constructor. Or possibly do reassignments inside a method within the class, but that is external to that class. You cannot form sets. You can only perform gets.
MM: Okay, so there is no case where the use of the syntax creates a private field with a nameable name like #X where there’s no declaration of #X plausible. Where there's only at the Declaration rates.
RBN: This creates a public getter named x, private setter named #x and an unnamed private field.
MM: Oh, private setter named #x. Okay. That's the case I was concerned about Yes. so I think I understand the motivation for that. I don't have a alternative to propose. But let me say I am extremely uncomfortable with that bridging between the namespaces. Right now, the two namespaces are considered to be two, completely separate species. There's nothing, nothing that relates a name, X, and a name, #X and the which and there's nothing that causes there to be a #X in scope, other than a declaration in which #x appears explicitly. So overall, my sense this is that I'm very skeptical that the visible extra mechanism here, both the the extra syntax and the peculiar rules and implicit new semantic bridges associated with them, that it pays for itself. Very unsatisfied that it pays for itself as a problem statement with your very nice case analysis in the talk. I'm happy for it to stage one, which is not an issue anymore since it is at stage one, but I think that we are now set for a good stage one analysis for how best to meet the problems that you've identified. I'm certainly not prepared to go to Stage 2 with these particular mechanisms. I don't like these mechanisms.
RBN: I'd be happy to have further discussions on the issue tracker to discuss those concerns.
MM: Good.
JWK: Okay, so I have a question about these slides. In the third example accessors z private set has a body. So how do we set the value to that backing private field when that backing field does not have a name. Do you return value to set it?
RBN: So the example, I was just as I was stating with MM in the third example, for grouped accessors. There is no private backing field. So what this actually, so accessor Z with a get and a private set is essentially a syntactic transposition of get Z with a body and set hashes e with the body except you have the ability to decorate, the pair of get and set. So this doesn't actually create any backing field. You would have to write your own logic to access something else. Just as you would with a normal getter/setter.
JWK: Okay. Thanks.
RRD: Auto accessors are a good concept to pursue, could they be accomplished differently?
RBN: As far as could they be accomplished differently, the proposal for decorators stage 3 has again this example here. The syntax on the first line here with with a duster is currently within the decorators stage 3 proposal. The accessor keyword was chosen. As we were trying to find a keyword representation that would create this syntactic transformation. That was necessary to turn a field into a getter and setter. So that wouldn't be something that someone would try to do in the decorator themselves. The Use the keyword accessor came from discussions, both in the decorators proposal. And when this proposal went to stage one, because their original proposal was just X curly, that:, set: and curly and there was concern that we were using up too much syntactic space via by taking identifier name curly. So we chose to use the accessor keyword here to both avoid carving out too much syntactic space within a class, as well as to represent the syntactic transformation needs to occur in decorators as far as what if there's anything else we can do. Getters and setters for to define get set or to possibly be able to decorate, the individual get set. There are certainly some options within auto accessories as exist within stage three proposal. There was a discussion early on in the decorators proposal about allowing a keyword colon prefix prior to the decorators, you can say at keyword colon, then the decorator expression. This was something we talked about back when we were talking about whether or not It was possible to decorate an export or several of the cases. So I could see possibly a @get: decorator. It would say, you're decorating the getter. It doesn't help with cases where I want to have accessor transformation that has a getter but no setter where I want to perform initialization. This often happens with collection properties, which is why illustrate this with an array, here. You could potentially have a decorator that you could apply that removes the set function or makes it throw, but then, if that's something that I've seen is a common case in C#, which also has auto accessors. Again, I mentioned that as reference where these collection property is get initialized, but having to reference, some third party library, just for that capability or having to roll it myself when I need it. For something that is has been a fairly common case from these have been used in C# doesn't seem like it would be terribly valuable. So if we do want to look for an alternative, I'd like to find an alternative that matches the majority of use cases that I've seen for this. so again, that's having the ability to find property shorthand. Definition for a property, declaration or accessor declaration. That does is get only, or being able to decorate the getter and the setter.
RBN: Right. So, from what I understand, it sounds like we're not currently in support of advancing to stage two. I would like to have some of the folks that had some concerns about design chime in on the issue, tracker to provide some additional feedback so that we can start a discussion about what they do and don't like about the design, what changes we might be able make. And this proposal is tracking the decorators proposal. We've been discussing it within the decorator stakeholders call that has been going on pretty much every other week and has been going on every other week for several years now. So, these are things that we've been discussing holes that we're trying to fill. So we definitely would encourage folks to participate if they're interested in direction of this. Thank you.
RPR: All right. Thank you, RBN.
- Proposal does not advance at this time
Presenter: Robin Ricard (RRD)
RRD: Okay. So today we're going to get as symbols as we can have keys for stage 3. We're going to do a brief recap of what happened with this proposal. Then we're going to go back. Demonstration for this proposal in the first place. We're going to talk about one thing that we discussed last time, which is single restrictions and then we're going to go through the stage for process. So, first of all, brief history here, is that in May 20 21, stay free was attempted and the proposal was unsuccessful in getting to stage 3. We mainly because there was a lack of motivation for context at the Record in to go wasn't adding a primitive type? That be at the time called box that was able to refer to objects from within and other primitive. So at the time these this specific feature of symbols as weak map keys was not motivating enough because it was already covered by another feature inside of are identical. But in December, 2021 with the committee to record into Bowl champion, group, chose to leave bugs, and so at this time, we called it object a solder aside and pursue symbols as we commit Keys instead because there were some issues around books and object placeholder and symbols. As many keys would seem a good compliment and better way to achieve the success. You are things initially. So, that brings us to the latest update that we've done in January 2022 to where we discussed registered and well known symbols, and there was a bit of luck in there and discussion mostly to be clear. This discussion is not new and it was already present in May 2018. When symbols, as keys was discussed in the X-Men 26. To issue tracker. So, this has been a long ongoing issue and we're going to come back to Solutions here. but first I want to restate motivation. So the motivation now is that we have two upcoming proposals that have primitive only features. So record and tuple can contain other primitive types, so that means that at this point if one Trevor objects from within record and tuple, go, it's going to be more difficult. Got the idea is what if we had symbols to do that and color. Boundary in Shadow Realms also has the same constraints. So to remind you, we took the decision in December, 2021, that who are not going to pursue a box or object Place older, as part of records and tuple. So, in order to make the following feature that is in small good example happen. We need symbols as WeakMap keys. So just explain to you what this code is doing is that it's creating a ref. So the ref is essentially, makeRef is essentially going to return a symbol that's going correspond to the object returned by document dot query selector here. And we, if we just look at what is node dot element, node being a (?) occurred here. We see that this know that element. A symbol but that symbol if used here F function on it is going to return the underlying object that's being pointed to from T symbol. This is a strong person library that we didn't make yet, but we do intend to have this possible alongside record and tuple and in order to make that library, not leak memory. need symbols being with my cheese. Otherwise, we could just use a map but obviously, the map wouldn't be able to track the single going out. Which brings me to another thing that we talked about in the timeline, which is the symbol restrictions. So to be clear given the motivation that we have this proposal. The only thing we really need to power this snippet of code I just showed you is the ability to put unique symbols as WeakMap keys. So, this is the main thing we want to happen, happen, is being able to it's unique symbols as with many keys. However, and that was the subject of discussion, last time. And then, because we discussed with multiple people, but this since January, so for registered, symbols implementations, have the freedom to choose whether registered symbol is always alive or not. For example, Spidermonkey doesn't always keep them alive. Well, Jesse and V8 does keep them alive right now, this Is a distinction where we don't want to assert what engine should do here and already differ in Behavior? Mumbles, well Known symbols, but unlike register. do not have the same property. So for example, all implementations cannot collect them right now and we want to avoid a special case by disallowing them. So there is no reason to disallow them. So we're going to avoid disallowing them at the moment. And then the general idea is that symbols are quite split into what they are. What we've seen here is that we're already got unique symbols, registered symbol, and well known symbols, and it would be eventually good to have a way to disambiguate them at runtime. So that's why we have a possible Stage 0 proposal that we created that could enable the addition of symbol predicates. So this one trike is be able to say if the symbol is registered or is well known the main question is why won't you do is valid with my predicates is mostly for forward compatibility issues, if we create that predicates and today we say OK, that predicate except subjects and this kind of symbols, then that's it. We cannot evolve that predicating. In the future and it would freeze the behavior of what is a weak map entangled. And in future, so that's it. That's the the decisions we've taken so we had stage three review. I also believe Matthew has been also giving us reviews recently, and I think we're almost done here and I guess that Mutual some editors. Changes. We should be ready for stage, 3, 4 that. I just want to look at the queue.
Thank you, the queue is currently empty. And make sure that comments. It's my audio getting through. Yes, it's good food. Yeah, so we have 1 new topic to new topics volume. I go ahead.
WH: I support stage 3.
thank you, And the next speaker is JHD, please go ahead.
JHD: Same thing, +1, nothing to add.
Thank you, JHD and MM, you’re next.
MM: Sorry. I've been so close too quickly. The just want to clarify one thing about well. Known symbols. is that there's a bit of confusion about whether there exists, a well-known symbol. That is not a string name property on the symbol constructor. There is one that comes from Intl. That is treated as a well-known symbol by two of the browser engines, but we took a look at the spec text, especially text is quite clear that that symbol should be fresh would be a new realm, So, the implementations that treated as well known are are not in conformance. Firefox. SpiderMonkey is not in conformance. And so we need to be aware that needs to be fixed. Once it's fixed, there is a invariant that the language currently obeys that, I would propose not necessarily in this proposal, but I would propose become normative, is that the well known symbols are exactly the string-named symbols on the Symbol constructor. because otherwise when you - let's say something passes the well-known symbol, that doesn't mean that you know how to get that symbol from a new realm. You just know that there must be some way to get it, which would be very unsatisfying. So with all of that clarified. I support this for stage 3.
MM: What is? To your, could you remember the name of the symbol and question?
I think it's just fallback symbol in Intl it's only reachable. It's only reachable through a weird execution pattern and specs. It is supposed to be pure realm but V8 and I believe Jesse both implemented as cross realm. And yeah, so basically we would And I think we should have a test for this. I think there's an issue open and the implementations fixed.
MM: Yeah and once that's fixed and then do have the invariant and and with the invariant in place, then the well known symbols are also discoverable in a standard way. So I just wanted to make sure we wanted to clarify all that and to bring the attention to V8 and JSC that there's a nonconformist that they need to fix. The fact that Firefox / SpiderMonkey does this correctly establishes that it is still web compatible to do this correctly.
RRD: So, Yeah, it's just from the champions' perspective, we do think that they should be clarified in. This is possibly something that should be clarified as far as a symbol predicates. Because if we're going to Define what is going to be a well-known symbol. It's very much here that needs to be figured out.
YSV: To confirm, Mark. We know that there is an open issue for this one symbol case is not entirely, apparently not tested in our test suite and possibly should be you, mentioned, a few other things. Do all of those have issues opened on the repo.
I do not know or was that the only one? Okay, let's make sure we go to the notes that make sure it does.
RRD: I believe there is no issue to list to make a, to make lemon symbols and have the invariant that Mark talked about, maybe we should have been one.
YSV: Yeah, to make sure that we capture marks concerns here. Let's make sure we have an issue open for that for further discussion.
MM: Thank you.
DLM: I just want to say that we also support this for stage 3.
YSV: Thank you, Dan. And that finishes the queue. You have 4 explicit votes of support. Would you like to ask for stage 3?
RRD: Yes. I'm going to ask for stage 3.
YSV: Any objections? [silence] The queue remains empty. It sounds like you have stage 3. Congratulations.
RRD: Thank you.
Stage 3
Presenter: Shu-yu Guo (SYG)
SYG: so as a reminder changer a by copies already stage 3, and this is something that we noticed during implementation. So this is implementation feedback, but it is a normative change, but we believe it's fairly small and one we should make. So, the motivation here that we're we're implementing with method on typed arrays. And see this note here down below. Step 10.b.i may return abrupt completion because value is a value of any ES language type and is passed to ToBigInt or ToNumber. And this is the step there, and value is the value argument. So, nothing is done to value before it is passed to kind of override the actual index in the copy. So with, as a quick recap, creates a copy of the receiver and then replaces whatever previous value was at index with the new value that's passed. And typed arrays have additional coercion that for the typedarrays, the value must be coerced the big end and for the other ones that must be coerced to a number and then to an integer. It's okay. So this coercion the current stage 3 spec is delayed until mid iteration. Why is that a problem? That is a problem because that means you can construct a weird evil value such as an object, with a valueOf hook that can do things like detach the array during the middle of your iteration, which complicates implementations as having to check for detach it nests and other things. And with the resizable buffers proposal you also have to check for resizes after this particular call to set the iteration.
SYG: Now, this doesn't have to be the case. There is precedent in methods like TypedArray.prototype.fill where we coerce up front, where's steps 4 & 5 here coerces, the value upfront by snooping what is content type of the receiver typed array, if it's bigint do the bigint coercion up front, otherwise you do the to number coercion up front. This means that, after this point, the iteration itself is not going to be executing user code. It's not going to do weirdness like the attach the buffer.
SYG: So, I'm going to switch tabs yet again to show the actual proposed change. The actual proposed change I am proposing here for the stage 3 proposal is to do that to do the upfront, coercion for the value and not do it mid iteration. So that by the time we get to the emitted radiation, we know that value is either already a bigint or a number and therefore can no longer call arbitrary code. And do weird things like the touch. And that's it.
YSV: Thank you. So going to the queue there is one topic on the queue which is from Ashley. ahead
ACE: Yeah, just sorry. I missed this in the initial stage three texts. This makes perfect sense. I support this.
KG: I support.
JHD: +1 validation should be as early as possible.
YSV: Thank you, JHD. Yep, and the queue is currently empty quickly. Switching to my Mozilla hat. Thank you for catching this issue. I think this is a good change. Back to the chair hat. Any further comments on this from folks?
WH: I agree, we should do this.
ACE: This has started shipping Safari Tech preview, but without this change, just so people are aware.
YSV: Yeah, on the Mozilla side. We were about to ship as well. So it's good that we caught this early. Shu do you want to ask for a consensus to merge in this normative change?
SYG: Yes, please asking for consensus.
YSV: We've had multiple plus ones. Any objectors here? [silence] the queue remains empty and I'm not hearing any objections. It sounds like you have consensus for this normative change. All right. right. Thank you.
- Consensus for proposed change
Presenter: Firstname Lastname (FLE)
KG: So I presented duplicate name capture groups yesterday. It got conditional advancement to stage 2, pending review from Waldemar who has now reviewed, and I have addressed feedback. Waldemar found a couple of bugs in the spec text and then there's one normative change, which was that previously the property iteration order of the groups object on the match result, and of the groups property on the match indices of the match result — the iteration order for those properties depended on the actual string that was matched against in a way I'm not going to go into. And I've now updated it based on Waldemar’s feedback and discussion on Matrix so that the iteration order is deterministic. The property iteration order will be just whatever group name first appears in the literal regex. So, having made this normative change, I intend to come back in July, and ask for stage 3 with the semantics as currently written. WH and RGN have both reviewed. That's the update.
- Proposal is unconditionally stage 2
Presenter: Ujjwal Sharma (USA)
USA: Yes. I assume. Yes. Okay, let's go. Hello, everyone. Welcome to Intl.durationFormat stage, 3 update. RGN is always coming up with the good, the most difficult suggestion. Okay. I'm USA. if you haven't heard from me yet. Let's go with the integration format update. So like any other tragedy. Oh go on. Mostly kidding. This is broken into different acts. So first, we have the first step, which is the bug. For background, DurationFormat went to stage three a while ago and while implementing it, Frank uncovered a bug in the spec text appropriately. Filed it at the GitHub repo, but let's talk more about the bug. So in the format function, which is for basically, every internationalization constructor class, whatever you might call it, one of the most important points of calling them, we call the ToPartialDuration. Is an abstract operation, right? But what does this do? So ToPartialDuration is an abstract operation from board from temporal. It, accepts a duration, like, as the input that this could be an options back, but it could also be a duration instance, just because the getter just work, right? So it doesn't have a special path for duration instances, but they just work and it returns a partial duration record, right, which a record. Like any other record in this spec, but it's a duration record. It has all the fields that are valid for durations, but unlike a duration record, it can have certain fields That is undefined if they don't exist, duration, records. On the other hand have these fields. Set to zero. The rest of the code is assumed that no undefined fuels would be around. So, we clearly needed a duration record and not a partial duration record. This was a bug. This was clearly an oversight and needed to be fixed. So, here comes the bug fix. I saw the issue, followed by Frank and I rushed to fix it up exactly a few months into it. But yeah, so I made a pull request that switched from ToPartialDuration, where we were a while ago to ToTemporalDurationRecord, record since we needed the original record, I felt okay. This is what's going to work. surprise. So yeah, we switch from this abstract operation to this one, Some Salient details about ToTemporalDurationRecord. It accepts also a duration like, with an options bag, which could also be a duration instance. As well as valid duration, strings. So, any string that could interpreted as a valid duration, right? If you remember, these are the iso 8601 duration strings. They would also be accepted by this. It also returns a duration record, which is exactly what we needed since it was assumed to be a bug in the original spec text And not some, some major change. I was keen to fix this as soon as possible. And unblock implementations. As I mentioned, there is a problem though. This normatively changes everything because do them for temporal duration record, also, accept strengths. This was an oversight. So here comes the a free which is the concern as soon as I mean, yeah, the hint is in the title, right? It's why is it normative to fix this bug by? I switch from A to B without noticing that there was huge scope creep happening here. And in JHD, thankfully pointed out but sort of tangentially, right? JHD’s concern was that we were using an AO that doesn't really exist in any sort of existing spec. It's just something from another stage 3 spec. So, it shouldn't be accepted. But this made me. So this is a valid concern, but not one that I thought about at the moment just because this was not exactly related to this one PR. We were moving from one abstract. Ation that didn't exist to another abstract operation that it exists, shouldn't be a problem, right? Well to quote, JHD. I'm sorry, JHD. I think it's a big issue to assume that one stays three pulls all the land before another this one seemed likely far simpler and faster than temporal. so lonely. Sorry due to its size if this proposal must Wait, for temporal. That's something that the plenary needs consensus on. So, now this was a concern and this One, that made me think more about the situation, these two problems, right? First of all, the one that JHD pointed out, this proposal depends temporal as it is. And the second which I found out which is probably more urgent. Is that there is a bug string parsing should not be allowed especially without temporal because string parsing is is not only a complicated Beast. It's completely specified completely specified in temporal. For instance, if we go back to It's the original AO. it’s trivial to copy over some, some of the content to this proposal as assuming that it will land before Temporal. However, if we include string parsing, that means that we have essentially the whole grammar and everything that comes with Temporal required for this proposal. So, so how do we deal with that? Here comes the app for the reconsideration. The question that I wanted to ask people to one that I was not sure about, is, that does duration format makes sense irrespective of temporal in a world where Temporal does not yet exist in browsers and other environments. There's duration format, still make sense. And I took this question to the TC39 TG2 internationalization working group. And the answer that we came up with was: Yes, This functionality is useful with or without Temporal. And something that becomes more useful, it can probe, of course because it adds first-class duration objects, but nonetheless would be useful. So the solution that we came up with was that duration format will explicitly avoid depending on Temporal at the moment. This means that it will be a sort of stand-alone proposal without any hard dependency. This means that only accepting options bags and not strings. Duration instances might be accepted by coincidence because, you know, the Getters would just work, But not intentionally, No special casing for anything that's strictly temporal, and right. then the, for ergonomics, follow-up can can later add support for things like strings, So you can throw a string into a duration formatter. a string that can be converted into a duration object trivially, and durations if needed. Well, it's durations would just work as soon as you get something, but you get the point, right? And and this one would be blocked in temporal because the logic of converting the string into a duration object is in Temporal. The question that I end up with that, I would need guidance from the committee on is, how should we do this? There's three ways to do this, right? We can either merge the follow-on part into temporal. This would be transferring Stuff from one stage 3 proposal to another stage 3 proposal. This is not something path-breaking. Temporal already has a substantial Ecma 402 diff. Temporal. already changes the behavior of date-time format in order to accept, you know, be the new Temporal Constructors. It wouldn't be to out of place. if Temporal also added to duration, format, this is part of this Ecma 402 death. Another thing would be to split this into two distinct stage three proposals. So there would be one stays three proposal, which is just the pure duration format that it only accepts the object, the plain objects, and, and the other one that adds support for temporal duration, as well as strings, that would be explicitly blocked on temporal. Or the third would be to move the follow-up part into a fresh proposal start from scratch. If folks are opposed to both of the first two options. I numbered them as such because they are in my order of preference. I think the first is not so outlandish and would take the lowest extra effort. The second would be okay, I guess, but would take some effort to move stuff around and so on and the third would, of course, course, make go to make us put an entire proposal through the whole stage process. So that's it for me. And now I'd like to open the floor to suggestions to questions to queries, whatever people would like to talk about.
RPR: At the moment, there is no queue.
SYG: So, clarification, here the They're in any of these three paths that we can choose. There are no normative changes. It is just a matter of how we move the parts that depend on two. Temporal. Where is that?
USA: Right, that is the case. Yes, this old tree are, it's hard to say, right? It's, it's normative in the sense that it would move functionality to one place or another but overall, doesn't add anything extra. The only difference It makes for duration format is that it would unblock duration format on temporal, allowing implementations to implement and ship it before Temporal, which is currently complicated; it might or might not be the case.
SYG: Right by normative and men in the eventual state that we have both shrimp. Temporal lender
USA: yes. This has absolutely no.
SYG: Okay, in that case, I agree with JHD that it seems just going to be true that Temporal will land and ship later and duration format. So given that I would prefer one. It's I see no reason to create an extra proposal. For this.
USA: Thank you. Yeah, I another thing. Maybe SFC might be to add on to it. But I'd like to point out that this is also the preference of the internationalisation group as well as of Unicode because this would allow us to iterate more on the duration formatting on the ICU and CLDR side Texas. And can you confirm that?
SFC: Yeah, that's one reason we wanted to decouple these, because there is some work that we need to do on ICU and CLDR side, and it would be good to have these decoupled since Temporal is still a little ways out from being completely landed fully. Another issue which may influence this question… this is a separate comment, so I should put myself separately on the queue for it, sorry… is that the Temporal.Duration toLocaleString function is not well-defined unless DurationFormat is defined. So, I think this was one question that came up from the ECMA 402 task group. So one advantage of doing option 1, putting this in Temporal, is that we can then make the toLocaleString function on Temporal.Duration work properly because if we go with the assumption that duration format lands first then this is a well-defined operation. Otherwise, we have to land Temporal with a non-functional toLocaleString on Temporal.Duration.
LCA: Yeah, so maybe I'm misunderstanding this but I thought you said that one of the changes from moving from partial. I forget the name of the AO, but from the partial one, the to the temporal based one, is that the temporal one? Support string duration formats, which we would not have prior to temporal landing and adding that would be in order to change or you suggesting that duration dot format would not support the string duration format. As I said, I said format too times.
USA: That's okay. Yeah, if we well, so so, so this way not decoupling them has. has is sort of disadvantages on both sides, which is yes if we do go ahead with adding string parsing to the current duration format proposal, then that is a normative change, but since that was not a part of duration format, when it was approved at stage 3, if we remove it again and only handle option bags. Then that would not be a normative change,
LCA: right. Okay. I understand. So, I guess my question here. Is does merging this x. Let's say we were to this in Temporal, it would still not support the string duration format. In any case, supporting the string duration format would be a separate proposal. Is that correct? Are you suggesting that if this? Like if the parts that depend on Temporal, get merged into the option one that would include having these finger Asian format is supported by until duration format.
USA:I am confused now, I think. I think temperatures, So I feel the Temporal should support the string parsing, right. And I think it should be. Would that be a known reference to Temporal?
SYG: Now that I think it. Let me see if I can react question, because I now have the same confusion. Okay, before so currently, okay, before the fix, before your attempted fix with the partial duration. Record and stuff. Where's that? The string, parsing Behavior? So one did the string parsing Behavior exists and two if so, where did it live in terms of the spec draft?
USA: No, there was no string, parsing of so you're you're right string, string, parsing to temporal would be a normative change to Temporal,
LCA: I would be totally fine with but I guess it would probably be more process to correct if this was going to separate proposal.
USA: Yeah, I mean, I guess we could get consensus on just going ahead without it in duration for met at the moment and I could consult with the temporal Champions group to to talk about if they would like to propose that normative change or make it a different thing I guess.
LCA: Okay. Thank you.
DE:. Maybe I'm missing something. It seems there. We're in terms of practicality. What is when and how should browsers ship these proposals like in what order another one is when should things go to Stage 4. For stage 4 feels a little bit like temporal and duration formatter and if you're trying, there may be heading to the stage for together unless we artificially, am I misunderstanding. Unless we artificially split up duration format.
USA: That is what I'm proposing. Yes, at the moment. It turns out that that is the case, but we're proposing that we split up duration format so that it could proceed both implementation and And well, later stage 3 wise, without being blocked Temporal.
DE: So, historically, what's happened with proposals at stage three is we know, know, we know that sometimes, They shape and browsers and also sometimes just part of a stage three proposal ships or part of multiple stage 3 proposal ships and other parts. Don't we saw this happen with class features where different browsers ship different fractions of them and eventually they all shaped everything was everything way ended up being fine because we all agreed on the semantics. Browsers were conservative to make sure to ship only semantics that we agreed on in stage 3, And that seems like a fine operating principle here. I spent a lot of time with class features refactoring it into Different sub proposals that ended up being extremely confusing for the community of people who is trying to understand what was going on with class features. The factoring really didn't end up making sense from a developer perspective based on that experience. I'd be hesitant to just split things up. again. We have these multiple proposals at stage 3. I don't think, going to say going to stage 4 will block them shipping. It won't block shipping part of them. them. And so, I'm I think it's a little bit. I don't think there's normative content towards refactoring. These stage three proposals. and because we have this this, you know, practice of shipping stage three things or even shipping part of stage three things. We could say, as a committee that we want to discourage browsers from Shipping parts of stage three things, but that would be, you know, that would be a new new thing to establish. And so right now I don't think the factoring has this is normative content.
USA: Right. Well, as from the point of view of a proposal author, this would be less work for me. So I don't mind it. The only thing is that implementers insisted on making cleaning up the, the spec part to make sure that they could implement it. I know Frank would be keen to implement this as soon as the Spec's lined up perfectly, but yeah, if if implementers agree that they wouldn't mind having this disconnection between duration format and Temporal and it wouldn't block them from implementing duration format before temporal. I think we can go ahead.
SYG: I'm just super confused now. DurationFormat is already its own proposal. My understanding of the situation is that it's already its own proposal. There was bug, then fix up the bug, created entanglement with temporal. This is attempt to disentangle?
USA: one minor clarification, it was somewhat entangled even before the bug fix and the bug fix only exacerbated that and made it more evident that we needed to disentangle? And yeah, it is its own proposal. But now the question is, does it split up into two proposals? One of them blocked on temporal, does it transfer functionality to temporal. thing that I didn't consider was just does it State's own proposal and and get implemented in parts?
DE: So this is all about abstract operation logic how that's distributed among the specs, you know, for private class features. I did a lot of that moving around and all it cost was confusion for everyone. reading the specifications. So I'd recommend against doing that. I think you should probably just leave it in one place and make the reference from one document to the other. Even if they're both at stage 3. Like I think both these proposals are going to happen.
USA: I agree that that both of the proposals are going to happen,
SYG: Okay, so I don't understand what it means to partially ship stuff here anymore.
USA: What I mean issue by partially shipping Shipping stuff is the ship duration format with the functionality of only accepting plain objects, and then later on adding support for for other types of inputs that are blocked Temporal.
SYG: Why would moving the AOs that support the additional follow-up functionality into temporal make the situation more confusing.
USA: Temporal already has AOs that support this functionality. They are used to construct new duration instances. And yeah, like
SYG: I don't understand DE's point of like, what is like, what is made more confused by 1 here?
DE: 1 could be fine. I think moving things around is confusing. You end up with different references to different things. I think we just have these two stage three proposals, and it's fine for people to ship different parts of them. That was just my experience that it caused them out of his den with nothing either. Well, it was so fun. I'm fine with one. I don't have any objection to 1
USA: Maybe I could simplify this by saying, do we have consensus on the first, which is change the… Well, this would not technically be a normative change for duration format, but somewhat a change of expectations with the committee that duration format would be. Would be changed to explicitly have no blockage on Temporal. And that any ergonomic improvements that make it easier to use but temporal, as well as the use of strings would be proposed later as normative changes to Temporal. Does that sound good?
SYG: Okay, so I think I finally understand DE. I think what DE is saying, is change nothing to the specs, but do the moral equivalent of one of just shipping the parts that don't depend on temporal.
DE: Yeah, exactly. Because I got a lot of recommendations from committee to do these refactorings and they really didn't help anybody. They just made things more confusing. So I said now that we have these multiple stage 3 proposals. I just don't want be, you know, repeating that, that kind of, that kind of error. Maybe it, maybe it wouldn't be as bad of a problem in this case because these proposals are less confusing than the, you know, the different dimensions of debate back with class features, but yes.
SYG: Yeah, in this case. I think the important thing. Is that okay, So I want to do the moral equivalent of. I wanted to have the Practical outcome of one. Whether or not that it makes sense to do for the spec drafts I guess. I don't really care very much about but I do get the sense that the temporal aspect draft is still. Under some flux, they'll it's slowing down maybe, but maybe that's consideration whether you would want to move them or keep them as this, keep this backdrop the same right now. But anyway, I guess I don't care what the actual where the AO lives. Never mind.
RPR: We have one minute left for this topic. There's two people in the queue.
SFC: Yeah, since we're at time, I don't have a lot to add except to say that, you know, the question here is really a process question. I just want to clarify again that DurationFormat was its own well-motivated proposal that happened to coincide with the Temporal proposal, and then the two got tied together with this string parsing operation that they're using. But they are two separate, independently motivated proposals, and it's not like one is a child of the other. And I think that's part of why we wanted to do this refactoring, to make it clear that these are really two separate independent proposals. That's all.
MAH: Yeah, so really quick. I have to I don't fully follow duration format and temporal and the layering here and we were not able to review this because the slides were not posted when we looked at them late last week, what I want to clarify is this is about abstract operations, and is this is pure. there is no impurity moving something from one proposal to another. There would be no impact on the visible expose APIs to the user. Right?
USA: absolutely not. The only difference would be that the version of duration format that would ship at the beginning would be a What less ergonomic one, it would only accept plain objects. If you could not allow you to just throw in like a string value that you get from over the network or something. That's.
MAH: Yeah. I basically don't make sure that we were not leaking International and local environment into temporal somehow by doing anything refactoring
USA: No, that would not happen. The only thing that would happen. that okay, looking at DE topic? But yeah, yeah, nothing of the sort would happen. The only difference that could happen Is that temporal would they would be a normative change to temporal which would assume the duration format exist and add certain functionality to it too. to that is Based on certain operations that are not Locale dependent, but that do involve things like parsing duration strings.
MAH: Thanks for clarifying.
DE: So say if this is a question to the committee about what the committee's process is my interpretation of the process that we currently have is: committee consensus or discussion is to make a refactoring that's unobservable or two or four browsers to ship parts of proposals. I mean, it's reasonable to be conservative and cautious about shipping parts of proposals and to discuss and coordinate epectations explicitly. But does anybody have any difference of interpretation of TC39 process?
(silence)
USA: I suppose not. Oh, that helps. Thank you. I guess in that case. The the final conclusion is it that will make the necessary changes to duration format to to make it explicit that it doesn't rely on. It doesn't block on temporal and and for implementations to move forward and Was further.
SYG: Like it is true that historically proposals have been partially shipped but other things being equal, it would be nice to not partially ship. like it will be nice to for that to be rare. So if it's possible to make unambiguously easier to not partially ship something and not entangle them. That would be preferred. But in this particular case, thank ya feel very strongly Either way.
DE: Great. Yeah, I agree that it's preferable to not partially ship things. Maybe it's a suggestion you could use an editor's note. If you're going to partially ship a proposal and editor's note, good described which part is shipped in which places and that could be used to coordinate among engines. I think that would cause lot less churn. And confusion, then splitting it up into multiple proposals.
USA: Great. Thank you. Then. That's all. Thanks a lot for these. These suggestions. Will take them to heart in. Hopefully come back in a few months to to give updates about duration format. format. you. Thank you, all.
Presenter: HE Shi-Jun (JHX)
JHX: Okay. Okay. Can I cast our yes, please do start. Okay. Yeah, the function.sent is, this is the updates of the function sense. First of all, for those who not familiar, with this proposal function scent is our meta property syntax, which allow you to use in the generator, And it's have the effects it could use the function s to do a get the Value of from the next. The problem that this proposal try to solve is the currently, there is no way in the generator to get the first value sent by the next. Because you you only can received the value from the yield. But the first valuing sent by next is before the yield.
JHX: Some history of the functions and proposal. It's actually a very old proposal or sort by AWB in 2015, and I'm not sure the process of the early day, but it seems in its I can't find it, the record in the notes, but It seems in 2015 November. It's already stage 2 and there's no much progress until 2018. In that time AWB retired, and this proposal need new champion. So I talked job in 2019, July meeting. Actually. I took on job in my first TC39 meeting. I took the job because it seems is a tiny proposal and it's a good first contribution for new delegate. And I happened to write to the Babel plugin implementation, but it's it's actually have some difficult issues. so, let's talk about the issues.
JHX: First for the first problem is the use case, Does the proposal have good cases in the this is this is the example by written by AWB. here is adder so you can use the functional to get the inputs and the rest of the different inputs and you do some differencing. So just is How it's used writer editor and you can change the increment method and value. And the guess the final value here, but this example, may be too simple and people always ask, is there any better use cases? I think the problem here is that generators are very new feature in 2015, and we need some time to discover the usage of it. So, here are some possible, use cases, I in recent years I try to collect the different use cases of this proposal. And first one is number parser to use the generator to use the functions and to check the average characters. Which you, you could. And send here to the outside. So maybe you can first see the usage? Hear you, You can use to use it and send every character to its and gets the results here. So if so, just you can see the logic here. If first, let's check the the sign and then the Integer part. And then if it's have the decimal point it passes the fraction part and the final age give calculate to the the number. and if there are any character it do not match, what what the syntax should be. It's just a server here. another use case is contributes by I don't know how to pronounce his name, but he posted this use case and is released. And basically, he writes a Pagination, which you can't use it to get error page. pager is fetched from the remote server, but it it's he wanted to pass optional options, which is about signal. So if it's out the factory is just about it. So this is the code here we can see the hear that. This is a generated here and the use, the use function sent here is used to function and sent to gets to see the abort controller and pass it to the another method this uses in message to fetch the next part of the next page. And yeah. In the, there are also new proposal Stadium proposal double-ended iterator. Let's use next value to. So it we can gather the first store and the last value here because the destruction depend on the iterator protocol. So if we want to support the double-ended destruction, we also need to operate the iterator protocol. So this is how you can Implement that using a generator? General, roughly the current array iterator is just just this line, but we can add the Z statistical, simple code here to check the track, The value parsed are staying and to, and give their last value here. So, this is a use as usage in the double ended in a proper structure and iterative proposal. And this is the my favorite use case. I got this from one of my friend. He is tennis fans, but tennis have a special Convention of the score. For example, they, they called 0, not 0 but love. So if someone have the party, it is 15-love. Of being so a 10, very interesting convention here. So this tennis game score. Is it could accept a value here to tell him, who win the next point, if the server will win the next part, it's reports the score as 15-love and so on and there are special case here. if they both have three points in and say have the same points then it's Deuce. Here's the how to use the generator to write that use the functional sent. Here. It adds the added points. or for the server or the receiver. And you can see the logic here. There are two parts. Want you to the first part is deal with the when they have the score below the deuce threshold. And if they have, if the is go to the next part that you think it's cool to care, too deal with that. of course, you can write, it logically, you can it. Not use the generator. For example, you can use a class to write it, but the code will be longer. It's will become longer because you need to separate the logic into small methods to make the code more readable. And there are some special logic here. To deal with who win the game. But in the general true version is much simpler. If you just written here, you do not need that special treatment. So, here are some summary about use cases. You can see it. There are different use cases here.
JHX: And the next is, let's talk about the, I think the most serious issues and I mean issue. Yeah, naming always a big issue. It's the number one issue in the issue list. Before we discuss it, we need to recap The go just go of this proposal is allow accessing receive the value. This value is sent by the next in the general function body, especially the first to receive that. Translators proposal use the matter property syntax. We currently have two meta property, new.target and import.meta. And this proposal to another one function doesn't but they did. There is problem this function does Santana, is this implies? It's a feature applied to all functions, but the functions actually only makes sense in the Generators. It also costs, another prominent speaks. It is not a naming, but as a consequence of it's so how functions work in generator functions. it is. It's a syntax error or just give you and undefined all or it's lecture note here, the new.target well, well, give you undefined it in normal function and And it's actual actually in the well, give you the actual new Target to in the arrow functions. So can forward that, but they are another serious problem. What about the arrow generator functions. If we have it, there are proposal for it, though. It's still a very early days. But but it's it's I think it's a problem because if we allow the functions work new Targets in the they are here. so, I think that many people may want to use the yield.sent instead, and or something like but the yield also have some problem here first. please remember our goal is, to access the first receive value. but the first value actually has no relationship who is here, Yes. It's actually before any year, the expression you could have a general function which have no yield expression. You should be course, two cats, The first to receive the Valium. and another problem. which AWB already points out in the issue in the comments of the issue. The ear doesn't, is could be a normal property outside the generators. So, if we use this syntax is surely a little bit, it may cause some confusion, especially if we check these things. We should note that in outside generous the day they are give you the same semantics, but in the generator meta properties. It's not either actually how very different semantics here. This is. I think it's this costs a bit, it potentially, it's cause big confusion. so, as the champion of this proposed, I, I agree with AWB. Yield maybe not a good choice here. Another part the naming, the sent is all so confusing here. yeah, I think it's I don't you stand because it's a value which sent by the generator object on X, but from the perspective of the developer. You are write code in the generator function body. You just received the value. So the sent here is somewhat confusing here. and another problem is actually, it's not only sent by the next day is also possible to stand by the parent generator and it could uh, you could write to the yield star and the return statement here. Will it give you that value? so, in the naming is there are Alternatives name. It seems people are much like ‘received’. I also preferred that name. So there may be some Choice here as we discuss. The function.sent is not a good name and the yield is also not good. So, the only choice I exist to I listed the var.received here because As we? Function is not is confusing about well, maybe maybe better, but I'm not sure about that. So I also listed it here, but they're also another serious problem in is the developer expierence. That's problem is repeats throughout assignments on. Actually, this is another, I think this under the motivation of the proposal that if you want to receive the value of 2. If you do not use function.sent and to you need to write code like this, you and it need to. You need to repeat that. So after every yet, but the permanent here is All these metal properties, these names very long even. This is the shortest of but the still have about 12 letters, characters, and the apartment is, is especially of was because there's no way too short. For example, this is the number parser example of before. As we are, we we want to do want to rip city to the function sense. Its name is too long and not very pretty descriptive. So I can write code like that, but you need to hook repeat the Moment you again, you need to repeat, assignments. Are after the, after all the yield and it's actually very easy to miss. here. We have a random assignments, but, at least it's not harmless, but if you miss here like this, I miss the reassignment time and so I just Introduce a bug here. So, So eventually people may only use the function sent here and use the pattern here. I just write every reassignment here with the yield. It's just not, not very good, good, good here. well, one possible solution is if we have the error function, which is actual you. Can you can write this but we already discussed that in use the error function to function sent in our function, is also have issue. Another problem, problem possible. Possible solution is the proposal, but it's you stage 0 even though you have it. So you finally, you will always need to at least a you need to, right? Right to our dislike on. So it is Okay, so let's rethink about the golden. The goal of this proposal is, is allow accessing receive the value sent by it's on. So what is the function functionality actually the argument of the next? So instead of the meta property with alternative desires, we use receive param syntax. And the that means is you just use our upper arm syntax to to to the value because its original is Sir parameter of next. so we can check the use case Rewritten and receive intense. This is the simplest example, and not that. And We can see here. We remove this line, and because the it will all true magically. Updates. So it's work like that. And for the number parser example, now the code is much simpler in. and you don't need to repeat the function sent everwhere. And this end is this case? We see we use the function send here on This is also exposed another issue of the functions and that if you read the code, you see the function here, brother. You don't know what what is it? It's it in four. What's the residual program syntax? You actually could have a name good name for it. It just options and another benefits is now Now can add type on notation for and in a meta property, syntax tax. It's very hard to add the type I have a separate issue a separate issue for it in the repo. And if you, if you are interesting that you could check that issue. So now it just work because it's just a parameter. So, so you get are every Everything which normal param have, this is the disruption and it's very seriously. seriously. Now is Walk like that. The and I think it's make the signal much clearer, and this is the last use case and I intentionally use long name here, but it's I think it makes the code much clearer because in here, the function is not very clear what it, what it is for. So now, It's clear. That's the. It means who win the next points.
USA: Hex, one thing is you only have four minutes left.
JHX: Okay? Okay. I just finished. So I think the receive permits in could just the sort of almost all issues in the concurrency, some of the issues. I'm not not explain here, but for example, the function dot need some spec work to make the work, but now it's if it's a received from we do not need that the only possible issue the received param and syntax is the value of receive param will update to automatically after yield. But function sent event though a meta property. It's also updated automatically, so I think this is maybe not very serious. so, the next step of the proposal, of course, I want to collect the feedback of the received param syntax, and if that, okay, I will rewrite, the spec text and deal with the left issue. There's no much left with this. You if we used to receive params in task 2, only one is the number 3 three is two. I will introduce it here in future meetings. Okay, that's it. Can we check the queue? Okay.
USA: Yes. Sure. So you have two minutes and three items in the queue up. There is Matthew.
MAH: Hi. I'll try to be quick first. Thanks for picking this up. It's not an easy topic, especially for your first one. Yes, at the time. We're really interested in trying to find a solution for this, Like priming generators is very unergonomic right now. However, I wish I had seen these slides before. It's a lot to take in but I have a big concern with this new syntax. This basically live binding. By this received syntax. it's one of the advantage of functions. And is that only the direct scope of the function had the send value available. So since it's live and updated after every yield, what would happen? For example, for this received binding if you had an async generator and inside the using a yield star, but also having a nested a function inside that closed over this binding. Would it now be able to observe the value of the yielded value update through the delegated generator. All-Star. It's just, yeah, it's I think the fact that it live updates with this syntax, is he's going to cause problems. And I don't know if you if that was clear.
JHX: Yeah. Yeah, I think this is I think this is this may be a problem. But as I said that the function sent itself also, also updated automatically at the difference he is striving on Kent goes over. Yeah, you need to it to. It will not If we limited this scope of it, so for example, if we don't the arrow function cannot access it directly. So it's you don't have the issue. But the problem is that the cost is the naming issue is very, very hard to solve. So it's the, it's the two side of the coin
MAH: Yeah, I would just say that having more characters to type. Type is not really a problem in my opinion and it's not exactly something most generators would do anyway.
JHX: Okay, we can discuss because that part in the issue and as soon as if you yeah, I feel like it could have courageous strong. For example.
USA: Yeah, we are over time next up we have Jack works.
YSV: Thanks for the presentation and all the work that you've done here. I think you've made a lot of important observations about this proposal. For example, the naming doesn't really work and there are other issues. One problem is my colleague, JTO raised an issue in 2019 stating that he wanted to see more use cases. And you tried to address that, but having seen the slides, I don't think that the use case is strong. Of yet, a couple of people have mentioned on the call that they do have use cases for it. I'd like to see them especially since this is such an old proposal and it has quite a history. And I think that what's being presented here is a corner case. that is pretty rarely encountered and we might have another solution that doesn't involve the addition of Syntax for doing something like this. For example, SYG mentioned in the chat about aliasing, the first next with prime, that's another way we can. Think about it. So this is my concern. It is a much older proposal. It came to stage two before my time, and I would like to make sure that we're not simply addressing this, because of this, because of the history of The Proposal, but because it's truly necessary today. That's all.
JHX: Thank you.
JWK: I think the concern of MAH is not a problem for me. In the old-style, the function.sent only available in the function scope and it's a bit like “this”. If you want to use it in a nested context, it will be very annoying. This new form of syntax we can introduce binding so you can assess it in the nested functions. I also agree with YSV, this proposal looks like it does not have a very useful use case because generators are less used. But I also appreciate the new syntax design for this problem.
JHX: Yes. Thank you. I'll probably use case. I have a one another comments about that because of the time are not list all the use cases. Actually. There are some other use real-world use case, case. For example, the crank. JS framework, they use the generators to and the JSX to replace the react. It is their design. They are some small problem in which the court in general cannot provide, but I do not have time to, to explain the that use case. I would like to write it and in the repo, and we can't discuss it in that in that. Okay. okay. Thank you
Presenter: Ron Buckton (RBN)
RBN: We'll see this afternoon. We talking about regular expression modifiers, modifiers. So are a feature Sorry, in multiple JavaScript engine. multiple regular expression engines and other languages that allow you to specify or possibly invert a subset of available regular expression flags from within the pattern. This is used in quite a few cases in other languages and also heavily used in places like textmate grammars, which are heavily used by JavaScript-based editors such as VS Code, Atom use these TextMate uses them well. Sublime and Eclipse. Also use text make grammars and they try to basically they're restricted to a subset of syntax that's valid across those in places like in VS Code. It's required to use something like node or electron bindings for oniguruma to support some of the advanced features. And while we might never be able to support everything yhat's available in something like oniguruma or across the board. There are other use cases where these become valid. Also interesting useful, when the external sources, what you're looking at external sources for regular expressions that cannot use executable code such as thinking actually don't have an example of the moment such as parsing, jest patterns, for what for what should be imported or looted, if you're working with something that requires something to case insensitive, but you have no control over case-sensitive parsing in their JavaScript language, when the JSON object, for the configuration files. Imported. It's useful to provide that So what this looks like is modifiers are an augmentation of the current non capturing groups. So a non capturing group is in regular Expressions is (? the modifier syntax allows you to add a subset of regular expression, flags that are either on the left or right side of a dash, or hyphen character. So in this case, you would be able to set if it's before the dash or if there is no dash. The ignore case, multi-line and dot all operators or optionally unset, the ignore case, multi-line and .all operators within a sub expression disjunction. We previously also had an Unbound variant that is also had very usage across engines, but we remove that prior to the stage two consensus to kind of simplify the design and go for something that is very explicitly bounded. Modifiers have no conflict with any existing regular expression syntax. They do require Unicode mode or any other special cased mode. And again, they currently support a very small subset of these modifiers. There is possible for future support for extended mode, which would allow you to be able to ignore white space in those cases. So, the flags that won't be supported are things like the global sticky, unicode, or has indices flags gyu, or D, or the potential future V flag. Because these affect the parsing state of the entire regular expression such as whether or not to handle Unicode, code points those types of things need to be defined prior to parsing the entire expression. Also Flags such as Global, sticky, and hasIndices. Don't affect the pattern itself. If They only affect the how the regular expression matching algorithm works and how advances indices modifiers has support within Perl, pcre and a number of other languages engines and this is not a fully inclusive set. This is just a subset of a language that I investigated. Some examples of how this would work. So, see the regular expression here, in which case, the entire expression is parsed, as a case sensitive expression. It lacks the I flag at the end of the regular expression literal. So when we parse the first set of terms within the expression, we know that the character class that matches A to Z is parsed as case sensitive or matches as case sensitive. Inside of the non capturing group that is adjacent to that. We can see that there is now a i modifier which in this case, turns on the ignore case flag within the group only which allows you to control case matching without having to write complex patterns such as I want to match a to z or capital a to capital z. Or if you're looking for specific characters who have having to say A class of a capital, A B capital b, d capital, capital, etc, for very specific cases. There's one open issue that I wanted to bring to me to discuss whether or not it should be legal to both enable and disable the same flag, the proposal spec text currently disallows a setting, a modifiers group that has no flags on either side, which is a no op. Perl, according to documentation, Perl warns on this but doesn't provide an error and only warns on that case, fine. Everything is in is in strict mode. It does not. seemed to provide any warning if you both enable and disable the same flag, the current spec text reflects same behavior that occurs in every engine that I've tested, Which is things are processed left to, right. So enabling ignore case. and then disabling it is disabling ignore case regardless of what it was before hand. So it is not a no op a person. Most likely will write something that That adds and removes ignore case, but it could possibly appear if the regular expression was created via generated code, which is again something that Perl calls out as to why certain cases might be considered safe, but are generally ignored. I am curious as to whether or not we should be more pedantic its kind of come back and forth within the committee even today about whether it makes sense to explicitly. Deny things, that there's no specific reason to prevent them versus preventing them because it's likely that you made a mistake. So I'm curious if there's any committee specific opinion on this and other than these status slide at the end. This is the only last slide, so I'd like to possibly discuss this and open up to the rest of the discussion, the rest of the committee for the queue.
USA: Okay, let's go with the queue. First up. We do actually only be Yulia.
YSV: In fact, it's not me. I'm speaking on behalf of JHD. He asked me to convey that it would be very confusing to have any modifier added and removed in the same current Group, which I believe will be something that you'll need to discuss with him offline. So it's about this issue.
RBN: Yeah, and I do have a pull request open to add the specific early error for having same flag on both sides. If that's something we decide to forward with. I believe his position as he would be in favor of disallowing that.
SYG:I think could you go back a slide, please? The thing I found most compelling up the bullet points, there is the second to last one about. We could be you could be created by generated code regular expressions. I do not use regular expressions, but I have found it on reasonably effective as a code gen target, so and I can totally see how you know for the same reason. We allow trailing commas and stuff in other places that you might want to allow this because it makes code-gen much cleaner. That's a pretty weak preference, but I think if these kind of local enablement flags are going to be heavily utilized by things that generate regular expressions that would put me on the side of we should just allow it instead of having it be an early error. Yeah, be good to know you see that often.
RBN: Yes, do. See that often amongst various date parsing libraries prior to Temporal, when that ships. There are a significant number of existing libraries that do things such parsing ISO date formats. There's significant number of libraries that deal with parsing of incoming text from things like YAML, whole markdown, I think if you look at marked its composed almost completely of concatenated strings of regular expressions where they don't currently use this capability. But since they do use this string composition to build up regular Expressions, this is definitely a case where code gen happens. So this is definitely heavily used within the ecosystem for very large major projects
KG: I agree that these flags are a useful thing for code generators to be generating. But I don't find that persuasive for this very specific case about allowing the flag to be enabled and disabled within the same group, because the only way that a code generator would output this is if it decided that it wanted to both enable and disable the flag. And it is not obvious to me that having decided that, the intended behavior is clearly to disable the flag. I think that probably if you end up in that situation as a code generator, you have a bug and it is better for you to get a syntax error and for you to handle the case when you actually, for some reason, have both flags, to explicitly decide which one you actually want. Defaulting to disallow is not obviously what the code generator even intended.
SYG: Is it disallow? Or is it like cancelled out? So that whatever the outer value of the flag is takes precedent.
RBN: It's read left to right. So if you said as in the example, here question, ?i-i this sets it to case sensitive. So it removes ignore case mode because what it does is set the i flag and then remove the i flag.
SYG: Uh-huh. I see.
RBN: So that is the same behavior that Perl, Ruby. dot.net, and most other engines that I've tried have the exact same behavior currently.
SYG: Okay, in that case. I find KG's argument that the default behavior for the contradiction is off, is not necessarily clear as the right one.
WH: When I first read the spec text “It is a Syntax Error if the source text matched by either RegularExpressionFlags contains the same code point more than once”, I thought that it was already disallowing this case. That spec wording is ambiguous and can be interpreted as the same code point appearing in any of the RegularExpressionFlags.
RBN: that was a change that was proposed by RGN in his review and I specifically made a comment that I was concerned that that would be confusing because I was concerned that the using the term, either might not be clear that is testing first the left one than the right one. So the intent behind that spec text is not to disallow both but to disallow ii:, you have but we also it can understand this can be possibly misinterpreted, which was my concern. But again, that was a review, comment that I made the change And so it is it is not the intent of the spec text that it is already taking this behavior.
USA: That's it. That's That's the queue.
RBN: So this is currently at stage 2. It's been sitting at, it's been in stage 2 since. So it reached stage 2 in December of 2021. I'm still waiting on some review feedback. I've had review feedback from RGN. WH is the other reviewer for the proposal and I haven't had an editorial review. I'm still waiting on those. I'm interested in seeking. Stage 3, but I Have to be I understand that it would be conditional on these reviews or possibly postponing until such reviews are made.
YSV: So again, this is not mozilla's position. I'm speaking on behalf of JHD, as the main concern that he is raising, is that we do not allow the to the the same, the disallowing and enabling of the same flag in the same capture group. I believe that this also extends to generated code. And he would support KG comments, but please verify with him. My understanding is you're open to not, including that. So that I believe would address his concern.
RBN: Yes. I'm perfectly fine with making that disallowed since that's that's something that we theoretically open back up if had enough feedback from the community that stated that this is too much of a burden for those that are doing code generation And these cases, I don't have a strong preference either way. I opted for the more lenient approach currently. We're that was the intent and again, I do have a draft PR that is ready to put up that makes these changes within the spec text.
YSV: Okay, then just to make sure that all of the i's are dotted and T's are crossed. I believe that he would be fine with that. But please speak with him for the Mozilla side. We don't don't have any concerns.
USA: Okay, I think Ron, you have your answer. Would you like to further ask for some?
RBN: So I would like to ask for conditional advancement to stage 3, pending the remaining review from WH and the TC39 editors and this change to be more pedantic about setting a flag and clearing the same flag within one group.
USA: I see nothing on the queue so far.
KG: I haven't done a detailed review as editor, but I am happy for it to advance to stage 3 now personally.
USA: Great. Thank you. Yeah, you have one supporting comment and nothing again. So I think you have consensus. Congratulations.
RBN: Thank you. Great. So Rob, what do we have planned next?
- Stage 3
Presenter: HE Shi-Jun (JHX)
JHX: This parameter for stage 1. Yeah, I think it's we were familiar with it. See if you already use TypeScript. It's TypeScript at this parameter syntax and what this proposal want do is just allow this syntax, so typescript will just this is just added in the type of notation on the disk parameter of JavaScript is perameter, okay? Currently TypeScript and the Flow type already support this syntax and the Java also have this syntax. There is a old proposal written by Gilbert six years ago, Even before T has added this type check, that proposal is much bigger proposal includes renaming and destruction exists. The main motivation of that proposal is solved this This confusion issue because this is always shadowing this. This proposal was presented on two years ago, but not advanced because I believe that the deck is have some concerns about whether the same syntax would be renaming. A data structuring the existing syntax could really solve the issue. And it seems it added too many syntax. And this this Farm is also included the type annotation proposal, which are the ones to to stage one in last meeting. But Strictly speaking. This form itself is not a type anotation. It's it's it is included in type of notation proposal because you need this syntax to make the type annotation of this parameter work. And another problem is I don't taste type annotation proposal is I believe it's just that proposal would try to avoid introduce any runtime semantics, but but I think that this parameter it could have the runtimes semantics. Who it's maybe it's better to to spec in a separate proposal. So this proposal. Drops the features of renaming and it's a structuring of the proposal and focuses. Is the same syntax and the runtime semantics? the motivations of the motivation is has. I think we it's a good thing to standardize the Syntax for TS and Flow, which are already supporting square of well simplify the toolchains and narrow the gap between JavaScript and a TypeScript ecosystem. Newcomers always have some confusion: “What what is the feature of JavaScript and what is the feature of TypeScript?” and a single with back to narrow. This is this is this permanent have been discussed in the last meeting us Just also, if aught of reducing the syntax burdens of type annotation proposal, because in the discussion, think many directory syntax. The current type annotation proposal includes too many syntax, so it's bad. As to, reduce syntax, who with back-to-back the syntax. If it's fit for the separate proposal. Usage type of meditation. Yeah, do we? Are they were doubts types will have flow. You can write code like this. You can go take this, you can add type for this parameter. Here. We we add a type for the handle. Click that. So the this should be HTML elements and also the decorator or this it's really, so I expect we will revisit the parameter decorators in the future. if we have parameter decorator, it should be be able to decorate to the this parameter here. In this example we use the decorator to do a runtime type guard. Instead, of compile-time type annotation. The earlier it's not this, it's just a follow the current TS and Flow errors. So the this parameter should be in the first position and error function. should. Now not have this parameter because our function always use the black Shu's is and the Constructor to Constructor. Also do not have this parameter because it is not argument. The Reflect.construct is very clear that they are no this arguments with, it's not the this in the Constructor, always generate magically or from the superclass. it down the runtime errors. during runtime errors also match the flow behavior. For example here. Because I think we should add. We should make them early. If we use, it is for me to issues should not have the [[construct]] internal method. So it's just a circle type error here and another runtimes a magical week. We think we can introduce is If it's, it's used this farming to makes it expects to be called with this arguments passed in. So if you direct calls, its we could just throw type error here. So if you can only use the call apply or you, add it to an object to and make it like a work. Like a method this weekend chords. So, just just introduce another extra motivation that provides syntax semantics for method. In JavaScript as a spec if you have a property, which is a function. It's just method the, but us developer. I think most developers methods are the front concept. That's that that there are three different type of functions the Constructor, which is actually know this argument and no master that you can order this Armenians and the method it expects this argument that the espalier disarming parsing and ends in the method body if we will use some property on the JavaScriot source. Stand it to some other place since you like that. Before, before es6, we only have the function which when you declare a function it plays three roles, but after es6 we have a dedicated Syntax for constructing a class. We also have the data case in telephone number method of the arrow functions, the always ignored existing this argument. It's always used lexical this but we do not have that. This in-house for method means method. What I mean method here, is we expected to these arguments. So we could use this parameter to for the dedicated syntax for methods. This allows programmers to explicit mark a function as a method. It for you. For example, we have a method here, but actually it's not easy to recognize weather some method on the because the use this thing a very deep nasty, and there are many code. And so it's very easy to miss use that. It's actually not So, here are around used, but it's not easy to discover that say especially We use this here conditionally, so it's possible here, here, the to not really use this. So it will not generally generate any runtime errors. So but sometimes it's well, sometimes it works. So this distance this is where hard for track the to discover the bug in the first place. But if we use the this parameter here and if we could have the runtime semantics I described before, we just got a TypeError and this also have the type error because of how it will work cards directly so it will help the help the developer to first. It's very to recognize. This is a method too. If we use its misuse that it will give the error as early as possible. Another usage is static class. Static methods in TypeScript also can't have these arguments. So in many other programming languages that mass would work. Well not. It cannot use this. So in JavaScript, that's that's a I think I'm, see me several times that people use the stack stack Master, which are used exist. Use this to to get water passes but usually going wrong way. So like this. Now, we add this here, it's just so type error and help to catch the error and you write code like that too explicitly mark this is a special stacked nicely though. It's the static but I still need this still need this parameter here. So make the intention clear. It's also useful to extension. And of course this proposal, for example, this is you can use it in court this proposal here and if you use it like this is Justice. Wrote a book in the discussion the causes proposal. There are many concerns about because the call-this proposal allows you to spread that the methods all over, we are and we have to concern about whether this leads to increased confusion. But at least I think is this could be mitigated by the this parameter for me. So if it's a method, or you can only use, it's like this. So I think it helped to solve the problem. Similarly, the extension proposal it do not use that because it already throws reference error here, but still, it could could be reversible to utilizing the this parameter. So it could only accept the methods which declared in this parameter syntax. If it's Just the so type print out here. It is. Even give a stronger protection. Okay, this summary of this proposal is adopted the TS and Flow syntax and allow you a note taker and decoratives argument and it provides methods syntax and the semantics. OK, OK, that's it. So let's check the queue.
USA:You have close to ten minutes and a big queue.
DRR: Yeah, so I wanted to just mention that the way that this is currently being pitched. We're at this parameter requires some sort of receiver object means that there's There's no real way specify the idea of an optional best, right? So there's not really a way to say “I have a function that can operate with the this or without the this”. In that sense it's not really compatible with the way that something like TypeScript or Flow might work. Where you can I expect at this recipient, but it can be either undefined or some other type. There are some other discussion in the chat as well about how, you know, these languages. Also allow new to work on these functions and things like that as well, but Really do see it as like an erasable annotation thing. Not so much as a runtime thing. So I just wanted to put that out as a topic. It does not really seem like it helps bridge the gap in that capacity.
JHX:Okay, I think the option was this is not not so common case and and it's more like you're the advanced feature in the older proposal. There are some discussion about optional just whether this parameter could, could have default value, if they have the default value, then it means it's optional, but I think it's the advanced feature, which we can explore in the future at all. Others taken the Cure.
USA: Next up WH. We have all three more.
WH: It's unclear from your presentation what exactly it is that you're checking for when disallowing f(). Are you checking for the syntax of how f is called? Or are you checking the this value to see whether it’s undefined?
JHX: Okay, let's think this is a good question and I actually have an extra slide that. The problem here is what about undefined or even though now, think it's it's not just stage one problem, but I think that in the, as the original proposal by Gilbert, I believe the intention is to check the syntax. So it's ideally it should be ok okay to allow and undefined and only throw type error for the direct call syntax, but I'm not sure whether it's the world. introduce our other issues, but I think if we could export that in Acts stage.
WH: Hmmm… This is getting really ugly because now f knows how it's called, and there is no way to faithfully reproduce the result of calling f() using Function.prototype.call anymore — f will behave differently if you invoke it via Function.prototype.call vs calling it directly.
JHX: I understand the concern that so if, if it's, it's introduce any serious issue, I think maybe We can, we can drop that. It just allow you to call it in any form So, I'm okay with it.
WH: What do you mean by “we can drop that”? Drop what?
JHX: I hope it could allow the reflector and the court to to allow them. And only through type error for this, but I understand there may be some problems.
WH: Yes, there are problems.
JHX: Yeah, so I sync sync. This is is issue. We need to explore.
WH: Let’s go on to the next person please.
MAH: yeah, I basically I don't think this proposal has enough value to pay for the syntax we are adding here. At first. I thought that this was completely innards being added to the Syntax for the benefits of TypeScript or in the future possible, property decorators, and then it even seem to change the behavior of how the function is called or can be called. And that seems to be actually contradicting with the TypeScript use cases, and bringing a bunch of issues. Like, WH just raised. So on top of not paying for its value. I think it has a lot of concerns, even if it did pay for it. Yeah, yeah.
JHX: First I think the motivation part, it's not only allow you to write up a list using, but The Decorator. So, the parameter decorator. Actually, I think is the important motivation. If we, if only for only allow it and like type annotation proposal. Then we also need to maybe you need to expect that for the parameter decorator. So later, apartment about the types of currents way. It's allowed. This could be a type of void. Yeah, I know that but I think Flow have different design here, in that flow if you did you you in a flow If you give the this parameter it is always if I remember correctly, it always report error. 44, the if you do not use the call. So I think here. We know there. there's a an edge case in TypeScript in that we will use a type void to mean and that this function is actually do not know this. But I think this is an edge case we can explore how to make compatible.
MAH: Yeah, I think that given that type annotations are currently just stage one and parameter decorators are not even a proposal yet. I really don't see the motivation here.
JHX: Yeah, the parameter decorator. is that what it's about, but it's already listed in the future.
MAH: It is not the it's part of future proposals for the Creator's, but is not part of any actual proposal.
JHX: Yes, but wow. My I feel that this, this, this parameter syntax has actually the common part of these things is, it's a basic syntax which, which the other proposal may rely on.
MAH: I think there is no ordering issue here. We're trying to preemptively add syntax based on what we believe those future proposals may look like and they're too early for having for knowing what that the syntax of those work was also will actually be or if they will even be
JWK: I’m not talk about the decorator part. I can see value in this proposal it can prevent footgun of missing errors. If if you're write code like this, then it will become an error instead of implicit bug.
USA: One thing we are on time. So let's wrap this up quickly.
MAH: So, I guess this kind of loops into my next question, Like, what is the use case for declaring a free-standing method like this or being explicit about a method. Are you saying this would prevent a method from being plucked from an object and called freely?
JWK: If the user choose to add this parameter into the parameter list, this means the function will not work correctly without a meaningful “this” parameter.
MAH: Isn't again, I'm not sure syntax is the right way to solve this. This seems like parameter validation or in this case receiver validation.
JHX: Yeah, I think that's a problem here is I always want to mitigate the confusion of this. There are many too many such problems. Yes, We the single proposal cannot solve it, totally. And actually, we also need also, okay, to use, for example, I just use TypeScript or Flow to prevent the misuse, but they are not, they're not. you can work together and actually I try to propose that they could have the behavior which couldn't match eachother. so, I know it's it's maybe not easy, but I think it's, it's have. The other is worse to explore that the worst weak spot. The ‘this’ problem space because it's always always the problem. Yeah. Yeah.
MAH: As a problem space, a I suppose I'm just extremely sketchy called that any syntax approach is warranted for now.
SYG: I'm not sure what the problem space is. What is the problem space?
MAH: I'm not quite sure either to be honest.
JHX: Yes, the problem space is first, the type annotation and potentially the parameter decorators would need were need to disarm it syntax to work. The other motivation is it could be used as a dedicated syntax for method of, what a method means is, it's expect to provide to provide a meaningful this arguments to the function. So, it could be used if we have the dedicated syntax so you could help the code to be much clearer. And if we could find the correct way to spec this with runtime semantics, it could also help the developer to catch the error as early as possible.
SYG: Like if the problem statement is so the first thing is not a problem statement that you might want to have parameter decorators and the second thing sounds like maybe the problem statement is you want some way to have earlier errors about misuses of this. Yeah, it's I suppose that's ok. But like don't know what you mean.
JHX: Possibly, not only the errors, but also it allowed people to mark the intention of their code.
SYG: Like, there is so I would not say stage 1 for anything shown in the slides here, basically. So, I'm not entirely like I understand that stage one can be just for a problem statement, but it's like I do not really understand a concise problem statement. because, as MAH said, if the if the problem statement is about like exploring that problem space of Intent. Like that sounds like syntax, right? It's like how do we get a more scoped problem statement? That is not like I'm not convinced. Okay, let me rephrase this. I'm not convinced that there is a solution to the problem statement that you have said that I would agree to for stage two. Therefore, I feel uncomfortable agreeing to stage one.
USA: there is Mark on the Queue but we're way over time I think, think
MM:, it mine is not essential I pass.
USA: Okay, but I think it's safe to say that we don't have consensus for stage 1. JHX, would you like to make any concluding remarks?
JHX: Yeah. I think to the, I think I write this proposal because I think for many reasons that if we eventually have a syntax in the type on the annotation proposal, mean, this type annotation is already in that if oh, if in that proposal, then the it will, it can't have any meaningful runtime semantics. So I think it's worth to explore whether that syntax could also have a meaningful runtime semantics. So I see this as my personal motivation about that sand. and the In the eye, I think it it and I know that so have different point. That's whether syntax could solve some problem or whether runtime Behavior could help the developers. I do, what I want to say is I don't expect a simple thing could satisfy everyone and every case, but we should put some efforts on this area because this relatives to ‘this’ have too many troubles in JavaScript. If we do not put in fourth gear, there will always know always no solution. So, I hope we can we can put so many efforts in just this direction.
USA: Yeah. Okay, great. Thank you for your time JHX