Eliza Weisman

> Apologize for my ignorance, but with GATs right around the corner, tower 1.0 will likely want to change the service trait ala https://tokio.rs/blog/2021-05-14-inventing-the-service-trait#gats, correct? Also, the specific note in...

IMO, the main reason GATs are actually desirable for `tower` is because, if we wanted to implement a design with a `Token` type for storing readiness (e.g. https://github.com/tower-rs/tower/pull/631), GATs would...

FWIW, linkerd/linkerd2-proxy#432 will change the Linkerd fallback implementation you mentioned to operate at the `Service` level, rather than on `Layer`s producing `MakeService`s only. I think that may make it more...

One significant benefit of `poll_ready` (and, a reason that not calling `call` after `poll_ready` needs to be permitted) is that it permits _routing based on readiness_. For example, `tower::balance` can...

At a very high level, I might summarize this by saying that if `tower` only had the `Service::call` future, requests could still _wait_ for readiness, but `poll_ready` allows requesters to...

Related to the split traits approach @olix0r mentions, I remember that a long time ago, `tower` had a `ReadyService` trait that could be implemented by services that are _always_ ready....

@stuhood that approach was proposed in https://github.com/tower-rs/tower/issues/412. At the time, some people looked into what an implementation of that design would look like, and you're correct that, unfortunately; it probably...

@mattklein123: Typically, any resource acquired in `poll_ready` and consumed in `call` will be moved into the returned `call` future. For example, in the `ConcurrencyLimit` service you referenced above, the permit...

> I can propose a documentation improvement PR for poll_ready() if that would be accepted? Sure, we'd love any docs improvements!

I believe the CI issues should have been fixed on master, mind rebasing?