4 ms·

That proposal is not fully compatible with Typescript: https://github.com/tc39/proposal-type-annotations?tab=readme-ov-file#how-does-this-proposal-relate-to-typ

That proposal is not fully compatible with Typescript: https://github.com/tc39/proposal-type-annotations?tab=readme-ov-file#how-does-this-proposal-relate-to-typescript https://github.com/tc39/proposal-type-annotations?tab=readme...

whstl 3y ago
Hmmm good catch. But on the other hand, it would be already fantastic to have at least a subset of TypeScript...
WorldMaker 3y ago
It is more compatible than not and there are workarounds for most of the things that wouldn't work, many of which you shouldn't be using in Typescript today, have known workarounds (enums), and/or you probably have lint rules already warning against using (namespaces). (There are more details elsewhere in that proposal document outside of the direct linked FAQ question.)
- whstl 3y ago
  Great point. It is 100% possible to survive without enums and namespaces. And in fact: I bet the Typescript team itself would deprecate them (or at least add extra checks to TS to avoid them) if the TC39 proposal above passed.
  - WorldMaker 3y ago
    Yeah, if this type annotations proposal gets to higher stages I expect the associated ES target to get far more strict warnings/errors on those features. Though I'd suggest that the Typescript team also doesn't seem to be waiting on that to try to deprecate them, either. They've made it somewhat clear that the only reason enums and namespaces survive is a commitment to deep backward compatibility (both go all the way back to 1.0) and are neither features that they would add today (without waiting on TC-39 proposals for those features in JS first). As an interesting side note: up until very recent versions the Typescript code base itself was one the biggest users of both enums and namespaces. (They managed to finally do a lot of namespace removal in the very recent ESM rewrite. I haven't checked where they are at in enum removal.) It is always fascinating to me how important backward compatibility can be when you bootstrap your compiler in its own language.

whstl 3y ago

Hmmm good catch. But on the other hand, it would be already fantastic to have at least a subset of TypeScript...

WorldMaker 3y ago

It is more compatible than not and there are workarounds for most of the things that wouldn't work, many of which you shouldn't be using in Typescript today, have known workarounds (enums), and/or you probably have lint rules already warning against using (namespaces). (There are more details elsewhere in that proposal document outside of the direct linked FAQ question.)

whstl 3y ago
Great point. It is 100% possible to survive without enums and namespaces. And in fact: I bet the Typescript team itself would deprecate them (or at least add extra checks to TS to avoid them) if the TC39 proposal above passed.
- WorldMaker 3y ago
  Yeah, if this type annotations proposal gets to higher stages I expect the associated ES target to get far more strict warnings/errors on those features. Though I'd suggest that the Typescript team also doesn't seem to be waiting on that to try to deprecate them, either. They've made it somewhat clear that the only reason enums and namespaces survive is a commitment to deep backward compatibility (both go all the way back to 1.0) and are neither features that they would add today (without waiting on TC-39 proposals for those features in JS first). As an interesting side note: up until very recent versions the Typescript code base itself was one the biggest users of both enums and namespaces. (They managed to finally do a lot of namespace removal in the very recent ESM rewrite. I haven't checked where they are at in enum removal.) It is always fascinating to me how important backward compatibility can be when you bootstrap your compiler in its own language.