As stated in [Accepted] SE-0507: Borrow and Mutate Accessors, I want to pitch alternative names.
Introduction
This proposal suggests renaming ownership-related accessors and types introduced in:
These changes aim to improve terminological consistency and grammatical clarity, making the terminology more coherent, while preserving the semantics introduced by the accepted proposals.
Because these features have not yet shipped in a stable Swift release, the window for renaming remains open.
Motivation
The ownership model introduced by recent Swift Evolution proposals significantly expands the language's ability to express borrowing and mutation semantics.
However, the current naming introduces several inconsistencies.
Current accessors are typically verbs, as they describe the operation or action being performed on the data, such as:
get
set
However, borrow and mutate are verbs that describe the ownership semantics rather than the access behavior. This creates an inconsistency, as the accessors are no longer describing what the accessor does (like get or set), but instead describing a broader ownership concept (borrowing or mutation), which doesn’t match how current accessors behave.
To make this clearer, replacing borrow with borrowed and mutate with mutable shifts the focus from the action (verb) to the type of access (adjective), which is more consistent with how new accessors work.
By using adjectives like borrowed and mutable, we clarify that we are describing the nature of the access (borrowed or mutable), not instructing the program to perform an action.
mutate reads like a directive rather than a capability
The keyword mutate reads like an imperative action, suggesting mutation should occur, rather than describing the possibility of mutation.
This difference becomes especially visible when combined with modifiers:
var value: NC {
mutating borrow { ... }
nonmutating mutate { ... }
}
The phrase nonmutating mutate is grammatically confusing and conceptually contradictory:
- nonmutating indicates that the accessor does not mutate self
- mutate is read as a directive to perform mutation
Such wording is awkward.
The resulting phrase reads roughly as: "perform mutation without mutating" which is unintuitive even when semantic is understood.
Rationale
The proposed names follow three principles:
- Use adjectives to describe the nature of access
- Align accessor names with type names
- Improve readability when combined with accessor modifiers
Proposed Solution
This proposal renames the ownership-related accessors and types introduced in the referenced proposals. It introduces the following renamings:
Accessors
| Current | Proposed |
|---|---|
| borrow | borrowed |
| mutate | mutable |
Types
| Current | Proposed |
|---|---|
| Borrow | Borrowed |
| Inout | Mutable |
Example:
var value: NC {
borrowed { ... }
mutable { ... }
}
This reads naturally as:
- the property can be borrowed
- the property can be accessed mutably
In other words it is clear that value is borrowed / mutable.
Detailed Design
1. Consistency with Swift ownership terminology
Swift uses adjectival ownership terms like borrowing, consuming, and mutating to describe access and ownership behavior:
| Concept | Usage |
|---|---|
| borrowing | borrowing parameters |
| consuming | consuming parameters |
| mutating | mutating methods |
Using borrowed and mutable aligns well with this vocabulary.
They describe how the property can be accessed instead of describing what the accessor does.
2. Alignment with type names
SE-0519 introduces types representing borrowing and mutable access:
Borrow<T>
Inout<T>
These names differ stylistically:
- Borrow describes an action
- Inout (inout) describes a parameter passing convention
Renaming them to:
Borrowed<T>
Mutable<T>
aligns them with the proposed accessor terminology.
Example:
mutating func at(index: Int) -> Mutable<Double>
This reads naturally as: "returns a mutable reference to the element."
Renaming Borrow<T> to Borrowed<T> and Inout<T> to Mutable<T> aligns type names with the proposed accessor terminology and improves consistency in Swift’s ownership model.
3. Improved readability in combined accessors
Swift allows accessors to be combined with mutating / nonmutating.
Replacing mutate with mutable improves the interaction with accessor modifiers:
var value: NC {
mutating borrowed { ... }
nonmutating mutable { ... }
}
This reads as:
- mutating borrowed access
- nonmutating mutable access
which is easier to interpret and understand.
While nonmutating mutable may still seem strange at first, it actually reflects the intended semantics: "providing mutable access without mutating self."
In other words, the accessor describes the kind of access being provided, rather than performing an action or directive.
Yielding accessors
The yielding keyword marks an accessor as allowing for the temporary borrowing or mutable access of a property.
Borrowed Accessor
var value: NC {
yielding borrowed { ... }
}
Mutable Accessor
var value: NC {
get { ... }
yielding mutable { ... }
}
Source Compatibility
None.
The features have not yet been released, so renaming them introduces no source compatibility concerns.
Effect on ABI Stability
None.
This proposal affects not yet released features
Alternatives Considered
1. Keep the existing borrow / mutate names
Pros
- Already implemented
- Shorter names
Cons
- Verb-based naming is inconsistent with accessor terminology
- Produces awkward spellings
â €
2. Only rename types (Borrow → Borrowed, Inout → Mutable)
Pros
- Improves SE-0519 clarity
- Minimal changes
Cons
- Leaves a mismatch between the type names and accessor terminology
Conclusion
Renaming these constructs to borrowed and mutable creates a consistent vocabulary across:
- yielding accessors
- borrowing/mutation accessors
- types representing borrowing or mutable references
while improving readability.
