Type parameters can be constrained only as an associated type

[arielb1]

You can create an inherent impl where the impl substs are not constrained by the impl signature. If the parameters are constrained by the method signature, you can even get code that usefully runs (otherwise you get "can't resolve" errors):

struct S<T>(T);

trait Tr { type Assoc; fn test(); }

impl Tr for u32 {
    type Assoc = u32;
    fn test() { println!("test for u32!"); }
}

impl Tr for u64 {
    type Assoc = u32;
    fn test() { println!("test for u64!"); }
}

impl<T: Tr> S<T::Assoc> {
    fn foo(self, _: T) {
        T::test();
    }
}

fn main() {
    <S<u32>>::foo(S(4u32),4u32);
}

Note that you need to use UFCS notation to avoid #25679 (which is an issue with method lookup).

RFC447 is silent with regards to this issue, but this allows you to create an impl that is not resolvable by its trait-ref.

[arielb1]

cc @nikomatsakis

[nikomatsakis]

Heh, I was just telling @aturon in IRC the other day that this case was broken. I agree, the current logic is too simplistic (it's also something I've been writing up in this RFC I keep talking about...). Basically, it currently considers all input/type parameters which appear as constrianed, but it ought to stop at projections. I made this gist, which is a similar example: https://gist.github.com/0c562768aeb9412269ce

[nikomatsakis]

To be clear, I don't think that fixing this issue requires an RFC (it's just a bug, I think). I just meant that I was writing up various text that referenced the notion of "constrained type parameters" and tried to give a definition, which is how I realized this problem.