[Accepted] SE-0390: Noncopyable structs and enums

scanon · May 23, 2023, 7:53pm

Hello, Swift community.

The second review of SE-0390 ran from March 21st through April 4th. The second review was narrowly focused on the revisions made after the first review:

The spelling of the "negative constraint" ~Copyable.
The spelling of the discard self operator and its constraints.

There was a lot of discussion about how to spell the negative constraint; there was a lot of discussion within the language workgroup as well. Ultimately, we felt that none of the offered alternatives were clearly better, so we went with what was in the proposal text. The spelling is ~Copyable.

There are three minor changes to the proposal that the workgroup agreed to make doing our discussion:

At the very end of the review, it was noted by one of the proposal authors that there would be no easy way to suppress an unused variable warning with _ = x or let _ = x when x is a noncopyable binding, if those assignments were consuming. The workgroup agreed to adopt the rule that assignment to _ will be interpreted as a borrowing, rather than consuming operation. If you want to end the lifetime, that can be written with _ = consume x.
Noncopyable enums cannot have a deinit.
When switching over a noncopyable type, you must switch consume self.

The latter two might be relaxed via future proposals; they are pragmatic considerations more than fundamental design requirements.

SE-0390 has been accepted with the above modifications. The proposal text will be updated to include them.

Thanks to both the community and the proposal authors for their patience.

Steve Canon
Review Manager

Joe_Groff · May 25, 2023, 11:46pm

Thanks Steve! I have amended the proposal to follow the Language Steering Group's recommendations:

github.com/apple/swift-evolution

Updates to SE-0390 to correspond to current implementation

apple:main ← jckarter:se-0390-may-2023-checkpoint

opened 11:59PM - 15 May 23 UTC

jckarter

+177 -14

- Doing flow sensitive escape analysis to allow for locals to be consumed before… they get escapingly captured is too hard and probably not really worth it. Just say that they always behave as escaped if they ever are escaped. - Local `let` bindings to closure literals are considered nonescaping if the `let` doesn't escape. This falls out of the existing analysis built into the mandatory SIL passes. - Deinit `self` is immutable for now, while we debate the proper way to handle mutation and consumption while controlling the potential for accidental recursion.

I have also subset out a couple of aspects of the original proposal to correspond to what we've been able to implement so far:

The proposal had specified that local variables escaped by closures become non-consumable after the point they get escaped by a closure, but we weren't able to implement this flow sensitive analysis, and the added expressivity seemed minor, so I've subset the proposal to have it so that escaped local variables are never consumable. We can potentially implement the originally proposed behavior later.
We are leaving self within deinits immutable for now, while we discuss the best way to allow for deinits to perform mutations and consumptions while mitigating the potential for accidental infinite recursion by implicit deinits elsewhere.