SE-0377: borrow and take parameter ownership modifiers

+1 This looks good to me. I like the new borrow/take/taking naming scheme.

I’m generally in favor of this and can already think of a few specific locations where this would improve performance in a meaningful way (when coupled with take expressions), even without any further language changes. Also very excited about the general progress towards move-only types.

Inside of a function or closure body, take parameters may be mutated, as can the self parameter of a taking func method.

I feel like this isn’t necessarily justified; while it is just as reasonable to mutate a take parameter as a local var, I don’t think it makes sense for that to be the default. With locals we still encourage let over var, and take doesn’t imply “mutation” to me. Certainly the implicit uses of the take convention today aren’t about mutating the value; they’re about storing it. Similarly, the use case I have in mind is purely about allowing the parameter to be destroyed sooner, avoiding having to wait for a deep stack to return.

I suppose you can always convert from one form to another by takeing into a local, but I don’t think take should imply mutability like var and inout do. I’d rather see a (separate) proposal to revert SE-0003 and revive var on parameters if we think this is interesting, noting that SE-0031 moved inout to the “type” side of the parameter declaration since SE-0003 was reviewed.

take cannot be applied to parameters of nonescaping closure type, which by their nature are always borrowed

The full form of a non-optional take closure parameter would thus be callback: take @escaping () -> Void, which is pretty verbose. (Or is it @escaping take () -> Void?) Given that escaping pretty much implies that a copy will be made anyway, does it make sense for take to imply @escaping, as inout already does today? That still leaves the occasional borrow @escaping () -> Void for where an escaping closure parameter might normally be taken, but that seems pretty rare to me; the main place where I could see it being useful is if the closure is only escaped some of the time.

On the implementation side: are non-escaping closure parameters passed borrow or take to initializers today? I would hope borrow even though the usual convention for initializer parameters is take, for the reasons discussed in this proposal, but if not this could be a good opportunity to fix some conventions (where not ABI-breaking).

Additionally, I remember the first implementation of __owned and __shared affecting a function’s mangled name even if the convention matches the implicit default for that parameter. Does that behavior extend to take and borrow, and if not…I guess there’ll be a special opt-out or shim for the stdlib, to use the explicit mangling where an implicit one would have done?

Again, very excited about all this! Thank you Michael, Joe, and everyone working on this.


I am +1 on this proposal. But I have one open question about closure capture lists. Is it possible to have take/borrow modifiers on capture list elements? We had this discussion over in this thread where we were talking about a safe way to pass AsyncIterators between Tasks while retaining the 1:1 relation ship.


I agree with this, the default should be borrow and Swift code with the borrow keyword everywhere would be unbearably ugly. However, don't we need some attribute declaring if it is a mutable or immutable borrow or is this covered by inout? Take passing is more rare and you also appreciate that badging because then you know that the function will take hold of that resource.

Is there a way to declare per function or even entire files that you want to use the borrow/take feature?

