为什么条件方法必须具有 return 类型的 void？
Why does conditional methods must have a return type of void?
我们正在为 API 编写一些全局异常处理程序，我们只需要在 Debug 配置中执行某些方法，显然条件方法是可能的解决方案。
但是我看到的是 [Conditional("DEBUG")] 只能用于 return 类型为 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 不简单地拦截方法调用 returning default(T) 例如，因此允许带有 return 的方法任何类型的类型都是有条件的？或者我遗漏了什么？
why not CLR simply intercept method calls returning default(T)
更重要的是...为什么 会发生这种情况？如果没有令人信服的理由这样做，那么就没有令人信服的理由投入大量的努力、工时、成本等来辩论、设计、考虑所有可能的场景、开发、测试并继续在该语言的所有未来版本中支持它。对于一开始就不需要的功能来说，这是一笔相当可观的节省。
一个void方法保证没有结果。所以已经存在一个合乎逻辑的保证，即没有任何东西依赖它的结果。 returns 一个值的方法不能提供这样的保证。
因为没有任何东西依赖于它的结果，所以省略它不会改变 code/logic 的直接本地行为。而如果某事 做了 依赖于它的结果（或者至少 可能 依赖于它的结果）那么局部行为可能会改变，这是不可取的。这种情况可能会带来许多意想不到的变化。即使是像返回 null 这样代码不期望 null.
这样简单的事情
一个人也许可以个人坚持认为一个人可以考虑自己的逻辑并在编译器可以保证的范围之外做出自己的保证。 （类型转换和反射之类的东西可能对开发人员来说是有用的工具，前提是他们可以保持他们认为可以保持的稳定性。）但在这种特殊情况下，它 很快 成为一个问题开发代码和生产代码不再做同样的事情。他们可能会做非常相似的事情，但不再是同一件事。这是一个严重的问题，语言试图避免这种情况。
这与系统可以做什么无关。我敢肯定，根据当时的信息，任何给定语言的任何给定版本 都可以 支持各种各样的东西。但是应该吗？这完全是另一个问题。在这种情况下，支持这一点的成本似乎会大大超过从中获得的收益。
我们正在为 API 编写一些全局异常处理程序，我们只需要在 Debug 配置中执行某些方法，显然条件方法是可能的解决方案。
但是我看到的是 [Conditional("DEBUG")] 只能用于 return 类型为 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 不简单地拦截方法调用 returning default(T) 例如，因此允许带有 return 的方法任何类型的类型都是有条件的？或者我遗漏了什么？
why not CLR simply intercept method calls returning
default(T)
更重要的是...为什么 会发生这种情况？如果没有令人信服的理由这样做，那么就没有令人信服的理由投入大量的努力、工时、成本等来辩论、设计、考虑所有可能的场景、开发、测试并继续在该语言的所有未来版本中支持它。对于一开始就不需要的功能来说，这是一笔相当可观的节省。
一个void方法保证没有结果。所以已经存在一个合乎逻辑的保证，即没有任何东西依赖它的结果。 returns 一个值的方法不能提供这样的保证。
因为没有任何东西依赖于它的结果，所以省略它不会改变 code/logic 的直接本地行为。而如果某事 做了 依赖于它的结果（或者至少 可能 依赖于它的结果）那么局部行为可能会改变，这是不可取的。这种情况可能会带来许多意想不到的变化。即使是像返回 null 这样代码不期望 null.
一个人也许可以个人坚持认为一个人可以考虑自己的逻辑并在编译器可以保证的范围之外做出自己的保证。 （类型转换和反射之类的东西可能对开发人员来说是有用的工具，前提是他们可以保持他们认为可以保持的稳定性。）但在这种特殊情况下，它 很快 成为一个问题开发代码和生产代码不再做同样的事情。他们可能会做非常相似的事情，但不再是同一件事。这是一个严重的问题，语言试图避免这种情况。
这与系统可以做什么无关。我敢肯定，根据当时的信息，任何给定语言的任何给定版本 都可以 支持各种各样的东西。但是应该吗？这完全是另一个问题。在这种情况下，支持这一点的成本似乎会大大超过从中获得的收益。