Suppose I define two tuples:
Tuple tuple1 = new Tuple(1.0f, 2.0f, 3.0f, 4.0f);
Tuple
==
is comparing object references. The Tuple
class does not overload the ==
operator, so you need to use .Equals
.
==
for Tuple will only see the references and hence you will see that it is false.
PS: Recommended way is to do something like:
var tuple1 = Tuple.Create(1.0f, 2.0f, 3.0f, 4.0f)
For Tuple, the == is comparing the object references because it does not overload the ==
operator. Since the objects are equivalent, but not the same specific instance, Equals()
returns true
and ==
returns false
.
Many types do not overload ==
, some prefer to keep a distinction between Equals()
for equivalence and ==
for reference equality.
In addition, relying on ==
for equivalence can lead to some weirdness:
public bool AreSame<T>(T first, T second) where T : class
{
return first == second;
}
The code above will always check for reference equality because an unconstrained generic is considered an object
at compile time, thus if the method isn't virtual, you will get object's version (even if the type, such as string
overloads ==
).
Thus this usage of the above code:
var x = "Hello";
var y = "H";
// doing concat to avoid string interring
AreSame(x, y+"ello");
Yes, the strings are equivalent, yes T
is string
, but the ==
is bound to object's ==
since the generic is unconstrained, thus this will return false
even though the same code with explicit string
parameters would return true
.