What are move semantics in Rust?

by

Semantics

Rust implements what is known as an Affine Type System:

Affine types are a version of linear types imposing weaker constraints, corresponding to affine logic. An affine resource can only be used once, while a linear one must be used once.

Types that are not Copy, and are thus moved, are Affine Types: you may use them either once or never, nothing else.

Rust qualifies this as a transfer of ownership in its Ownership-centric view of the world (*).

(*) Some of the people working on Rust are much more qualified than I am in CS, and they knowingly implemented an Affine Type System; however contrary to Haskell which exposes the math-y/cs-y concepts, Rust tends to expose more pragmatic concepts.

Note: it could be argued that Affine Types returned from a function tagged with #[must_use] are actually Linear Types from my reading.

Implementation

It depends. Please keep in mind than Rust is a language built for speed, and there are numerous optimizations passes at play here which will depend on the compiler used (rustc + LLVM, in our case).

Within a function body (playground):

fn main() {
    let s = "Hello, World!".to_string();
    let t = s;
    println!("{}", t);
}

If you check the LLVM IR (in Debug), you’ll see:

%_5 = alloca %"alloc::string::String", align 8
%t = alloca %"alloc::string::String", align 8
%s = alloca %"alloc::string::String", align 8

%0 = bitcast %"alloc::string::String"* %s to i8*
%1 = bitcast %"alloc::string::String"* %_5 to i8*
call void @llvm.memcpy.p0i8.p0i8.i64(i8* %1, i8* %0, i64 24, i32 8, i1 false)
%2 = bitcast %"alloc::string::String"* %_5 to i8*
%3 = bitcast %"alloc::string::String"* %t to i8*
call void @llvm.memcpy.p0i8.p0i8.i64(i8* %3, i8* %2, i64 24, i32 8, i1 false)

Underneath the covers, rustc invokes a memcpy from the result of "Hello, World!".to_string() to s and then to t. While it might seem inefficient, checking the same IR in Release mode you will realize that LLVM has completely elided the copies (realizing that s was unused).

The same situation occurs when calling a function: in theory you “move” the object into the function stack frame, however in practice if the object is large the rustc compiler might switch to passing a pointer instead.

Another situation is returning from a function, but even then the compiler might apply “return value optimization” and build directly in the caller’s stack frame — that is, the caller passes a pointer into which to write the return value, which is used without intermediary storage.

The ownership/borrowing constraints of Rust enable optimizations that are difficult to reach in C++ (which also has RVO but cannot apply it in as many cases).

So, the digest version:

  • moving large objects is inefficient, but there are a number of optimizations at play that might elide the move altogether
  • moving involves a memcpy of std::mem::size_of::<T>() bytes, so moving a large String is efficient because it only copies a couple bytes whatever the size of the allocated buffer they hold onto

More Related Contents:

  1. Temporarily move out of borrowed content
  2. Does println! borrow or own the variable?
  3. Do mutable references have move semantics?
  4. How does Rust provide move semantics?
  5. Why is the mutable reference not moved here?
  6. Is it possible to return either a borrowed or owned type in Rust?
  7. Type mismatches resolving a closure that takes arguments by reference
  8. Why does the compiler not complain that an iterator moved to a for loop is immutable?
  9. Can Rust optimise away the bit-wise copy during move of an object someday?
  10. How do I create a heterogeneous collection of objects?
  11. Is it possible to control the size of an array using the type parameter of a generic?
  12. How do I stop iteration and return an error when Iterator::map returns a Result::Err?
  13. Are polymorphic variables allowed?
  14. Error while trying to borrow 2 fields from a struct wrapped in RefCell
  15. “Expected fn item, found a different fn item” when working with function pointers
  16. What does “mismatched types: expected `()`” mean when using an if expression?
  17. How do I read the entire body of a Tokio-based Hyper request?
  18. When returning the outcome of consuming a StdinLock, why was the borrow to stdin retained?
  19. How does Rust pattern matching determine if the bound variable will be a reference or a value?
  20. Using generic trait methods like .into() when type inference is impossible
  21. Why does an enum require extra memory size?
  22. Why does Rust disallow mutable aliasing?
  23. How to store rusqlite Connection and Statement objects in the same struct in Rust? [duplicate]
  24. print! macro not executed until pressing Enter
  25. How can I override a constant via a compiler option?
  26. Why am I getting “parameter is never used [E0392]”?
  27. What is the purpose of the unit type in Rust?
  28. Why does the Rust compiler request I constrain a generic type parameter’s lifetime (error E0309)?
  29. Cannot pass self as callback parameter due to double borrowing
  30. How do I create a HashMap with type erased keys?

Leave a Comment