have been thinking about this some: I think it would make more sense as a build step.

e.g., you could, I think, write a babel plugin that transformed type(x) into a representation of the type of the expression x at build time.

that is probably better than building it in to the language, in a couple ways: 1) it lets you get a rich representation, instead of just a string, and do name resolution etc, 2) it means there is no risk to stripping types in prod, which is important lest we bloat every shipped file forever

have been thinking about this some: I think it would make more sense as a build step.

I worked on a project 2 years ago where I wanted reflection to power validation that proved at runtime that an object had the shape that TS claimed it did at development time. FWIW, I came to the same conclusion that bakkot did, that the most natural way to do what I wanted was via babel (or perhaps a plugin to the TS compiler itself).

Specifically, the babel part I wanted would turn TS types into plain schema-describing objects that could be accessed at runtime. Building these objects manually at development time was tedious, non-DRY, and error-prone. I ended up using runtypes which solves the DRY problem via uses ingenious hacks that build TS types based on validation code, but I really wanted to go in the other direction: start with TS code and get easy runtime-visible, validation-ready schema objects from it. Here's an overview of various ways people have tried to solve this problem: https://learning-notes.mistermicheels.com/javascript/typescript/runtime-type-checking/

What makes validation an interesting case is that type validation is necessary but not sufficient. For example, for type Foo = { someInt: number; } you want to validate that the someInt property is a Number, but you might also want to validate that it's an integer. Other languages (I'm thinking of C#) enable this case via static typing + decorators + validation libraries so you can colocate validation requirements with your type declarations.

The problem with putting type syntax & reflection into the JS language is that you'd end up with a similar kind of bifurcated solution where reflecting on the newest TS (and Flow and...) versions would require a polyfill or would require TS/Flow/etc to stop innovating with the types that were available. At that point, you've got a build step anyways so it's not clear that enough value is being added in exchange for making the language much more complicated, and for the inevitable language bugs that would be challenging to fix without breaking the web.