The second review of SE-0306: Actors begins now and runs through April 23, 2021. The previous review thread was here:
In response to the first round of review, the core team has decided to subset out actor inheritance. We would like to see how real-world adoption of actors plays out before deciding whether actor inheritance is necessary. The core team would like to focus review discussion on a top raised by Chris Lattner in the previous review:
The core team sees two competing draws for consistency here—first, as Chris notes, in other places where Swift models API design,
let is externally treated equivalently with a get-only
var, and by that principle, actors should follow suit and not expose
lets as implicitly
nonisolated outside of the actor even if they are immutable. That would reserve for the actor the ability to evolve the interface into an internally-mutable variable, or get-only computed property, without breaking API or ABI. It would also result in a consistent rule for how
nonisolated apply to actor members; instead of
lets being a special case, any actor declaration would require
nonisolated to be explicitly annotated in order to declare it as safe to access from outside the actor without isolation.
On the other hand, "
lets are immutable and safe to share across threads" has also been a common message through Swift's history, and it could seem boilerplatey to require an explicit annotation on top of
let in order to say that, yes, this immutable value is actually immutable. If actors in practice end up carrying a lot of immutable state, the annotation burden could be onerous. The core team would like to hear from the community, particularly adopters who have experimented with actors, to get more signal about how much burden treating the isolation
lets equivalently with other declarations will be in practice.
Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager. If you do email me directly, please put "SE-0306" somewhere in the subject line.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
- What is your evaluation of the proposal?
- Is the problem being addressed significant enough to warrant a change to Swift?
- Does this proposal fit well with the feel and direction of Swift?
- If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
- How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at https://github.com/apple/swift-evolution/blob/master/process.md .
Thank you for contributing to Swift!
Joe Groff, Review Manager