Feature #17195


Freeze Enumerator::ArithmeticSequence objects

Added by Eregon (Benoit Daloze) about 3 years ago. Updated almost 3 years ago.

Target version:


Now, all Ranges are frozen (#15504).

Enumerator::ArithmeticSequence is very similar to Range, just with an extra step.
They're essentially already immutable, except that one could use set instance variables, but it seems of little use.

So, should we make Enumerator::ArithmeticSequence frozen too?

Related issues 1 (0 open1 closed)

Related to Ruby master - Feature #15504: Freeze all Range objectsClosedmatz (Yukihiro Matsumoto)Actions
Actions #1

Updated by Eregon (Benoit Daloze) about 3 years ago

Updated by Eregon (Benoit Daloze) about 3 years ago

I just realized, this is problematic because Enumerator::ArithmeticSequence is a subclass of Enumerator and not of Range.
If it was a subclass of Range then I think it would be fine to freeze it.

But since it subclasses Enumerator, it has mutating methods like Enumerator#next:

[7] pry(main)> enum = (1..5).step(2)
=> ((1..5).step(2))
[8] pry(main)>
=> 1
[9] pry(main)>
=> 3
[10] pry(main)>
=> 5
[11] pry(main)>
StopIteration: iteration reached an end
from (pry):11:in `next'

@mrkn (Kenta Murata) do you remember why ArithmeticSequence is an Enumerator subclass and not a Range subclass?

Updated by mrkn (Kenta Murata) almost 3 years ago

The reason why ArithmeticSequence is a subclass of Enumerator is for conserving the compatibility of the return types of Range#step and Numeric#step.

Updated by Eregon (Benoit Daloze) almost 3 years ago

  • Status changed from Open to Rejected

Right, that makes sense, thanks for the reply.

Interestingly it seems Enumerator#next is still allowed even if the Enumerator is frozen, even though it is a kind of mutation.
I think that's a bug.

Given ArithmeticSequence has state through being an Enumerator, I think it's not reasonable to freeze, so I'll reject this issue.


Also available in: Atom PDF