`Eq` requirement for `V`

[rongcuid]

Is Eq really needed for the value type? Std maps like HashMap and BTreeMap does not pose any assumptions on the values except when implementing PartialEq and Eq, respectively.

[ripytide]

I think it's needed for the insert() method to decide whether to coalesce adjacent or overlapping ranges. Which doesn't apply to BTreeMap or HashMap.

[rongcuid]

But what about values that don't implement Eq? Implementation aside, would it still be a valid range map?

[ripytide]

You could indeed have a valid range map even if the value doesn't implement Eq range_bounds_map allows this for example.

[jeffparsons]

Thanks for answering this, @ripytide.

I do plan to make coalescing (and therefore the Eq bound) opt-in eventually, but I can't promise any timelines at the moment.

[wcoenraads]

Would it be possible to loosen the Eq requirement to PartialEq? I want to store floats, which don't implement Eq but do implement PartialEq. I imagine this wouldn't be a ton of work (correct me if I'm wrong!) and would allow significantly more types to be stored, since usually any type that stores a float somewhere doesn't implement Eq.

[jeffparsons]

@wcoenraads Yes, that sounds like it should be safe to change. Interested in making a PR?

[wcoenraads]

Sure! I'll try to whip something up this afternoon. 😄

[jeffparsons]

Relaxed the bound on V to be only PartialEq. Published in 1.7.0