Project

General

Profile

Actions

Feature #14575

closed

Switch Range#=== to use cover? instead of include?

Added by zverok (Victor Shepelev) over 6 years ago. Updated over 6 years ago.

Status:
Closed
Target version:
[ruby-core:85918]

Description

This is a conscious duplicate of the bug I've created more than a year ago. I believe that the previous one was rejected too easy, mostly due to the fact I haven't provided enough evidence to support my proposal. I also believe that writing the new, better-grounded proposal would be more visible than adding more comments to the rejected ticket.

The problem: Range#=== (used in case and grep) uses include? to check the value against the range, which could be:
a) really ineffective or b) simply unavailable.

Here are real-life and real-life-alike examples of types that suffer from the problem:

  • ipaddress IPAddress("172.16.10.1")..IPAddress("172.16.11.255"): it is really readable to describe in some server config "for this range allow this, for that range allow that", yet it could be fascinatingly slow, calculating thousands of IPs inside range just to check with include?;
  • Measurement units: (Unitwise(1, 'm')...Unitwise(10, 'm')) === Unitwise(5, 'm') throws "can't iterate from Unitwise::Measurement", which is reasonable: there is no .succ for numeric types; Ruby itself has an ugly workaround of "if this is a numeric type, behave like cover?"
  • Dates and times: (Date.today..Date.today + 1) === DateTime.now is false; it is hard to imagine code where it is a desired behavior.

Matz's objections to the previous ticket were:

I see no real-world use-case for Range#=== with strings. (Because I have provided only string ranges example initially -- VS)

That is addressed, hopefully, with the new set of examples.

Besides that, using cover? behavior for [string] ranges would introduce incompatibility.

I don't know how to estimate amount of incompatibilities introduced by this behavior change.
Yet it is really hard (for me) to invent some reasonable real-life use case which could be broken by it.


Related issues 3 (0 open3 closed)

Related to Ruby master - Feature #12996: Optimize Range#===ClosedActions
Related to Ruby master - Bug #19080: String Range inclusion using `===` brokenRejectedActions
Is duplicate of Ruby master - Feature #12612: Switch Range#=== to use cover? instead of include?RejectedActions
Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0