Incorrect diagnostic: comparing objects with `==` doesn't account for implicit coercion

[rotu]

🔎 Search Terms

Rule 2839 does not seem to know about Javascript's loose equality semantics for objects. It falsely states that:

This condition will always return 'false' since JavaScript compares objects by reference, not value.

Below are some examples that trip this diagnostic even though they evaluate to true.

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about 5.20

⏯ Playground Link

https://www.typescriptlang.org/play?ts=5.2.0-beta#code/MYewdgziA2CmB00QHMAUByA2iARgK1mABcACAeX0KIF10SBeekgbwF8BKAWAChRIYESNACIAZiBDCGTZiSIgAykQBOASzDIAXCVTt6APjESpHHnyhxEKVEcnSWJAG4BDaAFdYZUdt0HbJrl5wC0Frf3tZTAUATwBbHBh4eQAFNVjVIlVHWGofPUNxO1Mg-kshVABGCJIouIToJJBU1XTM7NydfKqOIA

💻 Code

'[object Object]' == {}
"foo" == { toString: ()=>"foo" }
"foo" == { valueOf: ()=>"foo" }
"foo" == { [Symbol.toPrimitive]: ()=>"foo" }
1 == { [Symbol.toPrimitive]: ()=>1 }

🙁 Actual behavior

The expressions all evaluate to true, but TypeScript erroneously reports:

This condition will always return 'false' since JavaScript compares objects by reference, not value.

And:

This comparison appears to be unintentional because the types 'string' and '{ toString: () => string; }' have no overlap.

🙂 Expected behavior

These error messages should not be shown.

[fatcerberus]

More or less a duplicate of #53757

[rotu]

@fatcerberus Thanks for finding that!
The behavior here is pretty terrible. Either:

1. The user meant to use loose comparison semantics (== instead of ===) and the error message is obviously wrong
2. The user did not mean to use loose comparison semantics, in which case the error message should steer them toward using === instead

[RyanCavanaugh]

Clearly you can construct a degenerate program to make this error message wrong, but the other 99.999% of time this error is issued, it is in fact correct.

[rotu]

Clearly you can construct a degenerate program to make this error message wrong, but the other 99.999% of time this error is issued, it is in fact correct.

I agree that this usually indicates a bad comparison. It is counterproductive to treat it as if == had saner semantics.

Here's a related example where it impacts user experience in a real way:

const ar = ['a','b','c']
for (const i in ar){
  if (i == 0){
    console.log("skipping first item")
    continue
  }
  // do something
}

You get the message:

This comparison appears to be unintentional because the types 'string' and 'number' have no overlap.(2367)

Which is silly and confusing because when you run the code, it does skip the first item.

It would make sense to acknowledge the actual problem with something like:

This comparison performs implicit type coercion. If this is what you meant, it is recommended to use === and explicitly convert to a primitive value with String(x), Number(x), etc.

[typescript-bot]

This issue has been marked as "Working as Intended" and has seen no recent activity. It has been automatically closed for house-keeping purposes.