eggyal / copse Goto Github PK

In some situations unsized keys work with LookupKey implemented on the unsized type (as one would expect); whilst in others it must (also) be implemented on references thereto, with additional explicit borrowing in function calls.

I think this is because some functions are missing a ?Sized bound on the generic key type, which is causing type resolution to go askew.

Will prioritise this and cut a patch release ASAP, but am travelling right now so could be a day or two.

Copyright in the original liballoc code rests with each individual contributor, albeit dual-licensed by them under MIT and Apache-2.0 at user discretion. I'm happy for copse to adopt the same approach for its contributions.

However, correctly attributing copyright therefore requires incorporating liballoc's git history into this repo (albeit that should also ease tracking/merging of upstream changes in future too).

Unfortunately that's not entirely straightforward, as git doesn't enable one to link only to another repo's subfolder: we'll probably need to maintain our own fork of the entire rust-lang/rust repo, include that fork as a submodule, and then (I guess) use a #[path] attribute to set our btree module to use the relevant file from that submodule?

I'm not 100% clear about this however: will investigate, or else any suggestions/PRs welcome!

Hi there, cool work!

I found this crate from your stack overflow comment here while looking for more flexible ways of imposing custom orderings inside BTreeMaps. I need such flexibility for the range_bounds_map crate I maintain. Specifically ripytide/nodit#21

My Question:

Is this not already possible without a full code-port by simply wrapping the BTreeMap in a new struct and then translating the types you get given into a newtype struct that dynamically applies the specified TotalOrder?

Something like:

struct CustomOrdApplicator<T, O> { inner: T, total_order: O }

impl Ord for CustomOrdApplicator {
   fn cmp(self, other) {
       self.total_order.cmp(self, other)
   }
}

Apologies if I have misunderstood something.

Ideally even add a bot that opens PRs when relevant files in liballoc are modified upstream...

Perhaps into a default submodule?

Maybe even put their functionality behind a feature flag (indeed, if disabled, we could instead provide a blanket impl<C: Comparator> LookupKey<C> for C::Key which might actually be more useful; with specialization we should be able to provide both blanket implementations).