Issue #19632 has been updated by make_now_just (Hiroya Fujinami). If a result value is not stored, `peek` invokes the iterator and stores it in its internal state. For that reason, I consider `peek` is also a mutable method like `next`. If you call `peek` in advance and then call `freeze`, `peek` will not change the internal state. IMHO, this case is exceptional and should still raise a `FrozenError` for simplicity. However, I would follow matz's decision. ---------------------------------------- Bug #19632: Disable external iterator for frozen enumerator https://bugs.ruby-lang.org/issues/19632#change-103047 * Author: make_now_just (Hiroya Fujinami) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Currently, methods to manipulate an external iterator like `#next` and `#feed` can be called even if a receiver of an enumerator is frozen. However, these methods change the state of an external iterator in an enumerator. Therefore, it seems a BUG to me, and these methods should raise FrozenError if the receiver is frozen. ```ruby e = 3.times.freeze # Current e.next # => 1 e.next # => 2 # Expected e.next # raise FrozenError ``` Two years ago, this issue was mentioned in [a comment](https://bugs.ruby-lang.org/issues/17195#note-5). I suggest fixing the following methods to raise FrozenError against a frozen enumerator. - `Enumerator#next` - `Enumerator#next_values` - `Enumerator#peek` - `Enumerator#peek_values` - `Enumerator#feed` - `Enumerator#rewind` Also, even if an enumerator is frozen, it does not affect other methods for internal iterators. -- https://bugs.ruby-lang.org/