title: Why do BCL Collections use struct enumerators, not classes?
body: <p>We all know <a href="https://ericlippert.com/2008/05/14/mutating-readonly-structs/" rel="nofollow noreferrer">mutable structs are evil</a> in general. I'm also pretty sure that because <code>IEnumerable&lt;T&gt;.GetEnumerator()</code> returns type <code>IEnumerator&lt;T&gt;</code>, the structs are immediately boxed into a reference type, costing more than if they were simply reference types to begin with.</p>
  <p>So why, in the BCL generic collections, are all the enumerators mutable structs? Surely there had to have been a good reason. The only thing that occurs to me is that structs can be copied easily, thus preserving the enumerator state at an arbitrary point. But adding a <code>Copy()</code> method to the <code>IEnumerator</code> interface would have been less troublesome, so I don't see this as being a logical justification on its own.</p>
  <p>Even if I don't agree with a design decision, I would like to be able to understand the reasoning behind it.</p>