c# - 为什么 BCL Collections 使用结构体枚举器，而不是类？

Question

我们都知道mutable structs are evil一般来说。我也很确定，因为 IEnumerable<T>.GetEnumerator()返回类型 IEnumerator<T> ，这些结构会立即装入引用类型，这比它们一开始只是引用类型的成本更高。

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

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

Answer 1

确实是为了性能考虑。 BCL 团队在这一点上做了很多的研究，然后才决定采用您正确称之为可疑和危险的做法:使用可变值类型。

你问为什么这不会导致装箱。这是因为 C# 编译器不会生成代码以在 foreach 循环中将内容装箱到 IEnumerable 或 IEnumerator(如果可以避免的话)!

当我们看到

foreach(X x in c)

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

这有两个理想的效果。

首先，如果集合是 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 是一个只读字段，您可能会合理地期望编译器会做它所做的事情:make a copy, and mutate the copy为了确保该方法不会丢弃需要处理的值中的东西。

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

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

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

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

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

• 但如果它是一个提升的局部变量(因为它是匿名函数的封闭变量或在迭代器 block 中)，那么局部变量实际上是生成为只读字段，然后确保副本发生突变的装置接管。

不幸的是，规范在这个问题上提供的指导很少。很明显，有些东西坏了，因为我们的做法不一致，但根本不清楚什么是正确的。