Comment by jy14898
11 days ago
> An API call, reading a file, calling less well-behaved libraries or making some system calls can all result in objects that pass compile-time checks but will cause a runtime exception or unexpected behavior.
Seems crazy to me to have this attitude, the whole point of typescript (and indeed many other languages with type checkers) is that we can leave out unecessary checks if proven by the compiler. The burden of compatibility is on the caller to ensure they supply correct values
I don't systematically pick one or the other location for these guards, but wouldn't it make more sense to have it in one place, the function itself, both for DRY and to ensure it being checked, rather than on every call site?
Such a requirement "oh yeah always guard your arguments for calls against this function for the "same" thing your compiler is doing anyway" shouldn't be implicit and duplicated everywhere if it's always meant to be fulfilled.
I think I take the attitude that you parse/validate data as soon as possible (ie when reading a file/coming from an API), so that the rest of the code can rely on typechecks alone.
That said, I come from a background where the language doesn't let you consider that the type of a value might be wrong (Haskell, for example), so perhaps I have more trust than typescript deserves.