SE-0528: Non-`Copyable` `Continuation`

Evolution Proposal Reviews
2

I think the idea is fine, but:

  • I think the "future direction" of ~Discardable could not actually be adopted by Continuation since "I can prove to the compiler that I always consume this object" is quite different from "dynamically, I always consume this object", and I wouldn't expect it to be able to be done source-compatibly.
  • The usefulness of this proposal is tied to the acceptance of SE-0527, since without UniqueArray the stdlib has no solution for storing a collection of Continuations
  • Until Mutex.withLock accepts a once-callable closure (#81546), most uses of this type will have to jump through silly hoops like:
let continuations = Mutex(UniqueArray<Continuation<T, E>>())

...

try await withContinuation(...) { continuation in
    var optionalContinuation = Optional(continuation)
    continuations.withLock { array in
        array.append(optionalContinuation.take()!)
    }
}

Overall, I don't think that this actually, right now, gets us to a situation where the compiler can ensure we're using continuations safely. The runtime crash for discarded continuations is glaring, and the necessity of using optionals and force-unwrap to deal with the lack of once-callable closures means that in practice, there are likely to be more runtime checks associated with using Continuation than are currently required by CheckedContinuation. Certainly I don't think I have any uses of CheckedContinuation that could be migrated and the code made better as a result.

It's a "yes, but not yet" from me. Let's get SE-0527 approved, once-callable closures added, and a concrete decision on ~Discardable before going here. This proposal will be all the better for the wait, and there's no clamor for it now.

9 Likes