[Second review] SE-0390: Noncopyable structs and enums

[Joe_Groff]

@ksluder

Sorry to continue this topic, but has there been consideration for how to spell non-copyable, non-nominal types? For example, Swift models C arrays as homogeneous tuples.

I don't think we want to make more language decisions on top of the way fixed arrays are currently imported from C; nobody likes it (that I know of) and it desperately needs to be replaced. But a tuple would be noncopyable if any of its elements are noncopyable, once noncopyable tuples are supported, and that shouldn't need any explicit annotation. We don't have a way to directly import a C type as a noncopyable type; like Steve said, you would probably want to wrap the C type in a Swift type already to give it an API with the right borrowing/consuming behavior, a deinit if appropriate, and other functionality that integrates with the language.

@ksluder

I think an insightful opinion will require playing with the feature, trying to implement a type that suppresses the default deinit. I definitely want to play with it myself.

It is implemented in nightly snapshot toolchains, if you want to try it out (though the declaration syntax is still @_moveOnly struct, and the disable-deinit statement is still _forget self pending a final syntax decision).

@dnadoba

@ksluder

What about non-copyable closures—are those the same thing as non-escaping closures?

To extend on this, how can we capture and consume non-copyable values in closures?

Closures today can be executed zero or more times and there is no way of spelling that they are called exactly once. This sounds like it would not be possible to capture and consume a non-copyable type. Lots of APIs actually guarantee that they are executed exactly once, e.g. most of the with* style methods, Result {} and we also have escaping ones like Task {} and EventLoopFuture.whenComplete from SwiftNIO.

non-copyable consuming closures could guarantee that they are not executed more than once but I think we still need another spelling that requires that they are called exactly once.

A run-once closure would be a reasonable future direction, but we don't propose that here. So there is no way to statically consume a value inside a closure yet. Nonescaping closures borrow their captures, either immutably or mutably as needed, for the duration of the call the closure is passed to, and escaping closures impose an indefinite borrow on the capture. You can still dynamically consume a captured value by wrapping it in an Optional-like enum (or eventually Optional<T> itself, once we support that), and giving the enum a mutating method that returns the value inside while resetting itself to nil.