Pitch: `Continuation` — Safe and Performant Async Continuations

[fabianfett]

@mattie

The second use case is gating, as a meaning of synchronizing access to an actor across awaits. I’m not sure I understand how a ~Copyable type would serve that use-case either. Normally I put these continuations into collections. Can I do that with this kind of type?

@fabianfett

Furthermore, the recent landing of new collection types that allow noncopyable Elements in swift-collections demonstrates that the ecosystem is ready to work with noncopyable types as first-class building blocks.

Yes, you can! As hinted in the proposal, swift-collections now has a UniqueArray and UniqueDeque.

@mattie

func myAsyncBridge() async {
  withContinuation { continuation in
    // this is an old API. Even if the language one day gained the ability to express that this closure is called only once, this API will never be updated.
     someCallbackBasedAPI { value in
      // doesn't this mean the capture here is invalid?
      continuation.resume(value)
    }
  }
}

This code would not compile, with a ~Copyable type, you would be forced to use an Optional<Continuation> here.

[Joe_Groff]

@mattie

The second use case is gating, as a meaning of synchronizing access to an actor across awaits. I’m not sure I understand how a ~Copyable type would serve that use-case either. Normally I put these continuations into collections. Can I do that with this kind of type?

That was a consideration for the existing UnsafeContinuation and CheckedContinuation types, that one of the primary use cases of continuations is indeed for bridging to foreign APIs, and since we can't really expect foreign APIs to ever be 100% annotated perfectly for the static Swift guarantees they might provide, so there would likely be indefinite need for a fully-dynamically-enforced continuation variant to pass through these interfaces.

Given only a non-Copyable Continuation, you can box a noncopyable value in an object, whose reference would then be Copyable, and furthermore place the value itself in an Optional so that you can dynamically consume it using Optional.take. That's the usual way we recommend interfacing noncopyable values with interfaces that are unfriendly to static ownership checking. One could look at CheckedContinuation as being a prepackaged "box-and-optionalize" type for the noncopyable Continuation. Perhaps there should even be initializers on CheckedContinuation and Continuation to make it easy to construct one by forwarding ownership from the other:

extension CheckedContinuation {
  // Take responsibility away from the given `Continuation`, which will become
  // dynamically checked.
  init(_ continuation: consuming Continuation)
}

extension Continuation {
  // Try to take responsibility away from the given `CheckedContinuation`, if
  // it is uniquely referenced, and has not already been resumed. May return
  // nil if unique ownership of the unresumed continuation cannot be regained.
  init?(_ checkedContinuation: consuming CheckedContinuation)
}

Those conversions could reduce friction in adopting Continuation for its stronger guarantees as much as possible, while still making it straightforward to degrade to dynamic checking where it becomes necessary.