SE-0429: Partial consumption of noncopyable values

Evolution Proposal Reviews
1

Hello Swift community,

The review of SE-0429: Partial consumption of noncopyable values begins now and runs through March 26, 2024.

Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to me as the review manager via the forum messaging feature. When contacting the review manager directly, please put "SE-0429" in the subject line.

Trying it out

If you'd like to try this proposal out, you can download a nightly toolchain and enable the experimental flag given in the proposal.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to Swift?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/main/process.md

Thank you,

Xiaodi Wu
Review Manager

12 Likes
2

Just checking: it’s already not binary-compatible to add a deinit to a frozen non-copyable type that didn’t have one, correct? (“I promise I don’t have a meaningful deinit” could have been spelled @inlinable deinit {}, but instead that’s implied by @frozen with no explicit deinit declaration?)

4

Hey folks. I noticed it's kinda tumbleweeds in here. :slight_smile: Which is not all that surprising. This feature is hard to grok unless you try it.

To help with that, I wrote up a walkthrough here. Trying to write the code in that post with this feature enabled and disabled helped me internalize what it means to partially consume a value.

5 Likes
5

FWIW, I think partial consumption is a really valuable feature and something a lot of people would stumble into a need for whether they understand the theory or not (I pointed out an example in @Ben_Cohen's other thread).

I just don't have the knowledge or familiarity with non-copyable types [yet] to offer an informed review of the proposal.

But big :+1::+1: for the feature in principle.

1 Like
6

I don't really have much to say about this. The feature is obviously needed, and works the way it should. The restrictions make sense given the current state of the language. The only thing I can think to say is that it'd be nice if all of the listed future directions (especially reinitializing consumed fields) were implemented sooner rather than later.

7

If I understand correctly, this feature is a necessary prerequisite for unavailable deinits, which could be useful for e.g. closing a file, so the error can’t be implicitly ignored. Maybe this could be added to future directions?

struct FileDescriptor: ~Copyable {
    private let fd: Int
    deinit = unavailable
    consuming func close() throws {
        defer { discard self }
        if close(fd) != 0 {
            throw SomeError(…)
        }
    }
}
1 Like
8

Correct. This was documented in SE-0390.

Non-implicitly-destructible types are more of a future direction of non-copyable types in general rather than this proposal. In fact, I think they're probably explicitly at odds with partial consumption — much like we shouldn't allow partial consumption of types with an explicit deinit, we shouldn't allow partial consumption of types that completely disallow deinit because it's likely to subvert the intended safety goal of the type.

3 Likes
9

Hi all,

The language steering group has decided to accept this proposal.

2 Likes