diff options
| author | Jon Gjengset <jon@thesquareplanet.com> | 2021-01-24 16:43:54 -0800 |
|---|---|---|
| committer | Jon Gjengset <jon@thesquareplanet.com> | 2021-03-28 12:37:09 -0700 |
| commit | 3b2b5b2914d40aa011d189bfe546084cdee53dbe (patch) | |
| tree | 5d23738c950c4a4df4561f2582c8933c9e859084 /tests/mir-opt/lower_array_len.array_bound_mut.NormalizeArrayLen.panic-unwind.diff | |
| parent | 0239876020e9a44593e7946af92b35728eede5ae (diff) | |
| download | rust-3b2b5b2914d40aa011d189bfe546084cdee53dbe.tar.gz rust-3b2b5b2914d40aa011d189bfe546084cdee53dbe.zip | |
Remove P: Unpin bound on impl Future for Pin
The `Unpin` bound was originally added in #56939 following the recommendation of @withoutboats in https://github.com/rust-lang/rust/issues/55766#issue-378417538 That comment does not give explicit justification for why the bound should be added. The relevant context was: > [ ] Remove `impl<P> Unpin for Pin<P>` > > This impl is not justified by our standard justification for unpin > impls: there is no pointer direction between `Pin<P>` and `P`. Its > usefulness is covered by the impls for pointers themselves. > > This futures impl (link to the impl changed in this PR) will need to > change to add a `P: Unpin` bound. The decision to remove the unconditional impl of `Unpin for Pin` is sound (these days there is just an auto-impl for when `P: Unpin`). But, I think the decision to also add the `Unpin` bound for `impl Future` may have been unnecessary. Or if that's not the case, I'd be very interested to have the argument for why written down somewhere. The bound _appears_ to not be needed, since the presence of a `Pin<P>` should indicate that it's safe to project to `Pin<&mut P::Target>` just like for `Pin::as_mut`.
Diffstat (limited to 'tests/mir-opt/lower_array_len.array_bound_mut.NormalizeArrayLen.panic-unwind.diff')
0 files changed, 0 insertions, 0 deletions
