= Solution
\b[Yes in special cases; an ordinary finite <iterator> that progresses through its input needs changing consumption state.] For a genuine immutable <counterexample>, an <iterator> over an infinite constant <sequence> needs no changing fields:
``
final class Ones extends Iterator[Int] {
def hasNext: Boolean = true
def next(): Int = 1
}
``
Removing the first entry of that <sequence> leaves the same <sequence>, so this satisfies the <iterator> behaviour without changing object state. A permanently empty <iterator> is another example.
For a normal finite nonempty traversal, however, repeated `next()` calls must eventually change the returned entry or availability, so the implementation needs mutable cursor state somewhere. Declaring only `val` fields is not a proof of deep immutability: those fields can refer to another mutable <iterator>, an <array>, or a stateful closure. The standard API's description of <iterators> as mutable captures the usual consuming case, rather than enforcing a mutable field in every possible implementation.
Back to article page
