Consider if Service::poll_ready should have a separate error type than Service::Error

[tower-rs]

Consider if Service::poll_ready should have a separate error type than Service::Error

[seanmonstar]

As an example, Reconnect returns a Future with an Error that might be the InitError, but the Future will never actually return that.

[carllerche]

@seanmonstar what do you think we should do here?

[seanmonstar]

I think the extra associated type adds a lot of complexity, and it's really only an issue in some situations. Like with Reconnect, the annoyance can probably be solved in a different way (should it even return InitError? Or, we could force E: Into<Box<StdError>>, or something else).

[jonhoo]

What we really want here is an existential associated type. That'd allow the future type to be different for each implementor, without making it necessary to name it explicitly.

[carllerche]

I'm guessing that the conclusion here is "no"?

Thoughts @seanmonstar

[seanmonstar]

Yes, that's what I meant by my last comment. That adding another associated error type doesn't sound like it pulls its weight.