swift-ownership

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

1. Name the resource and its invariant: who owns it, when it becomes usable, what ends its lifetime, and whether duplication is meaningful.
2. Classify the value: freely copyable value, shared identity, or uniquely owned resource. Do not use a class merely to avoid a compiler diagnostic.
3. Choose the smallest model that proves the invariant. Use ~Copyable for unique resources; keep ordinary domain values copyable.
4. 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.
5. Compile the smallest example that exercises the lifetime. Treat diagnostics as design feedback; do not add consume, copy, or @unchecked just to silence them.
6. 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.