谁最终决定什么是通用类型？

Question

我有这个函数，

 public static T2 MyFunc<T1, T2>( T1 a, T1 b, T2 c)
        {
            return c;
        }     

我正在创建 2 个 Persons 类实例：

 class Person
         {  }

            Person p = new Person();
            Person p2 = new Person();

我正在调用该函数：

 MyClass.MyFunc(p, p2, 5);

我的问题是：

谁真正决定 T1 类型？ (p ? p2 ?)

因为如果左边的是苹果，那么他检查第二个也是苹果

，如果第二个是橙子，他应该检查第一个也是橙子。

询问它似乎很奇怪，因为在编译时它们如果不一样就会失败。

仍然——谁决定类型？

其次 - 如果我将其更改为动态 - 在运行时 - 谁将决定 T1 类型应该是什么？

Answer 1

从高层次来看，方法类型推断的工作原理如下。

首先，我们列出所有参数（您提供的表达式）及其相应的形式参数类型。

让我们看一个比您给出的更有趣的例子。假设我们有

class Person {}
class Employee : Person {}
...
Person p = whatever;
Employee p2 = whatever;

相同的调用。因此，我们进行对应：

p  --> T1
p2 --> T1
5  --> T2

然后我们列出每个类型参数的“边界”以及它们是否“固定”。我们有两个类型参数，并且一开始就没有上限、下限或精确边界。

T1: (unfixed) upper { }  lower { }  exact { }
T2: (unfixed) upper { }  lower { }  exact { }

（回想一下我们最近在另一个问题中关于类型的相对大小的讨论，该相对大小取决于类型的限制性更强还是更少；限制性更强的类型比限制性较小的类型更小。长颈鹿比动物小，因为动物比长颈鹿多。“上”和“下”边界集正是这样：给定类型参数的类型推断问题的解决方案必须大于或相同。到每个下限，小于或等于每个上限，等于每个精确边界。）

然后我们查看每个参数及其相应的类型。 （如果参数是 lambda，那么我们可能必须弄清楚查看参数的顺序，但这里没有任何 lambda，所以让我们忽略该细节。）对于我们所做的每个参数对形式参数类型的推论，并将我们推断出的关于该推论的事实添加到绑定集。因此，在查看第一个参数之后，我们推断出界限：

T1: (unfixed) upper { }  lower { Person }  exact { }
T2: (unfixed) upper { }  lower { }  exact { }

在第二个参数之后，我们推断出界限

T1: (unfixed) upper { }  lower { Person, Employee }  exact { }
T2: (unfixed) upper { }  lower { }  exact { }

在第三个参数之后，我们推断出界限：

T1: (unfixed) upper { }  lower { Person, Employee }  exact { }
T2: (unfixed) upper { }  lower { int }  exact { }

在我们取得了尽可能多的进展之后，我们通过查找来“修复”界限边界集中满足每个边界的最佳类型。

对于 T1，边界集中有两种类型：Person 和 Employee。其中是否有一个满足所设定的边界中的每个边界？是的。 Employee 不满足 Person 绑定，因为 Employee 的类型比 Person 更小； Person 是一个下界 - 这意味着没有小于 Person 的类型是合法的。 Person 确实满足所有边界：Person 与 Person 相同，并且大于 Employee，因此它同时满足界限。边界集中满足每个边界的最佳类型对于 T1 来说是 Person，对于 T2 显然是 int，因为 T2 的边界集中只有一种类型。所以我们然后修复类型参数：

T1: (fixed) Person
T2: (fixed) int

然后我们问“每个类型参数都有固定的界限吗？”答案是“是”，因此类型推断成功。

如果我将第一个参数的类型更改为dynamic，那么如何推断 T1？

如果任何参数是动态的，则 T1 和 T2 的推断将推迟到运行时，此时语义分析器将值的最派生的可访问运行时类型视为动态提供的下界类型争论。

---

如果您对这个主题感兴趣并且想要了解更多信息，这里有一个我解释该算法的 C# 3 版本的视频：

