Type annotations needed for type alias that refers to associated type on trait

[thomaseizinger]

I tried this code:

enum Foo<A> {
    A(A)
}

trait Baz {
    type A;
}

type Bar<B> = Foo<<B as Baz>::A>;

struct Impl {
    bar: Bar<Self> 
}

impl Baz for Impl {
    type A = String;    
}

fn main() {

    let s = Impl {
        bar: Bar::A(String::new())
    };

}

Playground link: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=97b88d916216f04a93c1d24ca2a4f558

I expected to see this happen: It compiles without issues.

Instead, this happened:

Compiling playground v0.0.1 (/playground)
error[[E0284]](https://doc.rust-lang.org/stable/error-index.html#E0284): type annotations needed
  --> src/main.rs:22:14
   |
22 |         bar: Bar::A(String::new())
   |              ^^^ cannot infer type for type parameter `B` declared on the type alias `Bar`
   |
   = note: cannot satisfy `<_ as Baz>::A == String`

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

Unless I am missing something, the type of Impl::Bar is defined unambiguously to be Foo<String>. It works once you add the type annotation:

let s = Impl {
    bar: Bar::<Impl>::A(String::new())
};

Meta

The problem is reproducible for stable, beta and nightly (tried in playground).

rustc --version --verbose:

rustc 1.65.0 (897e37553 2022-11-02)
binary: rustc
commit-hash: 897e37553bba8b42751c67658967889d11ecd120
commit-date: 2022-11-02
host: x86_64-unknown-linux-gnu
release: 1.65.0
LLVM version: 15.0.0

[fmease]

I don't think this is a bug. Associated types (projections) are not injective in general. Just because we know that the projected type is String we should not make assumptions about the self type, here Impl. In this case, there's indeed only one possibility but as soon as you add another impl, you could potentially get to String through different impls. I don't know if we should special-case this.

[thomaseizinger]

you could potentially get to String through different impls.

How? There can only be one implementation of Baz for Impl, I am explicitly constructing Impl und Impl hardcodes B in Bar<B> to be Self, i.e. Impl.

The last point is important. The type definition of Impl literally says Bar<Self>, why would anything else be allowed?

[thomaseizinger]

you could potentially get to String through different impls.

How? There can only be one implementation of Baz for Impl, I am explicitly constructing Impl und Impl hardcodes B in Bar<B> to be Self, i.e. Impl.

The last point is important. The type definition of Impl literally says Bar<Self>, why would anything else be allowed?

Is the problem that type aliases are "invisible" to the type checker? Even if associated types are not injective, it appears that the compiler should be able to look at the definition site of Impl and reject anything that is not Bar<Impl>.

I haven't tried but are you saying that I could actually put another impl Baz into Impl.bar as long as it has the same associated type? That would be very unintuitive.