m01-ownership

Original：🇺🇸 English

Translated

CRITICAL: Use for ownership/borrow/lifetime issues. Triggers: E0382, E0597, E0506, E0507, E0515, E0716, E0106, value moved, borrowed value does not live long enough, cannot move out of, use of moved value, ownership, borrow, lifetime, 'a, 'static, move, clone, Copy, 所有权, 借用, 生命周期

2installs

Sourcezhanghandong/rust-skills

Added on2026-02-04

NPX Install

npx skill4agent add zhanghandong/rust-skills m01-ownership

SKILL.md Content

View Translation Comparison →

Ownership & Lifetimes

Layer 1: Language Mechanics

Core Question

Who should own this data, and for how long?

Before fixing ownership errors, understand the data's role:

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

Error → Design Question

Error	Don't Just Say	Ask Instead
E0382	"Clone it"	Who should own this data?
E0597	"Extend lifetime"	Is the scope boundary correct?
E0506	"End borrow first"	Should mutation happen elsewhere?
E0507	"Clone before move"	Why are we moving from a reference?
E0515	"Return owned"	Should caller own the data?
E0716	"Bind to variable"	Why is this temporary?
E0106	"Add 'a"	What is the actual lifetime relationship?

Thinking Prompt

Before fixing an ownership error, ask:

What is this data's domain role?
- Entity (unique identity) → owned
- Value Object (interchangeable) → clone/copy OK
- Temporary (computation result) → maybe restructure
Is the ownership design intentional?
- By design → work within constraints
- Accidental → consider redesign
Fix symptom or redesign?
- If Strike 3 (3rd attempt) → escalate to Layer 2

Trace Up ↑

When errors persist, trace to design layer:

E0382 (moved value)
    ↑ Ask: What design choice led to this ownership pattern?
    ↑ Check: m09-domain (is this Entity or Value Object?)
    ↑ Check: domain-* (what constraints apply?)

Persistent Error	Trace To	Question
E0382 repeated	m02-resource	Should use Arc/Rc for sharing?
E0597 repeated	m09-domain	Is scope boundary at right place?
E0506/E0507	m03-mutability	Should use interior mutability?

Trace Down ↓

From design decisions to implementation:

"Data needs to be shared immutably"
    ↓ Use: Arc<T> (multi-thread) or Rc<T> (single-thread)

"Data needs exclusive ownership"
    ↓ Use: move semantics, take ownership

"Data is read-only view"
    ↓ Use: &T (immutable borrow)

Quick Reference

Pattern	Ownership	Cost	Use When
Move	Transfer	Zero	Caller doesn't need data
`&T`	Borrow	Zero	Read-only access
`&mut T`	Exclusive borrow	Zero	Need to modify
`clone()`	Duplicate	Alloc + copy	Actually need a copy
`Rc<T>`	Shared (single)	Ref count	Single-thread sharing
`Arc<T>`	Shared (multi)	Atomic ref count	Multi-thread sharing
`Cow<T>`	Clone-on-write	Alloc if mutated	Might modify

Error Code Reference

Error	Cause	Quick Fix
E0382	Value moved	Clone, reference, or redesign ownership
E0597	Reference outlives owner	Extend owner scope or restructure
E0506	Assign while borrowed	End borrow before mutation
E0507	Move out of borrowed	Clone or use reference
E0515	Return local reference	Return owned value
E0716	Temporary dropped	Bind to variable
E0106	Missing lifetime	Add `'a` annotation

Anti-Patterns

Anti-Pattern	Why Bad	Better
`.clone()` everywhere	Hides design issues	Design ownership properly
Fight borrow checker	Increases complexity	Work with the compiler
`'static` for everything	Restricts flexibility	Use appropriate lifetimes
Leak with `Box::leak`	Memory leak	Proper lifetime design

Related Skills

When	See
Need smart pointers	m02-resource
Need interior mutability	m03-mutability
Data is domain entity	m09-domain
Learning ownership concepts	m14-mental-model