A while back, I proposed an RFC for a DerefMove trait, with the hopes of making part of Box's magic removable from the compiler.
Unfortunately, I neglected to account for partial moves out of Box, which means that it is not implementable as proposed in a backwards compatible manner.
I think it may be possible to implement DerefMove as an extension to the current mechanisms, however, if we make it extremely magical. For an explanation of how magical I mean, see this post.
The question then is whether this is worth pursuing, possibly as a direction towards &move references, or whether it is better holding off and revamping this into proper &move support. Thoughts?
I think we should have explicit &move in the language, even if we have unsized rvalues. There are a few good reasons for them:
They have a lifetime. This means they can be returned from functions just fine, whereas Unsized rvalues can’t be (at least, not without some sort of compiler magic involving implicit alloca and memcpy). I’m not sure what the signature of deref_move would be with unsized rvalues, but with &move it’s fairly straightforward: fn deref_move<'a>(&'a move self) -> &'a move Self::Target or some variation thereof
When you pass an &move T to a function, it is guaranteed not to be moved in memory1, so this would be a good building block for an owned version of Pin
@alercah FWIW, I would be interested in collaborating on an RFC that introduced &move references and DerefMove.
1 which is why @eddyb prefers to call it &own and not &move
Yes, I agree. One advantage to properly having &move is it becomes very clear how to handle storage for a deref_move—something that is very tricky to do otherwise.
@alercah can you clarify what you mean by "handling storage"?
Wait, why does &move provide a basis for an owning Pin ?
Right now we have PinMut<'a, T>, which mutably borrows a T, and there is talk of a Pin<'a, T> which borrows immutably. You could imagine a PinMove<'a, T> or PinOwned<'a, T> that wraps &'a move T