SE-0300 (third review): Continuations for interfacing async tasks with synchronous code

[Joe_Groff]

@Lantua

Since the generic type T is only used for return type, should we also add the parameter returning: T.Type = T.self ?

I haven't observed the need to explicitly state a return type in the examples I've seen, but we could certainly add this if we saw it become a problem in the wild. You should also be able to guide the type-checker's hand by writing withUnsafeContinuation { } as T to get it to pick up the return type from context.

@xwu

In the CheckedContinuation section, the function parameters for withChecked*Continuation still refer to CheckedContinuation<T> instead of CheckedContinuation<T, Never> or CheckedContinuation<T, Error> as appropriate.

I'll fix that, thanks.

@xwu

In the previous iteration of the proposal, it somehow seemed natural to include resume(with result: Result<T, E>) , but seen in a new light with the clarity afforded by consolidating the disparate types, I wonder how often this convenience will be used.

None of the examples in the proposal make use of that particular convenience; are there a lot of callback-based APIs that could take advantage of it?

If I'm not mistaken, Result does not have compiler magic for covariant generic parameters, and the with*Continuation APIs fix the type of the argument to resume(with:) to be Result<T, Never> or Result<T, Error> , and not Result<T, E> , where E is a specific error. So the convenience is restricted as it is to callback APIs that don't use Result to specify a typed error.

resume(with:) came up as a result of our own experimentation with migrating some codebases to async that used Result. It's true that tying the error type of the Result to the error type of the continuation limits the usefulness of this API when the continuation has Error type; we have since added a further overload to help with this case:

extension UnsafeContinuation {
  public func resume<Er: Error>(with result: Result<T, Er>) where E == Error
}

I'll update the proposal to include this.

@xwu

In the same vein, it seems that the design as-is doesn't really make use of a parameterized error type. It seems like either with*ThrowingContinuation should use a parameterized error type too, or the *Continuation types should not.

This is the issue with including error parameters in these APIs in general; they're more for future proofing in case we add typed errors in the future, even if today you can only really use them with Never and Error. Since we've decided to also include error type parameters in other parts of the API, like Task.Handle and Task.Group, it seems worth it to be consistent here.