Is it important to override Equals if I'm implementing IEquatable<T>?

Question

I know the importance of overriding GetHashCode when implementing custom equality checks - for which I have implemented IEquality<T> interface, and also the difference between generic and non-generic Equals as discussed here. Now is there a point to override Equals(object t)? Wouldn't everything come under generic Equals(T t)?

public override int GetHashCode() //required for hashsets and dictionaries
{
    return Id;
}

public bool Equals(T other) //IEquatable<T> here
{
    return Id == other.Id;
}

public override bool Equals(object obj) //required??
{
    return Equals(obj as T);
}

Answer 1

Unsealed types should not implement IEquatable<T>, since the only way to ensure (or even make it likely) that derived types will implement it correctly is to implement IEquatable<T>.Equals(T) so as to call Object.Equals(Object). Since whole purpose of IEquatable<T> is to avoid wasting CPU time converting things to Object before comparing them, an implementation which calls Object.Equals(Object) couldn't do anything faster than the default behavior that would be achieved if the interface wasn't implemented.

Sealed class types may achieve a slight performance advantage by implementing IEquatable<T>; the preferred style is to have Object.Equals(Object) try to cast the parameter to T; if the cast succeeds, use the IEquatable<T>.Equals implementation; otherwise return false. In no case should IEquatable.Equals(T) and Object.Equals(Object) yield different results when passed the same object instance.

Structure types may use the same pattern as sealed class types. The method of attempting the cast is a little different, since a failed cast can't return null, but the pattern should still be the same. If a struct implements a mutating interface (as is the case with e.g. List<T>.Enumerator, a struct that implements IEnumerator<T>), the proper behavior of equality comparisons is a bit murky.

Note, btw, that IComparable<T> and IEquatable<T> should be considered independent of each other. While it will often be the case that when X.CompareTo(Y) is zero, X.Equals(Y) will return true, some types may have a natural ordering where two things may be different without either ranking about the other. For example, one might have a NamedThing<T> type which combines a string and a T. Such a type would support a natural ordering on the name, but not necessarily on T. Two instances whose names match but whose T's differ should return 0 for CompareTo, but false for Equals. Because of this, overriding IComparable does not require overriding GetHashCode if Equals is not changed.

Answer 2

You certainly should override Equals(object t) - otherwise you may get incorrect results when that overload is used. You can't assume that the Equals(T other) is the overload that will be called.

If you don't override it, reference equality will be used, meaning that something like the following will return false:

myObject1.Id = 1;
myObject2.Id = 1;

myObject1.Equals((object)myObject2); // false!

Another possible problem is with inheriting classes - if you compare your type with an inheriting type, this can easily fail.

Answer 3

From msdn:

If you implement IEquatable, you should also override the base class implementations of Object.Equals(Object) and GetHashCode so that their behavior is consistent with that of the IEquatable.Equals method. If you do override Object.Equals(Object), your overridden implementation is also called in calls to the static Equals(System.Object, System.Object) method on your class. In addition, you should overload the op_Equality and op_Inequality operators. This ensures that all tests for equality return consistent results.

I could have done a better google search too. Here's a good article on msdn blogs by JaredPar on the subject.

In short, overriding Equals(object obj):

Needed for the static Equals(object obj1, object obj2) method on object class, or for Contains(object item) on ArrayList instance etc..

Accepting this since the link is more thorough on the subject. Thanks to Oded too..