Feature #5798

Range#include? needs some optimization

Added by yimutang (Joey Zhou) over 6 years ago. Updated 5 months ago.

Target version:


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.


#1 Updated by alexeymuranov (Alexey Muranov) over 6 years ago

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.

#2 [ruby-core:41804] Updated by alexeymuranov (Alexey Muranov) over 6 years ago

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

=> true

#3 Updated by ko1 (Koichi Sasada) about 6 years ago

  • Tracker changed from Bug to Feature

#4 [ruby-core:43804] Updated by mame (Yusuke Endoh) about 6 years ago

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

#5 Updated by mame (Yusuke Endoh) over 5 years ago

  • Target version set to 2.6

#6 Updated by naruse (Yui NARUSE) 5 months ago

  • Target version deleted (2.6)

Also available in: Atom PDF