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

[zpdDG4gta8XKpMCd]

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 
}

[RyanCavanaugh]

We intentionally allow this for the sake of defensive programming (i.e. defending against missing inputs from non-TS code). If there's enough demand we could add a flag or something.

[Spongman]

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

[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.

[wizarrc]

#17896 (comment)

As a quick fix for now there is a lint rule: https://palantir.github.io/tslint/rules/strict-type-predicates/

This seems to work good enough for me right now, but in the long run I would like to see this baked into the language.

[devoto13]

I would also like to have it implemented for the same reason as #14764: vulnerable refactoring. This proposal is a bit more broad, then #14764. Maybe they should be merged?

In the recent refactoring I've changed public key: string | null; to public key: string;. null was used to mark a special case and now it was decided to use particular string constant for that special case instead. Deep in the codebase there was a bunch of checks like:

if (myObject.key == null) {
  // perform some logic for the special case
}

This silently stopped working and took quite a bit of effort to debug. It was also surprising that this didn't fail type checking. Maybe do it as strictNullComparisons flag or something, so it is true by default under strict mode and then consumers willing to do defensive programming can opt out? This way people will get consistent (and expected) behaviour out of the box and those, who need to defend their code from JavaScript can do so as well 😄

[jfirebaugh]

I just encountered a bug similar to @devoto13. I was making some code work with --strictNullChecks that was trying to initialize a property declared as prop?: number with null. I figured that given the type declaration, the correct fix was to initialize with undefined instead. This caused a bug because other code did a strict-equality check foo.prop === null which was now always false. This feature would have flagged the comparison so that I would have known to change the type declaration to prop: number | null instead.

[pladaria]

We had bugs in our codebase due to this:

For example:

This is a bug:

if (typeof foo === undefined) { // this is impossible
}

it should be:

if (typeof foo === 'undefined') {
}

I know it is a dumb bug but shit happens and this is hard to notice, even with code reviews.

The typesystem shouldn't allow this