Enumerator::ArithmeticSequence missing allocator for #clone and #dup
In Ruby 2.5, with an Enumerator:
1.step.clone #=> Enumerator
In Ruby 2.6, with an Enumerator::ArithmeticSequence:
1.step.clone #!> TypeError (allocator undefined for Enumerator::ArithmeticSequence)
I've gotten around it in 2.6 and 2.7 by checking if an enum is an ArithmeticSequence and reconstituting a new one if so:
Range.new(enum.begin, enum.end, enum.exclude_end?) % enum.step
Instead of cloning:
I filed this as a bug rather than feature, since it seemed like a breaking change and I wasn't sure if it was intentional. Thank you!
Updated by shan (Shannon Skipper) over 3 years ago
After I filed this, al203-cr on #ruby IRC pointed out this seems intentional since
rb_undef_alloc_func(rb_cArithSeq); is manually undefined here: https://github.com/ruby/ruby/blob/v2_7_1/enumerator.c#L4068
Treating it as immutable makes sense to me, since an ArithmeticSequence's begin/end/exclude_end?/step can't be mutated without Fiddle. It just surprised me, since they're not frozen.
1.step.frozen? #=> false
Should an ArithmeticSequence be frozen or cloneable?
Updated by jeremyevans0 (Jeremy Evans) over 3 years ago
- Tracker changed from Bug to Feature
- ruby -v deleted (
ruby 2.6.6p146 (2020-03-31 revision 67876) [x86_64-darwin19])
- Backport deleted (
2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN)
ArithmeticSequence.allocate being undefined was definitely a deliberate change in 25a5227ab188b940d8bbc291bf4c9d62e5d63163.
I'm not sure that breaking
clone was expected. In general for frozen objects, I think
freeze: false should
return self. However, that's currently how Ruby works.