To clarify: this proposal is entirely agnostic to queues and performs no queue hopping. Absent anything else like actors being involved, whatever queue calls the resume method will continue being the current queue when the continuation is resumed. In all the examples shown, that means the queue on which the callback was called. Queue hopping is only introduced by actors, executors and the like; these are proposals that build upon the previous async/await proposal.
So in your example, again absent any use of actors, the awaited call to request would resume on whatever queue response used to execute the callback. Similarly, any APIs that uses customizable queues (either via a stored property or via an argument with the callback) would continue to do so and the continuation would resume on the same queue the callback does.
I’ll suggest to the proposal authors they add a note clarifying this to the proposal.
Not quite. This proposal is aimed at allowing calling of completion handlers from async functions. It is not directly related to actors, other than that actors rely heavily on async functions and this proposal helps with writing more async functions.
As such, this discussion of queue hopping, while helping clarify some things, isn’t really pertinent to this review. I’d ask further discussion of queues and queue hopping be taken to a separate thread to keep the review focused on the specific proposal. I realize this takes some level of suspension of concerns, because awaited functions resuming on a different and often unclear queue to the one on which they were called is unsatisfactory – as is completion handlers doing so. But that is what the actors and related proposals are intended to address, not this one.