liveBook · Manning

Move

As explained in Refactoring to Rust

Move semantics is Rust's ownership-transfer behavior, under which a value becomes inaccessible through its original binding after transfer.

Move semantics transfers ownership of a value into another binding or function. After the transfer, the original binding can no longer access that value. section 2.3

Passing an Artwork value to admire_art moves it from main into the function. Rust then drops values when they leave scope, so lifetime graphs show where each binding remains usable. section 2.3

Using a moved value

let art1 = Artwork { name: "The Ordeal of Owain".to_string() }; admire_art(art1); admire_art(art1); // error: use of moved value: art1 section 2.1

Figure 2.4 The lifetime graph in listing 2.5
figure

Inspect the lifetime graph for the failing double-admiration example to see where art1 becomes unreachable. section 2.3

Recognize move behavior through these patterns:

  • Move a value into a function and use it there. section 2.1
  • Keep separate values usable by moving each into a different call site. section 2.3
  • Treat a later use of the original binding as invalid unless the value remains available through another design. section 2.1

How Refactoring to Rust covers it

How deep it goes
Explains ownership transfer, scope-based dropping, and lifetime graphs, without extending beyond these introductory examples.
Examples
Uses Artwork values, admire_art calls, compiler diagnostics, and lifetime graphs.
What you can do after
Diagnose use-of-moved-value errors by tracing ownership transfers and lifetime disappearance across function calls.
How it connects
Connects move semantics with ownership, lifetimes, scopes, functions, and the Copy trait.

Also explained in

Compare how 5 books explain move →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Refactoring to Rust. The section links point to the parts of the book it draws on.