struct Foo {
   taking func foo()    // `take` ownership of self
   borrowing func foo() // `borrow` self
   mutating func foo()  // `modify` self with `inout` semantics

Yuck! :frowning:

This looks much better:

struct Foo {
   func foo() takes   // `take` ownership of self
   func foo() borrows // `borrow` self
   func foo() mutates // `modify` self with `inout` semantics

Though that is better aligned with other function modifiers (such as async and throws), it's worth noting that mutating with the former syntax already exists in the language, so to do that would be a breaking change. If the first syntax even becomes so much as a warning, we may see libraries having to do this:

#if swift(>=5.8) // or whatever version
    func foo() mutates {
        // ...body...
    mutating func foo() {
        // ...same body...

So I'm not sure that would be worth it.

This would introduce inconsistency with the fact that async and throws are keywords for denoting effects and already have their own set of "rules". Both are parts of their type signatures, (Int) -> String and (Int) async -> String are different (even though they have a certain subtyping relationships), while (Int) mutates -> String does not make sense as a standalone type signature. Effectful read-only properties were introduced in SE-0310, allowing get async and get throws in property declarations. In the light of that, what would get mutates even mean?

Additionally, throws has counterparts in throw and rethrows. async has await and potentially reasync, as discussed in future directions of the corresponding proposal. I don't think mutate and remutates make sense even at a conceptual level. In this sense, taking, borrowing, and mutating are not function/property effect modifiers.


Rust’s notion of “mutable borrow” does indeed correspond to Swift’s inout. They’re slightly different (and so are the two “borrow”s) because Rust’s references are first-class values that promise a pointer representation and Swift’s are calling conventions that do not expose the representation. (For example, a borrowed Int in Swift will still be passed by value because it is a small frozen trivially-copyable struct.)

Isn't mutating get already a thing? I'm 90% sure that lazy variables have an implicit { mutating get set } attached to them.

1 Like

Yes, that one's a weird special case, but note that it's then consistent with mutating func. It still stands far from effect keywords in all other aspects.

If we want a consistency argument, mutating and the new proposed keywords affect how self behaves within the function, while also changing the self the function is called on. What other modifiers on functions affect self like this? static/class, and maybe convenience as a stretch. These also appear at the start of the declaration.

(I don’t put a lot of stock in consistency here, though, cause it’s clear that “before the declaration” is the default place to put modifiers in Swift, and throws and async are the unusual ones.)


Since mutating get was brought up: what about nonmutating set? Would that be respelled borrowing set now?
Similarly, would it make sense to allow taking get or taking set?

Edit: it seems the compiler doesn't currently reject __consuming get and __consuming set. It even allows __consuming willSet and __consuming didSet, though I'm not sure why you'd use those.

Do we want to allow setters to borrow the new value? Currently, a setter can't mark its argument as __shared or __owned. However, allowing that opens up a whole can of worms:

  • What if a set, willSet, or didSet tries to have an inout argument?
  • What does it mean for didSet to take its argument (oldValue) by anything other than take?
  • Should willSet be allowed to take its argument (newValue)?

Maybe this was already discussed and I just missed it, but willSet and didSet don't seem to be mentioned in the proposal at all.

That's an interesting question. borrowing set would indeed be equivalent to nonmutating set, but we should probably keep the existing spelling working for compatibility. As you noted, __consuming is currently allowed on get and set accessors, and I would say taking and borrowing ought to be allowed as well. It doesn't really make sense to allow them on didSet or willSet since those get absorbed into the setter and modify coroutine ABI-wise, and they always follow the ownership semantics for setting a stored property of the containing type (which would be mutating for a struct or borrowing for a class).

It might be interesting to allow set to borrow or inout its newValue, but I think that doing so requires further language design to work out what that means in relation to the borrow/inout access on the base of the property being set. (Similar issues cloud our ability to put throws on set, for instance.) So I think it makes sense to explicitly subset setters out of this initial proposal. Since willSet and didSet are tied to the default assignment behavior of stored properties, I don't think that modifying the semantics of oldValue/newValue is particularly useful.


I was always in favour of prefix spelling for async/throw as well:

async func foo() -> Int {}
throwing func foo() -> Int {}

but OTOH as mentioned above async/throw is part of function signature so I am not so sure about it.


Taking is an action. Owning is a state. Taking means a transference of possession.

If an owned object can be borrowed, then an owning function is a contradiction in terms, because it explicitly cuts off this possibility: 1. by scope 2. by voiding the argument.


Actually, the term of borrowing is also not quite there. In actuality, how many borrowers have access to the same thing? How can multiple borrowers get the same thing?
Only 1. by reproduction, i.e. copy onto parameter or 2. by glimpsing into its argument in place, not moving or copying.

Only single-access borrowing should actually be considered borrowing.
(Considering that its intention is to change the value, it’s not perfect as well. You wouldn’t expect a thing you lend to return changed. The contract is usually precisely that trust is given to not change it. But at least changing it is not precluded.)

3 a musing, not even a suggestion

I myself enjoy a different analogy – that of flows. Terms like conduit, flow, tapping, filling.
One could imagine the value as a quantum of energy. Then borrowing is tapping, and mutable borrowing is switching or swapping. Or mutating.
I like the similarity of Take and Tap and how it separates itself from mutation in situ, which is the most special case and the main antagonist.
(I also like the mut of rust, as it does not only mutate, but ‘mute’ the value for the time being – not other place can have it). But it’s too poetic for the other tastes.

1 Like

Whatever modifier we choose to put in (front of?) the function, I think mutating needs to match inout. If we go with a naming scheme like takes, borrows, mutates then an inout parameter should also be spelled mutate. Because as it currently stands, take is a verb, borrow will be a verb and inout will have an adjective role.

1 Like

I wonder if an -ing prefix is at all good.

  1. appears in relation to value type methods only,
  2. has dual target – mutates property = mutates self
  3. modifies value
  4. most importantly, declares its behaviour towards the target, not the argument. i.e. it declares a side-effect from its body, with exactly zero relation to its arguments.

None of these points apply to ownership transfer; it

  1. appears in relation to any function,
  2. has a single target, no self pointer,
  3. either modifies place, or does no modification at all (value is modified by inout only)
  4. declares its behaviour towards its arguments, not its scope.

For the sake of consistency, it would necessitate a bunch of changes to the grammar of mutating, as well.

Thanks everyone for your feedback so far! I've kicked off a combined re-review of SE-0366 and SE-0377 focused on naming here:

Please provide further feedback on the new review thread. Thank you!

Holly Borla
Review Manager