[ruby-core:99222] [Ruby master Bug#17017] Range#max & Range#minmax incorrectly use Float end as max

Issue #17017 has been updated by marcandre (Marc-Andre Lafortune).


jeremyevans0 (Jeremy Evans) wrote in #note-13:
> I've added a pull request to restore compatibility for Range#max with integer beginning and Float::Infinity end: https://github.com/ruby/ruby/pull/3326

Good, thanks.

> I think this pull request should require matz approval because it is a deliberate tradeoff of correctness in order to keep compatibility. The correct behavior should be raising RangeError, as that is what an endless range returns.

Well, `(1.0..).max` raises a `RangeError` while `(1.0..Float::INFINITY).max` returns `Float::INFINITY`; which is "correct"?

> If you would like matz to consider it, please bring it up for discussion at a future Ruby developers meeting.

I'm surprised by the lack of response from other Ruby committers.

Unless I'm mistaken, this behavior change was not approved by Matz (or anybody else), changes a behavior that dates back to Ruby 1.8, breaks (that we know of) `activemodel` and `rubocop`, doesn't even raise the right error and isn't tested, and is a change that I and others disapprove of. Yet when you propose that that commit remains as is and that someone else has to bring up the situation with Matz, no other committer seems confused by this.

I would love to have pointers on what I'm doing wrong. I've had a commit reverted twice in a row because a committer disagreed with me on a much smaller and obscure bug fix. I've endured verbal abuse. I've been reprimanded for not waiting to get the approval from Matz for committing an improvement to the wording of a warning (even though nobody thought the updated warning had any issue with it, or that it could potentially break any code out there). I envy you, and I really would like to understand 

----------------------------------------
Bug #17017: Range#max & Range#minmax incorrectly use Float end as max
https://bugs.ruby-lang.org/issues/17017#change-86603

* Author: sambostock (Sam Bostock)
* Status: Open
* Priority: Normal
* ruby -v: ruby 2.8.0dev (2020-07-14T04:19:55Z master e60cd14d85) [x86_64-darwin17]
* Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN
----------------------------------------
While continuing to add edge cases to [`Range#minmax` specs](https://github.com/ruby/spec/pull/777), I discovered the following bug:

```ruby
(1..3.1).to_a        == [1, 2, 3] # As expected

(1..3.1).to_a.max    == 3         # As expected
(1..3.1).to_a.minmax == [1, 3]    # As expected

(1..3.1).max    == 3.1            # Should be 3, as above
(1..3.1).minmax == [1, 3.1]       # Should be [1, 3], as above
```

One way to detect this scenario might be to do (whatever the C equivalent is of)

```ruby
range_end.is_a?(Numeric)                      // Is this a numeric range?
  && (range_end - range_begin).modulo(1) == 0 // Can we reach the range_end using the standard step size (1)
```

As for how to handle it, a couple options come to mind:

- We could error out and do something similar to what we do for exclusive ranges

```ruby
raise TypeError, 'cannot exclude non Integer end value'
```

- We might be able to calculate the range end by doing something like

```ruby
num_steps = (range_end / range_beg).to_i - 1 # one fewer steps than would exceed the range_end
max = range_beg + num_steps                  # take that many steps all at once
```

- We could delegate to `super` and enumerate the range to find the max

```ruby
super
```

- We could update the documentation to define the max for this case as the `range_end`, similarly to how the documentation for `include?` says it behaves like `cover?` for numeric ranges.



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

Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>