HashMap::from_iter doesn't compile without explicitly supplying the hasher

[hniksic]

Now that FromIterator is in the prelude, I expected to be able to create a HashMap like using HashMap::from_iter():

use std::collections::HashMap;
fn main() {
    let h = HashMap::from_iter([("foo", 1), ("bar", 2)]);
}

However, that doesn't compile, saying "type annotations needed for HashMap<&str, i32, S>":

 --> src/main.rs:3:13
  |
3 |     let h = HashMap::from_iter([("foo", 1), ("bar", 2)]);
  |         -   ^^^^^^^ cannot infer type for type parameter `S` declared on the struct `HashMap`
  |         |
  |         consider giving `h` the explicit type `HashMap<&str, i32, S>`, where the type parameter `S` is specified

Playground

I would expect <HashMap as FromIterator>::from_iter() to pick the default hasher in absence of an explicit request for a different one requested, like Vec::from_iter() compiles and defaults to the global allocator. (HashMap::from() also compiles, but it seems to be limited to the default hasher.)

Note that this is different from #69123 which is about a confusing diagnostic. This issue is about the error itself, in particular as compared to Vec::from_iter().

Tested with Rust 1.56.1 stable.

[bragov4ik]

Also it might be helpful that there is a workaround

use std::collections::HashMap;
fn main() {
    let h = HashMap::<_, _>::from_iter([("foo", 1), ("bar", 2)]);
}

This way the compiler somehow understands to use the default hasher (not sure why it doesn't without ::<_, _>).

[SebastianJL]

Is there any update on this? Just stumbled upon this today with rust 1.65, although with std::collections::HashSet::from_iter().

[hniksic]

This is the same issue as the newer #101319. The explanation by @SkiFire13 there nicely explains what's going on:

When just HashSet is used it means to infer HashSet<T, S>, i.e. the S is also inferred. Default generic types are not used when doing inference. If you want to have the T inferred but not anything else then you can specify _ as its type

As summarized by the reporter there:

by doing HashSet::<_> you assert that the unmentioned parameters have their default value, whereas if you do not mention any type parameters at all, then defaults are ignored and so all type parameters must be inferred from other information

I actually wasn't aware of this distinction between omitting the type parameter and providing it as _, even after using Rust professionally for quite a few years now.