SE-0366: Move Function + "Use After Move" Diagnostic

tgoyne · 2022-07-26T15:20:13.304Z

michelf:

I'm seeing two purposes for move:

We want to avoid making copies.

[...]

I think move does a poor job for #1. Copies are implicit, so writing move at one place does not ensure no copy will be made unless you have a very accurate model of the language in your head.

This definitely fits with my experience with move semantics in C++. I've gotten very good at identifying at a glance where implicit copies will happen and after years of working with it I now find it pretty easy to avoid undesired copies, but that did take literally years. Based on my experience reviewing PRs, many developers who are otherwise very strong at C++ don't always have this intuition developed.

I think the Swift rules for implicit copies are more complicated than those of C++ (unless it's just comparatively less experience with avoiding copies in Swift on my end). I can see why move() does something useful in the examples given, but they aren't places where I would have immediately identified just from reading the code.

I think the current proposal is not something which the average developer will be able to use to successfully avoid implicit copies outside of cases where they're specifically profiling and benchmarking a specific function. OTOH, I'm not sure that's really a problem? In my experience overhead from implicit copies that aren't actually needed isn't a common problem in Swift to begin with. If move() is solving a niche problem that most developers don't need to solve, then does it really need a design that works without specifically profiling the function being optimized?

ksluder · 2022-07-26T15:23:21.327Z

ksluder:

It’s viral and interacts poorly with standard optimizations (NRVO).

I want to refine this opinion a bit. “Viral” seems like the wrong word, given that const is truly viral.

std::move() is more like a magic spell. The instant I see std::move(), I immediately start to worry about how load-bearing it is. Removing it might or might not affect performance, depending on the optimizer. Or it may affect correctness, if the move constructor enforces some invariant. Or it may even be incorrect, as std::move() in return position often is.

I don’t want to be struck with the same fear by encountering a move(_:) expression in Swift code.

xwu · 2022-07-26T15:50:26.631Z

Jumhyn:

IMO this is glossed over far too quickly—the concept of a "function which consumes a movable binding" (or indeed, any binding at all) is an entirely new concept, and isn't even representable in Swift today. The purported signature of the move(_:) function is a bit of a fiction. This is discussed and justified in Alternatives considered:

Declaring move as a function also minimizes the potential impact to the language syntax. We've introduced new contextual keywords without breaking compatibility before, like some and any for types. But to do so, we've had to impose constraints on their use, such as not allowing the constraints modified by some or any to be parenthesized to avoid the result looking like a function call. Although that would be acceptable for move given its current constraints, it might be premature to assume we won't expand the capabilities of move to include more expression forms.

AFAICT, though, this really only rebuts the proposed spelling of move x and not the other alternatives discussed just above such as #move(x) or @move x. In a vacuum it strikes me as equally premature to assume that move will expand to include more expression forms—the expansions discussed in Future directions still only really cover expansions of the potential bindings we could apply this function to.

I want to throw out perhaps a middle ground here: What about a standard library operator?

I'm not referring to making move an operator spelled as-is, I mean some counterpart to f(&x) for inout which could be declared as a regular standard library operator but, by virtue of eschewing the standard function calling parens at the call site, avoids reading as "just any old function."

For example, suppose we spelled the operation as prefix <-:

// Proposed syntax:
f(move(x))
// New bikeshed syntax:
f(<-x)

// Proposed syntax:
let y = move(x)
// New bikeshed syntax:
let y = <-x

tbkka · 2022-07-26T16:28:18.436Z

ksluder:

Swift has hidden retain and release since its inception. Requiring the use of an explicit move(_:) function feels like a step backward.

Swift's "hidden" retain/release (ARC) is great for general code, but it does have limits. In particular, over the last two years, we've worked to develop a set of ARC optimizations that tries to balance the need for predictable behavior vs. the desire for optimal performance. While I personally am quite pleased with the result overall, I also realize that it is a compromise: code with particular performance constraints will need to vary from the default ARC behavior.

The move operation is one tool for that purpose: As described in the proposal, it can be used to selectively control lifetimes of particular objects, clearly documenting the programmer's intention to avoid certain retain/release or copy-on-write operations.

As such, this move operation should never be "required" in any situation to ensure correct behavior. (This is significantly different from C++ std::move, which is sometimes required in order to avoid memory leaks.)

Tim

tbkka · 2022-07-26T16:54:45.913Z

ksluder:

I would much prefer the language team focus first on move-only types ...

Move-only types do not eliminate the utility of a move operation.

Most types in Swift will always be copyable, and so there will always be a need for developers to exercise occasional control over the copying of such types.

ksluder:

C++ has had std::move since C++11, and it’s kind of a nightmare.

I think a comparison with C++ std::move is rather misleading. C++ std::move exists specifically to control copy behaviors in a language that does not automate memory management.

Swift is still automatically managing all memory, even in the presence of move operations. The move operation is only a way for the developer to improve the compiled result by more clearly documenting their intent. By explicitly denoting the end of a variable lifetime, the developer can help the compiler make more appropriate choices about memory management for specific values.

This is not fundamentally different from @noescape annotations: You would still get correct behavior if every closure argument were conservatively treated as escaping, but the ability to annotate some closures as escaping and some as non-escaping allows you to specify cases where the compiler should favor performance (non-escaping) over utility (escaping).

tgoyne:

If move() is solving a niche problem that most developers don't need to solve, then does it really need a design that works without specifically profiling the function being optimized?

Most developers may indeed never need to use a move operation in Swift. I believe that Swift's design should always prioritize providing good behavior for the majority of developers without requiring specialized tools like move.

But many developers will rely on high-performance libraries that do indeed need to fine-tune their performance. The underlying ideas here were inspired by discussions with people building some very high-performance Swift libraries: Those developers are indeed doing significant profiling and identifying specific points where the compiler's defaults are not always ideal.

Tim

Joe_Groff · 2022-07-26T17:52:50.654Z

ksluder:

That would prevent the following very simple example from compiling:
let a = 100
let b = { a + 1 }()
let c = move(a)

Immediately-applied closure literals are nonescaping.

Chris_Lattner3 · 2022-07-26T17:52:53.766Z

I think the proposal is nice, and particularly appreciate the attention to detail with defer and repopulating an inout after moving from it.

I agree with the general concerns above. move isn't a function and breaks composition in weird ways, it is built-in.

I think that Xiaodi's suggestion is good, given that operators feel more "built in".

xwu:

I want to throw out perhaps a middle ground here: What about a standard library operator?

I'm not referring to making move an operator spelled as-is, I mean some counterpart to f(&x) for inout which could be declared as a regular standard library operator but, by virtue of eschewing the standard function calling parens at the call site, avoids reading as "just any old function."

For example, suppose we spelled the operation as prefix <-:
// Proposed syntax:
f(move(x))
// New bikeshed syntax:
f(<-x)

// Proposed syntax:
let y = move(x)
// New bikeshed syntax:
let y = <-x

I'd throw out <* or <= or << or <@ as other examples for consideration, e.g.:

  var y = x
  longAlgorithmUsing(&y)
  // We no longer use y after this point, so move it when we pass it off to
  // the last use.
  consumeFinalY(<*y)
...

  _ = <*x

Both connote "pulling the value out of the RHS".

-Chris

michelf · 2022-07-26T17:59:36.651Z

tera:

And ditto for retain ?

For a class/actor reference, copying the reference is what ends up calling retain. I could rewrite my example with this spelling and it'd be exactly the same thing:

@noimplicitretain let x = MyObject()
let y = x         // error, retain must be explicit: use retain(x)
let z = retain(x) // ok

Joe_Groff · 2022-07-26T18:12:13.832Z

I think it's a fair observation that a move annotation and and no-copying constraints are complementary approaches to a similar problem of wanting to increase control over the lifetime and copying of values. However, I think even when we have move-only types, no-implicit-copy annotations on values or scopes, and other such tools, an explicit move operation still has a place, as additional emphasis that the move-only value is expected to end its lifetime at a specific location. Although consuming a move-only value will provide a static constraint that the value can't be used again, that might not be evident to readers or future maintainers of the code, who might otherwise refactor the code to cause the value to be consumed later, or dropped without being consumed. I could still see the ability to explicitly mark the end of a value's lifetime being useful even with move-only types, so I think the proposed feature is still complementary to those future language features.

Andrew_Trick · 2022-07-26T18:25:37.560Z

hborla:

Does this proposal fit well with the feel and direction of Swift?

This is the epitome of a Swifty approach.

The vast majority of Swift programmers do not need to control lifetimes. The language lets them go about their business without being burdened by lifetime annotations. In those rare situations where the design depends specific lifetime behavior, programmers can express their intentions. That's important not only to verify assumptions but to communicate to other programmers.

The move intrinsic is complementary with a near-future @noImplicitCopy annotation along with other lifetime controls. They're being introduced in the order that it makes sense to develop them and get programmer feedback. Naturally, that tends to be in order if increasing importance. If you find yourself saying "I won't use this control, but would like the next one", then that's reasonable and expected.

We're starting with niche tools now, but they are an important steps toward introducing move-only types, which will be a much more visible language feature. Move-only types build directly on top of these controls and will inherit their semantics. Being able to experiment those semantics earlier means that the design of the larger feature will be better when it is introduced.

Michael_Gottesman · 2022-07-26T18:27:27.957Z

ksluder:

hborla:

What is your evaluation of the proposal?

-1 on move(_:) as a function. Wholeheartedly +1 on move semantics and use-after-move diagnostics.

My initial opposition to move(_:) as a function is well expressed by the first sentence in the Alternatives Considered section:

As a function, move is rather unusual, since it only accepts certain forms of expression as its argument, and it doesn't really have any runtime behavior of its own, acting more as a marker for the compiler to perform additional analysis.

However, my opinion has evolved a little bit and now I think it would be worth trying to avoid any syntactic marker at the site of the move.

Is the problem being addressed significant enough to warrant a change to Swift?

Yes.

Does this proposal fit well with the feel and direction of Swift?

No. Swift has hidden retain and release since its inception. Requiring the use of an explicit move(_:) function feels like a step backward.

I would much prefer the language team focus first on move-only types as alluded to under the “Suppress Implicit Copying” heading of the Alternatives Considered section. Move-only types are akin to non-Sendable types in that both dictate when reads are permitted. They just have opposite defaults—types are not Sendable by default, but they are copyable (that is, not move-only) by default. Move-only types could be signified with conformance to a MoveOnly marker protocol:
struct Pair : MoveOnly {
  var x: Int
  var y: Int
}

let p1 = Pair(x: 100, y: 100)
var p2 = p1 // note: value moved to `p2` here
print(p1.x) // error: value has been moved from `p1`
Like Sendable, we can imagine allowing developers to write move-only “envelope” types to opt values of copyable type into move-only semantics. Such an envelope would subsume the need for a standalone move(_:) function.
class SomeClass { }
struct MoveOnlyRef<T: AnyObject>: MoveOnly {
  private var wrappedValue: T?
  init(_ wrappedValue: T) {
    self.wrappedValue = wrappedValue
  }

  @_semantics(move)
  mutating func move() -> T? {
    // This implementation wouldn’t actually be used,
    // since this method is marked with @_semantics.
    // But it helps illustrate the value-level effects.
    let tmp = wrappedValue
    wrappedValue = nil
    return tmp
  }
}

let ref1 = MoveOnlyRef(SomeClass())
let ref2 = ref1.move()
print(ref1) // Optional<SomeClass>.none
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

C++ has had std::move since C++11, and it’s kind of a nightmare. It’s viral and interacts poorly with standard optimizations (NRVO). I fear move(_:) will be taught as "std::move() for Swift", and worse that it might in fact share enough of its confusing semantics. (Indeed, the proposal even refers to C++ and Rust’s use of move as a term of art.)

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A quick reading and periodic discussion with the authors over the course of development of this proposal.

One thing that I think is important to understand here is that when we mentioned move/c++ in the proposal, we were only using it to refer to the inspiration for the name, not the implementation. For instance:

This doesn't disable NRVO.
It doesn't leave behind a potential zombie value with underspecified semantics.

The way I would think about move is it is like Rust's drop except that it also works for copyable types and lets you get back out the moved value.

Michael_Gottesman · 2022-07-26T18:33:06.200Z

One thing that I would like to make clear to the reviewers is that the move function is not intended to be the end all be all of tools in this space. The idea behind this system swift effort is to provide system programmers with a new toolbox of compiler driven power tools to get their job done. The move function is just intended to be a wrench in that toolbox and its existence should not be seen to imply that the language will not eventually provide a jack hammer (full on move only types) or a buzz saw (no implicit copy) in the fullness of time. NOTE: That fullness isn't too far in the future since we already have a no implicit copy implementation on main and I am currently prototyping on main full on move only types.

tera · 2022-07-26T19:03:27.372Z

michelf:

For a class/actor reference, copying the reference is what ends up calling retain. I could rewrite my example with this spelling and it'd be exactly the same thing:
@noimplicitretain let x = MyObject()
let y = x         // error, retain must be explicit: use retain(x)
let z = retain(x) // ok

Yeah, I just wanted to emphasise that "copy" for references would be somewhat confusing ("copy a reference" vs "copy a referenced object") as historically in Obj-C we did have both "retain" and "copy" doing different things.

On naming. Like Array's removeFirst is used to remove first element and either use it to ignore it, we can use the name "drop" for both operations:

foo(drop(z))
let y = drop(x)
drop(y)

If to use an operator to make it feel more built-in:

foo(^z)
let y = ^x
^x

or

foo(z^)
let y = x^
x^

tera · 2022-07-26T19:44:12.409Z

tera:

pitch allows to write essentially the same but without the need of extra brackets / nesting. Is this correct observation?

Expanding on that thought, this is the alternative for pitch examples using nesting instead of "move".

The nesting alternative

Example from the pitch:

We can modify the previous example to use move to explicitly end the lifetime of y when we're done with it:

func test() {
  var x: [Int] = getArray()
  
  // x is appended to. After this point, we know that x is unique. We want to
  // preserve that property.
  x.append(5)
  
  // We create a new variable y so we can write an algorithm where we may
  // change the value of y (causing a COW copy of the buffer shared with x).
  var y = x
  longAlgorithmUsing(&y)
  // We no longer use y after this point, so move it when we pass it off to
  // the last use.
  consumeFinalY(move(y))

  // x will be unique again here.
  x.append(7)
}

How we can do it instead:

func test() {
	var x: [Int] = getArray()

	// x is appended to. After this point, we know that x is unique. We want to
	// preserve that property.
	x.append(5)

	// We create a new variable y so we can write an algorithm where we may
	// change the value of y (causing a COW copy of the buffer shared with x).
	
	do {
		var y = x
		longAlgorithmUsing(&y)
		// We no longer use y after this point, so move it when we pass it off to
		// the last use.
		consumeFinalY(y)
	}

	// x will be unique again here.
	x.append(7)
}

Another example from the pitch:

If we declare another local constant other with the same value of x, we can use that other binding after we end the lifetime of x, as in:

func useX(_ x: SomeClassType) -> () {}
func consumeX(_ x: __owned SomeClassType) -> () {}

func f() {
  let x = ...
  useX(x)
  let other = x   // other is a new binding used to extend the lifetime of x
  _ = move(x) // x's lifetime ends
  useX(other)     // other is used here... no problem.
  consumeX(other) // other is used here... no problem.
}

How we can do it instead (pseudocode):

func useX(_ x: SomeClassType) -> () {}
func consumeX(_ x: __owned SomeClassType) -> () {}

func f() {
	let other = do {
		let x = ...
		useX(x)
		return x
	} // x's lifetime ends
	// other is a new binding used to extend the lifetime of x
	useX(other)     // other is used here... no problem.
	consumeX(other) // other is used here... no problem.
}

The second example is more interesting as it asks for the value of "do {...}" block, something which is not currently possible (*):

let other = do {
	let x = ...
	useX(x)
	return x
} // `x` lifetime ended
// `x`  is moved to `other`

We don't have this today (*), but hopefully we will have it at some point (along with other statements like "if" and "switch" used as expressions).

Am I missing something obvious on why move is significantly better than nesting? It feels a bit like "goto" compared to more structured alternatives.

(*) Edit: in fact it is possible today, just using a closure:

let other = { () -> ... in
	let x = ...
	useX(x)
	return x
}() // `x` lifetime ended
// `x`  is moved to `other`

but it would be nice if "do" operator supported it as well (or better! without extra brackets and type annotations).

Andrew_Trick · 2022-07-26T20:08:50.737Z

Chris_Lattner3:

I agree with the general concerns above. move isn't a function and breaks composition in weird ways, it is built-in.

I think that Xiaodi's suggestion is good, given that operators feel more "built in".

True, but it's not a good idea to introduce cryptic syntax for a seldom used, niche feature. This isn't something programmers need to or should learn about when they start using Swift. They'll only be confused when they stumble across something that looks like stray characters.

Chris_Lattner3 · 2022-07-26T20:18:12.079Z

Agreed, but you seem to be implying that move semantics will be "a seldom used niche feature". I agree it is an "advanced" feature, but as soon as you start having widely used libraries defining move-only types, users of those libraries will have to use these features in practice.

One major point of operators is that they are visually distinct. Furthermore, Swift's approach is a benefit here: unlike C++'s operator overloading, Swift allows defining /new/ operators. Novel operators are better for conceptually new things like this, because they allow a reader to "realize that this is something they don't know".

Andrew_Trick · 2022-07-26T21:59:52.134Z

It might help to clarify the future of move in a world with move-only types/values.

Calling the move intrinsic on a move-only value would have no functional effect, except when used as a drop function. Even as a drop function, the intended behavior is identical to optimized builds. (There will need to be a separate discussion about whether debug builds should eagerly drop move-only values.)

When move is used with move-only values, it will be a form of self-documentation. Either the programmer used it correctly, and it does nothing. Or the compiler issues an error.

I view move mostly as a tool to use move semantics with copyable types with the highest possible precision--very much an advanced feature. But still an important feature because, when you do need it, it's on the critical path.

ksluder · 2022-07-27T01:08:18.764Z

I appreciate the additional information that various members of the Swift team have provided. It’s good to hear more about how move(_:) fits into the larger vision for move semantics, and how it differs from the C++ and Rust features that inspired its name. I think that context is necessary to properly evaluate this proposal, because without it I definitely got the impression that move(_:) was designed to be the core interface to Swift’s move semantics, à la std::move(). @Andrew_Trick says “move-only types […] will be a much more visible language feature”, and I am also told that move(_:) is explicitly not meant to address certain use cases such as guaranteeing in-place mutation.

Filling out the design

Even with that additional context, I do think the proposal under-specifies some aspects of move(_:)’s behavior. The interaction with captures is significantly underspecified, IMO. I’ve learned some things about @escaping in this thread that are not explained in TSPL. Perhaps if I were an expert on every nuance of closure behavior the proposal contains enough information for me to infer the complete interaction between move(_:) and captures. But like most people who will eventually use this feature, I am not an expert on any aspect of any of Swift’s behaviors, and I still don’t quite understand whether the compiler is expected to accept or reject capturing a variable that is at moved from at some future point in time.

Likewise, I think the proposal could do more to explain how move(_:) in argument position interacts with (and possibly redefines) Swift’s formal model of inout parameters, which have heretofore been defined as a copy to and write-back from an invisible temporary variable. Does that mean values must be moved into inout arguments by the caller to avoid a copy? What happens if the caller does not move the value into the argument, but the callee does try to move the value out of the parameter? Is it possible to define the new semantics without having to introduce something akin to the prvalue/xvalue family tree?

The spelling of the operation

As the proposal admits, move(_:) looks like a function but it’s not a function. The presence of the move(_:) token itself is what imparts its effects. One might be tempted to draw an analogy to type(of:), invocations of which are currently replaced by the compiler. But type(of:) behaves like a normal function in that you can wrap it in another function without changing its behavior. (If Swift had generic function values, you’d also be able to assign it to a variable.) And thanks to implicitly opened existentials, type(of:) can be implemented as a normal function in Swift 6, possibly wrapping a runtime call if source compatibility with Swift 5.x is desired.

Using a function-like spelling is also inconsistent with another very recent language change. There were significant parsing issues with any that could have been solved by requiring the use of parentheses or angle brackets, but those options were directly rejected. In fact, one reason for rejecting Any<> was that using such a familiar syntax might deceive a reader into thinking they could write their own equivalent of Any<>. Why reuse existing syntax for move(_:) when the same argument didn't hold for any?

@xwu proposed a sigil. I don’t think it could be a true operator for the same reason move(_:) isn’t a true function, and therefore I don’t think it’s a much better solution. Would the sigil reserve an otherwise-valid operator spelling?

The pursuit of alternatives

In my initial response, I said:

ksluder:

I would much prefer the language team focus first on move-only types as alluded to under the “Suppress Implicit Copying” heading of the Alternatives Considered section.

That specific phrasing carries a value judgment about move(_:) versus move-only types and implies an accusation of misprioritization, which was not my intent. What I really meant to convey was a suspicion that move-only types could be a functional superset of a move(_:) operation with less novel syntax, and thus it’s worth investigating them in tandem rather than deferring move-only types to future work. I’m happy to learn that @Michael_Gottesman is already hard at work on some alternatives/future directions.

I would like to propose another thread of investigation that is significantly closer to the existing proposal: move as a parameter modifier:

func takeAnArg(arg: move Int) -> Int { arg + 100 }

This shifts the syntax to the declaration, rather than the call site. Like inout, moving from a binding has effects on the caller’s environment, so a & would be required:

let x = 100
let y = takeAnArg(&x)
print(x) // error: value was moved out of 'x' and no new value was assigned

If we stop here, we have what we need to define move(_:) as a real function:

func move<T>(value: move T) -> T { value }

…which could either be provided via the Standard Library or left to clients to implement in the same way Swift leaves clients to implement local generic functions to implicitly open existentials.

Of course, this is an almost-bikeshed-level change to the original proposal, and does not address its interactions with inout or closure captures. But since there seems to be some supposition that explicit use of move(_:) will be rare to begin with, I would be interested to hear how the experts think this adjustment would play out in the cases where it’s currently necessary.

Extension to return position

A small extension to this design could address a related use case that move(_:) does not cover. Allowing move to decorate a return type could be defined as the spelling for placement-return:

// The ABI of `makeMeSomething` passes enough information
// to allow placement initialization of all of SomeHeavyStruct’s members.
func makeMeSomething() -> move SomeHeavyStruct {
  return SomeHeavyStruct(x: 100, y: 100, z: 100, w: 100, ...)
}

let ptr = UnsafeMutablePointer<SomeHeavyStruct>.allocate()
ptr.pointee = makeMeSomething()
// Avoids returning a temporary copy of SomeHeavyStruct via the stack.
// Runs the initializer directly on the storage pointed to by `ptr.pointee`.

Supporting move-only types

My understanding is that currently “no implicit copy” and “move-only” are being considered as separate primitive type attributes. My hope is that it would be possible to implement a move-only type by combining move-as-parameter-or-return-modifier with “no implicit copy”, but I haven’t yet succeeded.

michelf · 2022-07-27T01:40:07.300Z

Chris_Lattner3:

Agreed, but you seem to be implying that move semantics will be "a seldom used niche feature". I agree it is an "advanced" feature, but as soon as you start having widely used libraries defining move-only types, users of those libraries will have to use these features in practice.

That needs more explaining. The proposal isn't about introducing move-only types, nor is (openly) motivated by allowing move-only types. It's obviously related somewhat, but I'd hope move-only types can work without requiring an explicit move.

For instance, let's say I have a move-only type, it could work like this:

let x = MoveOnlyType()
let y = x // ok, implicitly ends the lifetime of x, moving to y
let z = x // error: x consumed by previous statement

You can use the move-only type without calling move() anywhere, because the value is implicitly moved for you whenever it's needed. If you don't write code that requires an implicit copy, you might not even realize you're dealing with a move-only type.

To stay in line with the above, a @noimplicitcopy modifier for variables could work like this:

@noimplicitcopy let x = SomeCopyableType()
let y = x // ok, moving to y, implicitly ends the lifetime of x
let z = x // error: x lifetime ended with previous statement

The remedy would be to make an explicit copy when assigning x to y:

@noimplicitcopy let x = SomeCopyableType()
let y = copy(x) // ok, explicitly copying to y
let z = x // ok, implicitly moved to z, x's lifetime ends here

No move() necessary in all of this. The only remaining reason to use move would be to explicitly end the lifetime early, hence why I'm suggesting it be called endLifetime().

Zhu_Shengqi · 2022-07-27T03:06:16.394Z

Agree on the formalisation of __consuming (as well as __owned) in the language first. It is somewhat weird to have a formal proposal depending on some internal keywords inside the language, which makes it harder to understand and review (at least for me).