No,
as I see it, async / await without actors should behave the same way as if you pass continuations instead - especially if we auto convert CPS style functions into await/async style, the queueing behavior must not change IMHO.
1. Fixing "queue confusion" *must* be part of this proposal. The key bit of "magic" offered by async/await over continuation passing is that you're working in a single scope. A single scope should execute on a single queue unless the programmer explicitly requests otherwise. Queue hopping is a surprising problem in a single scope, and one that there's currently no adequate solution for.
Also consider error handling. In this code it's really hard to reason about what queue the catch block will execute on! And what about the defer block?
``` startSpinner() defer { stopSpinner() } do {
try await doSomeWorkOnSomeQ() try await doSomeMoreWorkOnSomeOtherQ() } catch { // Where am I? } ```
Please, please, PLEASE don't force us to litter our business logic with gobs of explicit queue-hopping code!
In my understanding, this is the advantage of using Actors, as calling `await` on actor functions is guaranteed to continue on the queue of the calling actor.
Only if you call „legacy“ non-actor async functions, you have to take care of queue hopping by yourself - as you do today.
It's true that actors would require a solution to the queue confusion problem, but not every program will want to use actors. My position is that the syntax of async/await demands a solution with or without actors. If we're ripping open the walls anyway let's fix the plumbing! |
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
