为什么 BCL 集合使用结构枚举器而不是类？

Question

我们都知道可变结构通常是邪恶的。我也很确定，因为 IEnumerable.GetEnumerator() 返回类型 IEnumerator，结构会立即装箱为引用类型，成本超过如果它们一开始只是引用类型。

那么为什么在 BCL 泛型集合中，所有枚举器都是可变结构呢？肯定有一个很好的理由。我唯一想到的是结构可以轻松复制，从而在任意点保留枚举器状态。但是向 IEnumerator 接口添加一个 Copy() 方法会不会那么麻烦，所以我不认为这本身就是一个逻辑依据。

即使我不同意某个设计决策，我也希望能够理解其背后的原因。

Answer 1

事实上，这是出于性能原因。 BCL 团队在这一点上进行了大量研究，然后才决定采用您正确指出的可疑且危险的做法：使用可变值类型。

你问为什么这不会引起拳击。这是因为 C# 编译器不会生成代码来将内容装箱到 foreach 循环中的 IEnumerable 或 IEnumerator（如果可以避免的话）！

当我们看到时，

foreach(X x in c)

我们要做的第一件事就是检查 c 是否有一个名为 GetEnumerator 的方法。如果是，那么我们检查它返回的类型是否具有 MoveNext 方法和 current 属性。如果是，则完全使用对这些方法和属性的直接调用来生成 foreach 循环。只有当“模式”无法匹配时，我们才会回去找接口。

这有两个理想的效果。

首先，如果集合是一个 int 集合，但是在发明泛型类型之前编写的，那么它不会受到将 Current 的值装箱到对象然后将其拆箱为 int 的装箱惩罚。如果 Current 是一个返回 int 的属性，我们就使用它。

其次，如果枚举数是值类型，则它不会将枚举数装箱到 IEnumerator。

正如我所说，BCL 团队对此进行了大量研究，发现绝大多数情况下，分配和取消分配枚举数的惩罚足够大，值得将其设为一个值类型，尽管这样做可能会导致一些疯狂的错误。

例如，考虑一下：

struct MyHandle : IDisposable { ... }
...
using (MyHandle h = whatever)
{
    h = somethingElse;
}

您完全正确地期望改变 h 的尝试会失败，而且确实如此。编译器检测到您正在尝试更改具有挂起处置的对象的值，并且这样做可能会导致需要处置的对象实际上未被处置。

现在假设您：

struct MyHandle : IDisposable { ... }
...
using (MyHandle h = whatever)
{
    h.Mutate();
}

这里发生了什么？您可能合理地预期，如果 h 是只读字段，编译器会执行其操作： 制作一个副本，并改变副本，以确保该方法不会丢弃需要处理的值中的内容。

然而，这与我们对这里应该发生的事情的直觉相冲突：

using (Enumerator enumtor = whatever)
{
    ...
    enumtor.MoveNext();
    ...
}

我们期望在 using 块内执行 MoveNext 会将枚举器移动到下一个，无论它是结构体还是引用类型。

不幸的是，现在的 C# 编译器有一个错误。如果您处于这种情况，我们会不一致地选择遵循哪种策略。今天的行为是：

• 如果通过方法改变的值类型变量是普通局部变量，那么它会正常改变

• 但如果它是提升局部变量（因为它是匿名函数或迭代器块中的封闭变量），则local实际上是作为只读字段生成的，并且确保副本上发生突变的齿轮将接管。

不幸的是，规范在这个问题上几乎没有提供任何指导。显然，有些东西被破坏了，因为我们做得不一致，但正确的做法是什么却根本不清楚。

Answer 2

当编译时已知结构体类型时，结构体方法会被内联，并且通过接口调用方法很慢，所以答案是：由于性能原因。