HashMap should be more widely usable

[Ericson2314]

Right now it can only be used on regular platforms due to the way the default hasher is initialized. This is a such a silly little thing. Yes, it's a one-of issue, but I view it as a good litmus test.

[jethrogb]

I think there's an issue for better handling of default type parameters, but I can't find it right now.

[Ericson2314]

There is. But I rather not wait for such language change when we can just move it into alloc and wrap in a new type. We could have done that years ago.

[jethrogb]

That would mean that users of std and alloc are seeing a different type, no?

[Ericson2314]

@jethrogb Yes. But that's no worse than today when its not even available in alloc. While alloc is unstable, a stop-gap solution like the newtype need not tie our hands.

[WildCryptoFox]

@Ericson2314 @jethrogb A newtype could have worked, but now the default type alias should work today. Is there anything blocking this today?

[Ericson2314]

type aliases cannot have default type parameters.

[WildCryptoFox]

@Ericson2314 Er. I use this feature often.

pub type Result<T, E = Error> = core::result::Result<T, E>;

[Ericson2314]

Woah I didn't know that was even allowed in stable Rust. @eddyb?

Still there are issues:

pub type Result<T, E = ()> = core::result::Result<T, E>;

fn main() {
    Ok(());
    // fn asdf<E = ()>() -> Result<(), E> { Ok(()) }
    //asdf();
    println!("Hello, world!");
}

Ok is ambiguous, and parameter defaults are not accepted on functions.

[WildCryptoFox]

@Ericson2314 Of course that Ok is ambiguious, it is Result<(), _>::Ok.

Indeed functions don't get this treat, but for all that it matters for HashMap you just need a impl<K: Eq + Ord, V> HashMapStd for HashMap<K, V> { fn new; fn with_capacity; }; where the HashMap type alias in std includes the default. See my suggestion in rust-lang/rust#56192

[WildCryptoFox]

@Ericson2314 I must admit I was surprised to find the following doesn't work.

type Result<T, E = ()> = std::result::Result<T, E>;

// doesn't build
//use Result::*;

enum XResult<T, E = ()> {
    XOk(T),
    XErr(E),
}

// works as expected
use XResult::*;

Edit: Although you can't use XOk(()); either as it doesn't know the E type concretely; thus no difference or loss of features. Although it would be nice if it defaulted the type and adopted the concrete types when made concrete later.

[Ericson2314]

To not break compat, we have to default those method type vars taken from the inherent impl. This isn't possible. We don't have the same problem with variant constructurs since HashMap has none exposed, but if it did that would be the same problem.

[Amanieu]

I would recommend anyone wanting to use HashMap on no_std to just use the hashbrown crate, which only depends on liballoc.

[Ericson2314]

That's a good idea if you don't need to worry about other libraries consuming a hash map. My RFC rust-lang/rfcs#2492, which will hopefully get more consideration after the Rust 2018 crunch, would get us a way to defer the definition of the default so the main one can be moved. (And I'd hope the general thrust of the portability push would allows @Amanieu's alternative hashmaps and locks to be substituted in custom-built standard libraries easily so that they can be used more widely.)