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:
Module for distributed actor related APIs
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.
More explicit initialization of actor system in initializers
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 id and 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.
Use of mangled names in method identifiers
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 mangledName and 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!