"ambiguous associated type" when accessing concrete type (but not on generic type)

[RalfJung]

Consider the following code:

trait Memory {
    type Provenance;
}

struct BasicMemory;

impl Memory for BasicMemory {
    type Provenance = ();
}

fn some_fn() {
    let x: BasicMemory::Provenance; // this fails
}

fn some_generic_fn<T: Memory>() {
    let x: T::Provenance; // this works
}

Using Type::Provenance works when Type is a generic parameter that implements the appropriate trait, but strangely fails when Type is a concrete type that implements the appropriate trait. That seems like a bug? Or at least it is an odd limitation that it'd be nice to lift. :)

Thanks to @memoryleak47 for pointing this out!

[JoelCourtney]

You need to use <BasicMemory as Memory>::Provenance. The reason why is because BasicMemory can implement multiple traits that happen to have the Provenance associated type, so it could be ambiguous.

[RalfJung]

It could, but it doesn't. This compiles:

trait Memory {
    type Provenance;
    
    fn foo();
}

struct BasicMemory;

impl Memory for BasicMemory {
    type Provenance = ();
    fn foo() {}
}

fn some_fn() {
    let y = BasicMemory::foo();
}

fn some_generic_fn<T: Memory>() {
    let y = T::foo();
}

This is the exact same situation but with a function foo rather than an associated type.

[Jules-Bertholet]

I know pretty much nothing about trait system internals, so can't say with any certainty, but I suspect this might be blocked on lazy normalization, like inherent associated types?