| name | swift-ownership |
| description | Use when Swift code owns a unique resource, has `~Copyable`/`borrowing`/`consuming` diagnostics, or needs an ownership-aware API. Do not invoke for ordinary value-type refactors with no lifetime or transfer invariant. |
Swift ownership
Make the ownership invariant explicit before choosing syntax. The goal is a statically checkable lifecycle, not maximum use of ownership keywords.
Procedure
- Name the resource and its invariant: who owns it, when it becomes usable, what ends its lifetime, and whether duplication is meaningful.
- Classify the value: freely copyable value, shared identity, or uniquely owned resource. Do not use a class merely to avoid a compiler diagnostic.
- Choose the smallest model that proves the invariant. Use
~Copyable for unique resources; keep ordinary domain values copyable.
- Design operations from their semantics:
borrowing observes without taking ownership, consuming takes the value, inout mutates exclusive access. For copyable values, default conventions are often sufficient.
- Compile the smallest example that exercises the lifetime. Treat diagnostics as design feedback; do not add
consume, copy, or @unchecked just to silence them.
- Test success, failure, early return, thrown error, and repeated finalization paths.
Non-negotiable distinctions
consuming gives the callee ownership. A copyable argument may still be preserved by a copy; a noncopyable argument is unavailable after consumption.borrowing does not extend a value beyond the borrow and cannot be used to manufacture an independent result without an explicit copy where legal.~Copyable is a capability constraint, not a performance decoration. A type that contains a noncopyable member must model its containing lifetime accordingly.- A
deinit is a last-resort cleanup safety net, not permission to make cleanup order implicit when explicit finish/close semantics matter.
- Generic parameters are copyable by default. Add
~Copyable only when the generic algorithm preserves unique ownership and its API can express the transfer.
For detailed rules and diagnostic patterns, read references/ownership-guide.md. Cite the relevant proposal in design notes when the choice is subtle.
Completion contract
Report the ownership invariant, why the representation fits it, every transfer/borrow boundary, and compiler/test evidence. If a resource cannot be proven to close exactly once, say so explicitly.
