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

I think the improvements make a lot of sense. One nit and one comment/question/piece of feedback:

Nit--

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.

Comment/question/piece of feedback--

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.

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.

2 Likes