Make RangeMap and RangeSet generic over a RangeTrait instead of core::ops::Range

[ripytide]

This is my attempt at fixing #56

Important caveats:

• I deleted serde impls because they scared me as I haven't got much experience with serde impls yet
• I didn't touch RangeMapInclusive or RangeSetInclusive but I imagine the changover process would be roughly the same. I wanted to see what you thought before I went to far (also I don't need Inclusive for my usecases lol shh)

Some things worth noting:

• Some comments may have been invalidated, I didn't read any of them -_-
• I added impl<T> RangeTrait for Range<T> which is nice
• I made a new trait RangeTrait for the needed operations but there may exist a more standard version of RangeTrait somewhere rather than making our own
• Not sure whether we should keep RangeExt separate from RangeTrait or merge them
• Soooo many Bounds everywhere which makes me nervous that I over-bounded something somewhere, (I wish module-level bounds were a thing)

Questions I have

• What do ya think?
• Is the extra complexity of using a trait vs just using Ranges worth it? And if so I am happy to overhall the Inclusive variants to match.
• What do you think about using an associated type in the RangeTrait vs using a RangeTrait<I>? I went with the associated type version but not for any particular reason.
• Since you're in post v1.0 would this count as a breaking change?

[ripytide]

I have gone ahead and written a crate to fix this, and add some other features I was missing. range_bounds_map

[jeffparsons]

Hi @ripytide ,

Thanks for your PR, and sorry for not getting back to you.

I think for now I'd like to avoid changes of this size/scope, partly because we're post-1.0, and partly because I just don't have time to process it right now. So making your own crate sounds like a good idea. I'll be sure to check it out when I have time. 🙂

All that said, by total coincidence there's a really exciting PR open right now on the Rust repository: rust-lang/rust#105641

This is something I've been waiting on for a long time, because it should allow me to express a lot of things more cleanly and efficiently. Once that lands on nightly and I find some time, that might be a good time to consider other kinds of major changes as well.

[ripytide]

@jeffparsons I probably should have been slightly clearer, I wrote the crate from scratch after using a Different (start + end) 'Bound: Ord' wrapper (one that takes into account inclusivity), and then made some fairly fundamental API decisions that might differ from this crate regarding inserts.

So not really a fork, unfortunately.

Great spot on that Cursor API PR I definitely feel your pain after recently writing a whole crate whilst yearning for it.

I briefly considered using https://docs.rs/intrusive-collections/latest/intrusive_collections/rbtree/struct.RBTree.html due to it having a cursor API, but alas it went slightly over my head.

[jeffparsons]

All good, I did recognise it's not a fork — so e.g.. I can't "backport" your changes or anything like that. I think it's healthy for multiple similar crates to exist with different priorities. 🙂👍 But I'm sure there will also be some things I can learn from what you're doing that will be at least conceptually compatible with my preferred future for rangemap.