Ownership & Lifetimes

Core Question

Who should own this data, and for how long?

Before fixing an ownership error, understand the data's role:

• Is it shared or exclusive?
• Is it short-lived or long-lived?
• Is it transformed or just read?

The compiler tells you what broke. Your job is to figure out why the ownership design led here.

Error → Design Question

Don't just silence the compiler — ask what the error reveals about your design.

If you've tried the same fix twice and it cascades, the ownership design is wrong — not just the syntax.

Quick Decisions

Smart Pointer Decision Tree

Need shared ownership?
├── Yes → Across threads?
│   ├── Yes → Arc<T>
│   │   └── Need mutation? → Arc<Mutex<T>> or Arc<RwLock<T>>
│   └── No → Rc<T>
│       └── Need mutation? → Rc<RefCell<T>>
└── No → Need heap allocation?
    ├── Yes → Box<T>
    └── No → Use stack (move or borrow)

When choosing between Mutex and RwLock:

• Reads dominate (>80% reads) → RwLock<T>
• Frequent writes or very brief locks → Mutex<T>
• Single thread → RefCell<T> (no locking overhead)
• Performance critical → consider parking_lot crate

Lifetime Elision

Rust elides lifetimes automatically in most cases. Don't annotate unless required.

The three elision rules:

1. Each input reference gets its own lifetime
2. If exactly one input lifetime, output gets that lifetime
3. If &self or &mut self is an input, output gets self's lifetime

When you MUST annotate:

• Multiple input references with ambiguous output lifetime
• Structs holding references
• Multiple distinct lifetime relationships
• 'static bounds

Use anonymous lifetime '_ for clarity when the compiler needs a hint but the specific lifetime doesn't matter: impl fmt::Display for Wrapper<'_>.

Usage Scenarios

Scenario 1: "I'm getting E0382 — value used after being moved" → Don't immediately add .clone(). Ask: does the second use actually need ownership? If it only reads, take a reference. If both uses need ownership, consider Rc/Arc or restructuring so one use happens before the other.

Scenario 2: "Should I use Arc or clone this config into each thread?" → If the config is read-only after creation, Arc<Config> is cheaper — one allocation shared by all threads. If each thread might modify its copy, clone before spawning.

Scenario 3: "I need to update a cache behind a shared reference" → This is interior mutability. Single thread? RefCell<HashMap<K, V>>. Multi-thread? Mutex<HashMap<K, V>> or RwLock<HashMap<K, V>> if reads dominate. Consider dashmap for concurrent maps.

Reference Files

Read these when you need depth beyond the quick reference above.

Cross-References