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

[CAD97]

@Yandros

Yep, will do; I wish [compile-fail tests] were easier to set up, though

trybuild makes this easier than ever.

[Yandros]

@RalfJung

We might even allow overlapping marker trait impls without specialization as they don’t have all the problems of overlapping general impls.

So, yeah, here it becomes very annoying that Unpin is safe to implement. Cc @withoutboats @cramertj

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

impl Unpin for SelfReferential
where
    (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

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
(I had tested ::compiletest_rs, and had issues with rebuilds and 2018 edition)

[RalfJung]

@Yandros

• (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

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

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.

@Yandros

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 .

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.