Why doesn't .NET have a bidirectional enumerator?

Question

It's been asked a couple of times on SO how you can implement a bidirectional enumerator (http://stackoverflow.com/questions/191788/two-directional-list-enumerator-in-net, http://stackoverflow.com/questions/451099/implementing-a-bidirectional-enumerator-in-c). My question is not how (which is trivial for most cases), but why no such type exists in the .NET platform.

public interface IBidirectionalEnumerator<T> : IEnumerator<T>
{
    bool MovePrev();
}

Obviously, there are many collection types which can't implement this, as MoveNext() is destructive or changes the state of the underlying collection. But conversely, many types can implement this trivially (List, IList, LinkedList, arrays). So why does no such type exist?

Answer 1

Because either nobody thought about it, or nobody thought that it would be particularly useful or because there was not enough budget or...

It's not really necessary, is it? You can easily implement it yourself. Maybe the BCL team thought it was not worth the pain of implementing, testing, documenting etc. Never underestimate the cost of a feature, it may sound "easy", but it does have costs.

Particulary because a single interface that nobody implements would seem strange, wouldn't it? You would expect List, Array etc. to implement the interface, which is quite a lot of work in the end.

Answer 2

Also, what would be the motivation for this? Language support for "backward" iteration?

The iterator pattern doesn't give much weight to the concept of "directionality" of a set of elements. It's a simple pattern for providing a simple interface for iterating over a set.

Answer 3

• IEnumerator supports the c# foreach statement as well as looping constructs of other languages.
• There is no statement or common programming idiom that IBidirectionalEnumerator enables.

Answer 4

When you are designing a framework, you have to make decisions about doing stuff at different abstraction levels. The trade-off is that if you choose to expose things at a high abstraction level, you'll achieve generalization at the cost of losing fine grained control over things. If you choose to expose stuff at lower abstraction levels, your concept will cannot be generalized as well but you can control details at a lower level.

It's a design decision. Implementing both will be costly and make framework more bloated and you'll need to support both when adding features. You'll need to preserve backward compatibility in the future. It's not a wise thing to add everything you can think of to the BCL without making sure it has a significant benefit.

Answer 5

Obviously, there are many collection types which can't implement this, as MoveNext() is destructive or changes the state of the underlying collection.

MoveNext() is non-destructive. In fact, if the state of the underlying collection is changed between the time that the IEnumerator was created and the time MoveNext() is called, the call to MoveNext() will fail.

The purpose of IEnumerator is to iterate over all of the items in a collection once, in the collection's native order if the collection has a native order. IEnumerator is not intended as a collection-navigation device, such as one might find in C++.