> This is exactly why simple, concise writing is essential, and their wall of text is...not it.
I only skimmed this but felt it was clear. They're asking for TypeScript, as part of the type erasure, to emit the type information it has discovered about the types in a side channel to the emitted JavaScript. Think of, say, PDB files as an analogy.
> They are really asking for a net new product which has very little to do with the TypeScript that exists today.
This is information TypeScript already has today but which it discards. It wouldn't take a "net new product".
You can use the TypeScript API to generate this information at whichever level of detail you want.
The level of detail TS has about types during the checking phase is much higher than you would want in practice for 99% of projects (e.g. 1 + 2 + 3 has 6 different types associated with it).
The level of detail TS has about types during the checking phase is potentially lower than you would want in practice for a lot of projects (which is critical since that makes the whole feature useless if that happens). For example, the list of properties of a particular generic instantiation is lazily computed, but it's possible your program never pulls on the list so it never exists in the first place, yet is something your type-based tool might want to know.
They're not asking for reflection on _all_ possible types (which would have the problem you mentioned), just ones explicitly requested at compile time via a function call.
I only skimmed this but felt it was clear. They're asking for TypeScript, as part of the type erasure, to emit the type information it has discovered about the types in a side channel to the emitted JavaScript. Think of, say, PDB files as an analogy.
> They are really asking for a net new product which has very little to do with the TypeScript that exists today.
This is information TypeScript already has today but which it discards. It wouldn't take a "net new product".