Eventual future in std or alloc?

[dhedey]

First off - I wanted to say that this library is great, and I use it all the time! And indeed I'm not the only one 👍

My question is:

Is there a possible future of indexmap in alloc or std? (ideally alloc, pending rust-lang/rust#27242)

I've searched rust github, zulip and indexmap github, and surprisingly haven't seen any threads on this question already, but I may have missed them, so if you know of any, please flag them.

My rough convincer is:

• Order-preserving maps appear in tons of practical application-oriented use cases, including mundane things like preserving JSON serialization, and other places where determinism is required when using a map as an inbetween (e.g. the rust compiler).
• Moreover, most lock files I see for non-trivial projects end up having multiple copies of indexmap in their source tree, which causes code bloat and compatibility issues (this was exacerbated by the v1 => v2 transition, but some libs also fix a version for some reason)
• For most applications where small performance improvements aren't important, using indexmap over hashmap is probably the least confusing default choice. The fact the iterator on a hashmap is non-deterministic is a partial footgun for quite a few developers I think, even if it's well-known.
• In my personal experience, indexmap seems to be used more than heaps/priority-queues, linked lists, vec-deques or even btree maps which are currently in alloc. I recall there was historically a big cull of collections before rust 1.0, although I can't find the blog post about this now.

... but of course there is the standard argument against in that having a small std library is good, and makes it easier to iterate and things (see e.g. https://blessed.rs/crates / Josh's talk on lib evolution), and e.g. maybe indexmap doesn't meet the bar or isn't sufficiently stable?

I appreciate this is probably a question for the libs team on zulip; but I wanted to get some input here first, before raising a discussion on zulip - in case there was no support from the indexmap maintainers, or there was a clear reason for this not to happen in the crate itself.

[cuviper]

FWIW, I am a member of the rust-lang/libs team, but not libs-api that would really make this decision. I doubt that the API team would want to pull this in though -- there are a lot of examples of high-quality useful crates that are left separate, even those like rust-lang/regex that are maintained within the Rust project.

• Moreover, most lock files I see for non-trivial projects end up having multiple copies of indexmap in their source tree, which causes code bloat and compatibility issues (this was exacerbated by the v1 => v2 transition, but some libs also fix a version for some reason)

If projects haven't migrated in the 18 months since v2.0.0 was released, then I wouldn't have high hopes for them switching to a std/alloc-provided version in any timely manner. Actually, I think an external crate has an easier path to adoption when you consider dependents that want to maintain an older MSRV.

Moving to the standard library would also make some implementations harder, like the rayon parallel iterators. In particular, a good by-value IntoParallelIterator requires access to the Vec<Bucket<..>> which is not exposed in indexmap's public API. Rayon already has to use less-optimal implementations for std::collections::HashMap, collecting to a local Vec first, whereas hashbrown::HashMap can implement those parallel traits internally on the in-place data.

(Then you might argue to pull rayon into the standard library too, but I think that's an even harder case -- even though I proudly maintain it, I wouldn't claim that it's a perfect API, and it could someday be usurped by something else.)

[dhedey]

Thanks @cuviper - really appreciate your insight on this!

I'll close this ticket to avoid polluting your issues. Thanks again for your work on this and the wider rust ecosystem.