Issue #15807 has been updated by janosch-x (Janosch M=FCller).


jeremyevans0 (Jeremy Evans) wrote:
> I think this is a bug we should fix, even if it breaks code relying on th=
is bug ("all bug fixes are incompatibilities" :)).

Yes, it is a bit reminiscent of https://xkcd.com/1172/ :)

> Does anyone have an opinion on whether `minmax` should call overridden `m=
in` and `max` methods?  Or do we expect if you override `min` or `max`, you=
 should also override `minmax`?  I don't have a strong opinion either way.

Other classes including Enumerable also require `minmax` to be overridden i=
ndividually. `Set` or `SortedSet` are examples from the stdlib. So I guess =
it would be more consistent to call the C functions.


----------------------------------------
Bug #15807: Range#minmax is slow and never returns for endless ranges
https://bugs.ruby-lang.org/issues/15807#change-78599

* Author: janosch-x (Janosch M=FCller)
* Status: Open
* Priority: Normal
* Assignee: =

* Target version: =

* ruby -v: 2.6.3p62
* Backport: 2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN
----------------------------------------
current situation:

- `(1..).minmax` runs forever
- `(1..).max` raises "cannot get the maximum of endless range"
- `(1..Float::INFINITY).minmax` runs forever
- `(1..Float::INFINITY).max` returns instantly
- `(1..1_000_000_000).minmax` takes one minute
- `(1..1_000_000_000).max` returns instantly

my suggestion:

- implement `minmax` in range.c, return [`range_min`, `range_max`]
- for endless ranges, this will trigger the same error as `max` does
- delegate to enum (rb_call_super) only if called with a block (?)

i could perhaps provide a PR if you can point me to some information on how=
 to contribute.

cheers!

---Files--------------------------------
range-minmax.patch (2.89 KB)


-- =

https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=3Dunsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>