Feature #5798: Range#include? needs some optimization

• Status: Rejected
• Assignee: matz (Yukihiro Matsumoto)
• Target version: -

[yimutang (Joey Zhou)]

For example:

('aa'..'az').include? 123

it seems that the procedure is:

1. check whether 'aa' == 123 # false
2. 'aa'.succ # 'ab'
3. check whether 'ab' == 123 # false
4. 'ab'.succ # 'ac'
5. check whether 'ac' == 123 # false
   ...
   n-1. 'ay'.succ # 'az'
   n. check whether 'az' == 123 # false
   finally return false

However, 'aa' and 123 are not the same class. It's not necessary to take the whole steps of 'succ' and '=='.
Maybe it should check 'aa'.class and 123.class first, or use <=> instead of == to check, when 'aa' <=> 123 returns nil(== only returns true/false, no nil), the procedure breaks.

[alexeymuranov (Alexey Muranov)]

There is method Range#cover? for this. Range#include? is inherited from Enumerable module, so you are proposing to redefine it inside the class.

This being said, i also had a somewhat related proposal here: #5534. I suggested to basically treat Ranges as infinite sets, and define their methods accordingly. I think however that the "enumerable" part of behavior of range probably does not need to be changed.

[alexeymuranov (Alexey Muranov)]

I agree that the behavior you point out seems inconsistent, because

(0..1).include?(0.5)
=> true

[ko1 (Koichi Sasada)]

• Tracker changed from Bug to Feature

[mame (Yusuke Endoh)]

• Status changed from Open to Assigned
• Assignee set to matz (Yukihiro Matsumoto)

[mame (Yusuke Endoh)]

• Target version set to 2.6

[naruse (Yui NARUSE)]

• Target version deleted (2.6)

[mame (Yusuke Endoh)]

• Status changed from Assigned to Rejected

Joey: Please use Range#cover?, as alexeymuranov. In Ruby 2.6, Range#=== will be also equivalent to Range#cover?. [Feature #14575]

Alexey: Range is chaos. It has many inconsistencies. If you think it is really what to be fixed, please open another ticket.