x != y marked as always true when it is not

[DominicKramer]

Search Terms:
!=, implicit conversion

Code

const x = 0;
const y = '0';

if (x != y) {
  console.log('In if block');
} else {
  console.log('In else block');
}

Expected behavior:
The code should compile successfully. Since != uses implicit conversion it is possible for 'x != y' to be false even if x is a number and y is a string. For example 0 != '0' is false).

Note that when the javascript file generated by tsc in the above code is run, the else block is hit as expected.

Actual behavior:
The code has the compilation error:

error TS2367: This condition will always return 'true' since the types 'number' and 'string' have no overlap.

5 if (x != y) {
      ~~~~~~

Playground Link:

http://www.typescriptlang.org/play/?ts=3.8.0-dev.20200128#code/FAYw9gdgzgLgBADzgXjgBgNykrOBPFOAcjSK2AEsAzOACiQEJU8BKOAb2DjnGjABsApgDp+YAOa0iASQhxqcAEZiQAayIssAXziD+UQRy48cAkWMky5eg0pXrNwLcCA

Related Issues:

No

[znrm]

This is intended as per the TS spec; == and === are both handled in the same way.

You can easily opt into the behavior you expect by casting either side of the comparison to any.

if (x as any != y) { }

[shicks]

That spec doesn't gel with the current behavior, at least for some of the later operators (&& and ||). For instance, && says that the return type is the same as the second argument, and || that it's the union - and then each gives a seemingly nonsensical table. But in actuality, TS does the right thing and unions the truthy or falsy projections of the left-hand type with the right-hand type.

To the original point, at the very least the error message is misleading.

[RyanCavanaugh]

This error message is correct the other 99.5% of the time and it'd be confusing to tack on a "... unless there's an implicit coercion which you shouldn't be doing anyway" clause to the message just to make it Technically Correct

[jcalz]

I feel like "it will always be true" or "it will always be false" is kind of beside the point, though. The real problem is "you shouldn't be comparing these things because the types aren't compatible". The implicit coercion is the problem, not the fact that one of the clauses is potentially unreachable. I can write if (3 !== 3) { } and there's no complaint.

That said this is probably a duplicate of #26592

[PixnBits]

This error message is correct the other 99.5% of the time and it'd be confusing to tack on a "... unless there's an implicit coercion..." clause to the message just to make it Technically Correct

FWIW trying out TypeScript in a new project I understood the existing message to mean that TypeScript didn't know how JavaScript evaluates.