c# - 为什么编译器不能在这种重载解析情况下告诉更好的转换目标？ (协方差)

Question

理解关于重载决议的 C# 语言规范显然很难，现在我想知道为什么这个简单的案例失败了:

void Method(Func<string> f)
{
}
void Method(Func<object> f)
{
}
void Call()
{
    Method(() => { throw new NotSupportedException(); });
}

这会产生编译时错误 CS0121，以下方法或属性之间的调用不明确: 后跟我的两个 Method函数成员(重载)。

我所期望的是 Func<string>是一个比Func<object> 更好的转换目标 ，然后应该使用第一个重载。

自 .NET 4 和 C# 4 (2010) 起，通用委托(delegate)类型 Func<out TResult>在 TResult 中一直协变 ，因此存在从 Func<string> 的隐式转换至 Func<object>虽然显然不存在来自 Func<object> 的隐式转换至 Func<string> .所以它会使Func<string>更好的转换目标，重载决议应该选择第一个重载？

我的问题很简单:我在这里遗漏了 C# 规范的哪一部分？

---

添加:这很好用:

void Call()
{
    Method(null); // OK!
}

Answer 1

My question is simply: What part of the C# Spec am I missing here?

总结:

• 您在实现中发现了一个已知的小错误。
• 出于向后兼容的原因，该错误将被保留。
• C# 3 规范包含有关如何处理“null”情况的错误；它已在 C# 4 规范中修复。
• 您可以使用无法推断返回类型的任何 lambda 重现错误行为。例如:Method(() => null);

详情:

C# 5 规范指出，更好的规则是:

• 如果表达式有类型，则选择从该类型到候选参数类型的更好转换。

• 如果表达式没有类型且不是 lambda，则选择转换为更好的类型。

• 如果表达式是lambda那么首先考虑哪种参数类型更好；如果两者都不是更好并且委托(delegate)类型具有相同的参数列表，则考虑 lambda 的推断返回类型与委托(delegate)的返回类型之间的关系。

所以预期的行为是:首先编译器应该检查一个参数类型是否明显优于另一个，不管参数是否有类型。如果这不能解决问题并且参数是 lambda，然后检查转换为参数的委托(delegate)类型的返回类型的推断返回类型中哪个更好。

实现中的错误是实现没有那样做。相反，在参数是 lambda 的情况下，它完全跳过类型优度检查并直接进入推断的返回类型优度检查，然后失败，因为没有推断的返回类型。

我的意图是为 Roslyn 解决这个问题。然而，当我去实现它时，我们发现进行修复会导致一些真实世界的代码停止编译。 (我不记得真实世界的代码是什么，我也无法访问存在兼容性问题的数据库。)因此我们决定保留现有的小错误。

我注意到，在我在 C# 4 中添加委托(delegate)变体之前，这个错误基本上是不可能的；在 C# 3 中，两种不同的委托(delegate)类型不可能具有或多或少的特定性，因此唯一可以应用的规则是 lambda 规则。由于 C# 3 中没有可以揭示错误的测试，因此很容易编写。我的错，对不起。

我还注意到，当您开始混合使用表达式树类型时，分析会变得更加复杂。尽管Func<string>优于Func<object> , Expression<Func<string>>不可转换为 Expression<Func<object>> !如果更好的算法对于 lambda 是去表达式树还是委托(delegate)是不可知的，那就太好了，但在某些方面它不是。这些情况变得复杂，我不想在这里强调这一点。

这个小错误是一个客观的教训，说明实现规范实际说的而不是你认为的的重要性。如果我在 C# 3 中更加小心以确保代码与规范匹配，那么代码将在“null”情况下失败，然后就会更早地清楚 C# 3 规范是错误的。实现在类型检查之前执行 lambda 检查，这是一个定时炸弹，当 C# 4 滚动时，它会突然变成不正确的代码。无论如何都应该首先进行类型检查。