Incomplete error message: unable to infer enough type information about _

[jruderman]

fn main() {
    let a = Vec::new();
}

Gives me:

<anon>:2:13: 2:21 error: unable to infer enough type information about `_`; type annotations required [E0282]
<anon>:2     let a = Vec::new();
                     ^~~~~~~~

This is confusing because it doesn't say what the _ is that it can't figure out. Perhaps it could say something like:

Only able to infer that `a` has type `Vec<_>`; please annotate so I can figure out what `_` is.

[daniel-vainsencher]

This matters to me too.

[Mark-Simulacrum]

@rust-lang/compiler: I feel like this should be prioritized since it is very painful to deal with for newcomers to Rust. Could we nominate and discuss at next meeting? I don't know what can be done, but at least saying where the _ is would be amazing: Vec<_>.

[nikomatsakis]

@Mark-Simulacrum current output for this example:

rustc 1.17.0 (56124baa9 2017-04-24)
error[E0282]: type annotations needed
 --> <anon>:2:13
  |
2 |     let a = Vec::new();
  |         -   ^^^^^^^^ cannot infer type for `T`
  |         |
  |         consider giving `a` a type

error: aborting due to previous error

In a sense, I think this issue is fixed, though we decided to punt on figuring how to display the "partial type information" we have available.

[Mark-Simulacrum]

Though to me it's relatively obvious, so I might be inferring too much here, I think it would be amazing if we change "cannot infer type for T" to "cannot infer type for T in Vec<T>". That would make it clear where the generic is, since it's not always easy to tell from the function, and the user code shown has no T anywhere.

I'm fine with closing this if we disagree, though.

[nikomatsakis]

@Mark-Simulacrum ah, that's an interesting idea; I agree that just giving this free-floating name T is confusing. What if there were more type parameters declared on Vec. e.g., imagine this were a hashmap, and the value type was unconstrained, would we say "cannot type for V in HashMap<K, V>"? Or "cannot infer type for V in HashMap<_, V>"?

[Mark-Simulacrum]

To avoid the difficulty in showing the generics, we could even go with "cannot infer type for generic V in HashMap". That way the user has something relatively googleable and, as a benefit, if they go to the HashMap docs, the first thing they see is pub struct HashMap<K, V, S = RandomState> { /* fields omitted */ } which immediately hints at what V is. An alternative message could be "Could not infer type for generic V in HashMap<i32, V, ..> (though I like this less since it distracts from the issue.

I'm somewhat on the fence with using _ since there's both positives and negative to it. It's almost what we want, but it has the unfortunate connotation of "infer this," and we do know what the _ is in this case. That's sort of why I prefer the first suggestion I had but also don't like it since it requires more knowledge, to an extent.

[nikomatsakis]

@Mark-Simulacrum one challenge is that V may have a meaning in that context, so we might end up e.g. printing HashMap<V, V, ..> where the first V is referring to the name in the one context, and the other V is referring to the name from the definition of hash-map. We could sidestep this by printing something like ??? or making a "fresh" name that does not appear elsewhere.

I definitely feel like printing the name given on the definition has not proven especially clarifying and would like to do something else.

Perhaps, in the event that the type we cannot infer is "embedded" within a bigger type, we could say something like this:

rustc 1.17.0 (56124baa9 2017-04-24)
error[E0282]: type annotations needed
 --> <anon>:2:13
  |
2 |     let a = Vec::new();
  |         -   ^^^^^^^^ cannot infer complete type; inferred `Vec<???>`
  |         |
  |         consider giving `a` a type

error: aborting due to previous error

This doesn't look as good now that I've typed it out. ;)

[Mark-Simulacrum]

Drawing from that, perhaps just using _ for the type we couldn't infer and .. for 1 or more types that we could; so like the following two (somewhat copied from yours). I also have thought about using X for the type we couldn't infer (or maybe a generated X that doesn't appear in current context; maybe picking a single letter name though -- A, B, ...).

I think I somewhat dislike the approach with .. since it blends in too much. I like X, but we'd then want to generate a note "could not infer X" or something like that.

error[E0282]: type annotations needed
 --> <anon>:2:13
  |
2 |     let a = Vec::new();
  |         -   ^^^^^^^^ cannot infer complete type: `Vec<_>`
  |         |
  |         consider giving `a` a type

error[E0282]: type annotations needed
 --> <anon>:2:13
  |
2 |     let a = HashMap::new();
  |         -   ^^^^^^^^^^^^ cannot infer complete type: `HashMap<.., _>`
  |         |
  |         consider giving `a` a type
  | note: could not infer `_` // <-- this is probably wrong looking but something like it

error: aborting due to previous error

[estebank]

Current output is

error[E0282]: type annotations needed
 --> src/main.rs:2:13
  |
2 |     let a = Vec::new();
  |         -   ^^^^^^^^ cannot infer type for `T`
  |         |
  |         consider giving `a` a type

It could be

error[E0282]: type annotations needed
 --> src/main.rs:2:13
  |
2 |     let a = Vec::new();
  |         -   ^^^^^^^^ cannot infer type for `T` in `Vec<T>`
  |         |
  |         consider giving `a` a type: `a: Vec<DesiredType>`