> On 25 Aug 2017, at 10:17, Thomas via swift-evolution > <[email protected]> wrote: > >> >> On 25 Aug 2017, at 09:04, Marc Schlichte <[email protected] >> <mailto:[email protected]>> wrote: >> >> >>> Am 24.08.2017 um 22:05 schrieb Thomas via swift-evolution >>> <[email protected] <mailto:[email protected]>>: >>> >>>> >>>> Yes, I think it is mandatory that we continue on the callers queue after >>>> an `await ` on some actor method. >>>> >>>> If you `await` on a non-actor-method though, you would have to changes >>>> queues manually if needed. >>>> >>>> Any `actor` should have a `let actorQueue: DispatchQueue` property so that >>>> we can call in these cases: >>>> >>>> ```await actorQueue.asyncCoroutine()``` as mentioned in the manifesto. >>> >>> Wouldn't that be really confusing though? That awaiting certain methods >>> would bring us back to the actor's queue but awaiting others would require >>> manual queue hopping? What if the compiler was to always generate the >>> 'await actorQueue.asyncCoroutine()' queue hopping code after awaiting on an >>> async/actor method? >>> >>> Thomas >>> >> >> I think we are not allowed to implicitly switch back to the actor's queue >> after awaiting non-actor methods. These might have been auto converted from >> Continuation-Passing-Style (CPS) to async/await style. With the `mainActor` >> idea from the manifesto, all existing code will run in some actor, so >> changing the queue semantics could break existing code. > > This would only happen when the caller is an actor, which means new code, so > I don't think we would be breaking any existing code.
Oh but yeah, the main actor will probably need migration/warnings from the compiler. Thomas
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
