IEnumerator specification inconsistency?

In MSDN (August 2006) in the specification of IEnumerator.Current there
is word on exceptions. InvalidOperationException shall be thrown in case
"The collection was modified after the enumerator was created.". But in the
remarks section it can be read that "If the collection is modified between
MoveNext and Current, Current returns the element that it is set to, even if
the enumerator is already invalidated."
For me both this sentances seem to be contradictory. Or am I mistaken?
Also another intersting thing. IEnumerator<T> does not specify
exceptions at all. In remarks section it says only when Current is
undefined.

Framework doesn't seem to do checks at all.

Adam Badura

guffa
Sat Aug 18 19:38:17 CDT 2007

Adam Badura wrote:
> In MSDN (August 2006) in the specification of IEnumerator.Current there
> is word on exceptions. InvalidOperationException shall be thrown in case
> "The collection was modified after the enumerator was created.". But in the
> remarks section it can be read that "If the collection is modified between
> MoveNext and Current, Current returns the element that it is set to, even if
> the enumerator is already invalidated."
> For me both this sentances seem to be contradictory. Or am I mistaken?
> Also another intersting thing. IEnumerator<T> does not specify
> exceptions at all. In remarks section it says only when Current is
> undefined.
>
> Framework doesn't seem to do checks at all.
>
> Adam Badura

Yes, that is inconsistent. In the 1.1 version of the documentation, it's
consistent:

http://msdn2.microsoft.com/en-us/library/system.collections.ienumerator.current(VS.71).aspx

The implementation seems to follow the 1.1 version of the documentation.
If you for example look at the code for List<T>.Enumerator<T>.Current,
it only returns the current element without checking the list object
version:

public T Current {
get {
return this.current;
}
}

--
Göran Andersson
_____
http://www.guffa.com