Remote attendees:
| Name | Abbreviation | Organization |
|---|---|---|
| Ashley Claymore | ACE | Bloomberg |
| Waldemar Horwat | WH | |
| Robin Ricard | RRD | Bloomberg |
| Josh Blaney | JPB | Apple |
| Chengzhong Wu | CZW | Alibaba |
| Chris de Almeida | CDA | IBM |
| Staffan Eketorp | SEP | Apple |
| Michael Saboff | MLS | Apple |
| Philip Chimento | PFC | Igalia S.L. |
| Frank Yung-Fong Tang | YFT | |
| Mathias Bynens | MB | |
| Pieter Ouwerkerk | POK | RunKit |
| Eemeli Aro | EAO | Mozilla |
| Istvan Sebestyen | IS | Ecma International |
| Rick Waldron | RW | Salesforce |
| Jack Works | JWK | Sujitech |
Presenter: J.S.Choi
JSC: Okay. wonderful. Good morning or evening, everyone. I'm J.S. Choi, I'm presenting stage zero proposal for a function for stage 1. It's a, it's a Once function. This is a function that creates a new version of the function that is guaranteed to be evaluated only once, no matter how many It gets called. It's really popular. I had a prior function helpers proposal that I presented last October, which was rejected for being too broad. This ‘once’ function was one of them. At a recent incubator meeting it was the most popular one from other representatives. So like one representative said I use all the time and it's annoying to write yourself. So it's pretty good. It meets criteria pretty well for being included in the core language. Here's just some examples from a bunch of userland libraries. There are a bunch of userland libraries that let you create ‘once’ then there are a lot of dependencies on those libraries. Here are just some examples. These are very popular libraries. The reason why people want to guarantee that functions get called once vary. Sometimes they are event handlers. They sometimes they happen that they are in streams. Sometimes they're in the command line or they're getting, they're running some child processes, whatever it is. It's very common. So, it's pretty straightforward. You can you call it on a function and it creates a new function. No matter how many times you call it, it will call the original function only the first time, any subsequent calls to the created function with the result of this first call. And so here's just examples of those user land examples modified with this proposal. There's some bike shedding we can do though. I'd rather not do it during this meeting. Since this is just for stage 1, you can issues are linked into slides, for instance. There could be a prototype function versus a static function on the constructor. They have their advantages and prototype disadvantages. Like there's press that bind on the other hand, like a lot of times people put inline function declarations. That might be a little less readable if you have prototype function, someone also floated the idea in that issue of function decorators, although that would make it dependent on function decorators in the future. There are three possibilities here. As for web compatibility, someone raised the issue that they're some some libraries that are using now do monkey patching on Function.prototype, most of them are not conditional, so it is web compatible. However, there is one library that is a problem. And in fact, this is something that we talked about yesterday with groupBy - sugar.js currently unconditionally monkey patches Function.prototype, so that wouldn't be a problem. But old versions of sugar.js did conditionally monkey patch the prototype up until it was changed in 2016. The first version that was conditionally monkey patched in up to 201, as far as I can tell, matches the proposed behavior here, where it caches the first result and returns it every time. But if we went with Function.prototype.once we will probably have to be careful to completely match its behavior, or we could just call it something else or make it a static function or whatever. That's something to bikeshed. There's also some behavioral things to bikeshed. We don't necessarily have to cache. We could on subsequent calls return undefined. We can throw an error on subsequent calls; like some userland libraries have a separate strict once function or something like that. Where you want the regular ones function, caches and returns. The valve, the first result while ‘strict-once’ throws an error on each subsequent call, whatever, feel free to leave comments in the issue. That's not something to really argue about for stage 1
JSC: There's a more subtle issue. Where the first time, you call the function, what if the original callback throws? What's going to happen on subsequent calls? Do you cache the error and rethrow the same error? Do you rerun the original function on subsequent calls? That's also something to bikeshed in that same issue. There's also a race condition problem and a recursion problem. What should happen if you somehow call the function again before the first call completes. What should happen. Should it Deadlock? Should it get blocked until the first call completes? It's a, it's a little uncertain and this is something where we need to investigate what current user land libraries, in particular sweet.js. do. But that's issue number three. So those are bikeshedding issues, but those are things investigated during stage 1.
JSC: I'm asking for stage 1 now. This was a pretty popular function during the incubator call to add to the language. So with that, let's take a look at the queue.
WH: I like the idea. However, I don't like passing any parameters to such a function. If you have a function square which just returns the square of its arguments, then, if you make a once version of it, then it will always return the square of the first number that you called it on. Seems like an anti-pattern. I have no concerns with doing once on functions which take no arguments, but using it for memoization seems a bit questionable.
JSC: Yeah, so there are a couple of things we can do here, we could throw whenever the new function gets arguments, which would it match any of the user land libraries right now, but that is option. We could go down the rabbit hole of more sophisticated memoization, which we kind of talked about during the incubator call, but like we agreed that there's lots of ways to handle memory with memoization, whereas like just this once function is relatively simple, so we'd want to focus on that, the simple case first. That's something WH, I will open an issue on the repository about what to do when the new function receives arguments. Feel free to comment there.
WH: You could just not pass them.
JSC: That's also an option, yes.
WH: That issue combined with the caching story just breaks down when you have re-entrant functions, as you’ve already noted in the presentation. So yes, I have concerns, they're not blocking for stage 1 but I have concerns about caching results being somewhat of an anti-pattern.
JSC: All right. Thank you WH. I will create an issue. Please leave your comments on there as convenient. Looks like JRL has a reply to this.
JRL: On this specific case whether or not arguments are passed and what the return value is on subsequent calls, even if the argument doesn't match, the ecosystem is already decided on a precedent and it's been the same thing for 12 years or something, whenever underscore came out. The way that I've always written once is this exact same way, when I'm personally writing it, the way that I've seen in Google's code base and AMP’s code base, it's this exact same almost line for line, the exact same. So I think the current semantics are the correct one.
JSC: All right. Thank you, JRL. Let's see. Next up is JHX about Function.once versus prototype function.
JHX: Oh, yeah, I just want to say I prefer Function.once instead of prototype messes. They may not have the web content compatibility issue. I prefer it in some use cases. You may have use cases. It gives you a better coding style because when you use the prototype method, it's very possible you write a very long function, and in the end you call .once and it's not very clear that this function will only be called once. All right.
JSC: Thank you JHX. Yeah, I remember saying your comment on the issue about it. I think I do agree. I'm going both ways just between precedent with .bind(), versus it's definitely more readable to have a static function when you have an inline function declaration. I don't know. So like we can talk more about that on the issue. I am currently inclined to make it a static function. Just to avoid web compatibility and also because of the inline function declaration stuff, but we'll see.
JSC: Next up. You also have to think about whether the or use case is triggering side effects only once. I will say that real quick. There's also the caching thing like for content that is computationally expensive results, sort of like a likely memorization, I guess. There's that too. But yes, side effects and also result caching I guess. So, but go ahead JHX.
JHX: The next topic is I am not sure about. It seems their core use case is triggering the side effect only once. So. Um, I'm not sure about it but seems the cache behavior, I'm not sure how frequently it'll really be used. But I guess, maybe we only need to return undefined or something to denote whether the function is executed; that might be enough. I'm not sure. I just want to discuss that.
JSC: So yeah, I will say that. The big thing is about side effects, as you say, in particular it's important. It's useful for making side effects idempotent, as MF points out on Matrix, so that you're guaranteed that no matter how many times you call it - maybe in rapid succession - it only happens once. It's so, like I did, are you suggesting a change here? Are we just exploring ideas here?
JSC: Well, in any case JHX, your point is taken. Yes. It's true. The big reason is for it has to do with side effects. ‘Memorization is kind of this kind of a side effect’ - kinda like the fact that we're trying to make side effects idempotent but like, the big thing is to try to make sure that no matter how many times you call it, the result is this, the side effects are the same. JHD you're up next.
JHD: I've used .once() countless times over the last decade or more, but always only for side effects. I've never even considered using it for something that has a return value that matters. It seems like there's a lot of added complexity and potential anti-patterns as well, like WH mentions, by conflating in this memoization behavior. Is there a reason we can't just make it like .forEach() and ignore the return value, so it just calls the function and the function only ever returns undefined?
JSC: Returning undefined every time is an option.
JHD: I'm sorry, I missed that, thank you.
JSC: Yeah, that’s issue Number two. Feel free to put your comments there. I'm coming around to it myself after you WH and MF said that, it's sideeffect idempotency. That's the key thing rather than memoization. So that has ramifications for naming since we wouldn't wouldn't be matching the old version of sweet.js. But so, yeah, I'm coming around that. The attitude I'm getting from the committee is that maybe let's go with Function.once, no web compatibility problems as far as know, return undefined, don’t pass arguments (because that shouldn't be a problem if we're returning undefined instead of caching).
JHD: Thanks. Yeah, I'm sorry. I just missed that one section of the slide.
RRD: Yeah, I think if you go to the next slide or something like this, yeah, here we had the option of caching layer. I think if go towards and find it would make sense to also return undefined for subsequent calls. The reason of that is that then we could in some ways think of throwing an error as also part of side-effecting. I don't know if that makes any sense.
JSC: I think that makes total sense. So makes total sense. So only the first call would throw, subsequent calls would not do anything, and all of them would return undefined. Yep, that's great. WH agrees. great. All right. Queue is empty. I would like to call for stage 1. Okay, great. I would like to call for stage 1. Are there any objections?
RPR: Are there any explicit support calls?
MF: Yes, I explicitly support.
MS: Michael Saboff supports it as well.
RRP: Alright, so we've had we've had explicit support and no objections.
JSC: All right, so TCN is mentioning. What's the utility of returning undefined build? Be mostly that we don't have to worry about passing like what arguments we pass every time guaranteeing that the thing is returned every time and that it makes sense, basically.
USA: All right. Thank you everyone. I'll give ten minutes back to the schedule. That's it. Great. Thank you. So next up, We have shuttle rooms updates, later. Are you ready?
- Stage 1
Presenter: Leo Balter (LEO)
LEO: Yeah, so hi everyone. This video, I'm sharing some updates on ShadowRealms. Let's see what we have here. So we do have the some integration status here, as ShadowRealm has involves not only ECMAScript but also some great work we need to integrate this with the web platform. So we do have an ongoing pull requests for the HTML specs. This is still work in progress, but we have Igalia working on it these days and it's still being reviewed interactions are being active. We also did some work on exposing some of the web APIs on the ShadowRealms. This links to a pulll request where we can see all the parts that we are doing this. Also working being done by Igalia and we have WebIDL [Exposed=*]. This work is done and for all of this work we do have web platform tests and test262, matching the spec. We are glad to sponsor this work from Salesforce. And Google is doing amazing work. As you're going to see, there is more is more to it. For this, we have the implementation status. ShadowRealms is finally shipping on Safari Technology Preview. By the time that I wrote these slides I was still waiting for for it, but it was just released a week ago or less than 8. We are being able to test it directly without getting a without needing a specific web kit build. It's going great, and performance is wild! We just, for just a detail here. We plan to release a better data on this. We have our membrane framework that we use we use today on the web platform. We have iframes and we plan to use with Shadow Realms. That's the intention of this proposal. I just did some quick benchmarks. They're not super solid yet but with WebKit comparing the initialization of the iframes with ShadowRealms, the benchmark was pointing like eight faster with ShadowRealms, But when we got Safari technology preview the initialization bumped up to 13 times faster. We are still going to see some data. And this is going to be way more solid when we get a new membrane framework done in, which I expect to be very soon and I'm going to be publishing this soon as well. So we expect like some performance gains to when we have the new membrane frameworks. It's not just about the initialization, but about how we have all this data, there might be some callable boundaries. There I am so thankful for Igalia doing this work and I think it was my best bet. They're from Salesforce in the meanwhile. We also have the Chrome having an implementation on going We still we have a skeleton released in V8, but we still need some web integration. This work is still being done. Legend occurs is being one of the main responsible for this. I believe, Legend Echoes represents Alibaba. Now, I'm getting like some time with the Igalia to work along and help reviewing and everything. And let's see what comes next. Hopefully, in the next meeting we have more updates about this.
LEO: I'm sorry I don't have any updates so far on Moddable, XS and Firefox. But also, it's probably going to be part of the upcoming meetings. For specs related. We have a pull request, an additional requests for every need, and we might need some review from the TC39 editors. That was one the requests and reveals their appreciated on this pull request. I think it's the only editorial for requests open. So here are some very small but important to mention TC39, normative changes that we have with ShadowRealms.
LEO: The first one was actually just fixing a normative mistake that we made in a pull request merging.. We removed the name prefix for wrapped functions, just for a quick recap into the TC39 meeting in December. In 2021 we decided to set removing the name for prefix for wrapped functions, but the pull request was not reflecting that. So I had a pull request that is reflecting it as these are normally of changes inbetween. I just wanted to confirm with everyone and make sure it's like, everything's okay. If we do have any concerns, I can go deeper through this as well. If anyone has questions, but finishing the summary here, we have another pull request that we have a type check only value, the second parameter that we said this pull request. I'm going to read the summary and then I'm going to go visit there. This restricts the second parameter of import value to receive only a string value. And with this pull request. We would throw a type error for other types. This pull request is important for us to make sure we have a path ahead towards extensions. It's not a guarantee for any extensions. Although it works well with import value when you don't, when you only send one argument calling import that value, and it does not coerseu to undefined to the string with undefined. This would help moving forward with like extension such as considering import value. Having a second parameter. There has an array of different values or if those have undefined. If he doesn't have a second parameter it may just default to the default name from the module namespace. If we do, eventually have structure serialization, we could also use import value for only one parameter to be used as a structured serialization of the module namespace object. There are so many things to think about here. So, this restriction is only saying that second parameter must be a string value, throwing a type error instead. Any other expansions are not being handled right now. This is the only thing being done by this pull request. Let me open this as I already went through this. This is the change, which is gotta be soon thing. So this is just saying the export name, the second parameter of import value needs to be a string. And that's the change being done here.
LCA: LEO, we can't see the pull request, we can only see the slides.
LEO: I'll because it was sharing a slide only and it opened in a new screen. I'm sorry about that. Yeah so this is the change being proposed. We need consensus, of course. I think I also edited this one day after the deadline, but this is the change. If someone is not comfortable with accepting this change right now, that's okay I understand that. I will just bring back and present this again, in the next meeting. But how big is it? A change. And going back to the other pull request to finish the summarization. We have a very small change where getFunctionRealm abstraction may throw on revoked proxies. This pull request as I'm going to show sets proper exceptions from revoked proxies coming from a different realm and this pull request, improves the API to avoid any leaking, coming cross boundaries. I'm going to this. Once again, I need to share. Okay, this tab. It's merged but it can be reverted if we don't find consensus here. This change looks subtle, but it's normative. I consider this as effects so as like for the fundamentals of the ShadowRealms, it preserves any leaking cross boundaries. But yeah, it's a normative change. So I'm communicating this to TC39 to make sure we have consensus and we don't have any specific objections here. This pull request was suggested just from Legend?? who is working on the Chromium implementation and that's I think it makes sense, but we can go deeper if we have more questions about this.
LEO: So this is a summary and here, I am asking for consensus. We have some blog posts coming in. If we have time, we can talk about it, but it, yeah, I'm requesting consensus for these three pull requests.
USA: We have three items on the queue.
LEO: Yes, please, sure. So, first up, have Shu
SYG: Is it is more of a question for the Apple folks? I heard LEO say that Safari is shipping and I want to clarify what that means with the HTML. Integration still work in progress, I'm not sure if the, if all web APIs have already been audited to see if they should be [Exposed=*] to are or not exposed to
MLS: so I think LEO said that its Safari technology preview, which means it's not chipping in a release version, but in the two weeks version,
SYG: I see, and and I want to further clarify that shipping in the released version would block on HTML integration, being done and the web API and an audit being done.
MLS: Yeah, which might be done nothing. Yeah. Sure. I don't know the details. But, yeah, we don't things and official releases, unless their standards.
SYG: Yeah, sounds good. Thank you.
LEO: And, for clarification SYG has. We are tracking this? This work with Igalia is not done, so we plan to keep track and make sure everything is up to date as we catch on as we are also working with Igalia like Salesforce is working with you. Guide, you updating these, this work on the web APIs. So we make sure this reflects what my goal is for any eventual, release implementation to be paired with what we should be reflect. What should be landing. I want to stay tuned to match it. Everything exactly as we spec. So, we intend to continue this work, this work in progress.
USA: Great. Thank you. Next up. We have a common from LCA who says that Deno is also working on integration for Shadow Realms in this quarter.
LEO: This is nice. Thank you.
USA: Great, next up we have MM.
MM: Oh, hi the phrasing on the slide “may throw on revoke proxies”. I'm confused by that phrasing. And I'm confused about how this maps to what I thought we had agreed on when we had discussed this at this SES meeting. Could you bring up again the spec change corresponding to that text?
LEO: Yes. Am I am I sharing my screen? Screen?
MM: No, you are not.
LEO: I think CP the answer here, reflects better on this change. Okay. so, where he says the observable difference, here is to revoked proxies coming from a different window like a proxy created from the same domain Iframe that was revoked and pass into a shadow realm associated with the main window. The difference now is that the error is from the main window. the caller realm rather than the iframes realm. It makes the code more predictable. I'm sorry, if the phrasing of the pull request item by most,
MM: So, even with this clarification, I mean, yeah, his text seems very different than yours, but I don't understand either one yet. I'll let me walk through the case that I'm trying to understand. I thought that what we had agreed on the SES call that shadow Realms doesn't need to make any special case for proxies. That the proxy behavior in the shadow realm behavior, were orthogonal and composed correctly. For all of these cases this disease.
LEO: Not exactly. This is not a special case for proxies just like, in the case if we do have a revoked proxies without a special case, you don't leak the you don't you throw the error in the correct Realm
MM: When you say when you say the correct realm, you've got a... let's go through it. You've got a… We have a the revoked proxy is being passed through the realm boundary is the case that we're concerned with?
LEO: Yeah, if we do have, if we don't have this pull request, and if you have a revoked proxy as a revoked proxy will naturally throw, that's not given any special like behavior for it and it will end the end.
MM: The revoked proxy will throw an error that is where the error itself is in. Proxies realm, is that correct?
LEO: Yeah. So like if you have if I had realm A and B and I have revoked proxy coming from B, without this pull request, I would observe the B realm inside realm A.
MM: I'm sorry. I don't understand Insight. We have a ShadowRealm, boundary. Is this ShadowRealm boundary or is there are we talking about direct realm to realm contract,
LEO: Shadow realm boundary.
MM: Okay. So in a so in the shadow realm, in the case of a shadow realm boundary. Are we passing a revoke proxy or we invoking a report is, or is this a question of what? We're Over here. You're starting at step. You're showing step one of some algorithm. What algorithm are we in the midst of the
SYG: MM that, that's the internal call on a wrapped function. This the bracket bracket call.
MM: Okay, so this is on a wrapped functions. We're talking specifically about a function proxy. Is that correct? Now? That's that.
SYG: That's not the calling a proxy. That's the call on the Exotic wrap function. That's produced by Shadow Realms across the call of a boundary is
MM: Okay, so the wrapped function how in the old texts, texts, the wrapped function return a her from the how could the yellow in the, how could they sorry? How could the blue? wrapping function return, a error from the yellow realm or the proxy is revoked. revoked. Proxy is yellow.
SYG: I have no idea what those colors refer to.
MM: Okay, give them named them, give them whatever color names you want, but just talk it through in terms of things on one side of the the realm boundary being one color things on the other side outside of the realm boundary being the other color. Because I just don't understand how the old text or the new text could possibly result in an error from the wrong realm being thrown.
LEO: Let me try to get the test262 related to this. Oh, sorry, CZW.
CZW: Yeah. I have kept the type of function calls, there are notes on function calls in the spec. We have black nodes that we switch in the throwing error contacts. What is it? Not strange and it presents in Next state function dog? Track it back to call So there are three realms involved in this situation. One is for the execution realm. And one is for the realm, the shadowrealm is created, and one is for the realm that the shadowRealm itself. So, when we call GetFunctionRealm and without the note, the error is thrown in the execution realm.
SYG: Are you suggesting to note is normative the no is not what switches the realm. I think the note was an actual editorial note, because before the change, could you put the diff back on LEO?
MM: Yes, please.
LEO: Yes.
SYG: Thank you. So before the note, I have to chase, I don't have another tab handy, but before the note you have two fallible calls to get function realm that may throw then after the note, you have calls to things like get wrapped value and call. call off the target of the wrap to Target function. I Function does think the call of the realm actually switch realms to the realm of the target and I have to look at get wrapped value. Maybe it does something special with the exceptions it throws, but I think that only made sense, when all the function realms calls were before the note. Now, the function room calls is after the know if you want to change the realm the function, call. Sorry if you want to change their Realm of the are produced by get function Realm. I don't see anything having a normative effect to affect that. So I think MM is right. Like, I don't also understand how this specific spec change, the realm of the error thrown.
MM: Thank you. we also have a reply from Matthew.
MAH: Yeah, I mean, I just wanted to say what you said, like original get function around can throw, which is, I guess the intent was to avoid the throwing step and get function around, but I didn't know that notes isn't normative. So I don't know what mechanism needs to happen there for that to actually be the case.
SYG: Right? All notes are not normative FYI.
LEO: so, what I try to see with this change.
SYG: I never heard. What MM thought the high level behavior should be that was agreed in the SES call.
MM: The high level behavior is that it's already the case that a revoked proxy, any trap on it, throws an error from the realm of the proxy. Obviously, if there's a shadow realm, boundary between the proxy, let's all just go the blue proxy and the other side of the Shadow realm, boundary is yellow. Then the proxy itself that are revoked proxy going to throw blue errors and in the yellow world, all you can see is yellow errors. So I just don't understand and all of that needed didn't need to take any account of proxies as being different from anything else. Anything else that you call on the blue side will throw blue errors and any errors that manifest on the yellow side will be yellow errors.
SYG: So MM, okay, so thank you for the what you think should happen at a high level. As my reading of the current spec text, for get function realm and revocable proxies. Is that when get functionRealm throws on a revocable proxy? I do not see any mechanism that looks up TypeError in a different realm. It just says throw a type error and moreover proxy objects do not have in the spec. They're creating their creation realm, like where do you get the realm of the proxy to look up? The TypeError constructor on to throw that specific type error? That doesn't exist in the spec as far as I can tell.
MM:So, it's so the. So the real issue is that has nothing to do with Shadow Realms. The real issue is the proxies errors are under specified.
SYG: I suppose I don't think they're under specified, there are specified to do something else then what you described.
MM: What are they specified to do then?
SYG: To throw a type error in the executing realm? Basically, the current realm?
MM: The, we avoid Dynamic scoping.-
SYG: there is no Dynamic scoping of here.
MM: So when you say the executing realm, there's I mean at some point there a
SYG: There's no like control being done here. When you tried to get the realm of revoked proxy. It's not like you look up at wrap and you call it. You're just trying to unwrap the layers of revocable proxies and other wrapped functions to get the realm. And if the proxy handler is null, so a revoked proxy mechanically has no internal proxy handler. So there's just a check. That's like when unwrapping these layers of wrapped functions, If the proxy handler is to null, throw TypeError, and there's no like changing of the execution context. There's no, there's nothing to do with like entering a different realm. It's yeah.
MM: Okay. So the reason why proxies are a special concern here is is that the only case where the function realm Itself can be caused to throw?
SYG: correct?
MM:I see. Okay, that makes sense. That explains why they're not orthogonal. Okay. thank you. All right.
USA: That's the end of the queue
LEO: okay, so, as I was just trying to show here, these example like this test262. I think it does show the intention here on life again.
CZW: Okay. I just noticed that SYG said that all notes on the spec are editorial, so I just think we are missing some switching context in the current spec. It seems we are not switching the execution context for the errors.
SYG: During let's take it offline on that, please. You probably did flag CC. Me already on that thread to please re CC me. I guess it should work it out on the spec because the the high level behavior that MM wanted. I don't think it's actually possible to spec without significant like normative changes to changes to the entire spec. So um, so let's hash that out for what the realm should actually be on the thread.
LEO: Okay, so let's go to thank you. Okay, so you're short on the time box here. I just want to make sure we advance a few things. So, right now, I would like to do separation here. I like to ask consensus for each one of them. So for the first one was to removed the name prefix for wrapped functions. That was a fixed that I intend like just matches a consensus of what is achieved in December 2021. Do we have any objections for this? I don't see anything on the queue.
USA: No, there's nothing on the queue. You have consensus.
LEO: So the second question about the import value. You restricting the second parameter to receive only a string value and throw in a type error or otherwise. Do you have any objections for this one?
[silcence]
LEO: Okay. Thank you can consider the silence as no objections.
LEO: For the third one MM, do you want to? You want time for us to work on this? What do you think?
SYG: I would actually block consensus on this because I think the current fix doesn't really do what it purports to do and we don't know what the right fixes yet. So I don't think there's anything to ask for consensus on.
LEO: So, okay, so I'm going to revert that pull request. and I'm going to reopen discussion for that pull request. Okay, SYG.
SYG: Okay, sounds good.
MM: And that, that suits me as well. I feel like like this might be okay, but don't feel like I understand it well enough and it's really crucial not to get this wrong.
LEO: Yeah, I think MM there is concern on special case for revoked proxies, which I don't think it's the case of this, but I think it's worth a discussion after this
MM: [unintelligible]
LEO: on that MM. I thought I was going to say, I think it's worth of us having a discussion after this TC39 call. As I was finishing. Thank you. Yeah. Great.
USA: Thank you. We are over time, so, thanks Leo for the presentation.
- None - purely an update
Presenter: Philip Chimento (PFC)
PFC: (slide 1) My name is Philip. I'm here to present an update to Temporal and ask for consensus on some fairly minor normative changes. (slide 2) This presentation is going to be pretty similar to the last few presentations that I've given about this. I will give a general update about the presentation and about the progress of standardizing the string format in IETF and then I will have one or two slides on each of the normative changes, explaining them briefly. As last time, there are some actual changes to how the proposal works — feedback that we got from implementers — and then there are other minor changes to the spec text to make it accurately reflect the intentions of the champions. Let's call these bug fixes. In some of the previous presentations there have actually been large discussions. I don't believe anything that I'm about to present now is controversial enough that a large discussion is going to be necessary. It's mostly just fixes.
PFC: (slide 3) In the near future, we will continue turning implementer feedback into presentations like this, with fixing as many things between plenary meetings as bandwidth allows. We still seem to be on a good track: the number of normative changes per plenary meeting seems to be trending downward. I last presented in December and skipped January. So even with a period of 2 plenaries, there are still fewer changes than last time. That implies that the limit is a proposal in which people don't want to change anything else.
PFC: (slide 4) An update on standardizing the string format in the IETF. As a reminder, we decided last year that Temporal should not ship unflagged in any engines until this string format is standardized. That's why I'm reporting on the progress now. There was an IETF meeting last week, where USA attended. He's in the working group that is working to standardize this format. I'm happy to report that the discussion threads that were still open have been resolved. The syntax extensions have been finalized. This is not yet reflected in the Temporal proposal itself, so that is one more normative change that you can expect me to present in a future plenary. A draft of the string format standard is going to be published in the coming weeks. As I understand it, they did make some changes to what was previously adopted as the draft in the IETF meetings, so the new draft needs to have a comment period before they can officially publish it. And then there's one question that the working group is still working on, which is how to deal with strings that have internally inconsistent timestamps: where the UTC offset, for example, does not agree with the name of the time zone. This doesn't affect the syntax of the string format. It only affects the recommendation that the working group is going to give as to how consumers of that string format should behave when they see a conflict. This may not affect Temporal at all, because Temporal gives the programmer the choice of how to interpret the string when there's a conflict between the UTC offset and the time zone name. This is still under discussion by the champions. So the outcome may be no change or it may be that we make a change included in what I present next time to reflect the final form of the standardized syntax.
PFC: (slide 5) On to the adjustments. (slide 6) The biggest one this time is storing mathematical values in the internal slots of Temporal.Duration. This is actually feedback that we received a while ago as we entered stage 3. The general principle is that when we describe objects with internal slots in the spec that store numerical values, those should be mathematical values. It avoids subtle bugs, and avoids "speccing IEEE arithmetic". However, we got feedback from implementers that this was not just an editorial change. The difference in the case of Temporal.Duration, unlike the other Temporal types, was actually observable, because the values in these internal slots are unbounded integers and they are potentially exposed to JavaScript through getters. For an implementation to store 10 potentially unbounded BigInts in those fields, affects performance in a way that storing 10 doubles for JS Number values does not. (slide 7) In the end, what we've done after talking to implementers and to spec editors is to change these internal slots to store values that are the intersection of JS Numbers and mathematical integers. So they cannot store NaNs, infinities, negative integers, or integers that are not exactly representable by a 64-bit double. This was something that was previously implicit and sort of sloppily defined. Now it's explicit. For example, the way that the spec was written before, you could get negative zeros in a Duration, and you could get integers that weren't representable in a double. (slide 8) Here's a code example of what would change, and why this is a normative change, not just an editorial change. Here at the top, you could negate a duration and get −0 in some of the fields. And in the lower code example here, you could add values to a field that was already at Number.MAX_SAFE_INTEGER, and then get a different answer out when you use the subtract() method, then when you just took the values of the fields and subtracted them. These are two things that were inadvertently allowed by the spec before and are now, let's say, regularized. We wanted to explicitly call this out since since it wasn't an explicit choice before these things were disallowed, and now it is.
PFC: (slide 9) Continuing on to consistent default options. This is about custom calendars calling into user code. It's a lot more of an esoteric case than the previous one. We found an inconsistency: when the caller didn't provide an options object, Temporal still has to pass a value into the calendar methods, that may be defined in user code. Sometimes, this value was undefined and sometimes it was an object with a null prototype. This should be consistent because it's observable in userland calendars. So, we've changed it to always pass in undefined if there is no options object to pass in. (slide 10) Here's a code example showing what the observable change would be. This is going to be fairly rare. This example is using Temporal.PlainYearMonth.from, but it also affects several other places where we are not passing in an options object.
PFC: (slide 11) The next adjustment is making the output of expanded years consistent with how the Date.prototype.toISOString() method does it. If you have a legacy JavaScript Date, and the date has a year between 0 and 9999, you'll get the year output with four digits. If you have a year before zero or after 10,000, you'll get it output with the expanded year format with 6 digits. But in Temporal, between 0 and 999, this was not the case. Instead we would use the the 6-digit expanded year for years between 0 and 999. This was originally done to avoid outputting a string with leading zeros, but after receiving some feedback about this, we decided that it was possible for this to lead to pitfalls when porting code from using legacy Date to using Temporal. So we decided it was better to keep the output consistent. The ISO 8601 standard is silent on this either way, because they say that representation of any year earlier than the year that the Gregorian calendar was inaugurated is by agreement of the communicating parties. You can see the before and after of this string output here [on the slide].
PFC: (slide 12) Right. Those are the adjustments, on to bug fixes that ended up being normative. (slide 13) There is a sign flip error in the subtraction algorithm for PlainYearMonth and it was pretty clear what the spec meant, but it would produce wrong results if it was implemented exactly as written. So it's a normative change.
PFC: (slide 14) There is also a step skipped in the add and subtract algorithms of PlainYearMonth, where we unintentionally mixed dates in calendar space, with dates in ISO space. This usually works but occasionally would throw or return wrong results. So that's bad. We want to correct that and have the correct results.
PFC: (slide 15) There's a daylight savings bug in comparing Durations relative to a point with a time zone. This was due to calculating the time zone offset at the wrong point of the day. It should have been calculated at the start of the day. So this this affected days that were not 24 hours due to Daylight Saving Time.
PFC: (slide 16) We had inadvertently made a serialization of PlainYearMonth and PlainMonthDay that wasn't round-trip-able. The output of the toString() method would return a string that wasn't valid as input to the from() method. So, the rule is that when you include the calendar, then the full complement of year, month, and day should be present. And so, we've fixed this.
PFC: (slide 17) There is an unintentional omission in the modifications that the Temporal proposal makes to Intl.DateTimeFormat.prototype.formatRange(). It didn't properly check the types of its arguments when one was a Temporal.PlainMonthDay. When you mix two different Temporal types in formatRange(), you're supposed to get a TypeError, but without this change, if you mix a Temporal.PlainMonthDay with another type, you wouldn't get a TypeError. You get some bogus results.
PFC: (slide 18) There was some mistake in the grammar of these special Etc/GMT time zone names. They were not correctly parsed.
PFC: (slide 19) And finally, there was a normative typo where the word "not" was omitted and that changed the sense of an if condition which would lead to incorrect results if implemented exactly as written. (slide 20) Those are the changes that I'd like to request consensus on. Does anybody have any questions about any of these? I'd be happy to scroll back to the appropriate side and discuss it.
USA: Thank you. You have two items on the queue. First off we have MM.
MM: Could you go back to the slide where you explain the intersection of mathematical numbers and Numbers?
PFC: Sure.
MM: So 2 to the 54th satisfies the definition that's written down on the slide but is outside the safe zone. Do you intend for this definition to include, for example, 2 to the 54th?
PFC: Yes. Duration fields would be able to store numbers all the way to Number.MAX_VALUE. It's intentional that if you have durations with values that large, then you will lose precision. But the idea is that a Duration should be seen as similar to a property bag. For example the duration here (slide 8), where you created from this property bag { nanoseconds: Number.MAX_SAFE_INTEGER }, the intended semantics are that the Temporal.Duration objects are the same as if you were just actually using this this plain object here, only it's got some methods like add() and subtract() and compare(). Let's say you have a duration of 100 years and you decide to convert that into nanoseconds. That's a number of nanoseconds that's beyond MAX_SAFE_INTEGER. And so you would get a number of nanoseconds that was not precise anymore. We allow that rather than throwing.
MM: Okay, good. Thank you.
SYG: This is not a technical feedback to anything here, but I have a general question. I want to ask of committee and food for thought for committee and a general question to PFC and other Temporal champions. Do you think the existing TC39 proposal process has worked well, for something the size and scope of Temporal?
PFC: I happened to be thinking about this yesterday after the discussion in the delegates channel about mega proposals, so I have somewhat of an answer. My opinion is, it's true that Temporal is a mega proposal and I think that does make it difficult for delegates who aren't involved as champions or otherwise closely involved, to be able to grasp the proposal as a whole because it's so large. That's something that we've tried to mitigate by having extensive documentation, more than just a proposal document. We have a polyfill for people to try out the proposal, from early on, before the stage when polyfills are usually created. We had the documentation available way before the stage when documentation is usually written. I think those things help. I'm not sure that they were enough to really allow other delegates to get a sense of the proposal, as a whole. Now yesterday in the matrix channel we had also talked about splitting up some proposals. I'm not sure that would have helped Temporal very much. There are seven major data types in the proposal, and they all have certain commonalities, and my opinion is that splitting them up and adding them to the language one by one would have led to inconsistencies. And some of them don't make sense without the others. So yeah, I do think there are some ways in which the process didn't serve a huge proposal like this very well. But I don't directly have a suggestion for how things could be improved and I'm not sure that dividing up the proposal into smaller proposals would have served it well either. So not a very well-defined answer to your question, but I'd be curious to hear what others have to say about this.
SYG: Thanks for your thoughts. Well, since I asked, I'll respond quickly that the thing that stood out to me is that in my opinion, the defining characteristic of how TC39 designs features is that we design them all up front all at once and then we implement, and it seems like there's some kind of natural limit once a proposal gets very large, that it's difficult to design it all at once. For Temporal in particular, my understanding is that in fact, you did not just design it on paper all at once, you had a fully-featured polyfill that you were using to basically implement and to guide the design of the proposal that way. That seems like a lot to ask in general for every proposal, but it says something to me that that was basically the main way to move it forward. And we see now with the constant stream of normative fixes and other things that come up with more implementation experience for such a large proposal, is that stage 3 is not as clean cut as we would have liked for other proposals, right? Just like, we reached stage 3 for Temporal, but it just keeps going. There seems to be some room for improvement there to me.
PFC: I agree on using the polyfill, and actually we used the documentation to help inform the design as well. I can recommend that approach to anybody. I thought it was great. I would personally much prefer that to up-front design. All that was possible within the current process. But for anybody wondering whether they should design their proposal that way, I can highly recommend it.
USA: There's YSV on the queue.
YSV: So I think because I raised this question about how do we do large proposals yesterday, and we're talking about it now and you also brought your thoughts about it yesterday in the chat. I wasn't thinking that the solution is to split up proposals necessarily. I think that there are different reasons why we may want to split up a proposal for example. Yesterday, when we suggested that decorators and metadata were treated separately I think that there is a problem space that decorators is solving very well there. Is this related to the metadata decorators, but that still needed design work separately from what was finished and pretty much ready to go. So, I think that a split there was appropriate for something like what we discussed yesterday. My comment about a concept of ‘epics’ or ‘modular proposals’ was rather “how do when we're presenting these large proposals to the committee it can be very overwhelming” and I think that that's what we saw yesterday. In an effort to make sure that there's a good information transfer from the champions to the delegates, I think it may make sense to break up the proposal, not necessarily in the sense of it is treated as separate parts, but rather the way that it's introduced to the committee. A well-formed pattern, for example, pattern matching is presented as: here's a primary problem that pattern matching is solving and this is what we consider to be the core set of design features, like basically rather than presenting all of the syntax, saying here are the design features that we consider to be core and they are being treated in these, like, subfolders of the proposal or in sub [?] of the proposal, but the main motivation for which we've gotten stage 1 core is this. And here is one part that we're going present to you, or have a design discussion about, for example, how the syntax of this piece looks. Then we have another design discussion about how the next piece looks. Because having a unified design discussion about everything that is in one of these large proposals, I think, doesn't lead to the best use of time and doesn't lead to the best result in terms of how much attention we have for those problems. I think that there is also the other problem that SYG brought up about implementation, which also Temporal addressed, and so did Records and Tuples, which was early implementation. In Temporal that is possible with a polyfill, but it's not necessarily possible for all proposals. And this is another interesting space where, how would this would look like if, for example, we had a process for doing this iteration? Or, maybe we just said that this was something that could happen earlier. Well, no, I mean, it does happen: for example, Records and Tuples was implemented early. I'm just thinking, how can we make it so that we reduce the burden when we're transferring these large pieces of information, either by staging how a proposal moves forward, which effectively happened with Temporal: it presented multiple pieces of itself to the committee. And we had this two-hour period where we discussed all of it at once, but there was this period where components of it were discussed and we continue to do that today. But we don't have this as a way to solve problems for larger spanning proposals. There's another aspect to this, which I think is important. Approaching it in this component based manner, helps us understand those pieces much better and ask difficult questions about those pieces. Otherwise if we say no, no, everything's essential, it all has to go in together, it all has to be part of the same thing, we can't break it up at all, it makes the analysis of components that we may want to question more strictly, more difficult because it becomes an “all or nothing” discussion. And I think that has bitten us in the past.
USA: Okay, we are on time. PFC, do you want to keep discussing this or do you want to take this offline?
PFC: How much time is left in the time box?
USA: There's no time left.
PFC: I'd like to ask for consensus on the changes that I presented.
[silence]
PFC: That sounds like nobody's objecting to that. I also had a sneak peek slide for next time, but we're out of time. So you can click on the slides in the agenda and see it if you're curious. I'd be happy to continue talking about this topic in the matrix channel.
USA: Thanks, everyone.
- Consensus on presented changes.
Presenter: J.S.Choi (JSC)
JSC: Hi everyone. This is JSC again. This is an update and a little time for bike shedding for the call-this operator formerly known as the bind-this operator. It's currently at stage one. There are four options to talk about. There's lots of cross-cutting concerns. I'll try to be quick with the slides. So just to review call-this: this is an operator that lets you change the receiver of a function call. Okay, there. There are four possible syntaxes for this. I will describe them in more detail after I talk about some other stuff. So call-this used to be called bind-this, it was a resurrection of the whole bind operator. It's also a rival proposal to JHX’s extensions, although now, you could think of it as a subset of extensions because we dropped functions from the operator so that it's valid with functions called with parentheses, but it's a syntax error without it. And so, we can decide what we want to do without parentheses later. A lot of this will plug into Redux and the holistic dataflow discussion later in this meet at the end of this plenary. But for this, I want to focus on bike shedding the syntax of call-this just this just to quickly review. Why might we want to add this? someFunction.call is really common, people use it for a lot of reasons whenever they have a method using a function in some variable for whatever reason, whether it was imported from a module, whether they extracted it from an object and need to conditionally switch between it, whether they need to reuse it on a monkey patched objects, whether they want to cache it to make sure it doesn't get bit by prototypes changing, whatever. It's really common. It's one of the most common methods in the entire language. In fact, we did a pretty robust corpus analysis. You can see our methodology and reproduce it if you want. It's on GitHub. There's a link there that includes transpiled code. A volunteer did a pretty thorough manual review. We it seen in our in the data set from Chi. From a GSM need. It was more common than console.log, more common than .slice. more common than .push, .set (whatever .set might be). It's really common, but it's really clunky. It's long, and it flips word order from what you would expect from a regular subject-verb argument order that you would have with regular dot calls. And there's just a lot of boilerplate. Every time you type verb.call(receiver, …), it just separates the receiver from the verb. It flips the order. It makes nesting difficult. It's really clunky call. This operator would make this a lot less clunky. It would make the word order back to subject, verb, then arguments; it will put them near each other. Again, it just makes it a lot more or readable. .call() is very clunky, very common, and it's very clunky. So, very common times very clunky means worth improving with syntax or at least considering it. Big impact on the language. One might argue that “Doesn't the pipe operator solve this?”, I would argue that it does not. I would argue that if you try using the pipe operator to make the word order better - receiver |> function.call(@, args) - the result is actually less readable. So the word order is better, but there's just so much excessive visual noise that for such a common operation that I don't think the pipe operator addresses this problem adequately. The pipe group has been investigating for a long time whether it's possible to modify the pipe operator to address .call()’s clunkiness while still addressing pipe’s other use cases. And we still haven't found any, except like a separate operator, or modifying the pipe operator enough that it's essentially a separate operator. There's also concerns about ecosystem schism; I plan to get into this a lot more during the dataflow holistic discussion redux. I’d like to just briefly touch on it. I would argue that there's an ecosystem schism already happening right now between the non-this-based functions and this-based functions, and the most important thing is whether you can easily interoperate between the two paradigms. It's actually not so easy right now because they have such differences in whether they can have linear data flow and whether you can tree-shake them. And I would argue that with both the pipe operator and bind-this, the ecosystem schism actually gets bridged and interoperability becomes better. That schism is already happening right now and it would be improved by adding these operators. But let's get into that more in the data flow. I would like to focus on bike shedding four candidate syntaxes. That was the update. Now for the bikeshedding. There are four candidate syntaxes that different representatives have floated. Two of them you can group together, in that they are receiver-first and then the verb and then arguments, and that they're unbracketed, so they resemble dot-syntax. And you can have loose precedence, which means it resembles the pipe operator, or you can have tight precedence, which means it resembles the dot operator; that affects whether people will usually put white space around them, and it affects grouping, obviously, and it also affects how you conceptually think of the operator. Is this, basically, another pipe, or is this basically another dot? There's also a bracketed version of receiver-first syntax. This isn't too popular, but it's there and possible. There's function-first, which means you would have to use it with pipe if you want to have a “natural” word order, but it's still better than .call(). And then there's using this as an argument, annotated with a special this annotation. So those are four examples of syntaxes. There's an issue thread here. I just wanted to get some temperature checks from the committee on which ones the committee thinks might be the best to go with. Let's go to the queue. Looks like it's empty right now. If nobody has any comments to make, I will say that I am currently leaning towards tight receiver syntax. First I have heard from some representatives that they are concerned that there may be confusion, with beginners or whatever, on when should I use or should I use call-this? And I would just say that almost like you should usually use . and call-this when you know what you're doing. I don't think that's really a big deal. It's just a matter of a little education. I think that tight precedence makes more sense than and would be less surprising than loose precedence. And I think that, I share concerns with like some people like JHD, that other syntaxes like receiver first wouldn't bring enough benefit to warn syntax. We looks like hex yeah.
JHX: discuss about the proceedings. This is the I think the most important thing we to consider personally I prefer the tight precedence like the operator. This problem is also discussed in the oh The barring operator Ripple. So if it's used in loose style it. It's looks more like pipeline. Operator. This is a problem of the old by bind operator because the as the old, bind operates are all current to call this, all the extension proposal, they all use the function at some methods. So, it used as a master cylinder, which which army methods that, it have the receiver, receiver, so generally people would would like to use it like a normal method. this this is why it's better to use the same precedence as the dot and i think it will be better for the mass of the changing. And another prominent of the operator precedence is the style of tight unbracketed. I'm practicing. It's use. Proceedings is hard to describe the precedent's the left side. It could be seen as the same precedence as thought, but the right side, it it's a little bit lowered, the and Toppers so I believe it's Circle a possible, but I feel it's a little bit confused.
JSC: Yeah, this is my my yeah JHX. Sorry. I found it. It's a little hot difficult to think about it without just over verb over words. Maybe if you could leave comment on, I think there's a precedence issue with not go ahead and open it and write up what you're talking about since will be a lot easier to see it, you know, but from what I'm getting you. Are concerned about the precedence of the right hand side, is that correct?
JHX: yes, it's it's not I believe it's certainly possibility. It's hard to, For example are right. The document and educate the people that's the the left side and the right side actually have a subtle differences.
JSC: Okay, so, right, yeah, right now it's using decorators as precedent where it's an identifier chain identifiers, or Eyes. And there are a bunch of and there are some early errors that try to guard against confusing precedence when you like put in parentheses unexpectedly, but we can talk about this more. That sort of orthogonal to this overall thing which syntax we should do, but it sounds like you said that you prefer tight receiver first, so I'll keep that in mind. How much time do we have left? In this time slot in the in this up for this agenda, item, you have another minutes. Okay.
Next up is Ashley, not keen on the pipes might be confusing with, like, just real before you go. Can just? Yeah, go ahead
ACE: Okay. I just want to want. I'm I typed part of it too quickly. It's more, it's specifically the ones. So I'm ones that very very, very close to the pipe. Like the first two Like: exclamation mark. Like, if it's below my eyes are just like fish. I kind of I do. It's not so much. Like does it use a like a greater than Arrow? B, Co the ones that are only a few pixels away. I think if I didn't have my glasses at on, I'd find it really hard Spot the Difference and considering the semantics are very different in terms of You are you just getting a binding on the right hand side or just the right hand side, need to return a function as a Vista receiver. Like because the quite different I just want them to be fairly visually different. That's what my two cents. It's not a strong opinion. It's just my gut reaction looking at
JSC: Okay, so so you are talking purely about the visual appearance, Not about like loose versus tight precedence, and you are saying that when second character is a greater than sign it like especially the pipe for instance. It it looks too similar to the pipe of visually especially far away. Are you fine with the squiggly wavy and then wavy, the wavy, the tilda greater than because right now I'm going with that because it's it's similar like this. to like Darrow, like a hyphen greater than the, the single, the single Arrow. That's some other languages use 444 method calls, but it's different because so because it's different, so it's a little different. Are you fine? We had greater than
ACE: yeah, at least for me that the fact it's like a rotated line helps me immediately. See immediately. See the difference personally. See I'm a that was purely the kind of ones that look like a vertical line. All the rest. I'm personally, happy with.
JSC: okay, so you're just you're you would just be against colon greater than I intend exclamation point greater then.
ACE: correct, correct.
JSC: maybe octothorpe greater than okay. All right, very good. Next up is JHX. Just real quick. Hacks with regards to relationships between Puzzles. There's going to be a long dataflow Redux thing, and I'd like to focus their there on, like, stuff like this. So if you could be brief about this item.
JHX: yeah, well be very shocked that because currents are the causes. Now, the semantics is the size of the exact proposed. If, if this proposal could choose syntax, which leave the syntax the syntax space for the extension. From proposal to comparison compatible with it. I would be very appreciative if we could go to this direction. Thank you.
JSC: Does that affect which operator, which greater you would prefer?
JHX: The operator if it could use the receive first and bracket style. It's It's possible to be compatible with the extension proposal
JSC: And you referring to that you specifically being compatible with your ternary operator?
JHX: the binary reform.
JSC: Okay. All right, that's fine. All right. It looks like the queue is empty and I'm getting the sense that tight receiver first. It would be preferred over the other four. Does anyone else have anything to say? If not, I can just send this early. All right, we can talk more. That's great. We can talk more about this in the holistic. Dataflow Redux. There certainly will be a lot to talk about there. Thank you Thank you very much. That's all.
USA: Thank you.
Presenter: J.S. Choi (JSC)
JSC: this is not advancement. It's an update and bike shedding. So long-awaited pipe operator nearly ready for stage 3. Hopefully we have two more big hurdles. That's this one, but we've got to one of them is that we're stuck on by shifting the spelling of the reference crucial piece of its syntax. Um, why a pipe operator really quick developers often transform stuff and data flows. They don't want to use, you don't want to use variables for every step, they're able to do this with DOT method with regular prototype method chains. You can see the numbers there, left to right, linear easy to read. But if you mix in functional function, calls or other Russians, the reading order gets become zigzagging between left and right and To left. It's not linear anymore. So if you want to read from like the beginning to the end of the data flow, it becomes a lot more difficult. Follow the numbers (on the slide) to see what I mean. So developers need should be able to express other data like data flows that not only use prototype method change, but other things like function calls and other stuff. It's still in linear left to right chains and a pipe operator would make this possible. So the pipe operator would create a lexical context around its right hand side within, which it would bind a topic reference topic reference to the result of its left hand side, the topic reference that being some sort of symbol, and this is a, this is a reflection of like a greater trend in the ecosystem towards using more tree shakeable functions, like instead of things straight on the prototype chain. Because in order to be able to split module, Like, there's a prominent example with the new Firebase JavaScript SDK, which recently switched from prototype based methods to individually importable functions, but a big complaint with that has been that you have to rewrite your code and it becomes a lot harder to follow the code without introducing a lot of temporary variables. The pipe operator would help with that. It's been a long road to get here. You can read my History document if you want to get the Gory details, this has been. This is like maybe the fifth or sixth presentation of pipe to the committee since 2015. We've gone back and forth on a lot of sin taxes in particular between two possibilities with tested unary function calls. That's take a F# style and Hax style, which is what we have now with lexical topic references since last summer we've had consensus or style is the way forward to, to concerns about f# style from the from the broad committee, the developer committee itself remains split, but they just want some pipe operator, largely in general. We've also been talking about data flow proposals in general and where things fit i, and there's going to be a long discussion during this plenary that continues that discussion. You can see the there have been two meetings so far and you read the notes for that. And I also have a long article that I recently updated that you can also read about that. If you can't find it, just ping me.
JSC: So, you know, we that one big hurdle is figuring out pipe, operator and where it fits in with this other data flow, proposals in particular. There's a representative who has a hard requirement that pipe operator be packaged with call this but like that's one hurdle; the other hurdle is to bikeshed, the spelling of the topic reference. So I've got a couple of criteria here for choosing to token. Is simple doesn't make parsing more complex for computers or for humans, is it visually distinguishable. Is it does it blur into ASCII soup? With other common symbols? Does it make it excessively more verbose? Is it easy to type in common keyboard formats? And when we're thinking about these criteria we gotta away from them by expected by how frequently their cases are going to occur. For instance there is a candidate topic to number signs to up to octo-thorn[??], and I would argue that because I expect Tuple and record literals to be very common. I would use that very commonly and that their costume visual distinguishability Scott to be x + Large expected number of occurrences. So that's just an example of weighing these criteria by expected numbers of current of occurrences. We've four, we've got four slides with candidates, but those are all the candidates on the left of this slide. There are six candidates. You can look at the wiki page. You can even edit it at yourself. There's an issue that has maybe 400 comments on it accrued over the past four years and just some notes. We are excluding things that are currently binary operators. So that includes carret and percent. Some implementers have raised concerns about increasing coupling between the lexer and the rest of the parser. You know, like like / that having to be distinguish between division and regular expression literals. So like we have excluded those we have also excluded the single number octothorpe[??] because it would require because if Tuple literals go with with the number sign for to indicate literals, then we would have to parenthesize them for topic property access in. Definitely identifiers like the dollar sign cetera team too hazardous to refractor and refactoring. It would be. also. There also common identifiers who would be quite annoying if we could not use them within pipe bodies, and there is a representative who would hard block anything that involving that is an identifiers. So we won't talk about them. So we've got that @ sign only viable single character token, there is with regards to decorator, syntax allowing @ in parentheses, and then an expression in there to indicate to let you decorate classes and functions with arbitrary expressions. There is maybe arguably an automatic semicolon insertion hazard, but I would argue it's not that big of a deal. One thing to remember is that we statically at parse time, have an early error that requires developers to put at least one topic in every topic body or else it will, it will not compile. So if there is, if the only, if they use an @ and they, it's it's being used as decorator and not topic reference, then it will throw if they use an @ elsewhere. And it and it's still that wouldn't catch it. We could put in an utterly are to prevent unprinted size decorated classes or functions as pipe bodies. I don't think this is a very big ASI Hazard and of course the committee generally thinks that people should be using semi colons anyway, it's only viable Single Character token. I am biased towards it, but here are the other possibilities, like double carret. Which is fine. It bitwise xor exclusive or is not that common and can set there was a concern about dead keys with a keyboard layouts, but it actually is usually easy to type with the exception of some keyboard layouts that require four keystrokes. There's double percent, Similar thing remainder more common, but still not bad-common, @@ there's, there's a number, a number sign, and then underscore, which actually, I think probably should be disqualified because it will be ambiguous with private fields, and is already ambiguous within this and then there's double the number sign, which I is not ambiguous, but I'm not a big fan of because I think it will be quite Noisy with Tuple literals. Anyways, those are the six possibilities.
JSC: Let's look at the queue. The queue is empty. I will glance at matrix. Nothing. I am currently inclined towards that and I would, and although I'm not the only champion of the group. I, that's what I would push for within the champion group. So I'd like get temperature from the other committee and what they like, or don't like. There's a bunch of things on the queue now. Okay, MM.
MM: so of the candidates as you walk through them I had a positive reaction only to at and at at I like that better the confusion with decorators, I appreciate what you went through on that. I'm a little concerned with that. I'm trying. But I think I accept your arguments that I'm I'm not alone that I should not. Be a lot concerned with that at, at would avoid. That is just bigger, the other ones I think are just too close to other things in the language in ways that are At is that are more confusing than the way. close to decorators . JSC: All right. Thank you MM I will add one thing which is that, I think we all should discourage developers from making pipe, body's too complex. I think pipe body should stay simple. I would argue that the linters should ban class expressions in pipe bodies in general, probably, and maybe decorated functions in pipe bodies in general. I like, I don't really that - maybe that's a little too extreme but like, pipe body should be colorful. We should discourage developers from, definitely from ever putting decorated things inside of pipe bodies. The only other concern is for developers who don't like semicolons, whether they will accidentally, create a decorated thing with a semicolon and the early errors should prevent that. So, thank you MM for your opinion. Next up is JHX.
JHX: Yeah, I also prefer the @. I have a small question. I'm not sure what it is. The Decorator allowed to have some white space between data and identifier?
JSC: That is currently being argued over. There is a thread devoted to that I created.
JHX: [unintelligible unfortunately]
JSC: Yeah, I'm not sure what the answer is. It reached stage 3? So probably it's been locked down and I don't recall the answer. I'll have to check again. SHO. Yes. The Baseline thing the Baseline thing.
SHO: Yeah. I just wanted to voice that. I remain a huge fan of the double carret because I think my having the higher baseline, it's just really distinguishable while also still being light, right? You're not like being assaulted with all of these full height topics, and I think the win is such that on the few keyboards. That caret is harder to type remapping or other shortcuts could be made to make it work. And so in my opinion from the, from the dimensions, on which we are balancing, everything. I think this is still a clear win. Xor is not used very often and it's so distinguishable. So I just wanted to throw in my favor for that one.
JSC: All right. Yeah, I appreciate the typeographic baseline argument. I always have I really wish that single carrot. Could have been a thing. It, having said that, I think I personally feel that a single character having a single character is enough of a win over having raised typographic baseline, but I understand that this can be subjective. It looks like others in the community are generally supporting so, but I do appreciate your argument for distinguishability do to raise typographic baseline.
JSC: JHX, looks like is looks like 5 carrets would be valid syntax. No need to talk actually hacks if we went with double carrot, we would ban topic the xor being right next to next to each other. They would have to be At this separated by parentheses 4 spaces.
JSC: Next up is WMS, as who supports @.
JSC: Next up is PFC. mental heart blocks over up like shit. This Shu. Yeah, the heart block being identifiers. That there's a representative who really doesn't want identifiers the as in like variable identifiers. That's why I mentioned. That is go public. Go ahead.
PFC: It seems to have been mentioned more than once in your presentations about bikesheds, that somebody's willing to block the proposal if the result ends up being this or that. I think that is odd for a bikeshed issue. If that's happening a lot, as it seems to be from what I gathered from your presentation, we should think about additional guidelines for appropriate use of a block.
JHD: So I can speak to that. So, first of all, “block” is sort of a strong term. That concept doesn’t really exist. Outside of plenary, the reality is many, many people have repeatedly suggested the same things that have already been discussed on the bikeshed issue, which is often something that happens in bikeshed issues. One of the things that's repeatedly been suggested is using identifiers, and I'm sure I'm not the only one - I hope I'm not the only one - but I am not comfortable with an identifier being used that would shadow an existing identifier that breaks, I believe it's Tennent's Correspondence Principle. It would be a refactoring hazard. So that's the sort of concern that has blocked many changes in the past. Thus I would be very surprised if I’m the only one who shared that concern. I brought that up on the bikeshed thread to try to avoid, you know, ratholing on that one particular topic, and so that we can have more productive discussion about alternatives, since bikeshedding which identifier we should use is sort of a waste of effort, if a valid identifier is not going to be something that can make it through plenary. Does that provide sufficient context?
JSC: PFC, is that all for your item?
PFC: Thanks for explaining. That instance wasn't the only time blocking something from this presentation, but I won't take any more time from the discussion about this.
JSC: Other thing with blocking is has to do with this proposal and call-this, and we can talk about that more during the dataflow. Holistic, data flow discussion. There is a representative. I wouldn't say, that's a byte should issue. More of a conditional, or the conditional advancement issue. There was the advancement of pipe to stage 2 or stage 1, I think one a few years ago was conditional on some buying this, or call this operator advancing with it or else the representative would not want pipe to advance, but that's not really a bike shed issue so much as it's a broader. Issue that we can talk about during data flow. Next up.
USA: We just have two more minutes.
JHX: I just want to express its have a reason that each because the proposal is for the ergonomic is so even if it's byte should issue. It's a very important.
JSC: Sorry, thank you. Next up. MM.
MM: This is a response to Philip. The blocking sounds like you're actively doing something. And I think the framing here is really consensus must be earned and a syntax that I don't like and think, would cause something to overall subtract value from the language can cause consensus, not to be earned. And therefore, I don't, I don't think that there should be something unseemly about blocking on a syntax that you don't like or a name that you don't like.
JSC: All right. Thank you MM. We're out of time now. It looks like there's a general consensus for @ to be topic reference. Sorry. SHO. It's but yeah. All right. Thank you very much everyone and I'll see you at the holistic. Dataflow, be ducks.
USA: Thank you.
Yeah, so with that we're done for this session, although I would to invite you all to the whole we track, which is hubs. So feel free to hang out over there.
@was popular
—-
RPR: There's just one other notice that announcement we should do very briefly from JHD about updating the process. The small. Clarification beer.
JHD: Yes, after the confusion that we were talking about yesterday with this entrance criteria requirements to a stage and what quality the spec must be at, I made a PR to clarify that in the process doc. I believe everyone who had an opinion in that discussion has reviewed it already, but maybe some somebody's been missed. I posted the PR in the delegates channel Matrix; if there's no objections by the end of the day or concerns, I'll merge that. Thank you.
You're right. That's the end for this session. Please enjoy the hub's. You can be back at the top of the hour. So that's and 54 minutes time.
Presenter: Mathias Bynens (MB) & Markus Scherer (MWS)
MB: ... in when you feel the need Markus. All right. So yeah, today we're going to be asking for stage 3 on the regular expression v flag proposal which includes set notation, and properties of strings, but first, we'll give a quick update. This slide is a recap. You've seen it every single time we presented on this proposal. In a nutshell, the new v flag adds the following syntax and semantics for properties of strings and set operations. So difference, subtraction, intersection and nested character classes. Union was already supported previously – again, all of the details are in the Proposal repository. That's the source of truth. So everything you see in these slides is also captured. The slides are just to make it easier to present. And on the next slide We're talking about a few updates that happened since last time we presented which was in December, so just to get you up to speed, we already announced that we would be asking for stage 3 review, that we would be asking for stage 3 at some point. So we kind of asked for stage 3 reviews to kick in, in the December meeting and we have a tracking issue for that, which is number 24. The pr is linked here as well. And there's a link to the tool that can show you the spec preview with inline diffs.
MB: So, any review feedback is welcome on our repository directly or perhaps more conveniently on the pr itself. We've received some early feedback from the editors in particular, a shout out to KG who gave significant amounts of feedback, and we've addressed this feedback already several weeks ago. And then later, we also got and addressed feedback from stage three reviewers. So here's the links to the issues where these reviews happened. I do want to point out that we addressed all the feedback that WH gave us so far - that issue is closed. MS gave feedback that is still a work in progress. There is one particular open issue about the sort order of equal-length strings in string literal syntax. With \q{foo|bar|baz}, do we match in source/parse order, or do we treat the character class as a mathematical set of strings with no inherent order? Currently the spec text doesn't really have an inherent order for this, the question is, what do we do about this? This is not really observable other than through timing, if I understand correctly. So we would also not be able to write a Test262 test for this, but it is an interesting question that we would want to definitely address one way or another rather than it being an oversight. So that's still a work in progress. It's unclear to me if this is stage 3 blocker. MS, maybe you could speak to that?
MS: I don't consider it to be a stage 3 blocker, but it'd be good to resolve it.
MB: Yeah. Okay. Sounds like we are in agreement then, that's good. Yeah, then the same applies for RGN. He also left feedback. We've already been addressing - I would say most of it, but there are still a few open issues there, but all of these are issues with the way we wrote the spec text rather than the proposed observable syntax or semantics. RGN explicitly posted on his review, that he doesn't consider any of his feedback to be a Stage 3 blocker.
MB: Which brings us to the next slide where we've listed the stage 3 entrance criteria from the process document. The first is to have complete spec text. And so we believe that we do have this of course, modulo the remaining feedback that we aim to address in the coming days or weeks. Stage 3 reviewers have all submitted their feedback. We've been addressing it, but are still in the progress of addressing some of the feedback. And also, yeah, one other requirement, is that all ecmascript editors have signed off on the current spec text, my understanding is that most of the time stage 3 is granted conditional on this happening. I know that at least KG has already reviewed this very carefully. I know that - I can imagine that the other editors might want to take a closer look at some point, but I hope that we can ask for stage 3 in this meeting conditional on us completing, or addressing the remaining feedback and on the remaining editors also taking a look or giving their blessing. MWS, do you want to add anything to that?
MWS: No, I think you covered it very well. Yeah, that looks good.
MF: Mathias, I can comment here. I apologize for not having gotten editor review and sign off before for the meeting. But I am okay with it going to stage 3, conditional on the editor review.
MB: Thank you.
SYG: Same for myself.
MB: Awesome. So yeah, that's all we wanted to present, really. We're asking for stage 3. This is the current status, if there's any questions or people have any concerns we’d like to hear it now.
[silence]
MB: I don't have the queue open over here. I'm not sure if anyone is on the queue.
MS: Do you want to discuss my concern and see what not others have concern or whether we can deal with it at this meeting?
MB: Yeah, that would be excellent actually.
MS: This probably isn't the best way to show it, but if you could show the actual - click on the the link there, where it shows character class containing strings, or actually, what you put here, I think is pretty good. [tc39/proposal-regexp-v-flag#55 (comment)]
MWS: So, do you want to summarize what your concern is? And I can talk to what I put together as my thoughts yesterday.
MS: Sure. So, this proposal, not only does it allow to use Unicode properties of strings, put together in a regular expression, but it allows string literals. And the proposal specifies that strings are sorted based upon length with longest length first, preceding shorter lengths. My question is, what about collections of strings within such a property that are the same length. Do we want to preserve the ordering that was in the source, or does it matter? And my initial concern has to do with, if there's any intent that the programmer had, primarily related around performance, but then there's this kind of off in the future kind of concern is if we add to this proposal, will not specifying the sort order make a difference? Right now, we don't have property escapes included in these literals, but you can imagine that that could be a possible future extension.
WH: I can respond to that. I've looked at that in detail. What you have here is a mathematical set of strings. When you have strings with different lengths then the order matters because you can see whether a longer one or a shorter one matches. Within a subset of these which are all the same length the order does not matter.
WH: That's been that way since the beginning. Consider the set of all strings of length one in character classes. You can ask the same question. What order are they in? And the answer is that it's never observable and it never mattered. And yes, we've had this situation since character classes began.
MS: Yes, and I agree certainly with our current character classes where you have a single code point. In a collection of single code points it doesn't matter, and depending upon the size of that set, in JavaScriptCore We do different things because it doesn't matter.
WH: Yes. And you could make the same argument about all collections of length 2 or all collections of length 3. The same logic applies.
MS: Yes. There is a slight difference. In the case of a collection of strings. Here the example is three strings. We consider an example where there are several hundred strings. The algorithm you're going to use to match to check against those hundreds of strings, is going to be different than you're going to match several hundreds of characters. You can do a binary search or something related to that on single characters. Whereas on the string that's a little bit more difficult. So there are possible performance implications of how it's sorted or not sorted.
MWS: So, with my implementer hat on, what WH says rings true and kind of resonates with what I wrote yesterday, we define these as mathematical sets of characters and sequences of characters, and as an implementer I would expect that I should be able to actually use a set implementation to do the union, intersection, subtraction, and things like that. So, I would not want to be constrained by the spec to having to preserve an order of some of these strings from the input syntax. It would also be a little strange, I think, to figure out that this set of strings comes from properties so they don't have an order, or this other set of strings comes from a union of string literals and therefore they do have order, or a lot of stuff like that. If someone wants to be really fast for these kinds of things, I imagine they could use a retrieval tree, or trie. And that would make it reasonably performant to match strings. The other thing to remember is that the character classes that contain multi-character strings will remain the exception. Most character classes, I expect will continue to just have single code points.
MS: Yes, yes agreed. But I do see that this feature does open up different use set that, I could people take advantage because of not necessarily the Unicode strings, but because of literal strings.
MED: Yeah, I agree with Markus, I think. First of all, it's not going to be observable. If it’s conformant. It's not observable other than via performance. Mostly you don't want to constrain the implementation to say not use a trie or fast lookup, because you have a particular ordering among the elements. I mean, it's observable through timing, but you don't want to have the implementation forced to produce a sub-optimal timing in order to maintain some kind of ordering, and produce worse timing than you could. It doesn't seem to make sense otherwise to me to impose that it makes a difference in the order.
MS: Okay, the other reason I brought this up is we have talked about Array.sort and stability and things like that. This I think it's less likely to be an issue. I just want to make sure that we don't have concerns later because we didn't specify that. Others in the committee do not believe it's an issue, so I'm willing to remove this as an issue.
MS: That's why I wanted to bring future concerns. I'm willing to rescind it.
WH: Yeah, my preference for things like this is to have mathematical algorithms as much as possible and leave implementations some leeway in how to efficiently implement these. I did have concerns with an earlier version of this proposal which for case-insensitive matching produced exponential blow-up by enumerating all possible mixed-case versions of strings. And so I asked the champions to get rid of that. But for simple subset matching, I think the implementers are wise enough to just do the right thing. The other case where the formalism mattered was if we were to allow infinite sets. The champions have decided not to allow those for the time being. If we ever do allow infinite sets we'll need to revisit the formalism.
MS: Okay. You can consider my review complete.
MB: Perfect. Thanks everyone. So I guess with that we are back to the main topic, which is, are we okay, as a committee with advancing this to stage 3, of course, conditional to us finishing the remaining feedback from RGN.
MWS: I wonder if we would be permitted to check off one or two of these boxes. issue 24: “Designated reviewers have signed off on the current spec text”
MB: I guess we can check out Michael's review at this point. Well, we will update the readme and the FAQ on the repository to explicitly capture this. I will take care of that tomorrow, at the latest.
MWS: And of course, we will continue addressing what's left of the feedback.
WH: It's been a long road. I strongly support this for stage 3!
MWS: Thank you.
(silence)
MWS: So, what's the process?
MB: Is silence good news? :) I know we booked 30 minutes for this agenda item, but if we can move on earlier, that's great.
RPR: So you're looking for official consensus for stage 3.
MB: Yeah. Yeah. We want to make sure there's no concerns or objections.
RPR: So Champions are asking for stage 3. Are there any objections? [silence] No objections, and I think we've already heard the head support. So congratulations. You have stage 3.
RPR: Thank you, everyone very much.
- Stage 3 (usual condition of editors sign off)
Presenter: Daniel Rosenwasser (DRR)
DRR: Hi everyone. My name is DRR and with RPR and RCA today. We're presenting a proposal called types of comments for stage 1. So just before we jump into the specifics of the proposal. I want to talk a little bit about my background with typescript. I've been on the team for several years. And what is TypeScript Exactly? Well, just some History. JavaScript has grown in how widely it's used. This is TC39. So I'm sure many of you are not strangers to the fact that JavaScript is being used in pretty much every space that you can imagine these days, right? Front-end applications, back end applications, other devices, practically everything. But the thing about that is as JavaScript has been employed in more and more places we've seen, the sort of tasks people are using it for grow in complexity. As you try to build something more ambitious, it gets harder. We noticed this ourselves back in 2008/2009 or so, where we needed to start building out these richer more powerful web applications, but we just found that we were lacking the sort of tooling that we were used to for building other applications for something like JavaScript apps, right? So things like Office and whatnot. And the one of the biggest things instead of features that was missing was Modern constructs, right? Things like modules and classes, shorthand functions, variables that exist within the scope of the curly braces that you write them in and so that's ecmascript 2015, right? That came years later and that has made the language dramatically better for writing, modern code. But we were still missing some other things too. For example, we were making a lot of these typos and logic errors that I do. We could have been caught by running the code before shipping it off to production, and it's not actually just that static type checking that we're missing, right? This is, this is something that can help prevent errors before you run your code, but it was also the tooling, right? So we were used to using languages that had autocomplete, where you can like navigate, Out of the gate the code base at reusing. And our experience told us that that kind of tooling is best built when it's powered by types. The same sort of thing that provides the static type checking you want and so we set out to do something like that for JavaScript, right? What if we could bring the benefits of that to JavaScript? So the core idea is: what if you could tell some tools what the types are within your program. So you could say that my function takes something called a Point and that Point has an x and a y property and those x and y properties are both numbers, right? And once you have that information, a tool can give you things like error messages to tell you when you're doing something like accessing a property that isn't known to exist, but it can also provide things like autocomplete as well: so you can know that "Hey, this thing has an X". This is what we got to get the tape and you can know that those X&Y properties are used and correct ways too.
So, that's the PowerPoint version of this, but I want to just quickly jump into an actual code example of this.
DRR: So I'm going to open up a prompt. I'm going to write, I'm going run TypeScript in, I already am ready. Wow. Okay, I'm gonna run this in watch mode. And then what we can see is we have the output file. So this is the thing that I'm talking about typescript and it's taking some input JavaScript and it's providing creating some output JavaScript, right? Nothing's really different here. The new lines are removed. We don't preserve everything, but we try to make it somewhat readable.
[live demo setup]
DRR: Okay, so this is still a JavaScript input file, but what I can use with right now is a different file extension, called, .ts and this puts it in a different language mode. Where you're saying, I want to allow some extra type Syntax for my JavaScript as soon as I do that. I actually haven't changed anything, but I can catch some really basic mistakes, right? For example, here. I'm already getting some basic error message that says that receipt is declared here or recipient is declared here, but I couldn't find <typo> right? So maybe I need to correct this. Now notice even though I have errors. If I save this, I'm still getting output. So the core principle is that these type errors, don't block anything, errors are there just to provide guidance, but you can still run your code. You can still get output and run your code. But anyway, I'm going to use a quick fix here. Just to fix the spelling in the correct. One of the errors that TypeScript provides. Another error is right here. It's saying that strings not assignable to a DOM node in other words, right? And so what I've done is I've called this function and it has string apparently and I'm trying to put that in the DOM. What I probably meant to do was to create an element, and then I want to say that innerText = greeting and then I want to pass the element in right now. That's, that's unheard of the error messages. Those scary Red squigglies. What can remove the output here here. Now, I haven't actually changed the code at all. This is all just runnable JavaScript. But at this point I have, I'm still getting some amount of type checking because TypeScript is able to do some basic type inference and knows that even though we don't don't know the type of the here. It's going to produce a string. And so here the type of greeting is a string and then here the type of el is element And so we can do a certain amount of inference so that you don't don't have to annotate your types everywhere, right? So We could start adding type annotations to different positions. Sometimes it's optional you don't need to get better inference rather, but already, but just by adding something small, we can see that we've already made a mistake because we've accidentally used the wrong casing for the C in the toUpperCase method. I could use a quick fix here in my tooling or I could just write toUpperCase
Presents slide on popularity of TypeScript
[continues presenting slides]
DRR: So, jump back into this. Looking at the top four spots here, and that's actually been sustained in the year in last year's Octoverse ranking as well. So this is astonishing because we really didn't see this happening back when we started typescript and well came out with it in 2012. It's been around for about a decade at this point, but, you know, you can look at this chart and you can see that you can really think of this as TypeScript as being a subset of the JavaScript Community, right? And what this chart is really showing is that this is a very popular pattern: using types in your JavaScript, using a typed version of JavaScript, is extremely prevalent, right? You should see. This is the percent, you know, the number of people using types in their JS today and it’s really proven the value proposition here, right? A lot of people use types in this room. It's at least the lower Bound by trip. Is that is so You know, it speaks volumes to see the usage. We've also seen huge efforts from other companies as well. There are also other type-checkers out. There. Flow is one that also adds its own syntax extensions that look very similar to TypeScript; Closure Compiler also did a sort of similar thing where they use a format called. JSDoc, a common format called JSDoc to type-check JavaScript as well. And so in many ways these have sort of convergence, right? Like the fact that you know, these type annotations and types, don't have any sort of emit generally, but they have different approaches and goals, and it's been good that they've been able to sort of experiment with that as well. So, you know, one of the things about the people using typed JavaScript, or rather these typed extensions to JavaScript, is that as soon as you use these extensions, you can't just run the code, right? You have to find a way to strip out the types. And so, you know, we knew that this was an issue because people want to be able to do lightweight projects without a build step. They want to be able to actually just restart node or whatever their sort of program is to run code without having to do some sort of intermediate step. However if you're going to use this format, this is really convenient, but it's not directly runnable. You're going to get an error as soon as you try to run it. We try to solve this problem with TypeScript by leveraging the JSDoc format, right? So this is one way that you could annotate a function to say that, it takes two numbers and returns a number. There's other ways that you could do this to, by mixing TypeScript specific syntax with JSDoc. So here's another way that you can today, you know, write JavaScript code that's understood by a tool like typescript that says, it takes two numbers and produces a number as well. Flow had a another similar approach where they used comments that look a little bit closer to the actual types and tax that touch been flow. both use so So you can kind of hop into this comments syntax every time you have a binding and then say like this thing isn't going to be a number, right? So visually it looks a little bit more like something like typescript or flow, but you know, you have to kind of hop between these things. And so this this all these approaches are Usable, but they tend to be a little bit cumbersome, I would say. There are other approaches to get around the build step as well. Right? So for example, we're seeing this huge blob of build tools that are just meant to be as fast as possible. Right? So fast that it feels transparent to like have them around so you can just like run them immediately and within less than a second, many of these tools can produce output that you can run directly in your browser and node wherever and then some platforms either have hooks like node where you can you can use this sort of preprocessor like ts-node or other platforms? Like Deno just have TypeScript built-in so they can just run time to put directly correctly. And so These workarounds are okay, but often they have met some amount of configuration there, still issues with, you know, you run them here, but you can run them in other places as well. So that that tends to make things harder. So,
DRR: That brings us to what we're proposing today. So, the goal is to make static types more accessible, within JavaScript. So, a couple of the specifics of the goals, we want to make ergonomic type annotations in JavaScript, they should be easy to use. Should be optional. You shouldn't need to use them. We're not trying to change the way that every JavaScript developer has to write code. And the similar sort of duel of that: we don't want to change the semantics of the surrounding JavaScript. if you do choose to use types, so these types should not affect code that exists today and they should not affect code that exist with types either. So they shouldn't, you know, they shouldn't affect semantics but they should still be runnable, right? In other words: You should still be able to run the code that uses types. You shouldn't need some sort of preprocessor step anywhere that runs. JavaScript with types should run as well, but we need a space for type-checkers to actually evolve? Type-checkers are still innovating. They're still adding new constructs and we need room to grow while still having the syntactic space to do so in JavaScript, and on top of all of these things we want to meet community expectations from all JavaScript users here, especially users who have already invested interest in types. So we want to be able to serve those users users who already has and types of per flow. So that, you know, that we don't produce something that's going to be completely different from what they were already used to.
DRR: Some non goals are that we're not trying to make anything that has runtime effect. So one idea that people have often brought up is, what if you could hint to the engine that these two things are numbers so you should be able to optimize this function before it needs to get hot in some way a JIT. This is just not something that we're trying to enable, if an engine wants to do that it's free to but we don't really see that as a big enough win that we want to pursue it. We also don't want to work on runtime integrity checks. So in other words something where you can have these sort of guards for your functions where you say like, this thing is expecting these types and that should be enforced at runtime. That's not within the scope of this proposal. Observable runtime types where you can introspect these things that has the same sort of run time effect, and we just don't really see that as a value proposition that we want to deliver on this proposal. So, another non goal is 100% feature parity with existing type systems. Now, while we do want to enable some sort of sufficient amount of the syntax base of these types of systems, there are just going to be some features that we're going to have to drop and we know that. Those features can make their own way through TC39, if others are interested in the future, but that's not going to be something that we're pursuing today.
DRR: So, the idea is to just ignore the types. The way that you can think about it is that, if you go back to or go to this example, right here of an add function, when you see this add function you should think of the : number in each of these positions as comments, right? And so, in other words, they should desugar into something that acts effectively as comments, right? And so we want to define a syntax base for these things to add. You know, they were able to act as comments. They would be okay, but we need Syntax for what I would broadly break down into four categories. Annotations for wherever you want to say. The type of a binding is, type declarations to Define new types for static analysis, tools modifiers to be able to communicate some properties of properties and values. And type assertions to hint to a type system something about the expressions within your program.
DRR: so, Like I mentioned with these things being comments, the syntax would have no runtime semantics - it acts as comments. Hence the name of the proposal. We found this to be a really good framework for how to approach pretty much every aspect of the design in this proposal. So whenever you find yourself asking a question about the feature, how it should act, you should be able to answer: "Well, they're just comments, so..." and follow from there. Now because they're just comments a runtime would be able to just skip them over, not do anything with them but tools like TypeScript, Flow and other type-checkers that want to check JavaScript could continue to provide static type. Checking gives you errors and gives you tooling based on these types. So, for tools like typescript today, the process is something like: you have to take a TS file; you compile it to JS and that JS file gets parsed and executed by your engine, your runtime, whatever. What we're proposing is having some of that type syntax directly in JavaScript where it can just be parsed and executed directly by a browser engine. So, what that means is that you could write something like the code on the screen where you've written that X has the type string and you're assigning a number to it on the third line, but an engine would have no issue with this whereas tools, like typescript/flow/closure, or whoever, could provide an error message and say: "hey you're violating some sort of intent that you've communicated to me. Do you want to correct this? Do you want to do something about it?" And so, and so that would be where a lot of the value comes from, in this feature.
DRR: So why is this worth doing? Well, it really improves the developer experience for people using types in their JavaScript today, but it also allows JavaScript developers to start using types. They haven't given it a shot already because the barrier to entry is just high, right? So removing the need for a build step is just something that has many sort of implicit benefits for a lot of a lot of projects right for many projects out there. You have to think about what your bill step is for building between types of to JavaScript or another or any other syntactic, you know, transformation to JavaScript. You have to think about how your test runner transforms the code as well. You also have to think about how your debugging tools are going to be able to map between the input of your code and the output, right? So, you're running the output, but you need a way to jump to the input to see how that correlates between the input between the build step. And so source maps are another complication that for development time is often troublesome and then there's just other finicky thing where because JavaScript is just the language that they use in every context if you want to use something like, a REPL or an interactive prompt for JavaScript if you try to copy and paste some some typescript or flow typed code into a console, then it's usually going to fail because the type annotations are not parsable. So then you have to find a way to like get that compiled down, copy the output and paste that into the console. And that just is that, that's a nice developer experience to get rid of that stuff. Then from the tooling perspective, we have a space where we could innovate, and provide a lot of value in JavaScript directly. Basically, it's sort of a green light to innovate in this space as well. But, you know, there are some trade-offs here, right? Like for tools, there are some places where we're going to have to, you know, it's going to be harder to add new contracts and syntax. It's. But we see that as worth it for the developer experience, And if we have the right carve out, we could still do a good job, we feel. And then from the language perspective, by kind of bringing this typed and untyped communities together. They're able to just benefit from each other's work in a lot of ways, right? We've strongly been trying to bridge the gap between people who are actively trying to use TypeScript and people who are just benefiting from the tooling of existing editors and things like that, right? So if you've used in certain editors, like Visual Studio Code and whatnot, if you're using JavaScript that experience is actually powered by TypeScript today and a lot of users don't know it. And that's the beauty as they don't need to think about it. They're just kind of benefiting from a lot of the great tooling work that comes from TypeScript and whatnot. And then vice versa. We've tried to make it so easy so that people who are using untyped libraries can easily use those in TypeScript, by creating an entire ecosystem around that. But there is still a gap mentally for a lot of users. And so if types are part of the language, we can sort of bridge that gap more.
DRR: I think biggest added value for the language though. Is that it also allows JavaScript to grow, right? So, like I mentioned earlier in the presentation, a big part of you know, experienced pain point that we had was we were trying to use JavaScript in more places, and we just couldn't without types, right? If you provide types directly in the language and make it easy to use them, that actually allows JavaSScript to grow in a lot of other contexts as well. And so, whereas you have many mobile developers who are using native languages to build applications, they've actually considered using JavaScript because of things like Flow and TypeScript as well.
DRR: So, that's a lot of slides. Let's talk a little bit about the syntax. So here's the disclaimer. Syntax is up for debate. This is still stage zero so I don't want to spend too much time on it, But just as some examples of what we want and what we want to enable tools to have.
Here's a really basic example, it looks similar to the other examples that we've written in the slides. Here. You have a function calledequals, and it's saying that it takes two numbers and it's returning a boolean. Now, what if you have something that's a little bit more complex than that, right? Maybe you're not just taking primitives. Well, you can write something like this as well. You could say, you know, I'm going to take two Cats and return a boolean, and they're going to be compared by their names. From an engine perspective we wouldn't care. What’s written in that: because it's not going to try to resolve that at any point. So, this code should just run with no errors, even if there's nothing called Cat defined. Of course, they do have something called Cat defined, and this is something that a lot of static analysis tools would want you'd be able to write a class for and reference that and there's no issue there. And the expectation for these tools is that it what that, you know, Cat would describe the instance created by doing new Cat. Notice that there's a little bit of extra syntax here. We have to find a property declaration in the class. It has a type annotation as well. Sometimes though. You don't have a class in your program or you don't need a class. You're just trying to describe the shape of things. And so there are ways to do that in this proposal. One of them is called a type alias. So you could say type cat = then some type after it. Now remember this just desugars into comments, right? These are types as comments, but of course, that opens a question of like, where do the comments end, right? You need a way to know when to stop parsing and when to jump back into regular JavaScript code, regular runnable code. The current thinking is that we wanted to find some amount of well-known top-level syntax. Declarations and annotations, but in certain cases type systems are going to continue adding features. So what we need is a space where engines can just skip over that entirely. To enable that sort of independent evolution, we're thinking of an approach where we're leveraging balanced brackets, right? So basically, as soon as you see a set of parentheses or braces or brackets, an engine will Start going into this mode where it only looks for other sets of parentheses and brackets, and tries to make sure that they're correctly balanced within the scope and just skips over tokens, right? So, basically, as soon as we would want to add a new syntax to a type Checker, all we would have to do is just say, hey, for now, put it in parentheses, and then if we want to add that to the top level syntax, we could discuss that in TC39 here. So this is tentative as an approach. But we feel that this is the right way to open up independent evolution of the existing type-checkers, and future ones as well.
DRR: So, just a couple of questions that have already been asked, and we feel are worth clarifying. One question people have asked is "hey if you're going to add this new syntax, that does nothing for the engine, aren't people just going to ship a lot of excess code that just does nothing?" Well, that's just a comment anyway, right? And so people can ship too many comments today. So are people shipping too many comments? We don't think so, and for the cases where you have a couple of files, a small program, something like that. It probably doesn't matter, is what we're thinking. You know, the overhead there is so low that your comment size is not the bottleneck. There is probably no bottleneck in those cases, but if you're in a situation where you do care about bundle size of the code that you're shipping, then you can use a minifier.. But the cool part about this proposal is you don't need that minifier for every single build step. You can just do it in production. In other words, when you're developing and you're iterating, you don't need to have that sort of minification Step at every point. So the types can just be erased away by the minifier. Another sort of similar question is, whether or not this will reduce performance because of things like parse time because these comments need to be parsed a little bit more than what a typical comment would take. So we consider that, you know, cheap parsing is critical for this proposal, but we have sort of a similar answer here. Right? Like we don't think that it will matter for smaller projects and for bigger ones you can just use a minifier in the production step.
DRR: And another thing that has come up a couple of times, you know, we're not interested in doing any sort of runtime work here, but what if we did here in TC39 want to add something like that? Well, we could add something like a double colon (::). This proposal won't, right? Like, we're not interested in trying to, you know, grab that, you know, syntax space and we don't really want to pursue the types that are at runtime proposal if that ever comes up in the future, but another way to think about this is that you could imagine that the current proposal could, be adapted without introducing breaking changes by using something like a "use types" or "use type checking" prologue at the top of your file to say like this, this file should have some extra checks.
DRR: So just to recap, we think that there's a lot of value across developers, tooling and the overall ecosystem. We think that types in Javascript have grown to a wild level of popularity, it's being used throughout the ecosystem. And so, at this point we feel like it's gotten to the right time. We have a lot of validation that people like types in their JavaScript. But we still need a way to grow and we need to be able to ensure that, you know, adding new features in these type positions would not introduce any runtime breaking changes in any way. And as soon as you start thinking about that problem space, it really leads to the fact that these types need to be interpreted as comments, either be entirely ignored to allow these existing type Checkers, a new type characters to create new innovative features for each of them as well. And so I've been speaking for a while. while. I think I'm ready to open up to questions from the queue.
YSV: Okay. So regarding the queue, it's quite long and I have already partially organized. According to topic since it is so long. We do have 90 minutes to discuss this actually more than 90 minutes because the previous topic ended early. I'm going to ask people to stay very much on topic and if your topic is covered by someone else, please remove your item from the queue. I will be grouping topics so that we can cover everything together. So your item may move down, but I'll try to reserve the priority in which things have been listed, and I'm going to be keeping a rather tight leash be kept keeping a on this to make sure that this goes smoothly. So, the first topic is from Waldemar, please go ahead.
WH: Okay, this proposal has the largest amount of new syntax, I think, ever in EcmaScript. And I'm unclear as to why. Or let me rephrase that — I do not understand what the problem space is to be explored, or what problem we are trying to address here. In particular, I cannot tell whether the goal of this is to add TypeScript to the language or whether it's to add types as comments to the language in general.
DRR: I think I've clarified that but what I mean, let me take another shot. So basically we are trying enable some amount of existing syntax from type systems as they’ve been added today. We're not trying to add TypeScript Whole Hog, right? We're just trying to add what we consider to be a reasonable subset of existing type systems, but created an open enough space that they can grow. And so I don't know if that answers the question precisely.
WH: What's being proposed is not a small amount of syntax. It's maybe half or more of TypeScript. If the goal of this were to add a new way of having types of comments, I would expect maybe two or three grammar productions, not pages and pages of them. The issue I'm having is that this syntax is extremely brittle, highly tied to TypeScript, and it would form an attractive nuisance in that some of the TypesSript syntax will work while some will not, and this will just lead to major confusion and forking of the TypeScript language into syntax which works with ECMAScript and syntax which doesn't. This syntax is also specific to TypeScript, and any changes to TypeScript will likely propagate into changes in ECMAScript. So what I would rather see instead is if people wanted to program in TypeScript, they should be able to write code in TypeScript and not invent new hybrids between TypeScript and ECMAScript, which is compatible with really neither.
DRR: So I think just to tackle this, there's definitely concerns that I share with you. I do not want to make it so that existing TypeScript users are confused and basically end up with something that feels like a weird thing that doesn't work for most of what people write. So, I think that we're definitely in agreement there. I also acknowledge that this is a change that has a lot of scope, right? If you look at the tentative grammar, that is linked to in the top level the proposal Repository. Re you can get a sense of that. And so that is something that we can, we can work through it at later stages as well. I don't want to get too deep into the specifics here and then we'll be something that, you know, maybe we need to discuss it in more detail and have like, updates something kind of discussed a few times at this plenary. Where, what do we do about really big proposals? Right? How do we make it so that people who are not on board, have the time to understand, really have to do it offline all the time to get a good sense of what's being built. But, you know, I think that there's a way to approach that at later stages, but I definitely appreciate the feedback here.
WH: The main question has not been answered, which is, what is the goal of this? If in practice the goal is to support people writing TypeScript, then the simplest solution would be to add a flag which enables TypeScript syntax for your script and that way that people could write TypeScript without any hassle or worry about hybrids. It would be a nice clean solution behind some kind of an opt-in. And so then you could have the full TypeScript syntax without confusing people about what TypeScript syntax works and what doesn't.
DRR: okay, I do want to move through the queue. Maybe we can come back to that specific point that you had early in a little bit.
WH: I want to make it clear that I don’t feel that the questions about the motivation or scope of this proposal have been answered but would like to move through the queue.
YSV: Yeah, I think that will be coming to the goal in a couple of questions. Next up we have JWK also talking about the syntax.
JWK: We should avoid some syntax that might have runtime semantics in the future. Those syntaxes can be a proposal on their own. We should move that bunch of syntax out of the range of this proposal. For example, abstract classes, or the this parameter on the function parameter lists (a proposal from JHX). And we should also keep things like protected class field modifiers, also the optional parameters (x?: T) in the parameter list. Also, non-null assertion syntax. Therefore we don't limit the future design space we have.
DRR: I think this is valid feedback that we can discuss at a later stage, but I do appreciate the thoughts here as well.
RPR: Yes, if something has runtime implications then, by definition, that's outside of scope of proposal. The choice of exactly where to draw the line as DRR said, that would be one of the main things to decide in stage 1.
YSV: Good. I think that topic is finished. KG continues our topic on syntax.
KG: So, with regards to WH's question about what the point of this proposal is, I am taking as the point of this proposal that people would like to write types in their code and be able to run that in the browser. And specifically, I am taking that as the goal in contrast to making TypeScript syntax specifically work. So if the goal is just to have some syntax where you can write types, there are simpler options, and I would like the focus to be on those, so that we reserved a much smaller amount of syntax space. So for example : is already reserved in several positions, just reserve it in more positions and give rules for what it means in those positions. Sorry, rather than reserving the other positions, we could make it a comment in some positions. And then you could write, know, :interface as your declaration or whatever. This wouldn't make a typescript work, but it would allow you to write type declarations in your code with very little syntactic overhead. So, I'm fine with this proposal going to Stage 1, I would just like to ensure that we are saying that we are open to exploring syntaxes which are very different from TypeScript specifically, because TypeScript has so much syntax.
DRR: I am, I guess there's a sort of balance there with our goals. So like I don't want to bikeshed it here. I hear what you're saying. I'm open to exploring in various ways, but two of the goals that we have our meeting Community expectations. So like what do people expect types of look like in JavaScript? and also being ergonomic and so, you know, some of that is subjective and we can talk about that alone at a later point, but I am open to like thinking about that in ways that, you know, we're trying enable independent evolution as well. Right? So like what is the carve out? Right? That's something we can talk about further.
[call for note takers]
YSV: Reminder. This is going for stage 1. So what we are trying to prove out here is the problem space. So you have a concern that is potentially blocking on the basis of the problem that's being presented here. Please let me know and we'll move that the queue as a conversation. And if it is more discussing, how might approach this and other such topics than We can reorganize the queue in that way. Next up we have - sorry. Was this conversation finished? Kevin?
KG: Yeah, we can move on.
YSV: Okay, next, we have JWK.
JWK: Okay, so I am a big fan of TypeScript, but I don't think this proposal reaches its goal. The goal of this proposal is to enable people to write JavaScript with some types without transpiling their code. But I don't think it can be reached for the following reasons.
- If typescript added new syntax, and it's not falling within the range of this proposal, they will suddenly fail to run their code, and they need to a. Give up the new TypeScript feature b. Or they need to compile code, like we do today.
- If we have this proposal, some people will write their code base in this manner. If the whole code base has a single typescript syntax that's not covered by this proposal, they are suddenly fail to import those files like enums, namespace. For example, you have 20 files that's written in with this proposal and it works good, if you want to add an enum, suddenly the whole project is not able to run (even worse, dynamic import, so the syntax error is in the runtime) .
DRR: I mean, I think that you can make that argument about any syntax that, you know, might not work in your current browser. If it's too new or if you decide to use jsx, or I get that, there's expectation part of it. And so if we want to add any of those features, we could presumably, you know, Work through them here inTC39. So like if we find that we have sufficient motivation for something like enums, we can take that as another proposal. You can also get some reasonable feedback, right? If you're using something like I TypeScript, you can find out very quickly that hey that syntax is not allowed here, use this other thing instead, actually, right, but can give you suggestions. You can also continue to use TypeScript, right? Like, you can see if you still want, you can use TS files and compile them and do whatever you need to. It's ultimately up to you. But I do think there is something to be said about being able to use types in a very lightweight matter where - you know personally, I use JS doc types in build scripts, and lightweight contexts in cases, where I'm not going to be using JSX things like that, and it's fairly pleasant. But you know, I do find myself wishing that. I had a much easier syntax to use those types. So I see what you're saying, but I think that there is there still a lot of good value in here, and the tooling can be made to hint to you towards the "pit of success", right? Making sure you're doing the right thing.
RPR: So JWK, I think what you've outlined there is that there is always going to be a boundary where, when you hit it, you then need to jump to a compile-to-JS language and involve a transpiler. That boundary already exists today and today it includes any use of ergonomic types syntax. So this proposal is changing where that boundary is, and it's expanding the set of JavaScript programs that can now be written to take advantage of the ergonomic types in that syntax. So I agree, it doesn't eliminate that boundary, but it increases the pie. So I hope that is perceived in a positive way.
YSV: Okay, moving on to our next speaker, on the topic of goals or aim of this proposal.
GKZ: Hi, my name is George. I work on the Flow team at Meta and you know, obviously we're doing type checking for JavaScript. I'm a big proponent of types in JavaScript, and I appreciate the time that took to put together the proposal. I understand that we're going for stage one, so the specifics of the syntax and the grammar and all these other things is not really important, it’s all up for discussion that could change later. It's tentative. But something that I do think is important, something that should be made clear, is the aim of the proposal. What are we trying to do here? And that I think is clearly relevant for going to stage one. And there is a bit of a dissonance between what’s being described and what is actually the aim here. So it's not so much adding types to or, you know, adding this types as comments to JavaScript, but really, when you look at all the different details, yes, it's tentative, But the story it tells is this is specifically adding typescript to JavaScript or a subset of types of to JavaScript. You can see that in the little mini website, which says quote language in this specification papers typescript. As you can see in the grammar, which specifically is all of TypeScript and encodes typescript specific features and codes. None of flow specific features. You can see it in the readme which have we talked about TypeScript wanting to support typescripts. In reference to any flow specific features, it suggests that Flow can simply change its syntax, so that it manages matches typescript. you can see it in, you know, some of the comments of Gil who, you know, the Proposal is under, you know, in his repo. He's the originator of it, I guess something. Like, you know, "I want all types of code that develops right today to become JavaScript. If we don't do that. I'm afraid we lose control of the language to third-party type-checkers." Another quote. "My personal goal is not to improve detection or flow. it is to make types of programs also JavaScript programs." So I think it's really important to clarify here, what is the aim here? Is it simply to make, you know, give the special team to typescript and standardize that as part of JavaScript. And for us, I don't think that is a good aim. I don't think that's the direction. JavaScript should be heading in. It's almost, you could say, anti-competitive. And there's a couple ways we could resolve this. Maybe this is unintentional that we did it get feedback which was you know, no action was taken on that. Maybe it's unintentional and maybe we resolve this in a way to make things sort of not giving special treatment to one type checker on or another, I would say that, you know, to go to Stage 1, we should make it clear that no special treatment will be given to any existing type Checker. We're aiming, aiming, you know, to open up a spot. Some space to any, you know, potential type Checkers. We could say we're only going to take the intersection of features, you know things that overlap or the union of all the features, but the current situation, which is just doing typescript - that seems to the current aim - doesn't really seem like a good one. And another thing is that, well, JavaScript engines that are running code. Should just treat these as comments, ignore them. They don't even need to parse the actual type syntax itself. There are a variety of other tools that parse JS code. That do need to parse types. Now we're talking about eslint, prettier, whatever and you can imagine in a couple of years time from now under the default settings. Even if the intention of the proposal is not to, you know, be open to everything, What's going to happen is under the, you know, their default settings. They see a JS file. If we don't have some kind of annotation in the file saying what type system we are using, for example flow requires a comment with the @flow at the top of the file, what's going to happen is they're simply going to default to typescript and they're going to parse this any .js file, as TypeScript. So, even we without the intention, this can still happen if we if we don't require some kind of explicit way to denote this. So basically what I'm trying to get is, you know, know, what is really the aim here, and clarify that we're not in a special treatment to any existing type Checker.
RCA: Really, really good question. And I think that the arguments are also really good. Well, the aim, the motivation we have for this proposal. We said that this is three different foundations. Add the developer experience as you know, giving their erronomic types of users experience development experience and workflow improved. Either way, together with the tooling and also the language itself. Well, at this point, I think that going to Stage 1. It's the the step, where everybody interested in types domain can contribute to this proposal and can help us to shape the the best for it. We started with some ideas together also inspired by TypeScript by Flow. The actual state of art, and that also triggered curious and lots of new ways of seeing the grammar and new debates about the syntax. That is, they are really interesting to get this proposal where we want, but of course, we have to pass through the stages to get these shaped these initial part or the initial form of The Proposal is a declaration of intentions to open this space for types and aiming these three main foundations developer experience, the tooling, and also the Improvement of the language at level of community. (rephrasing) To go with the expectations of the community and also unify all this space domain and for the revolution. mostly that not favor one type Checker or other and even If we don't, we want to include and also inspire new ways of seeing this problem space and to help us to evolve.
GKZ: I understand that, but there seems to be a difference between what you're describing there and what is also de facto being with a proposal. As in literally, the website says, this is a language this language and specification favors typescript. It's only the typescript grammar very heavily focused on that. So what are you willing to make a commitment for in the future, that there will be no special treatment of TypeScript or select any other type-checker, there will be no inclusion of typescript specific features without looking at specific features of other ones, or we're only going to look at the intersection of features between them, and looking at ways to address the issue of ensuring that, you know, any files, there's a way to specify which what is the type, You know, what is the type Checker using this file? So I feel like I feel like you can say that now, but then de facto what is in the content of the proposal is something completely different.
DRR: But this is what TC39 is for, right? We can discuss these things and there's a lot of open questions here, and it's still stage zero.
GKZ: I’m asking about the aim of the proposal. Are you willing to say that the aim of the proposal, going into stage One, should not be giving special treatment as typescript and should be open to all type checker. the that just that one? Maybe we want understanding is, is that clear?
DRR: We want to strive to enable a space for all the type Checkers, right? We don't want 40 ways of doing the same thing. Of course, right? I think that's understandable. We want to be able to carve out something though, that each of the type checkers can use to enable their own syntax, right?
GKZ: Yeah
DRR: So I think first of all, like you've talked about maybe the materials that are publicly available. Well, many of those were written by extremely eager, really enthusiastic contributors. That's on me for not maybe trying to think about how that would have come across. So I apologize for that first of all. But yes, I mean, we want to make sure that you have like this space that you need as Flow to do the same things. We want to actually tackle the same sort of questions, right? We've had a pretty good relationship, I would say, in the last couple of years, just talking through syntax and similarities, and how mature. so, I think like, we can, we can continue that and work through those things on the repo here at TC39 at plenary figuring those things out. So we want to have that conversation with you. We want to make sure that like you have your space as well. We don't want to give preferential treatment. We want to make sure that we have the right stuff for the community. So I think that that I don't know if that answers it. I again apologize. I can see how that came across and I'm sorry about that.
GKZ: Okay, my concern is, you know, in the sort of feedback or given in the past, no action was taken to address that, so if that's commitment in the future that no special treatment will be given and you know, this feedback will be addressed and will be neutral to the underlying type checker then that makes a lot more sense. Going forward. That's all.
RPR: I know you've given feedback. I know that that's not been addressed yet. I think that was because that was coming down to the precise syntax. We've taken the approach that we really want to focus on the motivation. The aims, the problem space first. There was certainly no intent that that that your issues raised would be ignored.
GKZ: Well, I mean you have given specific…[trails off] I'll stop now, but you If you didn't want to focus on specific, so you want to fill the proposal with specifics. That also just happened. Be specifically typescript. That's why I'm saying. I understand the. Everything is kind of right now, but given what you have shared it is all exactly typescript-specific in both the wording of your motivations and any technical details you've given. So we can move on from that point. I think I've made myself clear. Thank you.
LCA: [via queue] There is an open issue about type 6 syntax, pragma on the repo. I do think an inbound, pragma is important and I think what we can take away from this discussion of goals is that there are concerns that proposed syntax is favoring typescript too much. And we would like their our committee members, who would like to see that Revisited with the the aim of the proposal being explicitly to enable multiple different kinds of type Checkers. To use this syntax as part of their addressing of the code base.
YSV: Okay, then we are going to move on to the next topic. The next topics are smaller. The first one is from JWK around developers new to JavaScript.
JWK: There are some other cons of this proposal. I have some friends who write other languages like Java or C++, and when they have to deal with JavaScript, they choose TypeScript. When I told them that TypeScript is not going to do any runtime check, they are very surprised and confused. This will become even worse if we add this syntax into JavaScript itself. Another point is, that this make the code harder to read (because the type annotation can be a lie). If the author wants to mislead the reviewers with some wrong type annotations.
RPR: I think we've got a slide on this.
DRR: Daniel. Is that in the appendix or is that? Yeah. “Is this a foot gun, people might misunderstand the feature, right:? So just two things here one, is that like you know, this has certainly not stopped people from using static types. You can write misleading comments as well, if you're using something like jsdoc as well. So if you're if you're I mean if you're writing that format and you're passing in the wrong data, then nothing stops that violation, unless you have some sort of static type checking ahead of time, right? The same thing applies here and and you know, it's been the case that TypeScript and Flow had been doing this for years and people might be surprised initially, but it kind of just all makes sense after we also have experience seeing this in other languages, right? For example, Python and Ruby both have type annotations now and they don't do any sort of runtime type-checking at all. And Again, I'm sure some people are confused when they first see that but you get used to it. And then you realize oh, this is actually a really convenient feature for your design time tooling. So I get the concern but we are experiencing signals that it is actually not a huge blocker to using the language.
JWK: Python has this feature, but I think they have some runtime reflection about the type right?
DRR: Yeah, and without going into too much detail here. There has been an effort to remove that by default and they found that it was too late because they had already added it to the language and libraries for depending on the default Behavior. So that has impacted things like runtime speed and They seem not to have been hugely happy with that outcome.
JWK: I'm not writing python. So I don't know what python people think about this feature.
DRR: Okay, I would say it's as I mean, it's a very similar approach and that's you know, yeah. I don't want to get into it for too long, but okay…
YSK: The next topic we have is from SYG. Please, go ahead.
SYG: Switching gears a little bit from from types to non-types, So, ignoring the stuff that I actually am not clear on if you are proposing right now with importing types of content types, ignoring the stuff that is not just type annotation comments and possibly type declaration comments. The mechanical way to look at what the proposal is doing, is just at unambiguous comment attribution, is my understanding. You have comments today, like C-style comments that maybe some toolchains— I think you showed an example with Flow— of annotating certain parse nodes at a finer granularity than line level to annotate that with a particular type using existing comments, but my understanding is that you like there is no standardized way to unambiguously attribute a comment to any particular parse node at a finer granularity than 'line'. So mechanically, I think the thing that this proposal ads is unambiguous comments attribution and I kind of agree with you that it opens a big space to explore. Maybe like well beyond types. Imagine that browsers decide to use performance hints Beyond types? Like think, performance guided optimization stuff. This makes that space open. Is that desirable? Have you thought about those consequences? What are your thoughts about those consequences?
DRR: I think that there is some prior art with runtimes experimenting. like SoundScript or whatever where the idea was like, let's try to hit a little bit to the to the runtime system to do so-and-so optimizations ahead of time. That would be cool but it's not something that we think is the primary benefits that something like this would bring it would be more of the design time. Authoring process, the tooling that we can provide based on that. You know, I'm not an engine expert but based on what I know of how optimizations work in existing runtimes. There's just a lot of difficulties when it comes to something like structural type checking, right? And in large Parts these types of stands for JavaScript are structural and it would be difficult in some ways. I would imagine to optimize so if—
SYG: We're not gonna be able to leverage the existing type systems, was I was starting my comment here was not about your thoughts on leveraging existing type systems in the runtime, but more that, I think this opens the gates to a lot more exploration than just type systems. If you have unambiguous comment attribution, you can annotate a lot of stuff, well beyond types. What are your thoughts on kind of like opening up that space?
DRR: Yeah, I mean if it's a carve-out you can use it right and And think for for several tools depending on if they like use a prologue or whatever or they just have some default mode. They might not understand whatever format that an engine would want to see. but you know, you could disable that checking in some way and then and then you would be able to like, sprinkle in whatever it takes and Information would nearly. I'm not against it. It kind of goes against the spirit but not the law, if that makes sense.
RPR: We've said, we're opening the space for tooling to innovate. I hope that's only a positive.
SYG: Yeah. I think I don't extend beyond tooling those also part of the point insofar as they if they remain like a tank. Hints or comments, right in that they did, did. They affect timing that they don't affect observable Behavior.
DRR: I think we were considering engines like tooling or like performance improvements in the engines to be tooling. But yeah, like I think that's within the scope of this proposed or that can be leveraged. We wouldn't mind in other words.
SYG: So then the second part, which is the original question on the queue is, do you think that characterization of your proposal stands on its own? Because I think most of comments, we have heard so far. on the discussion, we have heard so far is focused on the implications of adding type systems or adding weird hybrid type system or hints of the type system into the language, but there is a different framing of just looking at what a minimal version of this proposal might propose, which is just comment attribution.
DRR: I would have to see, I would have to discuss that a little bit more with you to understand that better. Maybe some of the use cases. I don't know if I could commit to saying like yeah, that definitely is within the scope and we want to add it as a goal of this proposal. Maybe we talked about it in more detail later.
SYG: Don't read too much of a value judgment into my question here. I'm not proposing One Direction or the other; I was just wondering about it, okay. I think that helps.
JWK: I want to reply about the JIT hints. In my daily life of writing typescripts, most types are inferred by the compiler. I'm not writing or annotating it. The only position I need to annotate the type is in the function parameter and I always use some compound types like generics, union, or intersection. If the runtime does not do a full resolution on types, those comments are just useless. You cannot use them as JIT hints. There's maybe some simple case, like function add(x: number, y: numbec), and the engine can have a reasonable guess to optimize them, but I think in most cases. It's will not help the runtime to speed up the code.
DRR: I agree. I think we can or okay with this and then agreement on this topic.
DRO: I feel like a lot of the people mentioning the potential use case for performance guided optimization— my gut tells me that as this proposal stands, it's very unlikely that minifiers would leave these types of comments and types in the code given how verbose they are. And so I'm not really sure what benefit there is to performance optimization in that case, given that all of these things would likely get stripped. if that's something that we want from this proposal. I think that needs to be stated very upfront.
DRR: I think I would say it's not within the scope at this point. I mean, maybe I misunderstood, but I don't want to focus on it too much longer this discussion.
YSV: Okay, that concludes Shu's topic. We are moving onto three topics from WH, which correct me if I'm wrong WH, but these appear to be all about parser ambiguity—
WH: Let me speak, please. I just wanted to point these out as examples of why I believe that the goal of having TypeScript-like syntax is unachievable unless you have an opt-in. There are places where you don't know whether what you’re parsing is a type or an expression until later. It makes trying to retrofit TypeScript syntax into the language untenable, unless you have an opt-in syntax mode. I just wanted to record these in the notes. I do not want to get into the weeds about the details at this time.
async as (x:y) => … : is this a function named as or a typecast of async?
(a):(foo)=>(bar)=>(baz) : confusion between arrow function and type syntax, which use the (a? … : confusion between type syntax and expression syntax
DRR: I appreciate it. I actually took a screenshot and I'm going to post some issues on these specific examples to try to figure out what we can do to discuss the ambiguities based on, you know, avoiding things like overhead.
WH: Yeah. I do not believe all of these are solvable.
YSV: Thank you WH for the summary of those three topics, and for grouping them. I think we can move on to other topics because the syntax right now is very unclear in terms of what we will do, we can move onto other topics which directly address the potential of this moving to stage one at this meeting. Next, we have JWK.
JWK: If people really want to run typescript directly, they can choose tools like Deno or TS-Node, and on the browser side, the browser can add an option in the devtools to enable transpile typescript syntax just in time. If they want to run their typescript code, not in the devtools to make a demo or something, they can have a browser flag in the canary version of Chrome or something. We don't have to care about that in the language.
RPR: Okay, I guess JWK you're suggesting there is an alternative way of dealing with the problem. That is basically adding a preprocessor everywhere that we run and use JavaScript. We could kind of encase it with a preprocessor that lets us achieve this goal. That sounds almost like an argument that this is starting to get so widespread/universal that it's one indicator that maybe this should be solved in the language.
JWK: Yeah, I mean, we don't even try that (add support in the dev tools) yet, if that solves the problem, we can stop there.
DRR: It's been discussed before, but then it is fairly nice to be able to just like not. You'll still need a build stuff when you go to production for even small sort of like project. It's the concern there. So maybe that's okay some people, but we just want to reduce the barrier to entry and make it lightweight.
RPR: I think this is a key thing here about the language, which is that if everywhere is implementing this preprocessor, then wouldn't you want the grammars to be unified? Wouldn't it be really important to keep them together with JavaScript? I think maybe JRL is in the queue and might have something to say about this.
JWK: But is typescripts really have a formal syntax?
RPR: But we're not talking specifically about TypeScript with this - this is a new proposal. Okay? We do have this.
JRL: If we think about a syntax space that both typescript and flow and whatever future syntax could take take advantage of, this allows the entire build ecosystem to move forward with just having types parsing and handling by default. Without having to enable in babel either the typescript or the flow plugins, without having to configure prettier to parse a particular syntax, without having to essentially choose one or the other because they're incompatible at times, and just be able to parse everything all of the time without any setup necessary. Having all the build tools be able to consume this union of type systems, makes it easier for developers at build time, not just at run time that the engine can just ignore the types. The build ecosystem here is massively improved, because you don't need extra configuration or incompatible configurations when consuming different projects.
TCN: Interjecting, and extending that a bit. I also think there's something to be said for having a foundation that, you know, when the next cool types tooling comes around and we all migrate to that, building upon that foundation and not having to constantly migrate types is a benefit that I think drives the ecosystem forward together rather than separate.
YSV: Okay, moving on to the next topic, which is related to this final statement JSC, please go ahead.
JSC: Yeah, I'm fine with Stage 1 for this since stage one is supposed to be just about problems. What I would like to be clear is what sort of evolution, You see what the current the ecosystem within the syntactic constraint, the standard syntactic constraints that this proposal would bring. what sort of innovation or variation between tooling that uses the same syntax quick could occur. Like what do you envision different type of inference algorithms? Do you envision non-type functionality? A lot of innovation does occur just syntactically, so I'd like to hear here or at least in the explainer later. See more about what sort of innovation could occur even with a constant syntax.
DRR: Sure. I’ll give you a really brief example. One is that within type positions, you need occasional expressivity to be able to talk about, you know, an array, and sometimes you'll have something like a read-only array, right? And so, we added a syntax, you have a modifier called read-only that goes in front of the array type, right? And so if you want to add that sort of syntactic, you know, change would you be able to do here is in braces or brackets, parenthesis or whatever, you'd be able to use that extra syntax and that would allow type systems to add that new construct or new modifier or whatever. Because, because often need expressivity to explain. Hey, I know what I'm doing, or hey, here's Actually happening to a type system. So that's, that's why we need room to kind of add more features. We can talk about it in more depth later on, if you're interested.
JSC: Yeah, I would definitely like to see this addressed in the explainer or other document.
DRR: Sure. And yeah, yeah, thank you.
YSV: Next, we have another topic by Shu.
SYG: Yes, so for this, I want to set that the topic. It's a bit clickbaity, my use of "catholicism" there. I mean kind of all-encompassing JS and in the JS ecosystem as a whole and what it includes. So for this I want to zoom out and not talk about the technical stuff and focus on something that DRR said about in the presentation about, 1. the enormous uptake of typescript and popularity of typescript in the ecosystem. And the comments said, the typescript is, you know, a superset of JavaScript and the ecosystem. The typescript community is thought of as a subset of the JavaScript ecosystem, and I think the popularity of TypeScript is a question that TC39 should reckon with. And part of what I see this proposal doing, aside from all the technical bits, is that there is this vast market opportunity, for basically forking JavaScript so that it could solve some particular problem better for some subset of developers. Typescript certainly hit the mother lode with tightly coupled tooling, usable type system tooling, the editor, all that stuff, and has enjoyed great market success because of it. And this proposal I see as a way to kind of say, well, we have reached a critical mass and it's time to maybe bring that back a little bit to re-merge it with TC39, as I think one of the slides said: "reinforcing TC39 as the venue of collaboration." And I think part of what we want to do here with whether agreeing to solve this problem or not, it is important to for us to discuss and to make a conscious decision. Because I think we if we say, we don't want to solve the problem of a tool that for good intentions, effectively forked JavaScript and did a bunch of things and is now super popular, and we don't want to take the work of doing something to bring that back into the fold. I think that's effectively saying, well, maybe we want to allow a bunch of forked JavaScript in the future and that also doesn't seem great. So, I'm cautiously optimistic that if we had that, the main effect, the main positive effect of this proposal in the very long term, is to kind of shore-up the health of JavaScript by owning up to saying that TypeScript is super popular and is a part of the JavaScript community. And let's do something to merge the two. If you know, it is, in fact, technically feasible, since that is up in the air. All right. I think that's the only thing I wanted to say.
PFC: [from queue] I find this point to be very perceptive.
YSV: Tierney has a short question. And then we will move to people expressing support or lack thereof before we wrap this up. We have about 10 minutes after please go ahead.
TCN: Yeah, there was I believe once I did, I mentioned “use types”. I'm curious if that's intended to be part of this proposal or if that's a, you know, forward-looking. This is something we could do to actually have to basically enforce checking, or would be a separate proposal.
DRR: That would be a separate one. If the committee found in an interesting avenue, but it's not really one we foresee. Let's say we were based you just calling out really that going down that route would be a breaking change. So it's a yeah, there's no proposal for "use types".
YSV: Okay, we have a series of support or lack thereof. Starting with LCA, please. go ahead.
LCA: Yeah, so I see that as the main point of this proposal is to simplify the Inner Loop or development Loop and this is something that with Deno we've seen many people really really value. transparent type stripping that we do. And essentially, this proposal would add that to the language. Right? And I think this is not just like a Time problem. We're like it, instead of taking. I don't know, a second for the typescript compiler to type strip something. I made it into a folder and then for your run, time to pick it up. I think it's also like a complexity problem with a for the project itself. If you have a small project, you don't want to have it build step. You don't want to have very large amounts of tooling. You don't want, think? Maybe you don't even want an output folder. Distributable. So you just want your source code and you want that source, code to run, but still get all the benefits from like the editor integration and And yeah, whatever else. The type comments provide. yeah, I'm very much in favor of looking into this further. and to, to quickly comment on the reply there. This is not yet. Not specifically TypeScript syntax, any type of syntax. Or any other syntax, that one would want to put into these comments.
MF: If this isn't typescript syntax, I don't know what build loop we're talking about here. When you say you're simplifying this inner loop, what are people writing in these comments if not TypeScript?
LCA: One could write flow comments in these attacks or flow types in these comments. One could write just arbitrary comics in this context if the Syntax for to allow that. I think the point is that people don't want to have to run the code through some sort of stripping step before actually executing it. Or at least not be able to see this stripping step because that's a pain point that adds complexity to the project.
??: And Daniel, I think it's Performance Management.
YSV: I think you communicated that well. Yeah, and I think just in the interest of time, I would like to move through the comments speaking in support of or lack thereof quickly. So next we have Ashley, please go ahead and please it concise.
ACE: Yep. just +1 to lots of the positive things have been said about tooling, but, you know, I have noticed on other proposals. As much as some delegates say that typescript shouldn't control, ecmascript decisions that we shouldn't take that into like a backwards compatibility thing. You know, personally have seen proposals steer away from syntax because typescript uses it. You're making it clearer what space like the tooling will consume, like flow, typescript hegel, and what proposals can then use for runtime semantics. I feel like that would really help a lot of conversations having that kind of much more like officially bounded as I understand how difficult finding that boundary is. I think there's a lot of value if we can find it.
YSV: Thank you. Ashley. Next, we have JWK.
JWK: As I explained before, I don't think it's a good idea to add this to the language.
RPR: Just specifically, which do you think is the strongest reason?
JWK: It cannot really reach the goal, even that make the bar higher.
RPR: So even if we expand what JavaScript can do, and encompass more use cases, you think it needs to go further to be worthwhile?
JWK: No, because you cannot be really expand too much. Otherwise, JavaScript becomes TypeScript.
YSV: Okay, next we have PHE.I
PHE: Plus one for Stage 1. typescript is remarkably popular with embedded developers worth committee. Time to consider it further.
YSV: And we have George again
GKZ: Just to make this really clear before we go for stage one, just on the record. I just want to ask simple. Yes. Or no question, which is, is there going forward with in this proposal is their commitment to neutrality and not getting special treatment to typescript? Yes, or no?
DRR: Yes, but I need to be very clear that everything here has to go through some sort of discussion. Right? And so, there is going to be some balance of, where are we seeing, you know, certain places where it doesn't make sense for certain things to happen in one place versus another. So we are entirely committed to neutrality. We’re entirely committed to like discussing this with you and working through the problems would be as well, but it's going to come down to what makes the most sense for the proposal to proceed as well. So, like just think we need to set expectations there.
GKZ: Yeah, thank you. Yeah, I just want to make that clear and for the record as we move forward. And again, I mean, just to be clear. Flow is not like some niche thing every day over 1 billion people in the world are running JavaScript. That was type-checked by Flow might concentrated in one spot versus spread out amongst a lot of smaller things, but if not, in some like Niche Niche thing here. Well, yeah, I appreciate that commitment. And glad to have that on the record. Thank you
YSV: Okay, we have two comments related to the discussion of superset or subsets. I am going to cut the discussion of this proposal there because we are out of time. There's three minutes and we still need to summarize. Okay, great folks Folks took their topics off hacks since we are on time. I'm going to I'm going to ask that. You take this topic up with a Champions outside of this call right now. Champions. We have a request from the chat that summarize, the problem statement that you are seeking to achieve with this proposal. This is outside of the syntax that you've proposed, but the actual concrete problem that you want to solve. Can you do that for us? And then we'll move to, if you want to ask for stage advancement.
RPR: So just going back to WH’s question. I guess he was asking the same thing for the motivation. So we can say here is: that the problem we're trying to solve is that there are folks out there who want to write type annotations in their code and not need to run any other build process before running it on a real engine. And this is something where today, we can see it in wild that that is a big psychological step and a big (I think) practical step that many people choose not to take, so we want to make sure that JavaScript is accessible and ergonomic for those folk to achieve that goal.
YSV: I think that we may not have a concrete problem statement there because we are talking about comments as types here. Maybe - can you tighten it a little bit?
RPR: In what sense?
YSV: What problem are we solving?
RPR: The problem space is that is the folks want to write type annotations on their JavaScript and not have a build step.
WH: They can do this today by having types in comments.
RPR: It's not ergonomic, and we see that in the wild that people only a few people are tipped over into using the full comment syntax. It's the Simplicity the developer experience. And yeah, the first class syntax is highly desired.
YSV: I will, I will also raise that my complaint was called out as that the problem stated by RPR is worth solving. It's been mentioned in the chat, “does TC39 care about long-term long-term unforking of a vastly popular JS “fork” is a pretty important problem for the ecosystem. There have been several +1s on that.
YSV: Do the Champions wish to ask for Stage 1 on the concrete problem statement. And also, the more General problem statement about paying attention to popular Forks, do the Champions want to request advancement for stage 1.
DRR: Can we have stage 1?
YSV: Do we have anyone explicitly blocking stage? One on this proposal, that is blocking because of the problem statement that they presented.
WH: I am uncomfortable with the problem statement they presented.
JWK: I am skeptical on this but am not going to block it hard.
DRR: Is there something that we can? Clarify in some way WH, Maybe any specific detail.
WH: The things that make me uncomfortable are that this appears to be very much tied to TypeScript, but only parts of TypeScript. I see putting parts of TypeScript to ECMAScript but only some parts as being actively harmful to the ecosystem because it will fork TypeScript. I see the argument for convenience of being able to just write TypeScript and run it in your browser. and I think that would be better solved by having an opt-in to TypeScript syntax. And that way, you could use all of TypeScript rather than just some parts of it with other parts not working or doing unexpected things.
DRR: I do hear your concerns. I think there are certain things that might be instructive. There one. is that, you know, when we support types in comments, write that JSDoc format that I showed the full expressivity of TypeScript is not there and yet, people do find it to be a useful tool. And they often understand why certain things won't work in those contexts. And we feel like we can bridge that gap, but so I believe that is something that, that it, you know, is not as big of a blocker, as one might think. If you look at what is being omitted much of it can still be achieved in supplementary declaration files, which are like header files you can use, you know, sufficient syntax that gets you by for many projects. So, I don't know if that sways your opinion. Anyway, if that if that's convincing, that's something that we can discuss at a further stage. Maybe that's when we would, you would discuss whether or not that, that's a blocker.
WH: Okay, what is included in the proposal, then? First of all, it doesn't work for syntactic reasons that I don't want to get into. It's also way too much syntax. If what we want is to allow people to have colon types, when we should have a few grammar productions, like colon followed by an identifier or colon followed by parentheses. The proposal is way too much, and too TypeScript-specific.
SYG: Can I interject here for a moment? I still feel like there's some confusion on the exact grammar being presented here. There's that grammar.md file, which is huge and was scary. And I see has been actually now removed to a link to something else that is still different. And then there's the very simpler suggestion of colon and then brackets and some identifiers. Can I get some clarification from the Champions on what the next step for, like the next concrete. grammar thing that you are investigating this
DRR: So I don't want to get into it into the tentative grammar here, to be honest, but I do want to ask whether or not Stage One is an acceptable venue to better discuss these nuances and concerns because if it is grammar or how much is satisfied of existing type systems by some proposal this, then I feel like that is actually a concern and the broader sort of problem statement is you know, is going to Encompass that discussion.
YSV: So, we are past time five minutes, and I think the core question is precisely the one that DRR just brought up, are the concerns that have been brought up in the course of this discussion for the last 90 minutes ones that block stage one? Or can they be iterated upon with in stage? Stage one being our designation for. We are allowing this problem to be explored within the context of Tc39. So if I could jump in, I did that.
CDA: We’re being asked to advance to stage one based on agreement on the problem statement. Can somebody succinctly state what that is clearly?
YSV: I did write it for you in the chat actually, if you can check it. It's in the delegates chat.
CDA: Oh okay.
JWK: We should try to add those transpilers in the devtools and node, as I said before, before we try to add the syntax directly into the language and to see if that works well. If that supports the community, we should stop there.
WH: I don't see a problem statement in the chat.
RPR: YSV put it in the chat, which is, it’s about providing an ergonomic way to declare types that can run in an engine, and whilst doing that, It's also un-forking the language and reinforcing TC39 as the venue to make grammar decisions and to resolve the boundary between where types are and where JS values are.
WH: The only way you can do them both is with an opt-in.
DRR: Maybe that's something we can discuss in stage 1? I mean, I do think that is something where we would be able to get more involved discussion within the committee on that. that. Yeah.
RPR: If this requires An opt-in for this mode then and that's on the table. So we can discuss them.
WH: I see defining a syntax for types without semantics to be actively harmful.
YSV: So folks, because we are 10 minutes over, should we schedule more time to discuss this later?
DRR: Maybe we can reconvene another day.
YSV: I thing that is going to be wise. Is everyone. All right with that outcome? For now, we will reconvene and discuss this later. I don't hear any opposition. So, thank you everyone, for the discussion. We are done for today, and we will be starting again tomorrow at the same time and I will speak with the chairs about finding time for short, extra time box for this discussion for this topic. Thanks everyone for the Champions. I recommend reviewing the chat. There are folks who would like more clarification on the problem statement and we are done.
- Continued on 2022-03-31