c# - 为什么条件方法的返回类型必须为 void？

Question

我们正在为我们的 API 编写一些全局异常处理程序，我们只需要在 Debug 配置中执行某些方法，显然条件方法是可能的解决方案。

但是我看到的是 [Conditional("DEBUG")] 只能用于返回类型为 void 的方法，正如 MSDN 所说:

A conditional method is subject to the following restrictions:

• The conditional method must be a method in a class or struct declaration. A compile-time error occurs if the Conditional attribute is specified on a method in an interface declaration.
• The conditional method must have a return type of void.
• The conditional method must not be marked with the override modifier. A conditional method may be marked with the virtual modifier, however. Overrides of such a method are implicitly conditional, and must not be explicitly marked with a Conditional attribute.
• The conditional method must not be an implementation of an interface method. Otherwise, a compile-time error occurs.

来源:https://msdn.microsoft.com/en-us/library/aa664622(v=vs.71).aspx

我们知道用 ConditionalAttribute 标记的方法会到达 IL，那么为什么 CLR 不简单地拦截返回 default(T) 的方法调用，因此允许返回类型为任何类型都是有条件的？或者我遗漏了什么？

Answer 1

why not CLR simply intercept method calls returning default(T)

更重要的是......为什么应该发生这种情况？如果没有令人信服的理由这样做，那么就没有令人信服的理由投入大量的努力、工时、成本等来辩论、设计、考虑所有可能的场景、开发、测试并继续在该语言的所有 future 版本中支持它。对于一开始就不需要的功能来说，这是一笔相当可观的节省。

void 方法保证没有结果。所以已经存在一个合乎逻辑的保证，即没有任何东西依赖它的结果。返回值的方法无法提供此类保证。

因为没有任何东西依赖于它的结果，所以省略它不会改变代码/逻辑的直接本地行为。而如果某件事确实依赖于它的结果(或者至少可能依赖于它的结果)，那么局部行为可能会改变，这是不可取的。这种情况可能会带来许多意想不到的变化。即使是像返回 null 这样简单的事情，代码不期望 null。

一个人也许可以个人坚持认为一个人可以考虑自己的逻辑并在编译器可以保证的范围之外做出自己的保证。 (类型转换和反射之类的东西对开发人员来说可能是有用的工具，前提是他们可以保持他们认为可以保持的稳定性。)但是在这种特殊情况下，它很快成为开发代码和生产代码不再做同样的事情。他们可能会做非常相似的事情，但不再是同一件事。这是一个严重的问题，语言试图避免这种情况。

这与系统能做什么无关。我敢肯定，根据当时的信息，任何给定语言的任何给定版本都可以支持各种各样的东西。但是应该吗？这完全是另一个问题。在这种情况下，支持这一点的成本似乎会大大超过人们可能从中获得的 yield 。