3 ms·
The GPs request is a very fair one. Typeguards are 10% of starting the solution. What everyone wants: Autogenerated type guards by class. What everyone gets:
by yazaddaruvala 4y ago
The GPs request is a very fair one. Typeguards are 10% of starting the solution.
What everyone wants: Autogenerated type guards by class.
What everyone gets: “Remains out of scope.” and need to use other libraries. The compiler can do this significantly better (more ergonomic, less time, etc) than 3rd party libs. TS devs really should reconsider this feature.
https://github.com/microsoft/TypeScript/issues/15265 https://github.com/microsoft/TypeScript/issues/15265
- eyelidlessness 4y ago> What everyone wants: Autogenerated type guards by class. I’m quite sure people are asking for that, but I’m quite sure they’d regret wanting it if they got it. To the extent it’s desirable, it’s a thing that should be in TC39, not in TypeScript. The wailing and gnashing of teeth over when or whether or how type coercions happen is already mythical for the underlying language. Adding it to a compiler that’s increasingly not used to compile but only to type check is gonna add ten years of gripes about JS tooling nonsense to every single discussion. They have considered this feature. Type guards are the solution and they’re a really good solution given the circumstances.
- gajus 4y agoThere are some very legitimate use cases for runtime validation, namely when dealing with external inputs/databases, e.g. https://github.com/gajus/slonik#user-content-runtime-validation https://github.com/gajus/slonik#user-content-runtime-validat... Flow had [flow-runtime](https://github.com/gajus/flow-runtime https://github.com/gajus/flow-runtime), which was nice. There were/are a few half-baked solutions in TS ecosystem, but nothing as mature as flow-runtime was. However, I wish that TS supported this natively.