Rust Memory And State

Rust Memory and State

Use this when the question is really "who owns this, who may mutate it, and how long must it stay valid?"

Working stance

• Prefer one clear owner and cheap borrowed reads.
• Reach for cloning last, not first.
• If cloning appears mainly to placate the borrow checker, fix the data flow before keeping the clone.
• Treat Rc, Arc, RefCell, Mutex, and RwLock as ownership decisions, not syntax bandages.
• If a lifetime gets hard to express, ask whether the type should own the data.
• Use RAII to make cleanup happen by scope, not by hope.

Decision surface

Red flags

• clones multiply each time the borrow checker complains,
• Rc or Arc shows up where one owner plus borrowed readers would do,
• Arc<Mutex<T>> appears before the real sharing pattern is known,
• references are stored where owning data would simplify the type,
• resource release depends on "remember to call close()",
• 'static is used to silence a lifetime problem instead of explaining one.

Read borrow-and-own-patterns.md for API choices, interior-mutability.md for shared mutation, lifecycle-and-raii.md for resource scope patterns, and encapsulation-and-raii.md for ownership as an architectural lever and the Mutex/MutexGuard/Drop wireframe.

Source: leynos/rust-skill — distributed by TomeVault.