I don't get the example for #3. I understand using "unknown" instead of "any", but both examples look effectively the same in terms of type safety.
I also don't get the example for #4. Side effects are the inherit "blind spot" of TypeScript. If you're really worried about your API changing on you, it seems like you'd be better off modeling it in something like JSON schema. Unless maybe your API is trivial.
It’s easy enough to do this in userland. I wrote a tiny library called narrows which has worked great for me: https://www.npmjs.com/package/narrows
After I looked at it, I have a sour feeling in my mouth. Why there can't be a way (or a library) to do very easy type guards in TypeScript? Something as simple as the keyword `is` in C#
I’ll add that writing manual type guards is fairly infrequent, so in practice there’s not a lot to gain here.
*Modulo polyfilling newer ES features if you compile for a lower version of the spec.
That you can do something so sophisticated is a testament to TypeScript's type system.
However, if you were writing JavaScript, I think it's (unfortunately) uncommon to have this kind of proactive validation. So, for people writing TypeScript as "JavaScript + types" (which is a perfectly fine way to use it), they would just use a type assertion, which is just writing down the assumption that the JavaScript programmer makes when consuming but not validating external data.
https://2ality.com/2020/06/validating-data-typescript.html#p...
What type guards are good for is marrying the compile time checks with runtime safety. They allow TSC to infer that in a given code path, the type can be narrowed down to something more specific. This is nice because it lets a single function e.g. handle a few different types without littering your code with `as` or `!`.