I would think that Iterator.copy()
would be quite a handy function. You could implement iterator filters in a much better way.
For example, the only reason in Googles Java Collection for the filter
(and similar) functions to use UnmodifiableIterator
(which is just an Iterator
without remove
) is because you cannot implement such a filter Iterator
otherwise without being able to copy it at some point. (Really, that is not possible with the current interface; try yourself.)
Another advantage would be that you could use an iterator in a for-each-loop: Because a copy-able iterator would automatically also be iterable. See also this question. Right now, the main design reason to not allow this is because an Iterator
which implements Iterable
and Iterator<T> iterator() { return this; }
would invalidate the iterator. By having a copy
function, it is as simple as Iterator<T> iterator() { return copy(); }
and it would not invalidate the original iterator. Thus there is no reason anymore to not allow this.
Is there any reason? Just to make it less complicated to implement it?
Although they usually are, Iterators do not theoretically have to be linked to a collection. The copy method over an input stream, for instance, would be difficult to implement, and would very easily cause obscure memory problems.