[Pitch] Noncopyable (or "move-only") structs and enums

[Joe_Groff]

@rauhul

Do you happen to have an example of where one would ever use a consuming set? (Though I see why this operation could be included if just for the sake of composability.)

I don't have a concrete example in mind.

@rauhul

passing an argument to an init parameter that is not explicitly borrowing:

Does this imply all parameters of the generated memberwise init are consuming and implicit copies are made for all copyable types?

Yeah, all initializer arguments are consuming by default, which is how the ABI is implemented today. Whether a copyable type is implicitly copied or not depends on whether it's the last use of the value; if the construction isn't the last use, and the parameter is used as part of the new constructed value, then a copy has to occur somewhere, but the consuming convention allows a copy to be avoided by forwarding when the construction is the final use of a value.

@rauhul

• Assuming Optional<noncopyable T> was allowed why is the explicit consume needed here if let y = consume x { ... }?
• Is the idea that one could write switch borrow x to avoid this consume-by-default behavior?

Iterating a Sequence with a for loop:

let xs = [1, 2, 3]

for x in consume xs {}
use(xs) // ERROR: xs consumed by for loop

Same question about explicit consume, otherwise this case seems covered by “explicitly consuming a value with the consume operator”

I use the explicit consume operator in these situations primarily because noncopyable types can't be used in these situations today, but I want to establish the conventions these operations have for future reference when we do have noncopyable types available in these situations. Extending if let, for, and friends to work with borrows is being discussed under the proposal for borrow and inout bindings. As you noted, you will most likely use a different syntax form to explicitly borrow.

@rauhul

it must declare whether the parameter uses the borrowing, consuming, or inout convention:

Is there a rational to requiring this as opposed to defaulting to borrowing like methods mentioned just below?

Primarily that forgetting to specify the convention and getting the wrong default could leave you stuck with the wrong behavior for move-only types, whereas when working with copyable types the difference is more of an optimization.

@rauhul

I could see a package/module where you one would not want this default. Ex: if you’re writing embedded firmware or device drivers (aspirational). In this case you would want a way to spell the “positive” case. I argue that this spelling is naturally extension MyType: Copyable. In which case the negative spelling (to mirror Sendable) would be extension MyType: @unavailable Copyable.

As part of the borrow and inout bindings, we're proposing that those bindings don't allow for implicit copying, which I think will allow you to get the effect you like by choosing those bindings over the typical var and let.

@rauhul

Additionally, is there ever a world in which we may want a type to be immovable, e.g. Literals stored in a .rodata/STRINGS sections? In this case I think spelling this would be extension MyType: @unavailable Moveable. While I don't think necessarily think this would be written frequently, I think it would be nice to be able to show these semantics in a generated interface when jumping to a module definition in Xcode/vscode.

Maybe, though nonmovable types are pretty niche in their applications. In Rust, you usually interact with global literals through &'static borrows. Since the values are owned by global constants, and globals can't be consumed out of because any code anywhere in the program can access them, they are effectively nonmovable.