Eliza Weisman

Unfortunately, I think being able to introduce trait bounds on `Service::call` futures is a pretty hard requirement for a lot of currently-existing code using `tower` (e.g. any code that spawns...

Potentially, we could consider other breaking changes to the `Service` trait prior to the availability of an RTN feature on stable, such as changing the receiver for `call` to `&self`,...

> People like myself could then already use the nightly feature to already allow async fn like implementations where this is needed / desired. And all is well? Or am...

bdea85784c6a0e210bb41fc58fc57a324a039cce makes a pass at this. I used Scopt rather than Docopt (mostly 'cause type-safety).

Ah, excellent, thank you! I'll see if it works for me.

Yup, it looks like `addSbtPlugin` doesn't resolve correctly, so I added it in `project` as you recommended. Everything appears to work correctly so far.

+1

:+1:

Looks nice on my machine, at least! 

If the intention is to run both connections in _parallel_, you'd probably want to `spawn` the `send` futures, as in ```rust #[tokio::main] async fn main() { pretty_env_logger::init(); let addr1:SocketAddr =...