Pitch: `borrow` and `inout` declaration keywords

+1. I like this better than both the proposal and the alternatives downthread. It addresses two concerns of mine:

  • inout as a muddled metaphor when we’re not talking about functions
  • borrow as an overloaded term when used as the term for both the action on a value (i.e. in an expression) and the behavior of a variable (i.e. in a declaration)

I also think that grid is the best, most concise casual explanation of these concepts I’ve seen. Even sort of mostly understanding these terms, I still find this helpful! It’s something I’d draw on a whiteboard any time I’m teaching these concepts.

I don’t think any terminology schema I’ve heard, including this one, makes the concept completely transparent to someone encountering it for the first time — but this alternative comes closest of the options I’ve seen to Swift’s ideal of progressive disclosure. And for the experts, I like how the terms roll off the tongue in context as I try sample sentences in my head, discussing things to a hypothetical colleague or student:

  • “A borrowing variable would improve performance here”
  • “Oops, var x = things[i] just means x is itself mutable; we need a mutating variable to modify the array itself”
  • “You can’t own a struct value that somebody else owns, except by making a copy. If you want to avoid the copy, you’ll need to borrow the value….” (Aside: Does this line of explanation lead to an incorrect conclusion? I think borrow will still induce copies in some situations…?)

While I'm mostly okay with mutating, this part in particular feels like the weakest link. I can already picture myself explaining that, yes, "mutable" and "mutating" might sound like the same thing but there's actually very important differences.

I don't feel like mutating conveys well enough by itself the ownership significance, which is IMO the more important and less intuitive thing for the keyword to convey. So I continue to lean towards something like borrow(var) or anything else that unites the items in the borrowed column a bit more explicitly.


I agree, it should be relatively easy to type. Just another suggestion:

ref x = y      // immutable borrow
ref var x = &y // mutable borrow

for ref x in array {}
for ref var x in &array {}

I think that borrow and inout are very awkward declaration keywords. Here's my suggestion:

var x = 7
alias y = x   // immutable borrow
alias z = &x  // mutable borrow

The bindings/types (e.g. when inspected with Xcode) would be:

var x: Int
alias y: Int
mutating alias z: Int

You are suggesting Rust’s ampersand, which means something different than Swift’s ampersand. Swift’s ampersand means “this value could get mutated”. Rust’s means “this statement forms a reference to this binding”. We are not going to change the meaning of Swift’s ampersand, for source stability among other reasons.


The ampersand is not intrinsically related to pointers, and it is not a marker for unsafety. People associated them because they come up a lot together in C interop, and C’s ampersand is confusingly related as well. However, in Swift the ampersand is intended as a marker for possible mutations.

1 Like

I've updated the pitch to address many of the issues raised in this thread and moved it to a pull request against the Swift Evolution repository.


I like the color of the shed, thanks!

In Exclusivity and scope, it sounds like we're allowing borrow and inout bindings to the same variable at the same time. Should that be construed as a relaxation of the law of exclusivity? For instance, today, this is illegal:

struct Foo {
	var x: Int
	mutating func frob(action: () -> Int) -> Int {
		return action()

var foo = Foo(x: 10)
let value = foo.frob { foo.x }
// ^^ Simultaneous accesses to 0x100c38000, but modification requires
// exclusive access.

Will this still be illegal?

In Not implicitly copyable, is copy a new standard library function? If not, how is A being copied: is return a allowed to return a copy?

borrow x = a    // Borrow `a`
func copy(_ a: borrow A) -> A { ... }
let z = copy(x)  // Legal way to explicitly copy x

In Switch and if-case binding, if you use switch &variable, do you have to use inout bindings for payloads or will it still allow non-inout payloads?

1 Like

No. There is no intention here of relaxing the law of exclusivity. There is some nuance about when a new binding causes a previous binding to be inaccessible, but there should be no point in the program at which a read/write binding and some other access are both useable.

I'll review that section; it sounds like it may need some additional clarification.

There's a copy function defined on the previous line. :grinning: I'm assuming that user-defined function knows how to construct a new A instance with the same information as the borrowed original.

A general-purpose copy function could be an interesting Future Direction, but I'm not proposing such a thing.

First, note that the & sigil here means that the variable might be modified. That means it is required if there are any inout bindings, but does not preclude there being other kinds of bindings. In particular, this leaves open the possibility of mixing different kinds of bindings within a single switch statement.

However, as I explain in "Future Directions", I think mixed bindings could be confusing in practice, so for now I'm proposing that we limit such mixing until we have more experience with this construct.

1 Like

I saw it, but I didn't feel copy would be trivial enough to be stubbed with no comment! If you get a struct from another module that has no public initializer, today, you can make the assumption that the library author did not want you to make your own values directly but they didn't mind if you copied existing values. As proposed, you need the library author's blessing to copy values that have been passed by borrow. This may well be approximately equivalent to needing the library author's blessing to pass by borrow at all. It feels like requiring explicit copy constructors in C++ to me.

That's a good point. I'll talk to some folks about this and see if there's something we need to adjust here.

1 Like

Wasn’t an explicit copy operator proposed as part of the @noImplicitCopy pitch?

I chatted with a few folks and think I see what got missed...

A copy operator was mentioned in the @noImplicitCopy pitch but not formally proposed there. So I think I'll add it to this proposal.

In essence, the copy operator can be used to explicitly copy a copyable type that is in a non-implicitly-copyable context:

let a = CopyableType()
borrow x = a
let b = x // Illegal.  x is not implicitly copyable
let c = copy x  // Legal 

But this cannot be used to avoid restrictions on non-copyable types:

let u = NoncopyableType()
borrow y = u  // Legal to borrow a noncopyable type
let v = y  // Illegal; y is not implicitly copyable
let w = copy y // Illegal; y is not copyable at all

The operator form here is consistent with what we're discussing elsewhere for "borrow" and "consume" operators.


It could also be a good idea to clarify the relationship between inout, borrowed and noescape. As I understand it with the copy clarification, an inout/borrowed value can still escape. This is most likely intended.

A borrowed value can escape only by copying it. This is intentional and has two important implications:

  • A non-copyable borrowed value cannot escape.
  • An escape of a copyable borrowed value requires an explicit 'copy' operation, which makes it obvious in the source.

Please take a look at these changes and let me know if they address your concerns.

1 Like

Yes, thank you!

I am glad to see that these bindings formally extend to end-of-scope, and wish to explicitly support that decision..

When I was relatively new to Swift, coming from some experience in C++ (where I knew about T& but not T&&), I remember writing something like this:

inout aliasToE = a.b.c.d.e

Having read through this thread I don’t think that’s what I would want the syntax to be, but it would be nice if there’s a fix-it to change that to whatever that should be (whether it’s var x = &y or inout x = &y or whathaveyou).

1 Like

Out of curiosity: Any progress on this pitch? Can’t wait for inout in an enum case.