Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Relax RangeMap::overlapping to allow infinite ranges as query? #97

Open
MultisampledNight opened this issue Oct 4, 2024 · 1 comment

Comments

@MultisampledNight
Copy link

Problem

I have a RangeSet that holds ranges of datetimes to denote when an event is happening.
I'd like to query for a relative index after some time point, e.g. "get the 3rd event after 2024-10-04".
This requires specifying a range with an unbounded side if the index is not known ahead-of-time.

At a first glance, RangeSet::overlapping is perfect for this! However, it only accepts finite ranges, not infinite ones.

Intended solution

Replace the R: Borrow<Range<T>> bound in Range{,Inclusive}{Map,Set}::overlapping with R: RangeBounds<T>.

Possible workaround

Call RangeSet::overlapping with the extreme value the key can hold as a replacement for the unbounded side. In effect, for example:

  • Replace upper unbound with maximum excluded: set.overlapping(4..)set.overlapping(4..i32::MAX).
  • Replace lower unbound with minimum included: set.overlapping(..4) → set.overlapping(i32::MIN..4)

This is also the workaround I'll head to for now, and tbh I can't think of a case where it wouldn't work (but i only thought like 3 seconds about it sooo there might be something i missed).

(Sidenote: thanks for the wonderful library! :3)

@ripytide
Copy link

ripytide commented Oct 4, 2024

The workaround of using the maximum value is the correct call in my opinion. I say this after trying out the RangeBounds idea you mentioned a couple of years ago, I made a PR here but then made my own crate for it which used RangeBounds but then eventually I found that it was unnecessary complexity and that just using the maximum values when needed is perfectly fine for all situations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants