使用EqualityComparer<T>.Default.Equals()时的CS8603空引用返回警告疑问

问题代码 #

static async Task<T> ExampleMethod<T>()
{
    T? result = default;
    while (true)
    {
        try
        {
            result = await TryToDoSomething<T>();
        }
        catch (Exception e)
        {
            // log
        }

        if (EqualityComparer<T>.Default.Equals(result, default) == false)
        {
            return result;
        }

        await Task.Delay(1000);
    }
}

Visual Studio在return语句的result下标记绿色波浪线，提示：'result' may be null here. CS8603: Possible null reference return.

1. 该警告是否正确，还是Visual Studio误报？ #

警告是正确的，并非误报。

2. 若警告正确，这种情况为何会发生，适用于哪些场景？ #

编译器的静态空值分析无法识别EqualityComparer<T>.Default.Equals(result, default)的判断逻辑能确保result非null，具体原因和适用场景如下：

• 不可空引用类型场景：当T是不可空引用类型（如string）时，T? result允许存储null值。虽然EqualityComparer<string>.Default.Equals(null, default(string))会返回true（因为default(string)就是null），理论上只有非null的result才会进入return分支，但编译器仅基于类型约束做静态分析，无法确认这个比较逻辑能完全排除null，因此认为返回T?类型的result可能违反Task<T>的非空返回要求。
• 自定义类型重写Equals的极端场景：如果T是自定义类型且重写了Equals方法，存在违反规范的实现可能——比如result为null但Equals(result, default)返回false，编译器无法排除这种不合理但语法合法的情况。
• 可空值类型的边缘情况：当T是可空值类型（如int?）时，若自定义的EqualityComparer处理逻辑不符合预期，也会导致编译器无法确信result的非空性。

本质上，编译器的静态空值分析仅识别直接的null检查（如result != null），不会深入解析通用比较方法的内部逻辑，因此触发该警告。

内容的提问来源于stack exchange，提问作者lojoh