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.
I suppose we could give the body without wrapping it prematurely, and then anyone needing to unify it could wrap it themselves. If they didn't need to, we could save them a boxed trait object.
Is there any reason we shouldn't do that?
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.
Sounds good I just don't know how as the body returned by
into_parts
has the privateDecoder
type so we need to wrap it some way right? If this were a method I suppose we could returnhttp::Response<impl Stream<..>>
. What do you think?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.
In at least the blocking implementation, I'd like to use a similar conversion trait for a simple
Vec<u8>
. See howureq
provides a few of them:https://github.com/algesten/ureq/blob/916ffbffbe098d28d9ac142054484fd71423d9a6/src/http_interop.rs#L55-L129
Seems there's also #1258, #1483, #1612 to track and implement (something) like this. The latter being a PR implementing the same trait in
src/async_impl/response.rs
but for anything with aFrom<Decoder>
. @seanmonstar is one of these PRs "superseding" the other? Can I help gain some traction on any of these?