tower-rs
Type parameter of server::Error can make its usage cumbersome
server::Error is generic with a MakeService type parameter, providing associated error types for content of variants Service and NewService. If the service factory type used by the application is itself generic and imposes trait bounds on its parameters, code using server::Error has to carry all that baggage over, even though the actual service error types may not require it at all. The generic parameters of the service type also percolate into error types that contain server::Error, making their Debug impls problematic to derive due to the likely phantom data type parameters.
Can this error type be decoupled from the signature of a MakeService type?
@mzabaluev I am a bit lost on the carrying the baggage around do you by chance have any code samples I could look at?
@LucioFranco here's my workaround illustrating the problem. Note the type parameter and the bounds on the From impl. If my Error type would embed tower_h2::server::Error, it would have to inherit the type parameter and the bounds would have to be specified in every definition involving my Error. In reality, any variants in the tower_h2::server::Error specialized for my generic server can only carry h2::Error.
@mzabaluev I somewhat see but the places that those bounds should exist is not very high? From your PR it seems that you are just bringing the errors up one level instead of leaving them to be generic on the MakeService level, meaning that someone who wants to stay generic will have to be more explicit. In this case, imo I think its fine to carry baggage around. I could be convinced otherwise but I personally would like to see where this baggage comes back.
It also could be that I have not really run into the issue of type baggage as well in my own experiences 😄
As server::Error can only arise from code that's bound by a MakeService impl, I don't see a problem in making its type signature less coupled. In fact, #51 will make explicit declarations using server::Error less cumbersome in many cases. For example, in applications of tower-grpc with their generated protobuf/gRPC bindings, Error<h2::Error> is much handier to write, and to read in compiler error messages, than Error<my_proto::server::MyProtoServer<MyProtoService>>.