`Unpin` bound in `impl<P> Body for Pin<P>` is unnecessarily restrictive
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 173
- Forks
- 69
- Avg merge
- 6d 15h
- Merged PRs (30d)
- 4
Description
the current code is :
impl<P> Body for Pin<P>
where
P: Unpin + ops::DerefMut,
P::Target: Body,
{
// ....
fn poll_frame(
self: Pin<&mut Self>,
cx: &mut Context<'_>,
) -> Poll<Option<Result<Frame<Self::Data>, Self::Error>>> {
Pin::get_mut(self).as_mut().poll_frame(cx)
}
// ....
}
th correct code should be
impl<P> Body for Pin<P>
where
P: ops::DerefMut,
P::Target: Body,
{
// ....
fn poll_frame(
self: Pin<&mut Self>,
cx: &mut Context<'_>,
) -> Poll<Option<Result<Frame<Self::Data>, Self::Error>>> {
self.as_deref_mut().poll_frame(cx)
}
// ....
}
without the Unpin bound. this likely has gone unnoticed as a !Unpin pinning pointer is a very strange idea, and all pinning pointers in std are Unpin.
but it is possible for such a type to exist, and thus this bound is making the api unnecessarily restrictive.
edit : i just saw as_deref_mut requires rust 1.84, which would be a significant bumb(prob unaceptably so) .
while there is no doubt this is sound in in earlier versions, i'm unsure wether the addition of unsafe code would be warranted.
maybe something to keep in mind for later , when/if http-body's msrv increases
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at the impl<P> Body for Pin<P> implementation shown in the issue and review how its Unpin bound affects !Unpin pointer types. Check the proposed as_deref_mut approach against the project's Rust MSRV and determine whether the bound can be removed without introducing unsupported or unjustified unsafe code.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- backend-api-design
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100