Krzysztof reminded me yesterday that

An enumerator remains valid as long as the collection remains unchanged. If changes are made to the collection, such as adding, modifying or deleting elements, the enumerator is irrecoverably invalidated and the next call to MoveNext or Reset throws an InvalidOperationException.

(For some reason, I can't locate the ECMA BCL standard to find what it says about this situation, and unfortunately don't have my SLAR book with me. The previous excerpt was taken from the MSDN documentation of the IEnumerator interface.)

Given my earlier use of iterators to incrementally execute and return results from an algorithm, I wonder what impact this requirement has? Does it have an impact? I guess my confusion comes from not understanding if this is simply a documented optional behavior, or if it is a semantic constraint by the ECMA specification. The C# compiler is responsible for baking up such IEnumerator implementations from a given iterator, which has the indirect effect of requiring that people implementing iterators toss an InvalidOperationException from their iterator methods under certain circumstances. I'm not sure if this is very evident.

If the sequence to be calculated changes sometime after the IEnumerator creation, does this trigger an exception? How would we possibly recognize this situation? If the algorithm relies on input variables, all of which are locked down at the construction of our IEnumerable, this may be good enough; but, what if the nature of the algorithm is such that it relies on realtime input or needs to access input which cannot be copied or locked at creation? For example, one could imagine an iterator which uses sensor data that is read as quickly as the program can consume; a foreach loop is used to consume the data, while an iterator provides a reading when it is asked for the next value.

Unfortunately, I guess I have more answers than questions right now. Comments, answers, etc. would be great!