Project

General

Profile

Actions

Bug #16165

closed

Endless ranges have inconsistency between #cover? and #include?

Added by adh1003 (Andrew Hodgkinson) about 5 years ago. Updated about 5 years ago.

Status:
Closed
Assignee:
-
Target version:
-
ruby -v:
2.6.4p104 (2019-08-28 revision 67798) [x86_64-darwin18]
[ruby-core:94911]

Description

In an endless Range, I'd expect to be able to use #include? just as I do with a Range that has an end value. It would amount to just a check on whether the argument was greater than or equal to the start value of that Range (and likewise, if "startless" ranges are eventually supported, it'd just be a check on the Range's end value, or if it were possibly to have both a startless and endless Range, always return true).

In Ruby 2.6.4, behaviour is unexpected. I "need to know" if a Range is endless and implement the check myself, because using #include? results in RangeError (cannot get the last element of endless range). The reason this feels like a bug, apart from being merely unhelpful, is because #cover? accepts a single value rather than a Range too - and this behaves exactly as we might expect. I can ask if (1..).cover?(0) and get false, or (1..).cover?(2000) and get true, just like I'd expect.

It's weird that #cover? works, but #include? throws an unusual exception. In my particular use case I have an array of Ranges for various periods of time that typically terminates in an endless Range for "everything afterwards". Being able to write clear, simple code that treats each of these the same to see if a given discrete time falls into a particular time "bucket" is obviously valuable. It'd be ugly to have to check each time to see if a given Range was endless and treat it specially, just because #include? would otherwise raise an exception. In this case, at least, #cover? comes to the rescue :-)

If there's a general agreement that this should be a thing, I could look into producing a patch to have #include? be a bit better behaved when dealing with endless ranges.

Actions #1

Updated by adh1003 (Andrew Hodgkinson) about 5 years ago

  • Description updated (diff)
Actions #2

Updated by adh1003 (Andrew Hodgkinson) about 5 years ago

  • Description updated (diff)

Updated by adh1003 (Andrew Hodgkinson) about 5 years ago

Doh, this needs closing; my apologies. I had not realised that I was testing in an execution environment that had pulled in ActiveSupport from Rails 6. This seems to break #include? in an endless Range. When I'm careful to use "vanilla" irb alone to try it on the CLI, the method behaves entirely as expected.

I'll raise the issue with the Rails team, if there isn't a matching issue already.

Updated by mame (Yusuke Endoh) about 5 years ago

  • Status changed from Open to Closed

Closing as per your request. Thank you for your investigation anyway.

Updated by adh1003 (Andrew Hodgkinson) about 5 years ago

For the sake of archives & potential future search engine hits - this got fixed a few days ago and will be in whatever public release of Rails comes after 6.0.0.

https://github.com/rails/rails/pull/36460

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0