3 ms·

Don't underestimate Typescript. Sure, it's somewhat restricted by the "superset of JS" property, but you still get stuff like ADTs with exhaustiveness checking

Don't underestimate Typescript. Sure, it's somewhat restricted by the "superset of JS" property, but you still get stuff like ADTs with exhaustiveness checking.

dmitriid 9y ago
TS doesn’t have exhaustiveness checking
- dahauns 9y ago
  I know TS discriminated unions may not be the most elegant construct in the world, but in what way is the check via the never type (as a return or assertion parameter after the switch) not an exhaustiveness check?
  - dmitriid 9y ago
    “exhaustiveness checking”: automatically making sure that we’ve covered all of the possible cases anywhere that we interact with a piece of data [1] Typescript doesn’t do that. There’s a way to manually force exhaustive checking with discriminating unions: https://github.com/basarat/typescript-book/blob/master/docs/types/discriminated-unions.md https://github.com/basarat/typescript-book/blob/master/docs/... However, it’s a manual workaround. [1] Quoted from http://www.adamsolove.com/js/flow/type/2016/04/15/flow-exhaustiveness.html http://www.adamsolove.com/js/flow/type/2016/04/15/flow-exhau...
    - dahauns 9y ago
      Hm? Typescript actually uses the same mechanism for exhaustiveness checking as flow (like your link describes).
      - dmitriid 9y ago
        It does. And, like in the article, Typescript is “saved by a hack”. Compare that to Elm, where it will automatically fail compilation if you don’t include all required types in a switch statement. Without any hacks or manual intervention.
        dahauns 9y ago
        Oh, I know. Elm is far more elegant in that regard. But just because I have to "switch on" exhaustiveness checks doesn't mean they don't exist.
        dmitriid 9y ago
        Thing is, it only works in if and switch statements, you have to be aware of it (I don’t think you can deduce it from docs), and you have to manually trigger it. It’s ”poor man’s exhaustiveness” and TS will hopefully get better at this

Don't underestimate Typescript. Sure, it's somewhat restricted by the "superset of JS" property, but you still get stuff like ADTs with exhaustiveness checking.

dmitriid 9y ago

TS doesn’t have exhaustiveness checking

dahauns 9y ago
I know TS discriminated unions may not be the most elegant construct in the world, but in what way is the check via the never type (as a return or assertion parameter after the switch) not an exhaustiveness check?
- dmitriid 9y ago
  “exhaustiveness checking”: automatically making sure that we’ve covered all of the possible cases anywhere that we interact with a piece of data [1] Typescript doesn’t do that. There’s a way to manually force exhaustive checking with discriminating unions: https://github.com/basarat/typescript-book/blob/master/docs/types/discriminated-unions.md https://github.com/basarat/typescript-book/blob/master/docs/... However, it’s a manual workaround. [1] Quoted from http://www.adamsolove.com/js/flow/type/2016/04/15/flow-exhaustiveness.html http://www.adamsolove.com/js/flow/type/2016/04/15/flow-exhau...
  - dahauns 9y ago
    Hm? Typescript actually uses the same mechanism for exhaustiveness checking as flow (like your link describes).
    - dmitriid 9y ago
      It does. And, like in the article, Typescript is “saved by a hack”. Compare that to Elm, where it will automatically fail compilation if you don’t include all required types in a switch statement. Without any hacks or manual intervention.
      - dahauns 9y ago
        Oh, I know. Elm is far more elegant in that regard. But just because I have to "switch on" exhaustiveness checks doesn't mean they don't exist.
        dmitriid 9y ago
        Thing is, it only works in if and switch statements, you have to be aware of it (I don’t think you can deduce it from docs), and you have to manually trigger it. It’s ”poor man’s exhaustiveness” and TS will hopefully get better at this