TypeScript please give us reflection/runtime types

Emitting types would run counter to several of TypeScript's Design Goals [0]. In particular, it would violate:

> 3. Impose no runtime overhead on emitted programs.

> 9. Use a consistent, fully erasable, structural type system.

It's also explicitly called out as a non-goal in that doc:

> 5. Add or rely on run-time type information in programs, or emit different code based on the results of the type system. Instead, encourage programming patterns that do not require run-time metadata.

> 6. Provide additional runtime functionality or libraries. Instead, use TypeScript to describe existing libraries.

[0] https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...

I had to read their problem statement like 4 times to understand what they are asking for. This is exactly why simple, concise writing is essential, and their wall of text is...not it.

> I love you. You do amazing work. You are gods among mortals. You have brought JavaScript from the darkness, and given it the warm light of strong typing. Look upon us, the cowering meek masses, and understand that we live in the muck and mire of a world where we are doomed to endlessly crawl on our bellies through the alleys of Github seeking the one true npm. We will forever wonder in the dark, until we have a type reflection model.

What even are they getting at?

As for their actual ask (runtime type safety), it is probably not going to happen because the TypeScript project has drawn the line at not being an alternate or additive runtime for JavaScript. Their job is simply to compile down to JS code and exit the picture. Whatever happens after that (in V8 or elsewhere) is your own business.

> TypeScript Needs to Emit Runtime Type Information

This is not possible at all because TypeScript is a compiler. They are really asking for a net new product which has very little to do with the TypeScript that exists today.

Small ot, if you like io-ts, @effect/schema is the spiritual successor from the same ecosystem.

The fp-ts, io-ts author Giulio Canti has decided that the best way to proceed was to merge the two communities of fp-ts and effect, even though it's his work that is mostly known with effect being much more niche.

It's essentially io-ts squared in its powers. The amount of things you get from schemas are endless, not just decoders and encoders but also apis, lenses, constructors, and many other things.

It's obviously heavily fp-leaning, albeit I would say effect systems such as effect, based on Scala's ZIO, are much more approachable than haskell/purescript-like languages.

This shouldn't happen... unless someone finds a way to do this without a runtime overhead, which naturally seems impossible.

If this is done, TS will become something entirely different as it currently doesn't have a runtime: it's a huge-and-smart linter.

But that's all about it. No matter how huge, it's a linter.

Reflection would imply something beyond that. Even though I absolutely love reflection, I believe it should not be integrated into TS.

Thanks for this. I thought I was screaming into a void. I started with typescript in 2018 and after two years started to believe this is just not really a solution because what it is. I came from Haskell/c#/f#, and TS, while it has a very powerful type system, just doesn’t give you much of the advantages the above languages give you outside (some of) dev. Even when it does, it is really limited in practice (aka when dealing with the real world) vs, let’s say, c#. You can defend from that somewhat, however, you have to always keep the extremely (and that’s intended, but not what it could be) leaky abstractions in mind to not run into bugs that shouldn’t be possible in something that claims static typing (if you don’t know that it drops to js without checks after compile).