If my parameter only accept "foo" or "bar" and that at runtime I send an invalid input, will I get a type runtime exception? Or will it silently allow the invalid input? If it's the former, that would be great news but then I wouldn't see the point in Io-ts, and where is the limit? Could they stop type erasure and allow generics reification?
> If my parameter only accept "foo" or "bar" and that at runtime I send an invalid input
calling a function with a general string argument when the parameter expects a string literal will have TS refuse to compile.
Most of the time you want to validate user strings/runtime generated strings. On most applications compile time strings are very few and not need validation. When you need validation of strings you generally need only runtime or both and then why duplicate the runtime validation with another compile time validation that take an alternative syntax? This seems 1) a niche feature And 2) a feature that users will misunderstand, the only dev I know which read about the feature think it works at runtime. Also I believe that existing template litteral do accept general strings I did a POC a few months ago so that's weird but maybe that TS can determine that a string is from runtime and then refuse it at compile time.
Some domains that will benefit: ORM mappers, CSS style generation, configuration strings, path munging, localization.
> Also I believe that existing template litteral do accept general strings I did a POC a few months ago
... yes, template literals accept general strings. Like I said,
> Template literals that contain non-string-literal parameters will still generalize to string.
the new feature kicks in when all the parameters supplied to the template literal are value types themselves, or an OR of value types (I don't know if something even more expressive is supported).
I hope you try to understand better what TS is offering before you make uneducated criticisms of it.
No, Typescript is very much just a static code analysis tool for JavaScript, there is no runtime at all, and there should not be one. It confuses a lot of people because they expect type guards at runtime, but it was never in the scope of the language to provide something like that.
If you are strict, don’t intentionally try to outsmart the type system, and use manual runtime type checking when necessary [0], TypeScript does a good practical job of ensuring that you won’t run into runtime type errors.
The reason TypeScript doesn’t automatically include runtime type information is (probably) because the overhead of runtime type checking would outweigh the benefit when static type checking does a good enough job.
Also, JavaScript being a dynamic language has allowed some pretty complex patterns of types to emerge from real-world use cases that would be exhausting to enforce all the time at runtime. Typically in TypeScript, runtime type checking is (manually) done when the type system cannot otherwise confidently guarantee the type of a value. For example, it’s common to have a runtime check for the shape of a JSON api response because you’re not necessarily in control of what that will actually return. There are community supported packages to help make this easier [1].
0: https://www.typescriptlang.org/docs/handbook/advanced-types....