Question

After reading this question Why do "int" and "sbyte" GetHashCode functions generate different values? I wanted to dig further and found following behavior:

sbyte i = 1;            
int j = 1;
object.Equals(i, j) //false (1)
object.Equals(j, i) //false (2) 
i.Equals(j) //false (3)
j.Equals(i) //true (4)
i == j //true (5)
j == i //true (6)
i.GetHashCode() == j.GetHashCode() //false (7)

1. Difference between (3) and (4) breaks the requirement that Equals should be symmetric.
2. Difference between (2) and (4) is not coherent with MSDN specification that says:
   

   If the two objects do not represent the same object reference and
   neither is null, it calls objA.Equals(objB) and returns the result.
   This means that if objA overrides the Object.Equals(Object) method,
   this override is called.

3. Difference between (3) and (5) means that operator == returns true, however objects are not equal in terms of Equals.
4. Difference between (4), (5), (6) and (7) means that two objects are equal in terms of operator == and Equals, however they have different hash codes.

I’m very interested if anyone can explain why such in my opinion inconsistent behaviour is observed in rather fundamental .NET types.

Answer 1

Your problem is that you missed the implicit conversion in i.Equals(j). It goes to the overload int.Equals(int). Here you’re comparing i and (int)j, which are the same thing. The same implicit conversion happens for ==.

The other comparisons work on an int and a sbyte, which by definition are different. j.Equals(i) goes to the overload int.Equals(object), because the argument isn’t implicitly convertible to sbyte.

Equals is symmetric for them, but your calling code isn’t. If you suppress the implicit conversion with i.Equals((object)j), it’ll return false, showing that Equals is indeed symmetric.