add Range.overlaps(Range) method

[bemace]

Seems very strange that the Range class doesn't have an overlaps(Range) or intersects(Range) method.

I expect it would essentially be

public boolean overlaps(Range other) {
    return isConnected(other) && !intersection(other).isEmpty();
}

[lowasser]

This is difficult without a DiscreteDomain. Your current implementation would treat [0, 1) and (0, 1] as overlapping, even though there aren't actually any integers in their intersection.

[cpovirk]

I see 32 hits in Google code for isConnected[^;{}]*intersection[^;{}]*isEmpty (PCRE:yes, exclude com/google/common/collect). I wonder if these are worth a look, either as evidence for the usefulness of the method or evidence that the approach is bug-prone.

[arustleund]

I've made this call several times in my own code when dealing with ranges. Ranges that are part of a DiscreteDomain deserve special consideration. As this method is mostly a convenience to save code and increase readability, perhaps two versions of the method, one for DiscreteDomain Ranges, and one for non-discrete? The method for DiscreteDomain ranges could canonicalize the ranges sent in and the caller would get their expected result. The non-discrete method could do the connected/intersection call as-is. Otherwise, a single method with a clear API documentation would be nice as well. Either way, I think it's a method that would see some use and I would love to see it added.

[jwgmeligmeyling]

Would be very useful! We're using isConnected(other) && !intersection(other).isEmpty() too (for Range<LocalDateTime>)

[hden]

FYI This is how PostgreSQL compares ranges

https://github.com/postgres/postgres/blob/a77315fdf2a197a925e670be2d8b376c4ac02efc/src/backend/utils/adt/rangetypes.c#L823-L854

[ayushsangani]

Is there any plan to implement overlap method on Range?

[alwinlin23]

so, is it done now?
if not, i'm current coming into the same problem and very glad to contribute my implementation
@cpovirk

[malcolmr]

fwiw, I just went looking for this again myself after reviewing another piece of code that could have benefited from this.

Given that there clearly is a demand for this functionality (I now see ~100 references in Google's code using @cpovirk's regexp from above), I think it would make sense to introduce an overlaps() method as shown in the first comment above, given that that's what people are writing anyway.

It is true that that implementation will consider [n, n+1) as overlapping with (n, n+1], but I don't think that should necessarily be a blocker. Often we know that that situation would be impossible at the callsite (e.g. because both ranges have closed lower endpoints), so my personal preference would be just to document that case, in the same way that we already document that isEmpty() returns false for ranges of the form (n, n+1) even though there's no possible c for which contains(c) returns true.

Alternatively we could add a precondition to enforce that the intersecting range won't be bounded by finite open endpoints on both sides (which I believe is the only way to run into this), albeit that's a little harder to document as a precondition.

[Gosling-dude]

Opened #8649 for this, following @malcolmr's suggestion above.

Implementation is exactly isConnected(other) && !intersection(other).isEmpty().
The [n, n+1) vs (n, n+1] case is documented (treated as not overlapping, since the only range enclosed by both is empty) rather than enforced with a precondition.
Discrete-adjacent ranges like [3, 5] / [6, 10] are also documented, with a pointer to canonical(DiscreteDomain).
Added RangeTest.testOverlaps; marked @SInCE NEXT;

Happy to adjust the signature or Javadoc wording.