Why does EqualityComparer<T>.Default (And thus Array.IndexOf, and thus List.IndexOf) have null special treatment?

[quixoticaxis]

sealed class ReallyComparable : IEquatable<ReallyComparable?> // treats `null` as equal to anything
{
    public static bool operator ==(ReallyComparable? one, ReallyComparable? other)
    {
        if (one is null)
        {
            return true;
        }
        else
        {
            return one.Equals(other);
        }
    }

    public static bool operator !=(ReallyComparable? one, ReallyComparable? other)
        => !(one == other);

    public bool Equals(ReallyComparable? other)
        => other is null || ReferenceEquals(this, other);

    public override bool Equals(object? obj)
    {
        if (obj is ReallyComparable other)
        {
            return Equals(other);
        }
        else if (obj is null)
        {
            return true;
        }
        else
        {
            return false;
        }
    }

    public override int GetHashCode() => 1;
}

var array = Enumerable.Range(0, 5).Select(_ => (ReallyComparable?)new ReallyComparable()).ToArray();
var list = array.ToList();
WriteLine(Array.IndexOf(array, null)); // -1
WriteLine(list.IndexOf(null)); // -1
WriteLine(new ReallyComparable().Equals(null)); // True
WriteLine(new ReallyComparable() == null); // True
WriteLine(EqualityComparer<ReallyComparable?>.Default.Equals(new ReallyComparable(), null)); // False

AFAIU, the comparer should respect IEquatable<T>. And the code here suggests is should, unless I miss something.

The interesting part is that neither the ops nor methods are even called when trying to find null.

[Dotoryman]

EqualityComparer<T>.Default does use IEquatable<T>, but only after it has established the framework's null semantics.

The current GenericEqualityComparer<T>.Equals implementation is effectively:

if (x != null)
{
    if (y != null) return x.Equals(y);
    return false;
}

return y == null;

CoreCLR's optimized IndexOf follows the same rule: when the value being searched for is null, it only looks for an actual null element. It does not call element.Equals(null).

That is intentional because a non-null value is required to compare unequal to null. In particular, x.Equals(null) should return false. Your implementation violates the equality contract in two ways:

1. It is not transitive. For two different instances a and b, a == null and null == b are both true, while a == b is false.
2. Equal values must produce equal hash codes. The default comparer uses 0 for null, while your objects return 1.

Those properties are required by hash-based collections and by APIs that use the default equality comparer, so IEquatable<T> is not an extension point for redefining what null means.

If you intentionally need this non-standard relation, use an explicit comparer with an API that accepts one rather than EqualityComparer<T>.Default. Also make every value that can compare equal return the same hash code. For example:

sealed class ReallyComparer : IEqualityComparer<ReallyComparable?>
{
    public bool Equals(ReallyComparable? x, ReallyComparable? y)
    {
        if (x is null || y is null)
            return true;

        return ReferenceEquals(x, y);
    }

    public int GetHashCode(ReallyComparable? obj) => 0;
}

Even then, the relation is still non-transitive for distinct non-null instances, so it is unsafe for Dictionary or HashSet. A predicate such as Matches(...) would describe this behavior more accurately than equality.

Sources: GenericEqualityComparer<T> and the CoreCLR IndexOf specialization.

[quixoticaxis]

Thank you for the input. I was curious not how but why it works the way it works. My example was non-transitive, true, I should have returned true unconditionally, and it still would fail for nulls. I was particulary interested in why null handling is special, but, as mentioned in the other answer, it's an explicit rule.

[tannergooding]

sealed class ReallyComparable : IEquatable<ReallyComparable?> // treats null as equal to anything

This is notably an illegal and invalid implementation

Equals and GetHashCode (and by extension IEquatable<T>.Equals) have implementation contracts you are required to fulfill. See also https://learn.microsoft.com/en-us/dotnet/api/system.iequatable-1?view=net-10.0#notes-to-implementers and https://learn.microsoft.com/en-us/dotnet/api/system.object.equals?view=net-10.0#notes-for-inheritors

In particular (especially note the last bullet):

The following statements must be true for all implementations of the Equals(Object) method. In the list, x, y, and z represent object references that are not null.

• x.Equals(x) returns true.
• x.Equals(y) returns the same value as y.Equals(x).
• x.Equals(y) returns true if both x and y are NaN.
• If (x.Equals(y) && y.Equals(z)) returns true, then x.Equals(z) returns true.
• Successive calls to x.Equals(y) return the same value as long as the objects referenced by x and y are not modified.
• x.Equals(null) returns false.

If you fail to successfully follow these rules, you may encounter undefined behavior, unexpected failures, or other bugs.

[quixoticaxis]

Ah, I see, I missed the explicit last point. Thank you.