Default type parameters are not used in type inference

[agluszak]

I tried this code:

struct BoxyMcBoxFace<T = ()> {
    inner: Option<T>,
}

fn main() {
    let _boxy_ok1 = BoxyMcBoxFace { inner: Some(()) }; // obviously
    let _boxy_ok2: BoxyMcBoxFace<()> = BoxyMcBoxFace { inner: None };
    let _boxy_ok3: BoxyMcBoxFace = BoxyMcBoxFace { inner: None }; // that's getting more interesting
    let _boxy_err = BoxyMcBoxFace { inner: None }; // ERROR: cannot infer type...
}

I expected _boxy_err to compile (i.e. that the compiler would use the default type during inference, as it does with _boxy_ok3).

Instead, this happened:

error[E0282]: type annotations needed for `BoxyMcBoxFace<T>`
 --> src/main.rs:9:9
  |
9 |     let _boxy_err = BoxyMcBoxFace { inner: None }; // ERROR: cannot infer type...
  |         ^^^^^^^^^
  |
help: consider giving `_boxy_err` an explicit type, where the type for type parameter `T` is specified
  |
9 |     let _boxy_err: BoxyMcBoxFace<T> = BoxyMcBoxFace { inner: None }; // ERROR: cannot infer type...
  |                  ++++++++++++++++++

For more information about this error, try `rustc --explain E0282`.

In the best case, this is working as intended (but that's unintuitive) and the suggestion is wrong ("where the type for type parameter T is specified"). But maybe that's a bug in the compiler.

If it's a bug, I can try to fix it if I get some guidance.

Meta

rustc --version --verbose:

rustc 1.62.1 (e092d0b6b 2022-07-16)
binary: rustc
commit-hash: e092d0b6b43f2de967af0887873151bb1c0b18d3
commit-date: 2022-07-16
host: x86_64-unknown-linux-gnu
release: 1.62.1
LLVM version: 14.0.5

cargo +nightly rustc -- --version --verbose:

rustc 1.64.0-nightly (7fe022f5a 2022-07-24)
binary: rustc
commit-hash: 7fe022f5aa32bbbb33c3a58755729d6667a461a9
commit-date: 2022-07-24
host: x86_64-unknown-linux-gnu
release: 1.64.0-nightly
LLVM version: 14.0.6

Setting the backtrace doesn't change anything in the output

[memoryruins]

This is expected behavior #27336

The suggestion reads correctly to me, but is definitely a general one. Do you expect it to suggest the default type or something else?

[Noratrieb]

@agluszak can this be closed? Or do you think the error message should be improved to talk about associated type defaults and leave it open?

[fmease]

Closing in favor of #98931 / as duplicate of #27336.