Sugared paths to associated types via non-variable types

[nrc]

E.g., Foo::A where Foo is a struct and A is an associated type on one of its impls, or int::A. (Currently T::A only works where T is a type parameter or Self).

[steveklabnik]

Triage: trying to figure out what this was about:

Foo::A where Foo is a struct and A is an associated type on one of its impls,

struct Foo;

impl Foo {
    type A = i32;
}

errors:

hello.rs:6:5: 6:18 error: associated types are not allowed in inherent impls [E0202]
hello.rs:6     type A = i32;
               ^~~~~~~~~~~~~
hello.rs:6:5: 6:18 help: run `rustc --explain E0202` to see a detailed explanation

So I'm either misunderstanding something, or things have changed since this was opened. @nrc , which is it?

[nrc]

e.g.,

trait T {
    type U;
}

struct S;

impl T for S {
    type U = i32;
}

fn main() {
    let _: <S as T>::U = 43;  // Works today.
    let _: S::U = 43;  // Doesn't work today but should, this issue.
}

Today, we get an ambiguity error, but there is no ambiguity here.

[rphmeier]

There is some potential ambiguity here.
Assuming that S is some type visible to both crates, and you pulled in some crate with code like this:

pub trait T2 {
    type U;
}

impl T2 for S {
    type U = isize;
}

The compiler can't determine if the type is i32 or isize for the code you've posted above. I've seen discussion in a few other issues/RFCs that pulling in some specific combination of crates shouldn't mysteriously break code which worked previously, so I think this is something to consider. Of course, if you can prove that S is not visible outside the current crate, it should be possible to determine that there is only one resolution for the type S::U.

[Mark-Simulacrum]

I'm not sure this is worth implementing.

Making Struct::Associated work when non-ambiguous would mean that adding a trait impl to a struct or making a struct public would both cause other code to not compile, I think, which seems unhelpful/wrong.

[Mark-Simulacrum]

Closing. I think that the decisions that need to be made with regards to ambiguity make closing this for the time being the best option. It's unclear that there are any significant wins, especially since this feature would make it more confusing to see T::U: T could now be anything (struct, enum, union, or trait) and to find U you have to look through all of T's impls, which seems unfortunate.

This works already with bounds that clear up ambiguity, as below:

struct T;

trait A {
    type Type;
    fn create(&self) -> Self::Type;
}

impl A for T {
    type Type = i32;
    fn create(&self) -> Self::Type {
        10
    }
}

fn t<X: A>(x: X) -> X::Type {
    x.create()
}

fn main() {}

[TitanThinktank]

thanks to nrc commented from Jan 1, 2016
This line
let _: <S as T>::U = 43; // Works today.
it did wonders for me, i could define a type inside trait and also make a member variable of that inside the struct that trait was implemented in, an amazing feature.