http://blogs.msdn.com/b/ericlippert/archive/2006/11/17/a-face-made-for-email-part- Three.aspx

(C# 3没有上限，只有下限和精确边界；除此之外，算法几乎相同。）

我写的一些关于类型推断问题的文章在这里：

http://blogs.msdn.com/b/ericlippert/archive/tags/类型+推理/

Answer 2

在调用中省略类型的可能性

MyClass.MyFunc(p1, p2, 5);

完全相同

MyClass.MyFunc<Person, int>(p1, p2, 5);

是一个语法糖果（除非您使用匿名类型），并且它的编译方式与编译器推导出 T1 和 T2根据参数a、b和c的类型。如果 p1 和 p2 是不兼容的类型（请参阅 svick 的回答 ，编译器将无法推导 T1 ，这将导致编译错误。

Answer 3

没有优先级，两者（a 和 b）应该相同，即根据设计，T1 在编译时解析。如果更改为动态，则只需将类型解析推迟到运行时，如果类型不相同，它将在编译时失败。如果你想让它们有所不同，你需要引入T3。

编辑：

有趣的部分：

Orange a = new Orange();
Apple b = new Apple();
string c = "Doh.";

MyFunc<dynamic, string>(a,b,c);

public static T2 MyFunc<T1, T2>( T1 a, T1 b, T2 c) where T2 : class
{
    return (a.ToString() + b.ToString() + c.ToString()) as T2;
}     

输出：

I am an orange. I am an apple. Doh.

但是这个：

dynamic a = new Orange();
dynamic b = new Apple();
string c = "Doh.";

MyFunc<Apple, string>(a,b,c);

会抛出：

RuntimeBinderException: The best overloaded method match for 'UserQuery.MyFunc<UserQuery.Apple,string>(UserQuery.Apple, UserQuery.Apple, string)' has some invalid arguments

然而，我似乎真的需要找到一本关于 C# 4.0 中动态类型的好书或资源来理解这里发生的魔力。

Answer 4

谁真正决定 T1 类型？ （p？p2？）

这不是显而易见的吗？他们两个。 p 和 p2 的类型必须兼容。与其他答案所说的相反，它们不必相同。实际规则是必须存在从一种类型到另一种类型的隐式转换。

因此，例如 MyFunc("a", new object(), 5) 与 MyFunc

此外，在某些情况下，让编译器推断类型的能力不仅很好，而且是必要的。具体来说，当使用匿名类型时会发生这种情况。例如，MyFunc(new { p = "p" }, new { p = "p2" }, 5) 无法重写以显式指定类型。

Answer 5

“谁实际决定 T1 类型？(p ? p2 ?)”

通常，由 C# 编译器决定。如果方法参数之一是动态的，则决策是在运行时完成的（由 Microsoft.CSharp 库）。
在这两种情况下，都会应用 C# 规范中描述的类型推断算法：
p 和 p2 的类型都被添加到 T1 的下限集合（上限边界也是可能的，但仅当涉及逆变泛型时）。

然后，编译器在边界集中选择一个也满足所有其他边界的类型。
当由于 p 和 p2 具有相同类型而只有一个边界时，这种选择是微不足道的。
否则（假设只涉及下界），这意味着编译器选择一个类型，以便所有其他候选类型都可以隐式转换为该类型（svick 的答案所描述的）。

如果没有唯一的此类选择，则类型推断失败 - 如果可能，则选择另一个重载，否则会发生编译器错误（当在运行时（动态）完成决策时，会抛出异常）。

Answer 6

在编译时，如果类型是显式的，则编译器将检查传递的参数类型，并查看它们是否对应并可以与泛型中的类型匹配（没有冲突）。

无论如何，真正的检查是在“运行时”完成的，通用代码无论如何都会编译为通用代码（与 C++ 模板不同）。然后，当 JIT 编译器编译该行时，它会检查是否可以根据您提供的模板和发送的参数创建方法。