I know how it works. I'm talking about practical implications. In practice, say I have type User = { name: string, email: string } let loggedInUser:

I know how it works. I'm talking about practical implications. In practice, say I have type User = { name: string, email: string } let loggedInUser: User = { name: 'Bob', email: 'bob@examaple.com' } or even // Can't change the contents, only reassign the whole variable let loggedInUser: Readonly<User> = ... and only ever use that `loggedInUser` from TypeScript code (because my entire codebase is TypeScript), and I avoid the 3 scenarios mentioned above (buggy JS library type definitions, non-validated external data, casting/any/`!`). How would a `null` email ever get inside `loggedInUser`? It just won't happen. I know there are no run-time checks - I don't need any run-time checks. I don't need 100% theoretical guarantees. I can be reasonably certain that `loggedInUser.email` will always be a non-null non-undefined string. It's a good enough™ practical guarantee. A null-check on `loggedInUser.email` would be pure confusing noise (because anyone reading it would go "wait, this can be null? I thought it was non-null"). Do you have a practical explanation of how a `loggedInUser.email === null` situation might occur given the above assumptions? >Given any JS variable can be assigned both `undefined` and `null` Any JS variable can be assigned literally anything. I don't need to check that `loggedInUser.email` is not null, just like I don't need to check that `loggedInUser.email` is not a boolean or a number. Because how would that even happen? Not having to do those checks is half the point of having a static type system in the first place (the other half is being notified of type errors at compile/edit time). If you need to defensively check whether something so basic that is never supposed to happen has happened, then the code is already a giant unmaintainable mess.