Hello, there is some desire to have &'a move T. As far as I can see it is basically a Box<T, Noop<'a>> - not deallocates anything, has lifetime, usize of space, represents an ownership over T but logical moves do not involve memcpy of T itself.
Also note that &'static mut T is approximately an intersection of &'a mut T and &'move T (as it is sound to move out of 'static mut T
), and box already has a method to make such conversion: Box::leak. Maybe, if it will turn out to be a good idea, some api on Box may be added to create Box<T, Noop<'static>> from &'static mut T.
At a minimum this would strongly want to decouple the allocation capability from deallocation. With the storage API, I've expressed the same concept with Box<T, &mut ManuallyDrop<T>> (and the handle being ZST); the ownership semantics of such a type do match that of (one common understanding of[1]) &move.
But, actually using Box for &move immediately hits ergonomic roadblocks similar to those with Pin. As we would like to be able to get &move to any place that can be moved from, and with the same tracking of partial moves as today, &move does require that it's a language construct to be properly useful to Rust code. For interop with C++ FFI, though, solutions in a library like moveit are indeed sufficient, even though they aren't the most ergonomic for advanced usage.
It's desirable to be able to have Pin<&move T>, but that doesn't enforce the “drop before deallocate” requirement with the Boxish semantics, since a leak isn't for 'static. So some people suggest for &move to also reference the parent scope's drop flags, such that it can drop the value if it hasn't been yet, or want &move to be pseudo-linear (cannot be leaked). This also ties into desires for &move to also cover other ownership patterns more generally than solely take. And then there's some potential argument for making &move T transparently act like T instead of like a reference sometimes (e.g. C++ reference semantics), e.g. as an explicit form of what function call abi does. ↩︎
One of the difficulties here is tracking which of several things people mean by &move.
The most common proposal I've seen for &move is for move-only places: things that can be reconstructed but don't necessarily have the same memory layout as the type, such as a bool placed into a niche of another type. This would require native language support. Box wouldn't suffice for that.
There have also been proposals for &own or similar, which is an owned pointer that does have a Drop. Box wouldn't suffice for that either.