Feature Request: Support RangeBounds.

[rljacobson]

Every std::ops::Range* struct implements std::ops::RangeBounds, which holds the endpoints of the range. The endpoints are std::ops::Bound<t>s:

pub enum Bound<T> {
    Included(T),
    Excluded(T),
    Unbounded,
}

Every possible kind of interval can be represented with this machinery: open, closed, half-open, unbounded on either or both ends, even degenerate intervals (singletons and null sets).

An argument against supporting anything other than inclusive ranges is, every numeric type is finite (including floats), and thus the topology of the type is discrete. In other words, for, say, floats, the half-open set [a, b) is precisely the same set as [a, b'] where b' is the largest representable float smaller than b.

My counterargument is that we use these sets to approximate continuous intervals and want them to have the semantics of the usual continuous topology on the reals. In other words, we wish to interpret [a, b) to include all of the numbers between b' and b, despite b being potentially approximate.

[spearman]

Thanks for the input, I can see how something like that could be useful in a math library, I've used 1D AABBs for something similar in collision libraries.

This library was originally written with discrete ranges in mind, primitive integers or types with Eq constraints, and with the intention of using it to represent "free-lists" of indices in contiguous storage. I'm not sure how much it would change the interface to relax the Eq constraint to a PartialEq to accommodate floats. If the type machinery in the generic version gets more complicated/harder to read, then I'd probably prefer to put it in a separate module.

I don't think I'm using this currently in anything upstream, so it's not going to be changing much in the near future, with that said anyone is welcome to submit pull requests =)