Hi everyone. The first review for SE-0344, Distributed Actor Runtime, concluded on March 8, 2022. The core team has decided to return the proposal for revision. Enthusiasm for the distributed actor feature remains high, but there were a handful of design points that deserve further discussion:
There were concerns about polluting the default
Swift standard library module with the newly proposed APIs. The implementation of this proposal is being prototyped in a distinct
_Distributed module, and the core team agrees it should remain in a distinct module. There is already precedent for language features requiring importing additional modules, particularly how
@objc interop requires importing
Foundation on Apple platforms. We'd like this review to determine the final name for the module should be. Removing the underscore and calling it
Distributed may be fine, but we want to make sure the community gets a chance to comment on this in the next round of review.
The previous distributed actor proposal, SE-0336, specified that all non-delegating
init members of a distributed actor take an
ActorSystem parameter, and that the corresponding argument would be used by implicit compiler-synthesized code inside of the initializer to set the new actor instance's
actorSystem properties. This design was chosen because there are nontrivial invariants that must be maintained, and we were concerned about implementation complexity of trying to maintain these invariants when these fundamental distributed actor properties could be initialized under the control of user code. However, YR Chen criticized this design, noting that the behavior is inconsistent with how most Swift initializers behave, and offering an alternative:
The core team agrees that this is more explicit and expressive than the originally proposed behavior, and the proposal authors have prototyped this new behavior and found it feasible to implement. We'd like to see SE-0344 re-reviewed with changes consistent with this new initializer behavior in mind.
There was a lot of deep discussion about the mechanism for identifying methods. As proposed, methods would be identified using their Swift mangled names as identifiers, and this fact was exposed through parts of the API design, particularly the
fullName properties of
RemoteCallTarget. Mangled names have a major advantage that they unambiguously identify Swift methods in all their full generality of overloading, genericity, etc., so distributed actor methods can use the entirety of Swift's expressivity without worrying about collisions. Reviewers however noted several deficiencies:
- They are too specific. Small changes to a method signature that might otherwise be wire-protocol-compatible will lead to changes in mangled name.
- The mangled name format is nontrivial for non-Swift nodes to implement that might want to interop with a Swift distributed actor system.
- There were efficiency concerns with string-based identifiers in general.
Discussion about alternative schemes for method identification continued up to and past the review date, so the core team would like to see this discussion continue in the next round of review. We also request that the proposal authors summarize the alternatives considered thus far, and include additional rationale addressing how these tradeoffs play out in the design of the feature.
Thank you to everyone who participated in the review!