# Rename borrow / mutate Accessors and Borrow / Inout Types to borrowed / mutable

**URL:** <https://forums.swift.org/t/rename-borrow-mutate-accessors-and-borrow-inout-types-to-borrowed-mutable/85287>\
**Category:** Pitches\
**Tags:** ownership\
**Created:** [March 11, 2026, 7:09pm UTC](https://forums.swift.org/t/rename-borrow-mutate-accessors-and-borrow-inout-types-to-borrowed-mutable/85287 "2026-03-11T19:09:35Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![Dmitriy\_Ignatyev](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/dmitriy_ignatyev/32/11340_2.png) [@Dmitriy\_Ignatyev](https://forums.swift.org/u/Dmitriy_Ignatyev)\
**Post date:** [March 11, 2026, 7:09pm UTC](https://forums.swift.org/t/rename-borrow-mutate-accessors-and-borrow-inout-types-to-borrowed-mutable/85287/1 "2026-03-11T19:09:35Z")

</div>

As stated in [[Accepted] SE-0507: Borrow and Mutate Accessors](https://forums.swift.org/t/accepted-se-0507-borrow-and-mutate-accessors/85266), I want to pitch alternative names.

## Introduction

This proposal suggests renaming ownership-related accessors and types introduced in:

- [SE-0474: Yielding Accessors](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0474-yielding-accessors.md)
- [SE-0507: Borrow and Mutate Accessors](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0507-borrow-accessors.md)
- [SE-0519: Borrow and Inout Types](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0519-borrow-inout-types.md)

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:

```swift
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:

```swift
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:

1. Use adjectives to describe the **nature** of access
2. Align accessor names with type names
3. 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:

```swift
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](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0519-borrow-inout-types.md) introduces types representing borrowing and mutable access:

```swift
Borrow<T>
Inout<T>

```

These names differ stylistically:

- Borrow describes an **action**
- Inout (inout) describes a **parameter passing convention**

Renaming them to:

```swift
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:

```swift
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

```swift
var value: NC {
  yielding borrowed { ... }
}

```

#### Mutable Accessor

```swift
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.

---

<div class="post-metadata">

**Author:** ![Nobody1707](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nobody1707/32/2169_2.png) [@Nobody1707](https://forums.swift.org/u/Nobody1707)\
**Post date:** [March 11, 2026, 8:02pm UTC](https://forums.swift.org/t/rename-borrow-mutate-accessors-and-borrow-inout-types-to-borrowed-mutable/85287/2 "2026-03-11T20:02:58Z")

</div>

These names seem good to me, but the fact that they keep us from sinking into a morass of repeated keywards makes them especially attractive. I, for one, was not happy about having our own "noexcept noexcept" or "requires requires". C++ can keep that to itself, thank you.

---

<div class="post-metadata">

**Author:** ![jacoblukas](https://avatars.discourse-cdn.com/v4/letter/j/85e7bf/32.png) [@jacoblukas](https://forums.swift.org/u/jacoblukas)\
**Post date:** [March 12, 2026, 2:24am UTC](https://forums.swift.org/t/rename-borrow-mutate-accessors-and-borrow-inout-types-to-borrowed-mutable/85287/3 "2026-03-12T02:24:49Z")

</div>

I find these names a significant improvement in readability and understandability.

---

<div class="post-metadata">

**Author:** ![davdroman](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/davdroman/32/46501_2.png) [@davdroman](https://forums.swift.org/u/davdroman)\
**Post date:** [March 12, 2026, 11:29pm UTC](https://forums.swift.org/t/rename-borrow-mutate-accessors-and-borrow-inout-types-to-borrowed-mutable/85287/4 "2026-03-12T23:29:22Z")

</div>

This is great. Feels less confusing and more approachable.

---

<div class="post-metadata">

**Author:** ![jpmhouston](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jpmhouston/32/4045_2.png) [@jpmhouston](https://forums.swift.org/u/jpmhouston)\
**Post date:** [March 13, 2026, 3:23am UTC](https://forums.swift.org/t/rename-borrow-mutate-accessors-and-borrow-inout-types-to-borrowed-mutable/85287/5 "2026-03-13T03:23:07Z")

</div>

> [@Dmitriy\_Ignatyev](#):
>
> However, `borrow` and `mutate` are verbs that describe the **ownership semantics** rather than the **access behavior**.

This argument seems contrived.

Furthermore this complaint you regard as a show-stopper for one:

> [@Dmitriy\_Ignatyev](#):
>
> The phrase `nonmutating mutate` is grammatically confusing and conceptually contradictory

sounds nearly identical to this admission you hand-wave away for the other:

> [@Dmitriy\_Ignatyev](#):
>
> While `nonmutating mutable` may still seem strange at first

Rather than claiming an thin, unjustified difference between `borrow` and `mutate` as behaviors vs. `get` and `set` as actions, I think the better argument admits that `get` `set` `borrow` `mutate` are consistent in isolation, but it's better to forego that consistency for sake of more natural english phrasing, and more thoughtful similarity among the new types, new accessors, and existing ownership terms.

This would deserve to be flesh out a bit more, something like this but better:

1. more natural english phrasing  
a. `nonmutating mutate` reads quite poorly, even a small improvement is warranted - `nonmutating mutable` is indeed a small improvement  
b. `borrow` is slightly ambiguous, and read as both "this _does_ a borrow", consistent with `get` and `set`, and also "this _is_ a borrow", more like "a thing that is borrowed"  
c. `mutating borrow` especially reads more in the undesired sense, "this _is_ a mutating borrow" rather than what's intended  
d. both `mutable` and `borrowed` are more appealing as accessors even while losing some (fiendish) consistency with `get` and `set`

2. consistency between types, accessors, ownership:  
a. the best read of `Borrow` and `Inout` together is as "a borrow and an in-out variable" which in turn enforces the wrong reading for the accessor `borrow`  
b. "inout" parameter keyword is a term of art in its context, but doesn't work well outside it, better to align the type with the accessor (perhaps someone should pitch "mutating" as an alternate spelling for that)  
c. changing the type to be `Mutation` would be most (fieldishly) consistent, but that has such negative connotation as to be a no-go

(kinda off the cuff, but you get the idea)

It seems every absolute consistent option for these 2 pairs of related additions lead to poor results. I think the pitch should be more honest that its proposes breaking consistency for whats the best compromise.

---

<div class="post-metadata">

**Author:** ![Lane\_Schwartz](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lane_schwartz/32/5295_2.png) [@Lane\_Schwartz](https://forums.swift.org/u/Lane_Schwartz)\
**Post date:** [March 20, 2026, 3:34am UTC](https://forums.swift.org/t/rename-borrow-mutate-accessors-and-borrow-inout-types-to-borrowed-mutable/85287/6 "2026-03-20T03:34:09Z")

</div>

👍🏼

Significant improvement. Thanks for putting this one in

---

<div class="post-metadata">

**Author:** ![CrystDragon](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/crystdragon/32/10461_2.png) [@CrystDragon](https://forums.swift.org/u/CrystDragon)\
**Post date:** [March 20, 2026, 8:11am UTC](https://forums.swift.org/t/rename-borrow-mutate-accessors-and-borrow-inout-types-to-borrowed-mutable/85287/7 "2026-03-20T08:11:55Z")

</div>

I cannot read `yielding borrowed`.

When I saw `yielding borrow`, I could interprete it as "this 'borrow' operation is a yielding one", that's the same way I interpreted a `mutating get` as "this 'get' operation is a mutating one".

It's a little awkward for me to think "this 'borrowed' property is yielding", shouldn't it be "yielded", instead of "yielding"?

---

<div class="post-metadata">

**Author:** ![Dmitriy\_Ignatyev](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/dmitriy_ignatyev/32/11340_2.png) [@Dmitriy\_Ignatyev](https://forums.swift.org/u/Dmitriy_Ignatyev)\
**Post date:** [March 26, 2026, 2:26pm UTC](https://forums.swift.org/t/rename-borrow-mutate-accessors-and-borrow-inout-types-to-borrowed-mutable/85287/8 "2026-03-26T14:26:56Z")

</div>

Thanks for detailed response.

I agree that original framing overstated the grammatical inconsistency between `nonmutating mutate` and `nonmutating mutable`, both read awkwardly in isolation. Would it better to say something like: "The argument for the renaming is indeed **readability and semantic clarity** , rather than verb-based consistency with `get` /`set`"?

Also, do I understand the following correctly? Both `borrowed` and `mutable` read more naturally, even if they lose some verb-based symmetry with `get` /`set` . This small loss in consistency is justified by the improved clarity.

Beyond the arguments presented in the motivation section, do you generally support proposed naming?

---

<div class="post-metadata">

**Author:** ![Dmitriy\_Ignatyev](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/dmitriy_ignatyev/32/11340_2.png) [@Dmitriy\_Ignatyev](https://forums.swift.org/u/Dmitriy_Ignatyev)\
**Post date:** [March 26, 2026, 2:49pm UTC](https://forums.swift.org/t/rename-borrow-mutate-accessors-and-borrow-inout-types-to-borrowed-mutable/85287/9 "2026-03-26T14:49:38Z")

</div>

The confusion is understandable, because this is a subtle aspect of how these accessors are read. The key point is that `yielding` describes the behavior of the accessor itself, not the property it returns.

- With `yielding borrow` it’s natural to read this as “this borrow operation is yielding” because `borrow` is a verb describing the action.
- With `yielding borrowed` we shift from an action to an **adjectival description** : “providing borrowed access in a yielding manner”

`yielding borrowed` is intended to read as “This accessor yields access to a borrowed reference”

Accessors like `borrowed` and `mutable` describe the kind of reference they provide rather than the action performed.  
By keeping the same names for accessors and their corresponding types, we preserve a clear 1:1 conceptual mapping. `borrowed` describes an accessor that grants temporary read-only access. `Borrowed<T>` provide the same ownership rules at type level.

---

<div class="post-metadata">

**Author:** ![Dmitriy\_Ignatyev](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/dmitriy_ignatyev/32/11340_2.png) [@Dmitriy\_Ignatyev](https://forums.swift.org/u/Dmitriy_Ignatyev)\
**Post date:** [March 26, 2026, 3:11pm UTC](https://forums.swift.org/t/rename-borrow-mutate-accessors-and-borrow-inout-types-to-borrowed-mutable/85287/10 "2026-03-26T15:11:05Z")

</div>

@Douglas_Gregor  
I’ve prepared a pitch proposing the renaming of accessors `borrow` / `mutate` to `borrowed` / `mutable`.

I want to confirm that I understand the process correctly: after publishing a draft proposal on the forum the core team oversees the discussion and taking community feedback into account before proposal is considered for review. Am I understanding this correctly?

Additionally, do you have any recommendations on structuring the draft proposal or examples I should include?

Thank you in advance for your guidance.

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [March 26, 2026, 5:00pm UTC](https://forums.swift.org/t/rename-borrow-mutate-accessors-and-borrow-inout-types-to-borrowed-mutable/85287/11 "2026-03-26T17:00:57Z")

</div>

> [@Dmitriy\_Ignatyev](#):
>
> I agree that original framing overstated the grammatical inconsistency between `nonmutating mutate` and `nonmutating mutable`, both read awkwardly in isolation.

Yeah, speaking for only myself, frankly I don't understand what it accomplishes to do a tour through the different principal parts of verbs. I can't imagine anyone staring at `nonmutating mutate` with confusion having a 'eureka' moment with `nonmutating mutable`.

My understanding of the steering group's request was that we're open to any terminology that's clearly better than `mutate`—that accessor specifically—which we hadn't considered, not asking for a reappraisal of the part of speech we use for accessors generally. If it's explicitly the case (as some comments above seem to indicate) that folks don't want to find different terminology, then I think we've completed our exploration of the design space.