Can we allow indirect inherent impls?

Given the following code:

trait T { type U; }
trait S {}

struct Struct;
struct _2Struct;

impl T for Struct {
    type U = _2Struct; 
}

impl <Struct as T>::U {
}

impl S for <Struct as T>::U { 
    
}

The 2nd impl block fails with E0118. However, the 3rd block implementing S does work, so the compiler can clearly "see through" the associated type and determine that it refers to a single specific type, unlike, e.g. the example given on that error page. That suggests it would be more consistent for the 2nd block to be valid, and there's no semantic reason I can see that it shouldn't be.

Would it be possible for the language to allow this in a future version, at least in the cases where impl _2Struct is already valid? (The named type is in the current crate, etc)

(The reason I discovered this and can't just directly write the name _2Struct is because I'm writing macros)

11 Likes

personally, i'm all for regularizing rust grammar to make generating code easier. i believe that was the main motivation for allowing const _ in more situations.

3 Likes