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


Thinking about this a bit more generally, I'm wondering whether `Enumerable=
#minmax` should actually use `rb_funcall` to get `min` and `max`.

This would fix the problem described in this issue.

But perhaps more importantly, it eliminates the trap of forgetting to imple=
ment `#minmax` whenever you override `#min` and/or `#max`.

Right now, `#minmax` is effectively broken for every case where `#min` and/=
or `#max` is overridden to optimize performance, to use custom checks, or t=
o return a custom value -- unless `#minmax` is also overridden with `def mi=
nmax; [min, max] end`.

As `Range` shows, arguably even ruby core coders have fallen into this trap=
 ...

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

* 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>