NewService is generic over error

[carllerche]

Previously, NewService required returning a future yielding io::Error as
the error. This is not needed and is restrictive.

[withoutboats]

What are the use cases for which io::Error is insufficient here?

My concern is basically that if you want to fold multiple NewServices together, you might end up needing to bound their Error types in a way which can be pretty ugly:

fn two_service<A, B, E>(factory1: A, factory2: B) -> Join<A::Future, B::Future> where
     A: NewService,
     B: NewService,
     A::Future: Future<Error = E>,
     B::Future: Future<Error = E>,
{
     factory1.new_service().join(factory2.new_service())
}

A way to mitigate this would be to add yet another associated type to NewService, InitError or something, so that at least you don't have to pass through the Future type to constrain the error type (I assume the same reason that Service's assoc types are on NewService).

Not advocating any particular path, just see three options here (master, this branch, adding another assoc type) and they all have drawbacks.

[carllerche]

Well, one example would be a TLS handshake.

I would say, in general, Service is pretty decoupled from I/O.

[carllerche]

Also, in the back pressure example, NewService spawns a task... which is unrelated to I/O (https://github.com/carllerche/tower/blob/7f59c78166edaa178a4e687d380a3befab2c1347/examples/channel_service.rs#L103).

[withoutboats]

Both great examples! I'm convinced.

How do you feel about the difference between this PR and adding another associated type? On the one hand, Yet Another Associated Type, but I'm worried people are going to end up having to write <T::Future as Future>::Error somewhat often.

[carllerche]

@withoutboats would T::Future::Error not work? I thought that was doable if there wasn't any ambiguity? (I am probably wrong).

I would say that T::Future as Future>::Error should be avoided if at all possible.

[withoutboats]

Right now, assoc types of assoc types are always treated as ambiguous, e.g. even this:

trait Foo {
    type Bar: Bar;
}

trait Bar {
    type Baz;
}

fn foo<T: Foo>(_: T::Bar::Baz) { }

I think this could be improved but right now that's the state of things unfortunately.

[carllerche]

@withoutboats do you have any ideas for how to name the associated type?

[withoutboats]

@carllerche:

• InitError?
• Name the other error ServiceError?

[carllerche]

@withoutboats I whichever is most common to address should be Error. I'm not sure if that will be the init error or the service error...

InitError could be a good option if we determine the service's error should claim Error.

[carllerche]

I added InitError as an associated type.

It requires this in the impl now, which is a bit unfortunate:

https://github.com/carllerche/tower/blob/65b8eea55a39b7934d5b73ab6dc424e4c985dde4/src/lib.rs#L219

[withoutboats]

S has an InitError now too, so you could instead write:

type InitError = S::InitError;

For the function impl, you could instead add an E parameter to the impl and bound R: IntoFuture<Item = S, Error = E>.