- Home
- Skills
- Zhanghandong
- Rust Skills
- M01 Ownership
m01-ownership_skill
- Shell
565
GitHub Stars
2
Bundled Files
3 weeks ago
Catalog Refreshed
2 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstart where the catalogue uses aiagentskills.
npx veilstart add skill zhanghandong/rust-skills --skill m01-ownership- comparison.md5.6 KB
- SKILL.md4.1 KB
Overview
This skill focuses on diagnosing and resolving Rust ownership, borrowing, and lifetime issues. It targets common compiler errors like moved value, borrowed value does not live long enough, cannot move out of, use of moved value, and lifetime annotation problems. Use it when you need concrete guidance on whether to move, borrow, clone, or redesign ownership.
How this skill works
The skill inspects the error code and the surrounding code intent to map the compiler message to design questions: who should own the data, how long it must live, and whether it should be shared or exclusive. It suggests targeted remedies (references, cloning, smart pointers, lifetime annotations, or API redesign) and traces persistent failures to higher-level design decisions or adjacent skills like resource sharing and mutability. It provides quick pattern references and anti-pattern warnings to avoid repeated fixes that mask design issues.
When to use it
- When you see errors E0382, E0597, E0506, E0507, E0515, E0716, or E0106
- When value moved or use of moved value appears in compilation
- When borrowed value does not live long enough or you need to return references
- When deciding between move, borrow, clone, Rc/Arc, or Cow
- When repeated fixes indicate a design-level ownership problem
Best practices
- Ask who should own the data and for how long before applying a fix
- Prefer redesign (API or scope) over cloning everywhere to avoid hidden costs
- Use &T for read-only, &mut T for temporary exclusive access, and owned types for returned or long-lived data
- Choose Rc/Arc for shared ownership and Cow for conditional clone-on-write
- Trace persistent errors up to domain/resource/mutability choices rather than patching locally
Example use cases
- Fixing E0382 by deciding whether to move ownership or use a reference/Arc for shared reuse
- Resolving E0597 by extending the owner scope or returning an owned value instead of a reference
- Handling E0506/E0507 by restructuring code to end borrows before mutation or cloning when appropriate
- Addressing E0515 by changing function signatures to return owned data instead of references
- Eliminating transient lifetime issues (E0716/E0106) by binding temporaries or adding accurate lifetime annotations
FAQ
Clone when values are cheap and truly independent; use Rc/Arc when multiple parts must share the same allocation without copying, choosing Arc for multi-threaded contexts.
Is adding 'static a safe lifetime shortcut?
No—'static often hides design problems and reduces flexibility. Prefer precise lifetimes or owned types that reflect actual data scope.