Bug #19080: String Range inclusion using `===` broken

• Status: Rejected
• Assignee: -
• Target version: -
• ruby -v: 3.1.0
• Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN

[baweaver (Brandon Weaver)]

When using === implicitly for a pattern match I noticed a behavior which I believe is a bug in Ruby. === does not match with include? for ranges of String types, but also does so inconsistently:

range = '0'..'255'

('1'..'5').map do |v|
  {
    v: v,
    teq: range === v,
    include?: range.include?(v)
  }
end
#  => [
#   { v: "1", teq: true, include?: true },
#   { v: "2", teq: true, include?: true },
#   { v: "3", teq: false, include?: true },
#   { v: "4", teq: false, include?: true },
#   { v: "5", teq: false, include?: true }
# ]

# But numbers work??
range = 0..255

(1..5).map do |v|
  {
    v: v,
    teq: range === v,
    include?: range.include?(v)
  }
end
# => [
#   { v: 1, teq: true, include?: true},
#   { v: 2, teq: true, include?: true},
#   { v: 3, teq: true, include?: true},
#   { v: 4, teq: true, include?: true},
#   { v: 5, teq: true, include?: true}
# ]

Am I doing something wrong? This does not feel like it is working as expected. I might dig through the C code to see how this is implemented and why this happens, but am currently confused by it.

[baweaver (Brandon Weaver)]

I've found this which illustrates that it uses String#cover? but that's really confusing for me at least:

https://stackoverflow.com/questions/67234283/why-is-the-string-3-not-matched-in-a-case-statement-with-the-range-0-10/67234587#67234587

Would it be worth updating the documentation here to reflect this?:

https://ruby-doc.org/core-3.1.2/Range.html#method-i-3D-3D-3D

[sawa (Tsuyoshi Sawada)]

You need to zero-pad the strings in order to compare them correctly by the number they express. It is an advanced thing, and people without appropriate knowledge would/should not try doing it.

[byroot (Jean Boussier)]

• Related to Feature #14575: Switch Range#=== to use cover? instead of include? added

[zverok (Victor Shepelev)]

=== uses #cover?, as it should be.
See #14575 and #15449.

The documentation for #=== says "if object is between self.begin and self.end," which means >= and <=, but I agree that it could be clearer (because one might conclude it is in enumeration sense).

Some inconsistency between #include? and #cover? is inherent for String (considering that strung.succ's behavior that will enumerate through values that are < than the begin in the comparison sense), but for most practical purposes, #cover? is the superior implementation for #===.

[byroot (Jean Boussier)]

• Status changed from Open to Rejected

CLosing as not a bug given it's doing what it is designed to do.

If you feel like you can imporve the documentation, feel free to open a PR on GitHub, these are always welcome.

If you think there's another behavior that would be preferable and that wouldn't be too backward incompatible, you can submit a feature request.