Ownership is a design question
A small Rust lesson: before asking how to share a value, ask who should own it.
Example entry — included to show the design, not a claim about the author’s personal history.
When a Rust program becomes difficult to express, it is tempting to reach for clone() until the compiler is satisfied.
Sometimes a clone is exactly right. But sometimes the compiler is pointing to a question the design has not answered yet: who is responsible for this value?
Start with the lifetime of the work
Suppose a function only needs to inspect a title. It does not need to own the allocation. A borrowed string is enough:
fn title_is_empty(title: &str) -> bool {
title.trim().is_empty()
}
The caller keeps ownership. The function receives temporary access. No allocation is required just to answer the question.
Now suppose a background worker must keep that title after the caller returns. The situation has changed. The worker needs owned data, or an explicitly shared owner that lives long enough.
The useful distinction is not "borrowing good, cloning bad." It is whether the lifetime of the value matches the lifetime of the work.
Three questions to ask
| Question | Why it matters |
|---|---|
| Does this function keep the value? | A temporary borrow may be enough if it does not. |
| Does it change the value? | Mutable access should have a clear, limited scope. |
| Does another task need it later? | Ownership must outlive the original call. |
An ownership error can be useful design feedback. It is worth listening before making it disappear.
Example technical entry. Replace this with your own notes, code, and conclusions.