Bug in rust automatic deref for methods of generic traits

[porky11]

Normally generics should just work like specialized versions, just substituted with the correct type.
For example trait MyTrait<T> {…} is intended to work for a type MyType as if I defined trait MyTrait_MyType {…}.
This doesn't apply, when one specialized version of a generic trait is implemented for a type T, which derefs to U, which implements a different specialization of the same trait.
Then the specialized version for T also shadows the specialized version for U, even if they could both be called on this type.

I made an example to show, what this means here.

[estebank]

You can use the fully qualified syntax, and it will work:

<IntegerList as AddElement<i16>>::add(&mut list, 1i16);

Agree that it is not completely ergonomic.

[ExpHP]

Sounds like an unavoidable consequence of rust's in-order type checker. I don't think there is any place in rust which handles this sort of polymorphism this well.

Basically, you've created a situation where it is not possible to express all of the possible signatures of list.add as a single generic function with where bounds; rather, the signatures can differ arbitrarily in a manner similar to function overloading. This thwarts the type checker, which is otherwise normally able to do it's job without any direct help from type inference. (at least, this is my understanding)

I suspect that the actual specialization feature faces problems like this as well.

Edit: struck out "unavoidable" because I don't know that.

[Enselic]

Triage: Since there is a way to make the code compile, I don't really see what other specific action to take here. Let's close.