Add HashMapEntry and BTreeMapEntry aliases to std::collections

[GrigorenkoPV]

Proposal: in std::collections add {Hash,BTree}MapEntry as an alias for {hash,btree}_map::Entry

Problem statement

Has this happened to you?

use std::collections::hash_map::Entry as HashMapEntry;

Motivating examples or use cases

It surely has happened to:

• tikv
• cargo-depgraph
• Rust X11 bindings
• shadow
• Rust port of Lucene
• CodeChain
• Hey! Listen! (notable for having BTreeMapEntry too)
• And many others.

Not to mention that most of the contents in std::colections::{hash,btree}_map are "internal" things like iterator implementations, which you rarely ever have to refer to directly. Unlike with Entry, which is a surprisingly versatility API that lends itself especially well with Rust's pattern matching. But then you have to name the type, and generally you have the following options:

1. Fully qualified name (long, not pretty).
2. use std::collections::hash_map; and then refer to it as hash_map::Entry. But importing an entire module just to refer to a single type inside doesn't sit right with me.
3. use std::collections::hash_map::Entry;. Suboptimal, the name is too vague and might collide.
4. use std::collections::hash_map::Entry as HashMapEntry;

Solution sketch

Add these two lines (plus the neccessary attributes) to alloc/collections/mod.rs & srd/collections/mod.rs:

pub use btree_map::Entry as BTreeMapEntry;
pub use hash_map::Entry as HashMapEntry;

Sadly, this is a breaking change because of the glob imports. But I guess this can be done across an edition boundary?

Alternatives

1. Do not do anything
2. type HashMapEntry<'a, K, V, A = Global> = hash_map::Entry<'a, K, V, A>; (sounds even worse).

[Amanieu]

We discussed this in the libs-api meeting. The overall feeling was against adding these aliases. As you've mentioned, it's already possible to do this yourself with the following code:

use std::collections::hash_map::Entry as HashMapEntry

With that said, there was interest in adding a type alias on the HashMap type itself, which would allow the Entry type to be named with HashMap::Entry. However this is blocked on inherent associated types (rust-lang/rust#8995) which are still unstable and in an incomplete state due to compiler limitations.

[GrigorenkoPV]

I agree, an associated alias sounds better.

And since this is a rather unimportant change, it can easily wait.

Thanks for the review!