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