没有从 'System.Collections.Generic.List<T>' 到 'T' 的隐式引用转换

Question

class Class1<T>
{
    public virtual void Update(T entity)
    {
        Update(new List<T>() { entity }); //It's failed
    }

    public virtual void Update(IEnumerable<T> entities)
    {
    }

    public virtual void Update<TSub>(TSub entity) where TSub : T
    {
    }

    public virtual void Update<TSub>(IEnumerable<TSub> entities) where TSub : T
    {
    }
}

我有一段代码。但总是失败。

如果我将Update(new List<T>() { entity }) 替换为Update((new List<T>() { entity }).AsEnumerable())，就可以了。

删除第三种方法Update<TSub>(TSub entity) where TSub : T也可以。

谁能告诉我为什么？

Answer 1

好的，让我们仔细检查一下。我们有

Update(new List<T>()); 

还有三个候选者——请注意，我们只关心这些候选者的签名，所以我们将去掉返回类型和约束，它们不是签名的一部分:

Update(IEnumerable<T> entities)
Update<U>(U entity) 
Update<V>(IEnumerable<V> entities) 

我们的首要任务是对最后两个候选者进行类型推断。如果推理失败，则它们不是适用的候选对象。

考虑第二种方法

Update<U>(U entity) 

我们有一个List<T> 类型的参数和一个形参U。因此我们推断U 是List<T>。

考虑第三种方法：

Update<V>(IEnumerable<V> entities)

我们有一个List<T> 类型的参数和一个IEnumerable<V> 类型的形参。 List<T> 实现 IEnumerable<T> 所以我们推断 V 是 T。

好的，所以我们的候选列表现在包括：

Update(IEnumerable<T> entities)
Update<List<T>>(List<T> entity) 
Update<T>(IEnumerable<T> entities) 

所有这些候选者都适用吗？是的。在每种情况下，List<T> 都可以转换为形式参数类型。我们还不能消除它们中的任何一个。

既然我们只有适用的候选人，我们必须确定哪一个是最好的。

我们可以立即消除第三个。第三个和第一个在形式参数列表中是相同的。 C# 的规则是，当您有两个在其形式参数列表中相同的方法时，其中一个“自然地”到达那里并且其中一个通过类型替换到达那里，被替换的那个就失败了。

我们也可以消除第一个。显然，第二个中的完全匹配优于第一个中的不完全匹配。

这使得第二个人成为最后一个站着的人。它赢得了过载解决之战。然后在最终验证期间，我们发现违反了约束：List<T> 不保证是T 的派生类。

因此重载决议失败。您的论点导致选择的最佳方法无效。

如果我打电话给Update((new List<T>() { entity }).AsEnumerable())，就可以了。

正确。再过一遍。三位候选人：

Update(IEnumerable<T> entities)
Update<U>(U entity) 
Update<V>(IEnumerable<V> entities) 

我们有一个IEnumerable<T> 类型的参数，所以我们推断第二个和第三个是：

Update(IEnumerable<T> entities)
Update<IEnumerable<T>>(IEnumerable<T> entity) 
Update<T>(IEnumerable<T> entities) 

现在我们有了三个具有相同参数列表的适用候选。那些正在建设中的自然会比自然的更糟糕，所以我们消除了第二个和第三个，只留下第一个。它赢了，它没有被违反的约束。

删除第三种方法也可以

您的陈述是错误的；这将产生与第一种情况相同的错误。带走第三位候选人并不会导致第一位候选人突然开始击败第二位候选人。

Answer 2

约束不是签名的一部分，Eric Lippert 有一个很棒的article 关于这个主题。

Answer 3

您实际上是在问为什么编译器没有创建从 List<T> 到 IEnumerable<T> 的隐式转换。原因是 C# 团队做出了深思熟虑的设计决定，即必须由程序员而不是编译器解决潜在的歧义情况。 （请注意，VB.NET 团队做出了不同的决定，总是尝试一些与感知到的程序员意图一致的合理事情。）

在这种情况下的好处是可以最大程度地减少意外 - 在幕后不会发生任何意外；缺点是偶尔需要更冗长的代码。