Possibly invalid "unconstrained types" calling trait method with constraints

[erickt]

Here is some example code:

trait Hash<H> {
    fn hash2(&self, hasher: &H) -> u64;
}

trait Stream {
    fn input(&mut self, bytes: &[u8]);
    fn result(&self) -> u64;
}

trait StreamHasher<S: Stream> {
    fn stream(&self) -> S;
}

//////////////////////////////////////////////////////////////////////////////

trait StreamHash<S: Stream, H: StreamHasher<S>>: Hash<H> {
    fn input_stream(&self, stream: &mut S);
}

impl<S: Stream, H: StreamHasher<S>> Hash<H> for u8 {
    fn hash2(&self, hasher: &H) -> u64 {
        let mut stream = hasher.stream();
        self.input_stream(&mut stream);
        stream.result()
    }
}

impl<S: Stream, H: StreamHasher<S>> StreamHash<S, H> for u8 {
    fn input_stream(&self, stream: &mut S) {
        stream.input([*self]);
    }
}

fn main() {}

This errors with:

hash9.rs:23:9: 23:40 error: cannot determine a type for this bounded type parameter: unconstrained type
hash9.rs:23         self.input_stream(&mut stream);
                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

One possibility is that the unconstrained type checker isn't taking in consideration of the impl<S: Stream, H: StreamHasher<S>> Hash<H> for u8 constraint and is only being evaluated in context of the unconstrained Hash<H> trait.

[nikomatsakis]

cc me

[treeman]

Visiting for triage, still relevant.

[erickt]

Was this determined to be the proper behavior? If not, we should probably reopen all the bugs #18324 closed.

[nikomatsakis]

I believe this is the expected behavior. What happens is that the trait matcher observes that there are no impls of StreamHasher and hence the only way you could possibly satisfy this trait is with the type H. This is fallout from our decision to infer more aggressively.

Note that if you add even one impl, e.g.:

impl<S:Stream> StreamHasher<S> for () {
    fn stream(&self) -> S { fail!() }
}

you get the same error you had before, because now there is genuine ambiguity (did you mean H? or ()?)

[nikomatsakis]

To be honest, I don't think there's a bug here. Where there is ambiguity, the impl matcher refuses to guess. You could use UFCS form to be more explicit about the type H.

[nikomatsakis]

Well, there is probably a (separate) bug in that the following does not work:

        StreamHash::<S,H>::input_stream(self, &mut stream);

which I rather expected to.

[nikomatsakis]

Anyway, going to close since I think this is working as expected.

[nikomatsakis]

Note: with the changes I am making to support "impl trait for trait" (shorthand term meaning that a trait object Foo implements the trait Foo), the test for this no longer compiles, because there is (again) ambiguity. I'm ... still thinking this is expected behavior, and hence I'm just going to move the test to compile-fail.