Maybe MainActor
will change its behavior, and start running synchronously when it can, yes.
But if I understand @ktoso well, at the time custom executors become public, we'd become able to write, outside of the stdlib, in our own application or library code, a custom global actor that does what we need:
@MainActor // (sic)
func someSynchronousUIKitOrSwiftUICallback() {
Task { @UIActor in // (sic) a custom global actor
for await value in someAsyncSequence {
// handle value
}
}
// <- Here values that were produced synchronously
// are already handled, and UIKit/SwiftUI has been
// correctly instructed.
}
This custom UIActor
would play exactly the same role as those existing tools:
They exist for a well identified reason: they help developers program asynchronously within the constraints of frameworks like UIKit or SwiftUI.
In UIKit or SwiftUI, a missed opportunity from one of their synchronous callbacks usually means a degraded experience for the app user or the developer, from a blank frame on screen, to a need to explicitly code against double-taps.
Combine and RxSwift exist independently of UIKit or SwiftUI, and yet they provide the sharp and necessary tools for a seamless integration. I'm very eager to see Swift concurrency fill the gap with custom executors.