When is it safe to move a member value out of a pinned future?

trybuild makes this easier than ever.


Well, currently the "best" hack I could find to prevent impl Unpin, since trivial bounds are also unstable, is adding

impl Unpin for SelfReferential
    (SelfReferential,) : Drop,
  • (T,) does not currently implement Drop (and I guess it will never do), so no real Unpin is ever implemented;

  • And yet coherence over-cautious approach does not like it being next to another (unbounded) impl :slight_smile:

error[E0119]: conflicting implementations of trait `std::marker::Unpin` for type `SelfReferential`:
  --> $DIR/unpin.rs:27:1
23 | / impl Unpin for SelfReferential
24 | | where
25 | |     (SelfReferential,) : Drop,
26 | | {}
   | |__- first implementation here
27 |   impl Unpin for SelfReferential {}
   |   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `SelfReferential`
   = note: upstream crates may add new impl of trait `std::ops::Drop` for type `(SelfReferential,)` in future versions

I hope that by the time marker traits impls are allowed to overlap:

  • either negative trait bounds are safe to implement, and do contradict an exact positive counterpart (so that impl !Unpin for X {} and impl Unpin for X {} is considered a contradiction), while allowing a more specialized positive impl.

  • or some kind of item / lang attribute is created that makes implementing Unpin for that kind of item / the affected type require unsafe (in a similar fashion to #[may_dangle] making implementing Drop unsafe)

::try_build is neat :slight_smile:
(I had tested ::compiletest_rs, and had issues with rebuilds and 2018 edition)

Unfortunately both of these are not stable guarantees you can rely on. :frowning:

Coherence can and will get more precise over time, so relying on it being conservative is not gonna fly.

And there are ideas for changing the T: Drop bound to mean "a type that can be dropped", which basically means "any type". See this RFC for why that is a good idea.

That's a good point. I don't know what the current "plan" is for the semantics of overlapping negative and positive impls. But this use-case seems interesting enough that it might be worth digging out whatever RFC discussion is relevant, and leaving a note.


This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.