What is "TC39: Type Annotations" aka the Types as Comments proposal
AI Generated Video Summary
1. Introduction to TC59 Type Annotations Proposal
Now, my name is Otto the Rocks. I used to work on the TypeScript team for about two and a half years. During that time I worked on website and documentation and a little bit of compiler features here and there. And one of my favorite things when I left was I had this great, like, YouTube video that describes the entire compiler process that's really, really useful if you're, you know, into understanding the tools that you use on an everyday basis.
5. TypeScript Constraints and Proposal Progress
The proposal aims to constrain TypeScript within the scope of this proposal, separating type features from runtime features. TypeScript wants to avoid supporting certain expression-level features that affect the runtime, such as enums and namespaces. The proposal has progressed from stage zero to stage one after addressing questions about interaction with the runtime and avoiding token soup in type specifications.
The next one is that like they want to separate out type features versus runtime features in order to really specify that, you know, a type the type extensions can't really edit the code that's running. And, like, within the context of TypeScript, there are features that the TypeScript team sort of regret but still support forever. And it just happens to be that when you look at the Venn diagram of these two things, they actually are the exact same things. You know, the features that TypeScript doesn't want to support necessarily are all features that are expression level features.
So, this neat little meme that I made at some point, which is like a way of saying, like, at some point, you know, TypeScript decided that, like, enums and namespaces and these features that like affect the runtime, they're not really the types of things that TypeScript wants to be involved in and that's like a responsibility for 2.6.39. And this types of comments style system really helps enforce the, like, the line between those two responsibilities.
So, where are we now? We're a bit further down the line. You know, it was March 2022 when this proposal first came out. You know, the proposal said, hey, we're really trying to find a way to, like, do this types of comments conceptual thing. And they sort of got to a stage zero, which effectively means, hey, this might, this is a thing. No one's gonna rip it apart. It's actually gonna be implemented as this. But it got to a point where it was, when talking with the rest of the TC39 teams, people concluded there's a few good questions to look at to start thinking for stage one, and they came back a year later and started, you know, answering some of the, answering some of those problems.
This the next one is trying to avoid this problem of token soup. The rough gist is that, like, it's hard right now to be able to specify actually what can live in a type and what cannot. The rough heuristic right now is if it's an open brace, there needs to be a closed brace. And you can look from left to right and count your braces this way and count your closes this way. And once they're finished, then you could be finished with the type if you see say an equal sign.
6. Research, Outreach, and Community Involvement
There needs to be research done to identify known and unknown problems in this space. The proposal is in stage one, and efforts are being made to quantify the effects of supporting this comment style. Community outreach and defining an unambiguous area of code are important goals. Get involved by following the GitHub repo, exploring alternatives, and participating in community surveys.
So, we're getting there. Right now, the folks that were working on the proposal are sort of working on trying to figure out how they can quantify the effects of changing to support this type of comment style. Ignoring can work. Browsers would be okay with very small performance hit in order to support the scope of this idea. But they might not be okay with trying to do that if it comes with too much performance trade-offs because the only way in which we can actually declare this is the type space is that it requires doing some parsing, going back and reparsing it again, now that we know they're in a different context, and things like that. It's kind of complicated compiler implementation stuff and if you really want to figure out those details, go watch my talk, How the Compiler Compiles, and you can see how a tokenizer generally works.
So, how can you get involved? Well, first of all, maybe follow the GitHub repo. We get lots of, we get relatively few issues over time. A lot of that activity happened in the first six months, and now a lot of it is just sort of people that are trying to explore alternatives to this sort of comment style type system that they're kind of very interested in creative, so they're always worth a look, but it would be nice to have a few folks in there that are like, hey, yeah, like a bunch of these are solved answers, and there's a lot of very, a lot of people that have already got code that looks a lot like this that might be, might be good to have a few more folks saying that sort of thing in there, and the other one would be participate in community surveys. Like a lot of the times, you know, type sanitations is the number one most requested feature and that's, you know, good for this proposal, because it provides backing for saying, you know, people want this, and also, you know, there's going to be surveys from the folks that actually write these proposals about trying to figure out, like, what sort of trade ups are acceptable. If you ever see any of those, I think most of those folks are mastered on and ideally, so should everybody else, so check those out, too. And I think that's enough.