I'm sympathetic to pin-project being a heavyweight dependency for such a simple use case.

On the other hand, I'm also conTcerned that this change will make tools like cargo-geiger flag tower.

Removing pin-project is probably worth it...

While we're here though: why does Either need to hold pinned values at all? Is this is just to implement Future? Doesn't the futures crate already ship a version of Either that implements Future? Perhaps we can remove this functionality completely in the next minor release?

Also note that #550 tracks updating the Either type to have Left and Right variants, planned for the next minor release.

My 2 cents: I think we should leave Either as it is currently and eat the dependency on pin-project. However for the next breaking version of tower I think we should change Either to not implement Future and change its response future to be a struct with a private inner enum that uses pin-project-lite.

While we're at it I also think we should change Either to not use BoxError as the error type but instead require the two inner services to have the same error type and use that. I've found it odd that combining two infallible services and gives you one that is fallible, since axum requires all services to be infallible.

While we're here though: why does Either need to hold pinned values at all? Is this is just to implement Future? Doesn't the futures crate already ship a version of Either that implements Future? Perhaps we can remove this functionality completely in the next minor release?

It's part of futures-util: https://docs.rs/futures-util/latest/futures_util/future/enum.Either.html

What I wrote about either::Either could of course be done with that one too. The impls in tower-service and tower-layer could even be added in a patch release, then other crates could build things off of that sooner.

While we're at it I also think we should change Either to not use BoxError as the error type but instead require the two inner services to have the same error type and use that. I've found it odd that combining two infallible services and gives you one that is fallible, since axum requires all services to be infallible.

👍 I've had this issue as well and had to roll my own option_layer because of it, including another separate Either type.