Type inferencer probably could figure this case out (associated types)

[carllerche]

trait Async {
    type Value;
    type Error;
}

enum Result<T, E> {
    Ok(T),
    Err(E),
}

impl<T, E> Result<T, E> {
    fn reduce<F, U>(self, init: U::Value, action: F) -> U::Value
            where F: Fn(U::Value, T) -> U,
                  U: Async<Error=E> {
        unimplemented!();
    }
}

impl Async for i32 {
    type Value = i32;
    type Error = ();
}

pub fn main() {
    let res: Result<&'static str, ()> = Result::Ok("hello");
    let val: i32 = 123;

    res.reduce(val, |val /* i32 */, curr| val);
    // Compiles if annotated ^^
}

cc @nikomatsakis

[eddyb]

This requires two features which have not been implemented yet: #19476 and #21939 - and I'm not certain on the interaction between the two.

[nikomatsakis]

Carl, I think you could workaround this limitation by introducing another type parameter:

impl<T, E> Result<T, E> {
    fn reduce<F, U, X>(self, init: X, action: F) -> U::Value
            where F: Fn(X, T) -> U,
                  U: Async<Error=E, Value=X> {
        unimplemented!();
    }
}

Indeed this works in play.

I'm actually not sure why it's not working today. I think what should be happening is that when we try to normalize $U::Value, where $U is the variable we created for U, we wind up with a type variable $1 and the side-constraint that $U: Async<Value=$1>. Clearly $1 will get unified with i32 and then $U should (through the return value) be unified with $1. This seems like enough to figure out everything that is needed. But you do get an error, so presumably something goes wrong at an earlier point in the process, I'm not quite sure what.

[eddyb]

Oh, my bad, I didn't realize U::Value was being fed i32 from passing val into the call.

[steveklabnik]

Triage: this still reproduces today.

[steveklabnik]

Triage: no change

[Spoonbender]

Triage: no change