Consider making Either uniform with futures::Either

[olix0r]

The tower::Either behaves similarly to futures::Either, but they've diverged over time. Namely, tower's is:

enum Either<A, B> {
    A(A),
    B(B),
}

but future's is now:

enum Either<L, R> {
    Left(L),
    Right(R),
}

• Should we rename our either variants to match future's?
• Can we simply re-export the futures::Either type and provide Service impls for it?

[davidpdrsn]

Should we rename our either variants to match future's?

Yeah I think thats a good idea.

Can we simply re-export the futures::Either type and provide Service impls for it?

There is a bit more to tower's impl Future for Either and futures's so not sure thats possible. It uses #[pin_project] and has bounds the variants containing Results.

[olix0r]

There is a bit more to tower's impl Future for Either and futures's so not sure thats possible. It uses #[pin_project] and has bounds the variants containing Results.

Does it need to? I.e. if we inherit the Future impl, can it be used for our needs to satisfy Service<Req> for futures::Either<L,R>?

[olix0r]

As discussed in #629, we should probably update the Either service's return type to be an opaque future so we can drop the dependency on pin-project in tower. We should also require the inner service's to have a uniform error type (rather than boxing the error, potentially erasing infallibility).