disallow comparing to null and undefined unless they are valid cases in strict null mode

the rationale is the same as for --noUnusedLocals which in this case would be --noUselessNullChecks (i am not proposing a new flag, the existing --strictNullChecks flag should be used, this is for illustration only)

declare const value: number;
if (value !== null) { // <-- somehow valid, expected to be invalid, since number doesn't have null as a possible value
}
if (value !== '') { // <-- invalid as expected 
}

[c-vetter]

The rationale behind the current behavior is understandable. However, in my view it lends itself to sloppy typing. My strategy is to guard the boundaries where data comes in from unsafe (=non-TS) sources. And there, null and undefined need to be accounted for, but that is really no special case as far as typing is concerned. Rather, null and undefined are just necessarily possible value types. Based on that, strict typing makes a lot of sense.

Until today, I fully expected the behavior this issue calls for to be present when strict is active. Then I came across a case similar to the OP sample and wondered why there was no error message. I even checked the tsconfig to see if somebody had disabled strict or strictNullChecks.

Please add this behavior, possibly behind a new setting 🙂

@DanielRosenwasser

Internal implementation detail: right now we use the comparability relationship for type assertions (casting) - if we did this, we’d need to have a separate type relationship (or ad-hoc check) for allowing you to cast undefined/null to any other type. Is this still a blocker? If yes: How is this casting required? Isn’t the problem an unintended non-distinction, which would be functionally equivalent to casting?

@RyanCavanaugh This issue is marked Awaiting More Feedback. Can you say roughly what this issue would need to get some traction, how far off it is?

[Spongman]

i would suggest to make type safety the default, and have interop require explicit casting.