An Informal Introduction to Move-Only Types

[Karl]

Good explanation.

But with regards to this section:

@tbkka

Unfortunately, compilers “copy” data for a lot of mundane reasons. For example, when you pass a value as a function argument, that data is “copied” from memory into a register. That means a truly non-copyable piece of data can only be passed by reference, never by value. Truly non-copyable data is tricky to work with.

But not all copies cause problems: In many cases, the “copy” exists in order to move a piece of data to a more appropriate location. For example, when you compute “x = x + 1”, the result may naturally end up in a different location (machine register or memory address) than it started. This isn’t really a “copy” since the first location is no longer valid. Similarly, when you return a value from a function, the original value inside the function is no longer valid. This makes it useful to distinguish between "regular copies" which result in two or more valid instances of the data, and "moves" which result in a single instance of the data in a new location, with the old location no longer being considered valid. Note that in "x = x + 1" and other cases, moves are really just side-effects of some other operation.

And then later:

@tbkka

A value that can be moved but not copied has a very well-defined lifecycle. It is created, passed into functions and back out again, moved into different variables, and finally stops being valid. Throughout this lifecycle, there is only ever a single valid copy of this value. Among other things, this gives it a well-defined end of life that can be determined at compile time. This is unlike a regular copyable value which requires run-time support to correctly determine when every copy has stopped being used.

I think the term "copy" is unhelpful and potentially misleading, and I hope we can think of a better alternative.

When we talk about copies here, my understanding is that we're really talking about arbitrary lifetime extensions - i.e. the ability to retain some class instance which will live until you, at your leisure, choose to release it, or for POD types: the ability to create a value containing the same bits as another value, but in independent storage (e.g. escaping the stack frame and copying the value in to a global or class instance).

I don't think we're talking about copy in the sense of shuffling data in/out of registers. We're also not talking about copies in the sense of copy-on-write (although those kinds of copies may be affected by controlling the copies we are talking about). Correct me if I'm wrong, but the only reason these notions enter the text in the first place is due to the potential confusion caused by the term "copy".

And I think it is important that we straighten this out - the text has to jump through some awkward hoops as a result of this terminology issue. Firstly it simply declares things like register shuffling as not a problem, including using the extremely confusing phrase "in many cases, copy exists in order to move". This leads to having to define a notion of "regular copies", and in order to explain what they are, we have to suddenly switch gears and start talking about lifetimes instead.

IMO, tightening the terminology helps us focus, and helps everybody understand what these features do and when to use them.

---

I also think the term "move-only" is problematic, for similar reasons. Firstly, it is factually incorrect - you can still borrow these values, so they are in no sense "move only".

What they are are non-copyable (see note above: in other words, you cannot arbitrarily extend their lifetimes; they have constrained lifetimes).

Similarly, the text refers to "truly non-copyable data". What it means is data which is both non-copyable AND non-moveable (in effect, borrow-only). Of course, it is difficult to talk about this if we stick to the term "move-only" as a synonym for non-copyable, as the former implicitly excludes borrows, meaning we would be left with the phrase "immovable move-only data" --- which, yeah.

---

By the way, I have mentioned both of these issues previously (and in other reviews). I didn't get any direct responses on the terminology issue. Hopefully the issues I've pointed out with this text illustrate why I believe this is still a significant issue.

This is still a somewhat-simplified ownership model. More easily digestible. Even with these features, I don't believe we would have the full expressive power to, say, store a value with a bound lifetime (say, a non-escaping closure) in a struct/Array, and have that struct/Array be bound to the value's lifetime (Rust's more verbose model can express that, with the drawbacks as mentioned in the text).

But it's still valuable, I'm really excited for it, and I think it will be a really great addition to the language. I appreciate that naming things is very, very hard, but I also think it is one of the most important aspects to ensure that Swift's ownership model remains usable even as it becomes more expressive.