Decouple server::Error from MakeService #51
Conversation
| where S: MakeService<(), Request<RecvBody>>, | ||
| { | ||
| #[derive(Debug)] | ||
| pub enum Error<E, ME = E> { |
There was a problem hiding this comment.
Since Server accepts a MakeService is there ever a chance that this won't be S::Error or S::MakeError?
There was a problem hiding this comment.
Since
Serveraccepts aMakeServiceis there ever a chance that this won't beS::ErrororS::MakeError?
No, and it's a good thing: Error does not need to drag the full MakeService implementation type into its signature, because it only needs two subdomain error types which are: 1) usually much simpler; 2) are types of actual contents of the Error enum, which makes Debug and other impls auto-derivable as seen in the commit.
Every meaningful declaration using this Error type locks its type parameters into the associated types of MakeService. Code that attempts to misuse the type parameters, e.g. by unintentionally swapping them, would either fail type-checking at use of the constructors Error::NewService and Error::Service, or would look obviously wrong.
|
@carllerche do you have any opinions on this? |
When server::Error is used in a generic way, but with a particular specialization of its MakeService type parameter, the type parameters and trait bounds of the specialization are included into the signature of the specialized server::Error, even though they may have no bearing on the actual variant error types. Redefine server::Error with two generic type parameters that receive associated types Error and MakeError of a MakeService impl, sans the explicit trait bound. To reduce verbosity in the common case when both parameters get the same type, the second parameter defaults to the type of the first.
mzabaluev
force-pushed
the
decouple-server-error-from-make-service
branch
from
fd65278 to
dc6cd01
Compare
When
server::Erroris used in a generic way, but with a particular specialization of itsMakeServicetype parameter, the type parameters and trait bounds of the specialization are included into the signature of the specializedserver::Error, even though they may have no bearing on the actual variant error types.Redefine
server::Errorwith two generic type parameters that receive associated typesErrorandMakeErrorof aMakeServiceimpl, sans the explicit trait bound. To reduce verbosity in the common case when both parameters get the same type, the second parameter defaults to the type of the first.Resolves #50.