Move HashMap to alloc::collections

[WildCryptoFox]

Can we move HashMap to alloc::collections?

std could use a type alias to assume the default, and use a trait to add the new and with_capacity methods back.

pub type HashMap<K, V, S = RandomState> = alloc::collections::hash_map::HashMap<K, V, S>;

pub trait HashMapExt {
  fn new() -> Self;
  fn with_capacity(n: usize) -> Self;
}

impl<K: Eq + Hash, V> HashMapExt for HashMap<K, V> {
  fn new() -> Self { .. }
  fn with_capacity(n: usize) -> Self { .. }
}

[sfackler]

The default hasher requires access to the OS's random number generator which isn't available in liballoc.

[WildCryptoFox]

@sfackler I realised this, thus the default would be set in std via that type alias, not in alloc. And why we need the trait to implement the new and with_capacity methods.

[jethrogb]

This is rust-lang-nursery/portability-wg#11

[steveklabnik]

Triage: not aware of any real movement here.

[Amanieu]

My position is that if you need a no_std hashmap, you can just use the hashbrown crate directly. Maybe we could make this official and add it to the documentation?

[jethrogb]

That is not a generally-acceptable solution due to interoperability concerns. Currently, if you get a Vec returned from a no_std library, you can pass this to function accepting a Vec in a std library. Whatever solution we come up with for HashMap should be the same.

[jethrogb]

Dup of #27242?

[dtolnay]

Closing in favor of #27242.