Support RangeBounds for T: Comparable

[al8n]

Hi, this PR adds functionality like RangeBounds::contains for T: Comparable.

[cuviper]

I think having a separate trait will make this awkward to use, because that's an additional constraint on the range type that you'd have to propagate in API. How about something like this added to Comparable (with a default impl):

    fn compare_contains<R: RangeBounds<Self>>(range: R, key: &K) -> bool;

It will be more awkward to use without the self receiver though, so I'm not sure this is better -- just an alternative to consider.

This would also keep the "direction" consistent, like my other comment.

[cuviper]

What is the intended use case? If it's something like BTreeMap::range, then I think the relationship should be the other way, T: Comparable<U>, or in map terms it's RangeBounds<Q> and Q: Comparable<K>.

[al8n]

The intended use case is most like a BTreeMap, I need something like

fn foo<R, Q>(&self,  key: &K) 
where
  R: RangeBounds<Q>,
  Q: ?Sized + Comparable<K>
{
  if self.range.comparable_contains(key) { }
}

[al8n]

I think having a separate trait will make this awkward to use, because that's an additional constraint on the range type that you'd have to propagate in API. How about something like this added to Comparable (with a default impl):

    fn compare_contains<R: RangeBounds<Self>>(range: R, key: &K) -> bool;

It will be more awkward to use without the self receiver though, so I'm not sure this is better -- just an alternative to consider.

This would also keep the "direction" consistent, like my other comment.

Yeah, another trait will require users to import it, but if there is no self receiver, the code should be something like Comparable::compare_contains(range, key). It is hard to assess which one is better.

[cuviper]

Yeah, another trait will require users to import it,

Hmm, my thought was more that you would have to add the trait as a constraint in your public API, but I guess that's not true -- with the blanket impl, you can still use it as long as RangeBounds and Comparable are met independently. So this is really a pure extension trait for convenience, and doesn't need any API-visible change.

but if there is no self receiver, the code should be something like Comparable::compare_contains(range, key).

Yes, or I'd write Q::compare_contains(range, key). But with my realization above, I think your way is better.