| > A common case where this is useful is if the address space where the object lives is accessible, for read or write, by references exogenous to the process like some kinds of shared memory or hardware DMA. Huh? Okay, I allocate some memory and DMA-map it to the device [0]. Then: 1. Device uses it. 2. I copy or otherwise consume the data. Hopefully not in a way that causes UB. 3. I’m logically done, but maybe the device isn’t. 4. I’m 100% done, and I unmap the memory. And it’s an error if the device touches it again. Why would I represent steps 2 and 3 as std::move? Maybe this results in efficient code in some particular code base, but it is not idiomatic, and I can almost guarantee that the same performance could be achieved in a less mind-bending and expectation-defying manner that doesn’t call itself a move. I don’t see why Rust would have any particular trouble with this as long as you don’t try to force the lifetime of a DMA allocation or mapping into an object that doesn’t live long enough. [0] The mapping operation may or may not be a no-op given IOMMUs, various VM translation schemes, etc. |