If an actor system is fully synchronous, it is much less efficient and can't be reentrant. Actor implementations tend to be split on reentrancy. Having multipl

If an actor system is fully synchronous, it is much less efficient and can't be reentrant. Actor implementations tend to be split on reentrancy. Having multiple paused in-flight invocations of the actor means that you need to have clearly understood suspension points (hence await keywords). Non-reentrant actors like in Erlang can deadlock if two actor instances are calling one another. Because of the deadlock and some inefficiency concerns, some actor systems allow you to decide reentrancy per-actor as well. Because Swift concurrency is an upgrade on top of decades-old systems, I believe a certain amount of additional complexity was required whether it was built as reentrant or not. It was a bit harder to find than I expected, but here is a discussion piece around the initial choice of reentrancy by default. https://github.com/ktoso/swift-evolution/commit/d55bbbd6cc1a9556976abd7bc7b7529c6c65b081?short_path=d8e27b3#diff-d8e27b312b244d4f3bf6aecf20a5a52b6cc91d1da47f6a9ba942a1733cbbb225 https://github.com/ktoso/swift-evolution/commit/d55bbbd6cc1a...