Why are parameters of IEqualityComparer<T>.Equals nullable?

[MrTA2]

Imagine this:

class Foo { public int X; }
class FooComparer: IEqualityComparer<Foo>
{
  public bool Equals(Foo? x, Foo? y) // if I change this to not-null to avoid warnings below, it conflicts with interface
  {
    return x.X == y.X; // this produces null warnings
  }
....
}

Why was this done? Why not pass T "as is" to Equals, whether it's nullable or not?

[gfoidl]

Imagine what happens when y = null in your example?
So the warnings are OK, and should remind you that (for reference types) both could be null and need to be handled that way.

[MrTA2]

y cannot be null, because I used Foo as generic argument of IEqualityComparer<>, not Foo?. If this comparer was meant for a scenario where x or y can be null, I would've used Foo? as the generic argument, which would've told me that I need to check if they are null and handle that accordingly. No, the warnings are not OK.

[Joe4evr]

y cannot be null, because I used Foo as generic argument of IEqualityComparer<>, not Foo?.

That's not how it works. The annotation for the class type argument can be independent of the usage in its members. The following is perfectly reasonable because there's no guarantee that Value is initialized:

public sealed class Result<T>
{
    public bool IsSuccess { get; private init; }
    public T? Value { get; private init; }

    private Result() { }

    public static Result<T> FromSuccess(T value) => new() { Value = value, IsSuccess = true };
    public static Result<T> FromError() => new() { Value = default, IsSuccess = false };
}

Result<Foo>.FromError().Value will return you a null regardless of the type argument being <Foo> or <Foo?>. The same applies to method parameters, and so you must account for null being passed into Equals regardless of your type argument.

[TahirAhmadov]

With all due respect, your example is irrelevant here. Value can be null because it's declared as being nullable. Now that raises another question - why is it allowed to mark a generic argument typed member/variable as nullable without a where T : notnullable? Topic for another day.

I cannot even imagine how this example bears any resemblance to the IEqualityComparer<> situation.

[huoyaoyuan]

Because most existing callers of the interface expects it to handle null. The nullable annotation follows the fact.

[MrTA2]

I assume you mean the existing callers in the .NET library? If so, all those should handle generic nullability the same way - respect what the user of the type in question is demanding - nullability or not. Other code in the wild is irrelevant, because nullability of reference types is a breaking change and is using warnings, not errors, specifically to give C# programmers time to adapt their code.

[Joe4evr]

respect what the user of the type in question is demanding - nullability or not.

Nullability annotations only exist at compile time and those have had to adapt to what 20 years of usage has made those APIs do. Passing nulls into IEqualityComparer has been done for forever, and the current annotations reflect this usage accurately.

[TahirAhmadov]

Something happening for a long time is absolutely not a reason to ingrain it into the language going forward. The whole nullability change was undoing something that's been happening for decades. Furthermore, I'm yet to see evidence of a need to pass nulls to IEqualityComparer<T>.Equals where T is known to be not null.

[lechu445]

It makes sense what @TahirAhmadov says.

@huoyaoyuan can you provide an example of such class handling nulls where T is known to be not null? I guess you mean handling as different than throwing ArgumentNullException, because in this situation https://github.com/dotnet/runtime/blob/main/docs/coding-guidelines/api-guidelines/nullability.md clearly says that the validation can be done on parameters marked as non-nullable.