The choice of the default is a design decision, with valid arguments for both options. That said, with limited time before release, I'll err on the safe side and prioritize compatibility by reverting to the original default of infinity.knu (Akinori MUSHA)
mame (Yusuke Endoh) wrote in #note-26: > If we do so, I believe `Enumerator#size` should be deprecated and renamed to something like `Enumerator#size_hint` or `Enumerator#size_estimate`. > ... I think size is and will always be an esti...knu (Akinori MUSHA)
The point of this discussion is that fixing the "bug" broke compatibility, and we are comparing the impacts. That "bug" can or should be properly fixed by changing the code to `Enumerator.produce(1, size: nil) { raise StopIteration }.la...knu (Akinori MUSHA)
mame (Yusuke Endoh) wrote in #note-16: > What problem do you have if the size is `nil`? Among others, `Enumerator.produce(1) { it+1 }.lazy.take(5)` now returns nil, which returned 5 previously. https://github.com/ruby/ruby/blob/6b...knu (Akinori MUSHA)
I'm leaning toward doing these: - Removing the Enumerator#to_set override that refuses to work against an infinite enumerator as a safeguard - Reverting the default size of Enumerator.produce from nil to infinity This way we can g...knu (Akinori MUSHA)
zverok (Victor Shepelev) wrote in #note-7: > 2) Somebody uses `Enumerator.produce` alongside other types of enumerators. In some branch of their code, they do `raise "Can't do this operation" if enum.size == Float::INFINITY`. The compati...knu (Akinori MUSHA)
zverok (Victor Shepelev) wrote in #note-7: > TBH, I don't see the compatibility argument applied with any consistency here. > ... This is where you are mistaken. - Ruby 3.4.7 ```shellsession % ruby -ve 'e=Enumerator.produce(1) {it>...knu (Akinori MUSHA)