3 ms·
Agree with you on the ergonomics of sealed classes in kotlin/scala/java. It works, but it's clunky. I quite like Typescript's approach. You do get exhaustive s
by yen223 3y ago
Agree with you on the ergonomics of sealed classes in kotlin/scala/java. It works, but it's clunky.
I quite like Typescript's approach. You do get exhaustive switch-case matching, so that's like 80% of what I want out of sum types. Typescript also lets you enforce that a type is one of the variants of a sum type, something which e.g. Haskell doesn't let you do. I assume this is a function of Typescript doing union types, but it's pretty convenient.
Definitely see ADTs becoming mainstream, because they are genuinely useful. Biggest gap to adoption imo is that no SQL database supports sum types or anything equivalent.
- DylanSp 3y agoTypescript's exhaustiveness checking can be kind of clunky sometimes, particularly if you have a switch statement that's just causing side effects and not returning a value. Last time I looked at it, I think you had to add a default case with some sort of dummy statement assigning a value to a variable with type `never`; while that's doable, the ergonomics are a bit annoying.
- yen223 3y agoI recall having to add that dummy 'never' branch in the past, but I haven't had to do that in newer projects on recent versions of Typescript.
- DylanSp 3y agoI just tried it in the online playground. I didn't get any sort of error with one of the cases unhandled. https://www.typescriptlang.org/play/?noFallthroughCasesInSwitch=true&q=115#code/C4TwDgpgBAKglgWzgOwOYFEBuFnCgXigG8pkBDBCALigCIBnYMgJ2FoG4oBXeiZgZSasIAExoAjAPaSANhDLIoAXygAfYqQrU6AYxmTeIjlBFdmZYHEnIayLgnF9l7AFBud1xlAAWCkXKwcPEIACghsXBp4JDRA3ABKAgA+YhcoKHoAdzhgHW8oMIjgADpySkSiNPSoHTJeOkYWNioq6prPPBQcuAtRACEQAFVeZgIocKDinj5BJtFXNvSPZHpZCGL9VBCuy16RAeG+eIXF8WZ5AGtXVqgAeluauuhaPQNRWha2++rlr0tKehgBRjCa4YqmcyWawndLfdJnS4nJQuJSuIA https://www.typescriptlang.org/play/?noFallthroughCasesInSwi...
- yen223 3y agoHmm. I think this is because in that situation, all cases (including the unhandled one) are "correctly" returning undefined. I can see that if I made the branch return a string, Typescript will correctly show the "Not all code paths return a value" error
- DylanSp 3y agoYep, or if you declare an explicit return type for the function, TS correctly gives a "Function lacks ending return statement and return type does not include 'undefined'." error. But if you have a function that's purely side-effecting, I think you still have to do something manual.