C# 中动态类型的限制

Question

您能给我一些 C# 中动态类型限制的原因吗？我在“Pro C# 2010 和 .NET 4 平台”中读到了有关它们的内容。这是摘录（如果在这里引用书籍是非法的，请告诉我，我将删除摘录）：

虽然很多事情都可以 使用dynamic关键字定义， 有一些限制 它的用法。虽然他们没有表现出来 塞子，确实知道动态数据 item 无法使用 lambda 表达式或 C# 匿名方法 调用方法时。例如， 总是会出现以下代码 错误，即使目标方法 确实需要一个委托参数 它接受一个字符串值并返回 空白。

动态 a = GetDynamicObject(); 
// 错误！动态数据的方法不能使用 lambda！ 
a.Method(arg => Console.WriteLine(arg));

为了规避此限制，您 需要与底层一起工作 直接委托，使用 第 11 章中描述的技术 （匿名方法和 lambda 表达式等）。另一个限制 是动态数据点不​​能 了解任何扩展方法（请参阅 第12章）。不幸的是，这会 还包括任何扩展名 来自 LINQ API 的方法。 因此，用以下方式声明的变量 动态关键字的作用非常有限 在 LINQ to Objects 和其他对象中使用 LINQ 技术：

动态 a = GetDynamicObject(); 
// 错误！动态数据找不到Select()扩展方法！ 
var data = from d in a select d;

提前致谢。

Answer 1

托马斯的猜想相当不错。他对扩展方法的推理是正确的。基本上，为了使扩展方法起作用，我们需要调用站点在运行时以某种方式知道编译时哪些 using 指令有效。我们只是没有足够的时间或预算来开发一个可以将这些信息持久保存到调用站点中的系统。

对于 lambda，情况实际上比确定 lambda 是要进入表达式树还是委托的简单问题更复杂。请考虑以下情况：

d.M(123)

其中 d 是动态类型的表达式。 *什么对象应该在运行时作为参数传递给调用站点“M”？显然我们选择了 123 框并通过了它。然后，运行时绑定器中的重载解析算法会查看 d 的运行时类型和 int 123 的编译时类型，并对其进行处理。

现在，如果是

d.M(x=>x.Foo())

现在我们应该传递什么对象作为参数呢？我们无法表示“一个变量的 lambda 方法，该变量调用一个名为 Foo 的未知函数，无论 x 的类型是什么”。

假设我们想要实现这个功能：我们必须实现什么？首先，我们需要一种方法来表示未绑定的 lambda。表达式树在设计上仅用于表示所有类型和方法都已知的 lambda。我们需要发明一种新型的“无类型”表达式树。然后我们需要在运行时绑定器中实现 lambda 绑定的所有规则。

考虑最后一点。 Lambda 可以包含语句。 实现此功能要求运行时绑定器包含 C# 中每个可能语句的整个语义分析器。

这超出了我们的预算几个数量级。如果我们想实现该功能，我们今天仍然会致力于 C# 4。

不幸的是，这意味着 LINQ 不能很好地处理动态，因为 LINQ 当然到处都使用非类型化 lambda。希望在 C# 的某些假设的未来版本中，我们将拥有功能更齐全的运行时绑定器，并且能够对未绑定的 lambda 进行同像表示。但如果我是你，我就不会屏住呼吸等待。

更新：一条评论要求澄清有关语义分析器的观点。

考虑以下重载：

class C {
  public void M(Func<IDisposable, int> f) { ... }
  public void M(Func<int, int> f) { ... }
  ...
}

和一个调用

d.M(x=> { using(x) { return 123; } });

假设 d 是编译时类型动态和运行时类型 C。运行时绑定器必须做什么？

运行时绑定器必须在运行时确定表达式 x=>{...} 是否可转换为 M 的每个重载中的每个委托类型

。为了做到这一点，运行时绑定器必须能够确定第二个重载不适用。如果它适用，那么您可以将 int 作为 using 语句的参数，但 using 语句的参数必须是一次性的。这意味着运行时绑定器必须了解 using 语句的所有规则，并能够正确报告任何可能的 using 语句的使用是否合法或非法。

显然这不限于 using 语句。运行时绑定器必须了解所有 C# 的所有规则，以便确定给定的语句 lambda 是否可转换为给定的委托类型。

我们没有时间编写一个运行时绑定器，它本质上是一个生成 DLR 树而不是 IL 的全新 C# 编译器。。通过不允许 lambda，我们只需要编写一个运行时绑定器，它知道如何绑定方法调用、算术表达式和其他一些简单类型的调用站点。允许 lambda 会使运行时绑定问题的实现、测试和维护成本增加数十或数百倍。

Answer 2

Lambda：我认为不支持 lambda 作为动态对象参数的原因之一是编译器不知道是将 lambda 编译为委托还是表达式树。

当您使用 lambda 时，编译器会根据目标参数或变量的类型进行决定。当它是 Func<...> （或其他委托）时，它将 lambda 编译为可执行委托。当目标是Expression<...>时，它将 lambda 编译成表达式树。

现在，当您拥有动态类型时，您不知道参数是委托还是表达式，因此编译器无法决定要做什么！

扩展方法：我认为这里的原因是在运行时查找扩展方法会非常困难（而且可能效率也很低）。首先，运行时需要知道使用 using 引用了哪些命名空间。然后，它需要搜索所有加载的程序集中的所有类，过滤那些可访问的（按命名空间），然后搜索那些扩展方法......

Answer 3

埃里克（和托马斯）说得很好，但我是这么想的。

此 C# 语句

a.Method(arg => Console.WriteLine(arg)); 

如果没有大量上下文， 就没有任何意义。 Lambda 表达式本身没有类型，而是可以转换为委托（或表达式）类型。因此，收集含义的唯一方法是提供一些上下文，强制将 lambda 转换为特定的委托类型。该上下文通常是（如本示例中所示）重载解析；给定 a 的类型以及该类型上可用的重载 Method（包括扩展成员），我们可以放置一些上下文来赋予 lambda 含义。

如果没有上下文来产生含义，您最终不得不捆绑有关 lambda 的各种信息，以期在运行时以某种方式绑定未知数。 （您可能生成什么 IL？）

相比之下，您在那里放置了一个特定的委托类型，

a.Method(new Action<int>(arg => Console.WriteLine(arg))); 

Kazam！事情变得容易了。无论 lambda 中包含什么代码，我们现在都确切地知道它的类型，这意味着我们可以像编译任何方法体一样编译 IL（例如，我们现在知道 Console.cs 的许多重载中的哪一个）。我们正在调用 WriteLine）。并且该代码具有一种特定类型 (Action)，这意味着运行时绑定器可以轻松查看 a 是否具有 Method 采用这种类型的论证。

在 C# 中，裸露的 lambda 几乎毫无意义。 C# lambda 需要静态上下文来赋予它们含义并排除许多可能的强制和重载引起的歧义。典型的程序可以轻松地提供此上下文，但动态情况缺乏此重要的上下文。