Feature #17195: Freeze Enumerator::ArithmeticSequence objects

• Status: Rejected
• Assignee: -
• Target version: -

[Eregon (Benoit Daloze)]

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?

[Eregon (Benoit Daloze)]

• Related to Feature #15504: Freeze all Range objects added

[marcandre (Marc-Andre Lafortune)]

Seems clear to me

[Eregon (Benoit Daloze)]

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)> enum.next
=> 1
[9] pry(main)> enum.next
=> 3
[10] pry(main)> enum.next
=> 5
[11] pry(main)> enum.next
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?

[mrkn (Kenta Murata)]

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

[Eregon (Benoit Daloze)]

• 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.