c# - 为什么即使只有一种可能的返回类型，方法调用表达式的类型也是动态的？

Question

受此启发question .

简短版本:如果只有一个 M 重载或所有重载，为什么编译器无法确定 M(dynamic arg) 的编译时类型M 的重载具有相同的返回类型？

根据规范，§7.6.5:

An invocation-expression is dynamically bound (§7.2.2) if at least one of the following holds:

• The primary-expression has compile-time type dynamic.

• At least one argument of the optional argument-list has compile-time type dynamic and the primary-expression does not have a delegate type.

这是有道理的

class Foo {
    public int M(string s) { return 0; }
    public string M(int s) { return String.Empty; }
}

编译器无法判断编译时类型

dynamic d = // dynamic
var x = new Foo().M(d);

因为它直到运行时才知道 M 的哪个重载被调用。

但是，如果 M 只有一个重载或 M 的所有重载都返回同一类型，为什么编译器无法确定编译时类型？

我想了解为什么规范不允许编译器在编译时静态键入这些表达式。

Answer 1

更新:这个问题是 the subject of my blog on the 22nd of October, 2012 .感谢您提出很好的问题!

---

Why can't the compiler figure out the compile-type type of M(dynamic_expression) if there is only one overload of M or all of the overloads of M have the same return type?

编译器可以找出编译时类型；编译时类型是动态，并且编译器成功地计算出了这一点。

我想你想问的问题是:

Why is the compile-time type of M(dynamic_expression) always dynamic, even in the rare and unlikely case that you're making a completely unnecessary dynamic call to a method M that will always be chosen regardless of the argument type?

当您这样表述问题时，它会自行回答。 :-)

原因一:

您设想的情况很少见；为了使编译器能够做出您描述的那种推理，必须知道足够的信息，以便编译器可以对表达式进行几乎完整的静态类型分析。但是如果你在那种情况下那么你为什么首先使用动态？你最好简单地说:

object d = whatever;
Foo foo = new Foo();
int x = (d is string) ? foo.M((string)d) : foo((int)d);

显然，如果只有一个 M 重载，则更容易:将对象转换为所需类型。如果它在运行时因为转换不好而失败，那么 dynamic 也会失败!

在这类场景中根本就没有需要 dynamic，那么为什么我们要在编译器中做大量昂贵且困难的类型推断工作来启用我们不需要的场景？一开始不想使用 dynamic for 吗？

原因二:

假设我们确实说过，如果方法组静态已知包含一个方法，则重载决策具有非常特殊的规则。伟大的。现在我们刚刚为语言添加了一种新的脆弱性。现在，添加一个新的重载会将调用的返回类型更改为完全不同的类型——这种类型不仅会产生动态语义，还会产生值类型。但是等等，情况变得更糟了!

// Foo corporation:
class B
{
}

// Bar corporation:
class D : B
{
    public int M(int x) { return x; }
}

// Baz corporation:
dynamic dyn = whatever;
D d = new D();
var q = d.M(dyn);

假设我们实现了您的功能要求，并根据您的逻辑推断 q 是 int。现在 Foo 公司补充说:

class B
{
    public string M(string x) { return x; }
}

突然间，当 Baz 公司重新编译他们的代码时，q 的类型突然悄悄地变成了 dynamic，因为我们在编译时不知道 dyn 不是一个字符串。这是静态分析中的一个奇怪变化!为什么第三方向基类添加新方法会导致局部变量的类型在完全不同的类中的完全不同的方法中发生变化，该类是在不同公司编写的，一家公司甚至不直接使用 B，而是仅通过 D？

这是 Brittle Base Class 问题的一种新形式，我们力求最大限度地减少 C# 中的 Brittle Base Class 问题。

或者，如果 Foo corp 说:

class B
{
    protected string M(string x) { return x; }
}

现在，按照你的逻辑，

var q = d.M(dyn);

当上面的代码在继承自 D 的类型时，给 q 类型 int，但是

var q = this.M(dyn);

当 在 一个继承自 D 的类型时，将 q 的类型指定为动态的!作为一名开发人员，我会发现这非常令人惊讶。

理由三:

C# 中的聪明之处已经太多了。我们的目标不是构建一个逻辑引擎来计算给定特定程序的所有可能值的所有可能类型限制。我们更喜欢有通用的、可理解的、易于理解的规则，这些规则可以很容易地写下来并且可以在没有错误的情况下实现。该规范已经有八百页长，编写一个没有错误的编译器非常困难。让我们不要让它变得更困难。更不用说测试所有那些疯狂案例的费用了。

理由四:

此外:该语言为您提供了很多机会来利用静态类型分析器。如果您使用动态，则您特别要求该分析器将其操作推迟到运行时。使用“在编译时停止进行静态类型分析”功能会导致静态类型分析在编译时不能很好地工作，这不足为奇。