# Can \`Box\\>\` be a replacement for \`&'a move T\`? **URL:** https://internals.rust-lang.org/t/can-box-t-noop-a-be-a-replacement-for-a-move-t/21460 **Category:** language design **Created:** [September 1, 2024, 4:25pm UTC](https://internals.rust-lang.org/t/can-box-t-noop-a-be-a-replacement-for-a-move-t/21460 "2024-09-01T16:25:19Z") **Posts on this page:** 4 **Page:** 1
### Author: ![Ddystopia](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/ddystopia/32/10915_2.png) [@Ddystopia](https://internals.rust-lang.org/u/Ddystopia) #### Post date: [September 1, 2024, 4:25pm UTC](https://internals.rust-lang.org/t/can-box-t-noop-a-be-a-replacement-for-a-move-t/21460/1 "2024-09-01T16:25:19Z")
Hello, there is some desire to have `&'a move T`. As far as I can see it is basically a `Box>` - 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`](https://github.com/rust-lang/rust/issues/125868) ), 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>` from `&'static mut T`. I also opened similar issue on [wg-allocators](https://github.com/rust-lang/wg-allocators/issues/133). I'm not proposing to add `Noop<'a>` to std, more like discuss that topic as a whole. ---
### Author: ![CAD97](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/cad97/32/3460_2.png) [@CAD97](https://internals.rust-lang.org/u/CAD97) #### Post date: [September 1, 2024, 6:17pm UTC](https://internals.rust-lang.org/t/can-box-t-noop-a-be-a-replacement-for-a-move-t/21460/2 "2024-09-01T18:17:24Z")
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>` (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. * * * 1. It's desirable to be able to have `Pin<&move T>`, but that doesn't enforce the “drop before deallocate” requirement with the `Box`ish 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. ---
### Author: ![josh](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/josh/32/5934_2.png) [@josh](https://internals.rust-lang.org/u/josh) #### Post date: [September 1, 2024, 7:02pm UTC](https://internals.rust-lang.org/t/can-box-t-noop-a-be-a-replacement-for-a-move-t/21460/3 "2024-09-01T19:02:13Z")
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. ---
### Author: ![steffahn](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/steffahn/32/13288_2.png) [@steffahn](https://internals.rust-lang.org/u/steffahn) #### Post date: [February 23, 2026, 7:03pm UTC](https://internals.rust-lang.org/t/can-box-t-noop-a-be-a-replacement-for-a-move-t/21460/6 "2026-02-23T19:03:02Z")
This topic was automatically closed 540 days after the last reply. New replies are no longer allowed.