Regression in inequality operator `!=` overload resolution

[xwu]

Description

Heterogeneous equality and comparison operators were added as part of SE-0104.

However, this led to an issue during comparisons with an integer literal where heterogeneous comparison with an Int is preferred over homogeneous comparison, as reported in SR-4984. This issue was addressed by @moiseev (in #13830) by adding overloads of these operators with same-type parameters to concrete integer types (which would be preferred).

There has been a regression in Swift 5.0 which leads to the problem resurfacing.

Reproduction

let x = Int32.min == 1 << 31
let y = Int32.min != 1 << 31
let z = !(Int32.min == 1 << 31)
print(x, y, z)

Expected behavior

In Swift 4.2, this produces the expected result: true false false.
As of Swift 5.0 and to this day, it produces the unexpected result: true true false.

Environment

Apple Swift version 5.9 (swiftlang-5.9.0.128.108 clang-1500.0.40.1)
Target: arm64-apple-darwin22.6.0

Additional information

https://forums.swift.org/t/nolocks-with-int32-inequality-check/68625

[stephentyrone]

Note that even with #70043, it is possible to reach the heterogeneous comparisons with literals in generic contexts constrained to the integer protocol hierarchy:

func compareGeneric(_ lhs: some FixedWidthInteger) -> Bool {
  lhs == 1 << 7 // rhs will be typed int with value 128 regardless of type of lhs
}

but this is somewhat less problematic because == and != will receive the same type in these cases. I think that this could be addressed by adding homogeneous == on BinaryInteger and marking the heterogeneous comparisons disfavored, but that's not a change I'm going to rush into. (https://godbolt.org/z/xP39KG5Eq)

[xwu]

Back in the day, before @_disfavoredOverload, I was not able to find a reasonably workable solution in the generic context; the experimental design for "designated types" for operators would have addressed it, but that was never brought to fruition. This would be a technically source-breaking enhancement rather than merely fixing a regression.

[stephentyrone]

Right, you can't "fix" this without @_disfavoredOverload (and the implications of adding it are hard to reason about, so I'm not eager to run into doing it).