Type inference asks for annotations that are already present

[alecmocatta]

use std::convert::TryInto;

fn main() {
    let _: usize = Some(0usize).map(|host: usize| 0usize).unwrap() + 0usize.try_into().unwrap();
}

(Playground)

Errors:

   Compiling playground v0.0.1 (/playground)
error[E0284]: type annotations needed for `usize`
 --> src/main.rs:4:38
  |
4 |     let _: usize = Some(0usize).map(|host: usize| 0usize).unwrap() + 0usize.try_into().unwrap();
  |                                      ^^^^ consider giving this closure parameter a type
  |
  = note: cannot resolve `<usize as std::ops::Add<_>>::Output == usize`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0284`.
error: could not compile `playground`.

To learn more, run the command again with --verbose.

[Coder-256]

That diagnostic is a bit misleading. This works:

Playground

use std::convert::TryInto;

fn main() {
    let _: usize = Some(0usize).map(|host: usize| 0usize).unwrap()
        + (0usize.try_into() as Result<usize, _>).unwrap();
}

I guess the compiler can't figure out the type of the 2nd addend, and by extension, what type you expect from try_into(). I think in this case, I think it's true that usize is the only type that satisfies T for both usize: Add<T, Output = usize> and usize: TryInto<T>. However, I am not convinced that the compiler should be expected to deduce this, especially because it is possible to implement both of these traits on usize for some other T (due to rust-lang/rfcs#2451). For example:

Playground

use std::{convert::TryInto, ops::Add};

struct Foo;

impl Add<Foo> for usize {
    type Output = usize;
    
    fn add(self, rhs: Foo) -> Self::Output {
        unimplemented!()
    }
}

impl TryInto<Foo> for usize {
    type Error = ();
    
    fn try_into(self) -> Result<Foo, Self::Error> {
        unimplemented!()
    }
}

In other words, I think it is expected that this would not compile, and the problem is the misleading diagnostic.

[alecmocatta]

Closing as this is fixed in latest nightly, I suspect by #71960. Thanks @estebank!