Copy + !Unpin

#1

Technically, this is valid today, as Copy is not bound by Unpin.

Is there any reason to support Copy + !Unpin? If we could turn back the stabilization clock, would we want to add the bound?

#2

I think that Copy types should be Unpin because it becomes very easy to accidentally move a type that is Copy without even knowing it. Especially because Pin implements Deref. So Copy not implying Unpin looks like a possible footgun.

If PhantomPinned wasn’t Copy we may have been able to change this, but (unfortunately) at this point it is too late without breaking stability guarantees.

#3

I think Copy actually does semantically imply Unpin. You must be able to Clone the struct, creating a new owned value, by doing a memcpy. This would mean that doing something that requires !Unpin would mean implementing Copy (though not Clone!) would be unsound.

Also, if a Copy type is !Unpin, you can trivially get around the restriction, as you’ve noted, by just safely copying the value.

Even though it’s technically a breaking change, I’d be behind adding the Unpin bound to Copy retroactively. Unfortunately, this is basically impossible since we actually want PhantomUnpinned to be Copy, right?

#4

I am also behind adding Unpin bound to Copy. I don’t think it is valuable to have PhantomUnpinned be Copy. If you want a new value you could just make a new one or clone an old one. Ergonomics of PhantomUnpinned are not as important as preserving safety.