<story><title>TypeScript please give us reflection/runtime types</title><url>https://github.com/akutruff/typescript-needs-types</url></story><parent_chain><item><author>andix</author><text>There is a good reason for not doing this. Typescript would become some kind of runtime on top of JavaScript. A new language that compiles to JavaScript. Currently TS is only JavaScript with type annotations.&lt;p&gt;There are many languages that compile to JavaScript. Pick one of them and use it!&lt;p&gt;And I have the feeling, that people who want runtime typed Typescript would rather like to write Java&amp;#x2F;OOP style code instead of JavaScript. But JavaScript is a dynamically typed language, and that&amp;#x27;s also nice. Be happy with what you have!</text></item></parent_chain><comment><author>armchairhacker</author><text>Not necessarily.&lt;p&gt;Consider&lt;p&gt;&lt;pre&gt;&lt;code&gt;    const fooType = generateTypeInfo!&amp;lt;Foo&amp;gt;();
&lt;/code&gt;&lt;/pre&gt;
Where `generateTypeInfo!` is a macro that expands to a JS object encoding the “Foo” type (e.g. if `Foo` a record type, `fooType` will be a record with its encoded field types). It still compiles to readable JavaScript.&lt;p&gt;What this macro &lt;i&gt;does&lt;/i&gt; break is that TS = JavaScript with type annotations, and all you need to do to compile is remove those annotations (excluding enums, but they are all-but-deprecated and obsoleted by string unions) without even type-checking. Since now you also need to expand the `generateTypeInfo!`, which requires actually computing the structural type of `Foo` (and if you want any sort of nominal type metadata, that too).&lt;p&gt;And that’s still a problem because type-checking is slow, but removing the annotations is fast. If there’s a limited way to resolve types for these annotations which restricts the resolution scope, that would be a good candidate.&lt;p&gt;—-&lt;p&gt;There&amp;#x27;s also more issues with TypeScript having a separate runtime besides it not being JavaScript. TypeScript types are structural, so they currently &lt;i&gt;are&lt;/i&gt; available at runtime: to determine an object’s type, inspect its structure. Anything more and you quickly run into non-trivial cases being literally impossible: if you want erased nominal information like whether a string is part of a string union, TypeScript’s type system is Turing complete; and if you want the nominal type name, implicit structural conversions mean that once a value leaves its annotated cast or definition it’s effectively undefined.</text></comment>
<story><title>TypeScript please give us reflection/runtime types</title><url>https://github.com/akutruff/typescript-needs-types</url></story><parent_chain><item><author>andix</author><text>There is a good reason for not doing this. Typescript would become some kind of runtime on top of JavaScript. A new language that compiles to JavaScript. Currently TS is only JavaScript with type annotations.&lt;p&gt;There are many languages that compile to JavaScript. Pick one of them and use it!&lt;p&gt;And I have the feeling, that people who want runtime typed Typescript would rather like to write Java&amp;#x2F;OOP style code instead of JavaScript. But JavaScript is a dynamically typed language, and that&amp;#x27;s also nice. Be happy with what you have!</text></item></parent_chain><comment><author>a_wild_dandan</author><text>I&amp;#x27;m misunderstanding your reasoning here. TS is &lt;i&gt;already&lt;/i&gt; a new (superset) language which compiles to JS. Runtime types solve the problem of maintaining two duplicate, separate type systems -- one for compilation, one for validating data. I&amp;#x27;m not seeing how that&amp;#x27;s related to OOP. For instance, my preferred workaround lib for this problem, `io-ts`, leans hard on functional programming.</text></comment>