Repository navigation
Move HashMap to alloc::collections #56192
Description
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 { .. }
}
Reacted by safarir, Elichai Turkel, Niklas, Juhan Oskar Hennoste, Mendy Berger and raldone01
Activity
sfackler commentedon Nov 24, 2018
The default hasher requires access to the OS's random number generator which isn't available in liballoc.
WildCryptoFox commentedon Nov 24, 2018
@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 commentedon Nov 26, 2018
This is rust-lang-nursery/portability-wg#11
steveklabnik commentedon Jan 22, 2020
Triage: not aware of any real movement here.
Amanieu commentedon Jan 22, 2020
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 commentedon Jan 22, 2020
That is not a generally-acceptable solution due to interoperability concerns. Currently, if you get a
Vecreturned from ano_stdlibrary, you can pass this to function accepting aVecin astdlibrary. Whatever solution we come up with forHashMapshould be the same.jethrogb commentedon Apr 24, 2020
Dup of #27242?
dtolnay commentedon May 27, 2020
Closing in favor of #27242.