Specialization on associated type

[vandenheuvel]

Specializing on an associated type doesn't yet work.

#![feature(specialization)]

trait Tr {
    type X;
    fn f(&self) -> Self::X;
}

// Works
// impl<T> Tr for T {
//     type X = i8;
//     fn f(&self) -> Self::X { 1_i8 }
// }

// Works
// impl<T> Tr for T {
//     type X = i8;
//     
//     default fn f(&self) -> Self::X {
//         1_i8
//     }
// }

// Doesn't work
impl<T> Tr for T {
    default type X = i8;
    
    default fn f(&self) -> Self::X {
        1_i8
    }
}

Error:

error[E0308]: mismatched types
  --> src/lib.rs:28:5
   |
25 |     default type X = i8;
   |     -------------------- expected this associated type
26 |     
27 |     default fn f(&self) -> Self::X {
   |                            ------- expected `<T as Tr>::X` because of return type
28 |         1_i8
   |         ^^^^ expected associated type, found `i8`
   |
   = note: expected associated type `<T as Tr>::X`
                         found type `i8`

error: aborting due to previous error; 1 warning emitted

On 1.54.0-nightly (2021-05-11 5c029265465301fe9cb3). Playground.

[jonas-schievink]

Isn't this working correctly? f cannot assume that a downstream implementation will use the same type for X

[vandenheuvel]

Wouldn't you want to be able to override the default implementation changing both Tr::X and Tr::f? Or are you suggesting that you can't provide any default implementation for Tr::f because its implementation would always depend on Tr::X, even if the types of the default implementation correspond?

Maybe this is the way it was intended to work, but it would be nice to choose a default implementation as in the above example. Then one would simply be required to make sure that X and f are compatible in any downstream implementations (as usual).

[vandenheuvel]

@jonas-schievink could you label it with the specialization and diagnostic labels? The error is in any case confusing, and then the visibility of the issue will help others decide whether this should compile or not.