In Rust, every value has a single owner, and that owner is responsible for the value’s cleanup when it goes out of scope. When ownership moves, the previous binding can no longer be used, which prevents double frees and dangling references. Borrowing lets you access data without taking ownership, and references are constrained by rules that ensure shared access stays safe and mutable access stays exclusive. Lifetimes describe, at a conceptual level, how long a reference must remain valid so borrowed data cannot outlive the value it points to.
Understand Rust Ownership Clearly
Learn how moves, borrowing, lifetimes, and slices work together to keep Rust memory-safe and efficient.
Read the lessonHow ownership keeps data safe
Core concepts and common mistakes
Immutable references
Use immutable references when you need read-only access to a value without moving it. Multiple immutable borrows are allowed at the same time as long as no mutable borrow is active.
Mutable references
Use a mutable reference when a function or block needs to change a value in place. Rust allows only one mutable borrow at a time, and it must not overlap with active immutable borrows.
Slices for arrays and strings
Slices let you work with a view into part of an array or string without copying the underlying data. They are useful when you only need a segment, such as a range of elements or a substring.
Ownership errors and fixes
Common errors include using a value after it has moved, borrowing a value mutably while it is already borrowed immutably, or keeping a reference alive too long. Fix them by passing references instead of ownership, narrowing borrow scope, or restructuring code so access patterns do not overlap.
Common questions about ownership
When does a value move in Rust?
A value moves when ownership is transferred to another variable or function parameter, typically for types that are not copied by default. After the move, the original binding is no longer valid.
Why can’t mutable and immutable borrows overlap?
Rust prevents overlapping mutable and immutable borrows to avoid reading data while it is changing. This rule preserves safety without needing runtime checks.
How do I recognize an ownership error?
Ownership errors usually mention moved values, borrowing conflicts, or references that may not live long enough. The message often points to the exact line where access rules are violated.
What is the usual fix for borrow conflicts?
Prefer borrowing over moving, shorten the lifetime of a reference by limiting its scope, or clone only when you truly need separate owned data. In many cases, a small refactor removes the conflict cleanly.