0

Can we tinker with move semantics in rust.

Maybe reimplement Move behavior just like Clone?

Or at least attach pre or post move hook to execute custom logic?

links to official rust docs would be appreciated.

From the internal language redesign proposal thread Idea: Limited custom move semantics through explicitly specified relocations it seems it's not present.

but I want make sure there no way of achieving it.

Arjun
  • 3,248
  • 18
  • 35
  • 3
    No, you cannot change how the compiler issues a move and there is no user-defined code that is executed. This sounds like an XY problem though, what is your goal? – kmdreko Jul 08 '22 at 04:23
  • 1
    Rust considers all types to be movable. [`Pin`](https://doc.rust-lang.org/stable/std/pin/index.html) weakens this a bit, but IIRC, what you want isn't possible. [See also](https://stackoverflow.com/questions/29490670/how-does-rust-provide-move-semantics). – Caesar Jul 08 '22 at 04:34
  • @Caesar wanted a trigger when a value is moved. – Arjun Jul 08 '22 at 08:33
  • I should have been more specific: "Rust considers all types to be always trivially movable". If there was some user code to be run, that might fail and rust won't be able to introduce and remove moves as it wants. It might also get in the way of optimizations. But eh, if you want move constructors, you can create [something](https://mcyoung.xyz/2021/04/26/move-ctors/) that at least feels like a move constructor. – Caesar Jul 08 '22 at 10:00
  • You can hack on the compiler to change the semantics of move. Is your question whether there is an easier way to do it? – hkBst Jul 08 '22 at 10:25

1 Answers1

1

Not just there is no such way, and not just this is a good thing (IMO), changing that is basically impossible now, and all proposal that attempted to do that were opt-in rather than opt-out (that is, your generic type should declare support in non-bitwise moves, or it will not support them. Basically some kind of opt-out trait ?Move). That means that a lot of things won't support them, at least in the ecosystem if not in std too.

This is for a very simple reason: lots of unsafe code relies on moves to be bitwise. If a move can execute user code, that also means it can panic, and now unsafe code has to defend against that. Or they can leave the object in invalid state even if it wasn't before. Basically, they can do anything, and this anything can mean anything to unsafe code. And anything possible in unsafe code means undefined behavior. So no existing unsafe code will be able to live with this moves, which means that no code at all will be able to and each type will have to declare if it supports them.

Not to mention the optimization benefits or that it's much easier to reason about bitwise move.

I don't think there was ever a RFC to do that, although I may not be aware (there was a RFC for ?Move, but it was replaced by Pin).

If you need a way to customize moves, you don't want moves. Use Clone or some other trait.

Chayim Friedman
  • 47,971
  • 5
  • 48
  • 77