[Accepted] SE-0507: Borrow and Mutate Accessors

Evolution Announcements
1

The review of SE-0507: Borrow and Mutate Accessors has concluded and the proposal has been accepted with some clarifications.

The proposal was amended with some clarifications regarding the the interaction with actors, optionals, global variables, local computed properties, and other aspects of the language. None of these clarifications changes the fundamental nature of this proposal.

The LSG considers the future direction enabling borrowing from unsafe pointers to be particularly important for the language, and encourages the authors to pursue a separate proposal for it.

During the review, there was some concern that mutate is not the best name for this accessor. The mutate terminology was introduced as part of yielding mutate in SE-0474. The LSG feels that this proposal (SE-0507) should not deviate from SE-0474. However, because SE-0474 has not appeared in a Swift release yet, it is still possible to rename the mutate keyword if there is a sufficiently-motivated proposal for a better name for this accessor. Such a proposal would need to pitched and reviewed relatively soon, because both SE-0474 and SE-0507 are expected to ship in the upcoming Swift 6.4, after which a change to the name cannot be done cleanly.

Thanks to everyone who participated in the review.

Doug Gregor
Review Manager

13 Likes
Rename borrow / mutate Accessors and Borrow / Inout Types to borrowed / mutable
SE-0507: Borrow and Mutate Accessors
2

I've made a pitch for renaming: Rename borrow / mutate Accessors and Borrow / Inout Types to borrowed / mutable

6 Likes
3

One question I had about the borrow and mutate accessors is under what situations we would expect these to actually not improve performance. Under what situations would get and set be expected to actually perform better?

Here might be a hint from SE-0474:

yielding borrow

For read-only operations on Copyable types, the performance tradeoffs between get and yielding borrow are more subtle.
borrowing yield can avoid copying a result value that is stored as part of the originating value.
On the other hand, get can execute as a normal function without the overhead of a coroutine.

What is not clear to me is how this might relate to what was accepted in SE-0507.

If borrow and mutate really are "fast buttons" then the implication is we should now always prefer borrow and mutate unless we are blocked on using them for that specific situation?

Is there any more advice here in another proposal or document? Would something like a "pros and cons" be coming soon where engineers could learn more under what situations borrow and mutate should and should not be used?

2 Likes