So much of the TS type system is just there to capture all the weird things you can do in JS. If you just wanted a new strongly typed dynamic language, I don't think TS is what you'd come up with. It is designed for a very large, but unique, niche domain, and that domain already has some incredibly optimized runtimes.
I wouldn't come up with a new language. I would use TS and use the types to optimize runtime decisions like using numbers to index arrays, without having to carry extra info about the number, and so on. I would change nothing except the runtime. Are you somehow arguing that's bad?
TS complains if it sees you trying to index a T[] with a non-integer. But there's nothing in the JS language that represents that T[] type annotation. So there's no way for the runtime to do that check. If you want to make that work, you'll have to invent a bunch of runtime type machinery and define it. The resulting combination of a subset of JS, TS, and whatever you had to invent to glue it together at runtime will be neither JS nor TS, it will be a new language (with, certainly, a family history).
Also, every high-performance JS runtime already knows that you're only indexing that object with integers and already optimizes it without you telling it to.
Comments
Yeah but it could be, as the runtime could take advantage of the type defs.
So much of the TS type system is just there to capture all the weird things you can do in JS. If you just wanted a new strongly typed dynamic language, I don't think TS is what you'd come up with. It is designed for a very large, but unique, niche domain, and that domain already has some incredibly optimized runtimes.
I wouldn't come up with a new language. I would use TS and use the types to optimize runtime decisions like using numbers to index arrays, without having to carry extra info about the number, and so on. I would change nothing except the runtime. Are you somehow arguing that's bad?
TS complains if it sees you trying to index a T[] with a non-integer. But there's nothing in the JS language that represents that T[] type annotation. So there's no way for the runtime to do that check. If you want to make that work, you'll have to invent a bunch of runtime type machinery and define it. The resulting combination of a subset of JS, TS, and whatever you had to invent to glue it together at runtime will be neither JS nor TS, it will be a new language (with, certainly, a family history).
Also, every high-performance JS runtime already knows that you're only indexing that object with integers and already optimizes it without you telling it to.