SE-0313: Improved control over actor isolation

Evolution Proposal Reviews
24

After reading this syntax-directed proposal and the other type-directed proposal (Exploration: Type System Considerations for Actor Proposal) , it seems easier to understand and reason about in the type-directed approach (@sync and @async actor types). I don't need to remember more complicated syntax rules (though it may be quite natural from a language designer's perspective), and I'm thrilled that I can use existing POP techniques and other third-party Swift libraries when the actor model is integrated into the language.

In the Alternatives Considered section, the author explains why the syntax-directed approach is preferred:

  1. The proposal treat isolated as a type modifier similar as inout, because "it provides a simpler, value-centric model".

    While I agree that it provides a value-centric model, I don't really think it provides a simpler model. What simplicity means to me is that we address more issues with less rules. The proposal should explain more on why this value-centric model is simpler.

  2. The type of an actor's self can change within nested contexts, such as closures, between @sync and non- @sync.

    It really seems natural to me that if a @sync actor is captured in an async closure, it will be automatically casted to @async type. Even this is a new syntax rule that modifies the captured variables behavior in the current language, I don't see strong reason why we should resist this change.

  3. The design relies heavily on the implicit conversion from @sync MyActor to MyActor .

    Again this implicit conversion seems natural to me. I don't understand why this should be the reason that we don't choose the type-directed approach. The author should explain WHY this implicit conversion is a bad idea.

  4. A @sync actor type is a subtype of the corresponding (non- @sync ) actor type. A non- @sync actor type conforms to Sendable (it's safe to share it across concurrency domains), but its corresponding @sync subtype does not conform to Sendable .

    My question is that: if we allow @sync actor type safely converts to @async actor type, does this behavior really means that a @sync actor type is a subtype of the @async actor type? I can take a simple example here: we can convert T to Optional<T> in Swift, but does this really means T is a subtype of Optional<T>? I don't think so.

So I can conclude that the counterarguments that this proposal raised against the type-directed approach (@sync and @async actor types) doesn't really hold from my view. I hope the author could add more rational and discuss more on this :)