This proposal is probably dead?

Vasile-Peste commented 1 year ago

The proposal has not been updated since the march 2022 Meeting of TC39, so I have consulted the meeting notes which made me realise this proposal probably isn't going anywhere, giving that I see no effort in updating this repository I assume this proposal is probably dead.

Here are the key points of the meeting:

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?

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.

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).

GKZ (Flow Team): 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

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.

Which in short means:

Unclear Goal: There is a lack of clarity regarding the goal of the proposal. Some participants question whether the aim is to add TypeScript to the language or to introduce types as comments in general. Without a clear understanding of the problem being addressed, it becomes difficult to evaluate the proposed solution. Syntax Complexity and Compatibility: The proposed syntax is seen as overly complex and closely tied to TypeScript. Participants worry that introducing such a significant amount of new syntax could lead to confusion and forking of the TypeScript language. They argue that instead of creating hybrid solutions, it would be simpler to have a flag or option that enables full TypeScript syntax for those who want to use it. Potential Issues with Existing TypeScript Codebases: Concerns are raised about the impact on existing TypeScript codebases if this proposal is implemented. If TypeScript introduces new syntax that falls outside the scope of this proposal, it could lead to code failures or the need for compilation. Participants worry that this could hinder the ability to import files or lead to runtime errors.
Anti-Competitive Behavior: Some participants express concerns that giving special treatment to TypeScript and standardizing it as part of JavaScript could be viewed as anti-competitive. They argue that JavaScript should remain a language open to multiple type-checkers and not favor any particular type-checking solution. They highlight quotes from the proposal discussion that emphasize the aim of keeping all types of code as JavaScript programs, rather than promoting one specific type-checker over others. The fear is that providing exclusive support to TypeScript could limit innovation and hinder the development of alternative type-checking solutions, creating a less competitive environment in the JavaScript ecosystem.
Syntax Complexity and Compatibility: The proposed syntax is seen as overly complex and closely tied to TypeScript. Participants worry that introducing such a significant amount of new syntax could lead to confusion and forking of the TypeScript language. They argue that instead of creating hybrid solutions, it would be simpler to have a flag or option that enables full TypeScript syntax for those who want to use it.
Potential Issues with Existing TypeScript Codebases: Concerns are raised about the impact on existing TypeScript codebases if this proposal is implemented. If TypeScript introduces new syntax that falls outside the scope of this proposal, it could lead to code failures or the need for compilation. Participants worry that this could hinder the ability to import files or lead to runtime errors.

At this point, it's possible to have any insight from the authors of the proposal?

romulocintra commented 1 year ago

Hi, @Vasile-Peste proposal is still alive and making progress. In fact, it was presented during at TC39 last March. The champions behind the proposal are actively working on its development.

The champions are considering initiating a recurrent community meeting to ensure better alignment and gather valuable feedback. This would allow stakeholders and community members to share their thoughts, suggestions, and expectations regarding the proposal.

Vasile-Peste commented 1 year ago

Hi, @Vasile-Peste proposal is still alive and making progress. In fact, it was presented during our latest meeting at TC39. The champions behind the proposal are actively working on its development.

The champions are considering initiating a recurrent community meeting to ensure better alignment and gather valuable feedback. This would allow stakeholders and community members to share their thoughts, suggestions, and expectations regarding the proposal.

This is good news! The community meeting is a great idea as I see divided (community) feedback about this proposal, I strongly hope it's going to be pursued

ctcpip commented 1 year ago

a proposal is active so long as it is not withdrawn or rejected

as @romulocintra mentioned, it was discussed in plenary in March. see agenda and notes

eldoy commented 2 months ago

Why do we need this when we have JSDoc? I'd rather have a more compact JSDoc syntax and not litter the code with tons of new syntax. The JS engine will probably be slower too having to parse all these "comments". For what? Developer OCD?

markcellus commented 2 months ago

Exactly. The proposal's first sentence reads:

This proposal aims to enable developers to add type annotations to their JavaScript code, allowing those annotations to be checked by a type checker that is external to JavaScript.

You can already do this today by just using JSDoc to annotate your project and use TypeScript to type-check it.

tc39 / proposal-type-annotations

This proposal is probably dead? #178