SE-0377: borrow and take parameter ownership modifiers

Evolution Proposal Reviews
1

Hi Swift community,

The review of SE-0377: borrow and take parameter ownership modifiers begins now and runs through November 8, 2022.

Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager. When emailing the review manager directly, please keep the proposal link at the top of the message.

This proposal is closely related to SE-0366: take operator to end the lifetime of a variable binding, the second review for which is running concurrently.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to Swift?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/main/process.md

Thank you,

Ben Cohen
Review Manager

15 Likes
2

+1. I like this direction. My work currently makes use of a BlockConfigurable marker protocol that adds this method:

extension BlockConfigurable {
  func configure(_ apply: (inout Self) -> Void) -> Self {
    var copy = self 
    apply(&copy)
    return copy
  }
}

The copy that gets made there is, theoretically at least, not necessary. If I understand correctly, this proposal can make this more efficient.

extension BlockConfigurable {
  taking func configure(_ apply: (inout Self) -> Void) -> Self {
    apply(&self)
    return self
  }
}
1 Like
3

Glad to see this work on move-only types start to make it towards shipping. I have a naming suggestion to throw onto the pile: Instead of borrow/borrowing and take/taking, spell them "use"/"using" and "own"/"owning" (not "owned"). The SE-0366 proposal would probably have to use a different verb though (perhaps drop?). Edit: I read the other proposal too hastily, I retract this bit.

4

+1 I like own/owning much better than take/taking

5

This functionality is definitely needed for Swift, and it's good to see this being addressed.

That being said, I don't really like the use of 'take' for this kind of modifier. It feels weird to me that take x would end a variable's lifetime, while passing x to a take parameter wouldn't. Additionally, as Dave Abrahams pointed out on the last thread, function parameters are already described as 'taking': a function of type (Int) -> Void is described as taking an Int.

3 Likes
6

I think the naming take and borrow are too simple, and should better convey that these are not features that should be regularly used and instead devs should continue to trust ARC in the vast majority of cases, similar to how dropping down to raw pointer APIs have "unsafe" prepended.

My worry is that with simple names there is an implication that we should be manually managing ownership because ARC is not able to optimize adequately, and we'll see this proliferate in codebases because obviously we should all want better memory usage, and then we're slowly (or quickly) drifting back to the pre-ARC retain/release days.

1 Like
7

I wonder if this could be helped by an @ prefix, bringing it more inline with other features you should only use after looking up how they work.

8

I'm a +1 on this proposal. Having read it through I think it addresses a useful hole in the language, and we'd use it in a number of places throughout SwiftNIO.

9

+1 from me, I've had a fair few use cases where I'd love to have more control over Swift making copies (or explicitly not). I think that take and borrow clearly state their intentions by themselves.

1 Like
10

+0.75, I like borrow naming, but I find take too broad and potentially confusing as a keyword. Maybe own is a better counterpart?

Yes, especially as a part of the Ownership Manifesto.

As far as I understand, this is not as advanced as the ownership model that Rust has. At the same time, I don't think there's a consensus that all of the decisions that Rust made in this area are overwhelmingly positive. The piecemeal and cautious approach that Swift takes feels right to me.

I've been following the Ownership Manifesto as it evolved and some of the pitch threads that were published prior to the proposal review.

1 Like
11

I'm a -1 on this proposal. I think that it would result in the unnecessary proliferation of "borrow" and "take" throughout codebases. Most Swift developers don't know anything about parameter ownership today (excluding inout), but will start using "borrow" and "take" because they aren't scary, making many codebases slower because with copyable types the non-optimal passing convention still compiles.

In my view, a better design is:

  • By default, all parameters are passed at +0 / shared to all functions, including initializers and setters

  • A single new modifier, sink, which changes the passing convention to +1 / owned and makes the parameter mutable

Automatic memberwise initializers will use sink for every parameter. When explicitly writing initializers, IDEs will issue a warning when a parameter is simply stored to a member, but isn't marked sink. A similar warning will exist for setters too.

This may be source breaking, but I think it's worth it. Let's limit this to Swift 6 if necessary.

5 Likes
12

