3 bugs with Lazy enumerators with state
I found the following 3 bugs with Lazy#drop, drop_while and zip:
drop = (1..4).lazy.drop(2) drop.to_a # => [3, 4] drop.to_a # => [1, 2, 3, 4], should be same as above drop_while = (1..4).lazy.drop_while(&:odd?) drop_while.to_a # => [2, 3, 4] drop_while.to_a # => [1, 2, 3, 4], should be same as above zip = (1..2).lazy.zip([3, 4]) # or (3..4) zip.to_a # => [[1, 3], [2, 4]] zip.to_a # => [[1, nil], [2, nil]] should be same as above
I found them when writing a Ruby implementation of Enumerator::Lazy.
My implementation created the same bug with #take as described in https://bugs.ruby-lang.org/issues/6428.
This made me realize that the api of Lazy.new makes it near impossible to write most lazy enumerators requiring a state, as there is no general way to reset that state.
When looking at my code, I used a state for drop, drop_while and zip. A quick verification showed me that the MRI implementation also has the same bugs!gene
So the meta question is: should there not be a general way to initialize the state of the lazy enum?
#1 Updated by Marc-Andre Lafortune over 3 years ago
- Status changed from Open to Closed
- % Done changed from 0 to 100