btreemap and not-btreemap should not be mutually exclusive

[stepancheg]

If there are two crates in dependency tree of a project, and one crate requests no-btreemap, and other requests btreemap, first one won't compile.

[michaelsproul]

Do you mind creating a repo with a demo of this issue? I would have thought that Cargo's dependency resolution would take the union of features and enable the btreemap feature for both: https://doc.rust-lang.org/cargo/reference/resolver.html#features

[stepancheg]

would take the union of features and enable the btreemap feature for both

Exactly. So if someone relies on it being hash, code will be broken (Ord is now required where Hash was expected). But also performance will be different.

[michaelsproul]

Mm, I guess a better solution is to have both variants available in the crate and then users can import and use whichever one they want. I'd accept a pull request to do this if you have time (I don't have time to do it myself, sorry).

We'd also need to publish a new release v0.4.0 as we'd be changing the public API quite drastically.