I’ll just repeat something I’ve tried to say before: we should find our way to a future where “borrow” doesn’t need to be written at all. For copyable types there’s no difference between borrowing and pass-by-copying-a-value, and for noncopyable types the latter doesn’t exist. When do you ever want to pass by implicit copy? I say never.

7 Likes
13

borrow will still be the default in almost all cases, so you shouldn't have to write it much. The alternative to borrow isn't pass-by-copying, it's pass-by-ownership-transfer (what we call take in the proposal). Whether the caller makes a copy or not is an orthogonal decision made by the caller, and there are reasons we'd do so for both borrowed and taken parameters—to avoid aliasing writes to shared mutable state in the former case, or to preserve the lifetime of a value the caller either still needs to keep around for itself, or doesn't have ownership of in the first place, in the latter. Stay tuned for future proposals if you want to hear about controlling or preventing implicit copies.

10 Likes
14

borrow will still be the default in almost all cases

Huh, maybe I have misunderstood all along. I didn't think borrow was currently the default; my understanding was that retains are omitted but for small types, bits might be copied. I guess that's not distinguishable from borrow for copiable types which I guess is what I was saying.

so you shouldn't have to write it much

So the only place you'd be writing it is, e.g. for initializer parameters that you don't want to consume?

That sounds pretty good!

to avoid aliasing writes to shared mutable state in the former case

Sorry, I don't quite see how that plays out. We're talking about copies implicitly generated by the compiler, but a borrowed variable is immutable, so you can only mutate a different variable; if there's a copy involved it seems like it would have to be made explicitly by the user. And if you mean it's sharing state behind-the-scenes, no amount of copying will avoid the aliasing. Could you explain?

to preserve the lifetime of a value the caller either still needs to keep around for itself, or doesn't have ownership of in the first place, in the latter

That makes total sense; it's a place we'd be telling the user to make an explicit copy in Val (unless they turn on @implicitcopy). Maybe the models are closer than I thought. /cc @Alvae

15

You are right that, from the callee's perspective, the borrowed parameter value is always an immutable value (well, shared-borrow, which is the same most of the time). The "do we retain/copy or not" negotiation happens primarily on the caller side, though. If the argument is known to untouched by anyone else for the duration of a call, then the caller can pass its value along without any copies or retains, which should happen for unescaped local variables, parameters, and let constants:

class Foo {}

func callee(_: Foo) {}

let globalLet = Foo()

func caller(param: Foo) {
  let local = Foo()
  var localVar = Foo()

  // We shouldn't need to retain/release for any of these calls:
  callee(local)
  callee(param)
  callee(globalLet)
  callee(localVar)
}

If there's a potential for the argument to be modified during a call, though, then we have to copy or retain in order to safely maintain the illusion of pass-by-value. This happens with mutable globals and class ivars, since we don't usually know whether the callee turns around and calls something that touches those, as well as if you try to pass a mutable variable by-value and by-inout simultaneously:

class FooBox {
  var foo: Foo
}

var globalVar = Foo()

func mixedCallee(_: Foo, _: inout Foo) {}

func caller2(boxParam: FooBox) {
  var localVar = Foo()
  // This has to retain, to resolve the exclusive/shared conflict
  mixedCallee(localVar, &localVar)
  // These probably retain (but might not with enough effects analysis…)
  callee(boxParam.foo)
  callee(globalVar)
}

For copyable types, borrow vs. take on the parameter doesn't have a huge effect on whether these copies are necessary or not; take introduces the ability to forward ownership for the last use of a value, but conversely, requires a caller to also copy for any non-final uses of the value. In Swift, we've already made our bed more or less with how copyable types work, so the way I see to eliminate these kinds of implicit copies is to provide ways for the code in the caller to opt out of implicit copying, and require explicit copies in situations like mixedCallee(localVar, &localVar) that obviously violate exclusivity without a copy, and/or specify that we aren't concerned about aliasing writes to objects or global variables at certain call sites, and it's OK to borrow their values in place (and trap if someone does come and try to rewrite the value during the access).

4 Likes
16

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

17

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.

4 Likes
18

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.

3 Likes
19

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?

20 
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
}