Issue #11113 has been updated by Myron Marston.
> The "can't iterate" error is simply because Time is float-based: there is no succ number.
Floats don't have a `succ` method, and yet `(2.3...3.2) === 3.0` works just fine. Actually, I'm surprised that `succ` is used for `===` at all...it implies that `===` is a `O(N)` operation over the size of the range. Seems like something like `range.begin < other && range.end > other` would perform better (constant time) and avoid this problem. I haven't looked into the implementation of `cover?` but is that basically what it does internally?
----------------------------------------
Bug #11113: Time ranges cannot be used in case statements in 1.9+ but they could in 1.8.7
https://bugs.ruby-lang.org/issues/11113#change-52308
* Author: Myron Marston
* Status: Open
* Priority: Normal
* Assignee:
* ruby -v: 1.9.2, 1.9.3, 2.0, 2.1, 2.2
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN
----------------------------------------
Given this script:
```ruby
range = (Time.now - 1000)...(Time.now + 1000)
case Time.now
when range then puts "in range"
else puts "not in range"
end
```
I'd expect it to print "in range". This worked on 1.8.7:
```
$ ruby -v time_range_problem.rb
ruby 1.8.7 (2013-12-22 patchlevel 375) [i686-darwin12.5.0]
in range
```
...but raises an exception in 1.9.2, 1.9.3, 2.0, 2.1 and 2.2:
```
time_range_problem.rb:4:in `each': can't iterate from Time (TypeError)
from time_range_problem.rb:4:in `include?'
from time_range_problem.rb:4:in `include?'
from time_range_problem.rb:4:in `==='
from time_range_problem.rb:4:in `<main>'
```
It looks like `Range#===` is broken. Given that `===` is a standard ruby protocol, I would not expect a built-in type to raise an error like this. IMO, `===` should either return true or false but should not raise an error. We rely upon `===` in RSpec to do matching and this behavior means that if users pass us a time range, things blow up. See https://github.com/rspec/rspec-mocks/issues/938 for an example.
--
https://bugs.ruby-lang.org/