当最后一个条件调用有条件时，为什么C＃编译器会删除方法调用链？

Question 1

考虑以下类别：

public class A {
    public B GetB() {
        Console.WriteLine("GetB");
        return new B();
    }
}

public class B {
    [System.Diagnostics.Conditional("DEBUG")]
    public void Hello() {
        Console.WriteLine("Hello");
    }
}

现在，如果我们以这种方式调用方法：

var a = new A();
var b = a.GetB();
b.Hello();

在发布版本中（即，无DEBUG标志），我们只会看到GetB控制台上打印的内容，因为Hello()编译器会省略对的调用。在调试版本中，两个打印都会出现。

现在让我们链接方法调用：

a.GetB().Hello();

调试版本中的行为不变。但是，如果未设置标志，则会得到不同的结果：两个调用都被省略，并且控制台上没有打印内容。快速浏览一下IL会发现整个行没有被编译。

根据针对C＃的最新ECMA标准（ECMA-334，即C＃5.0），Conditional属性置于方法上如下（强调我的意思）：

如果在调用点定义了一个或多个与其相关的条件编译符号，则包括对条件方法的调用，否则将省略该调用。（第22.5.3节）

这似乎并不表示应忽略整个链条，因此是我的问题。话虽如此，Microsoft的C＃6.0规范草案提供了更多细节：

如果定义了该符号，则包括该呼叫；否则，将忽略该呼叫（包括对接收方的评估和该呼叫的参数）。

没有对调用的参数进行评估的事实有据可查，因为这是人们#if在功能体内使用此功能而不是使用伪指令的原因之一。但是，有关“接收者评估”的部分是新的-我似乎无法在其他地方找到它，并且确实可以解释上述行为。

有鉴于此，我的问题是：在这种情况下，C＃编译器不进行评估的原理 是什么a.GetB() ？根据条件调用的接收者是否存储在临时变量中，它的行为是否真的有所不同？

Question 2

我进行了一些挖掘，发现C＃5.0语言规范实际上确实已经在第424页上的17.4.2节的Conditional属性中包含您的第二个引号。

马克·格雷韦尔（Marc Gravell）的答案已经表明，这种行为是有意的，在实践中是什么意思。您还询问了基本原理背后却似乎被去除开销马克的被提及的不满。

也许你想知道为什么其视为可以消除的开销？

a.GetB().Hello(); 在您的情况下根本不会被调用 Hello()被忽略的话，其面值似乎奇怪。

我不知道该决定背后的理由，但我发现了一些合理的推理依据。也许它也可以帮助您。

方法链仅当每个先前的方法都有返回值时，才可以进行。当您想对这些值做某事时，这很有意义，即a.GetFoos().MakeBars().AnnounceBars();

如果你有一个功能，只不某些操作而不返回值您不能在其后面链接某些东西，而可以将其放在方法链的末尾，就像您的条件方法一样，因为它必须具有返回类型void。

还要注意，前面的方法调用的结果被丢弃了，因此在您的示例中，执行此语句后a.GetB().Hello();的结果GetB()没有理由继续存在。基本上，您暗示您GetB()只需要使用的结果Hello()。

如果Hello()省略了为什么要GetB()那么呢？如果您忽略Hello()了行，则将其归结为a.GetB();没有任何分配，并且许多工具会警告您您没有使用返回值，因为这很少是您想要执行的操作。

您似乎对此方法不满意的原因不仅是尝试执行返回某个值所需的操作，而且还产生副作用，即I / O。如果您确实有一个纯函数，则实际上没有理由GetB()忽略后续调用，即，如果您不打算对结果做任何事情。

如果将的结果分配给GetB()变量，则它本身就是一条语句，无论如何都会执行。所以这种推理解释了为什么

var b = a.GetB();
b.Hello();

Hello()当使用方法链接时，只省略对的调用，而整个链则被忽略。

您也可以在完全不同的地方看待以获得更好的视角：C＃6.0中引入的空条件运算符或elvis运算符 ?。尽管对于带有null检查的更复杂的表达式来说，它只是语法糖，但它允许您构建类似于方法链之类的东西，并可以选择基于null检查进行短路。

例如，GetFoos()?.MakeBars()?.AnnounceBars();如果先前的方法不返回null，则它将到达终点，否则将省略后续的调用。

这可能是反直觉的，但试试你的情况想象成这个倒数：编译器之前忽略你的电话Hello()在你的a.GetB().Hello();链，因为你没有达到链的末端反正。

免责声明

所有这些都是扶手椅式的推理，因此，请与猫王操作员进行一番比较，然后撒一粒盐。

Question 3

归结为以下短语：

（包括接收方评估和呼叫参数）被省略。

在表达式中：

a.GetB().Hello();

“接收者的评价”是：a.GetB()。因此：按照规范被省略了，这是一个有用的技巧[Conditional]，可以避免未使用的东西的开销。当您将其放入本地时：

var b = a.GetB();
b.Hello();

那么“接收者的评估”仅是local b，但原始var b = a.GetB();评估仍将进行评估（即使将localb最终删除）。

这可能会带来意想不到的后果，因此：请[Conditional]谨慎使用。但是原因是可以轻松添加和删除日志记录和调试之类的内容。请注意，如果天真地对待参数，也可能会出现问题：

LogStatus("added: " + engine.DoImportantStuff());

和：

var count = engine.DoImportantStuff();
LogStatus("added: " + count);

如果被标记，则可能会非常不同-结果是您的实际“重要内容”没有完成。LogStatus[Conditional]

Question 4

根据条件调用的接收者是否存储在临时变量中，它的行为是否真的有所不同？

是。

a.GetB()在这种情况下，C＃编译器不进行评估的原理是什么？

马克和索伦的答案基本上是正确的。这个答案只是为了清楚地记录时间表。

该功能是在1999年设计的，该功能的目的始终是删除整个语句。
2003年的设计说明表明，设计团队当时意识到这一点尚不清楚。直到现在，规范仅指出不会对参数进行求值。我注意到，该规范犯了一个普遍错误，即将参数称为“参数”，尽管当然可以假设它们的意思是“实际参数”而不是“形式参数”。
在这一点上，应该创建一个工作项来修复ECMA规范。显然，这从未发生过。
更正的文本首次出现在任何C＃规范中的都是C＃4.0规范，我认为是2010年。（我不记得这是我的更正之一，还是别人发现了它。）
如果2017年ECMA规范不包含此更正，那么这是一个错误，应在下一版本中修复。我想，迟到15年总比没有好。