c# - 为什么编译器为 "yield"生成的枚举器不是结构？

Question

compiler-generated implementation的 IEnumerator/IEnumerable对于 yield methods 和 getters 似乎是一个类，因此分配在堆上。但是，其他 .NET 类型，例如 List<T>具体返回struct枚举数以避免无用的内存分配。通过对C# 深入 帖子的快速概述，我看不出为什么这里也不是这种情况。

我错过了什么吗？

Answer 1

Servy 正确回答了您的问题——您在评论中自己回答的问题:

I just realized that since the return type is an interface, it would get boxed anyway, is that right?

没错。您的后续问题是:

couldn't the method be changed to return an explicitly typed enumerator (like List<T> does)?

所以你的想法是用户写:

IEnumerable<int> Blah() ...

并且编译器实际上生成了一个返回 BlahEnumerable 的方法这是一个实现 IEnumerable<int> 的结构, 但有适当的 GetEnumerator允许 foreach 的“模式匹配”功能的等方法和属性消除拳击。

虽然这是一个看似合理的想法，但当您开始对方法的返回类型撒谎时，会遇到严重的困难。 尤其是当谎言涉及更改方法返回结构还是引用类型时。想想所有出错的地方:

• 假设该方法是虚拟的。它怎么能被覆盖？虚拟覆盖方法的返回类型必须与被覆盖的方法完全匹配。 (同样适用于:该方法覆盖了另一个方法，该方法实现了一个接口(interface)的方法，等等。)

• 假设方法被做成委托(delegate)Func<IEnumerable<int>> . Func<T>在 T 中是协变的，但协变仅适用于引用类型的类型参数。代码看起来像是返回一个 IEnumerable<T>。但实际上它返回的值类型与 IEnumerable<T> 不协方差兼容, 只有作业兼容。

• 假设我们有 void M<T>(T t) where T : class我们调用M(Blah()) .我们期望推断出 T是IEnumerable<int> ，它通过了约束检查，但是结构类型没有通过约束检查。

等等。你很快就进入了 Three's Company 的一集(男孩，我在这里约会自己)，一个小谎言最终会演变成一场巨大的灾难。这一切都节省了少量的收款压力。不值得。

我注意到编译器创建的实现确实以一种有趣的方式减轻了收集压力。 第一次 GetEnumerator在返回的可枚举对象上调用，可枚举对象将自身 变成一个枚举器。第二次状态当然不同，所以它分配了一个新对象。由于 99.99% 可能的情况是给定的序列恰好被枚举一次，因此这大大节省了收集压力。