Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The bound here is copied from
tracing-futures. It might be worth adding aFuturebound to avoid polluting autocompletes too much though?Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The
tracing-futuresversion does not have aFuturebound because it also allows wrapping types implementing other traits, such asStream, with a subscriber. However,tracing's version only provides implementations forFuture, becausetracingdepends only on the standard library, not thefuturescrate. So, it should be fine to restrict the blanket impl toT: Future, here.However, when the
Streamtrait eventually does make it intostd, we'll probably want to add aStreamimpl forWithSubscriber<T: Stream>, as well. Then, we'll have to make the blanket impl more general. Technically, I think this is a breaking change, as it could break userWithSubscriberimpls for types that don't implementFuture. To protect against that, I think we would need to seal the trait so that downstream code can't addWithSubscriberimpls. Then, it would be fine to add aFuturebound on the blanket impl, for now.