SE-0316 (second review): Global Actors

Evolution Proposal Reviews
5

I really like the addition of the GlobalActor protocol and appreciate the ability to isolate data to GlobalActor-constrained generic parameters. It's definitely a +1 from me!

Also, I wonder what the compiler uses to differentiate global actors. I imagine it’s type identity, which would mean that super- and sub-classes are treated as different global actors. Is this correct?

A witness that is not inside an actor type infers actor isolation from a protocol requirement that is satisfies, so long as the protocol conformance is stated within the same type definition or extension as the witness:

Are default implementations considered witnesses? If not, it seems reasonable that they — like witnesses — inherit the corresponding requirement’s isolation.

The accessors of a variable or subscript declared with a global actor attribute become isolated to the given global actor. (This includes observing accessors on a stored variable.)

Could this rule be relaxed in the future, allowing multiple accessors to be isolated to different global actors? This would be useful for UI frameworks that both get and set state through a single property declaration, and that require state to remain constant during updates. For example, SwiftUI’s @State could declare wrappedValue as:

var wrappedValue: Value {
    @MainActor get
    @PostUpdateActor get
    @PostUpdateActor set
}

Then, event handlers, such as onTapGesture, would provide an @PostUpdateActor-isolated closure:

func onTapGesture(
    count: Int = 1,
    perform action: @PostUpdateActor @escaping () -> Void
) -> some View

Nits:

  1. In my opinion, callbackAsyncly and callbackAsynchronously read better than callbackAsynchly.
  2. The AppKit sample code uses UIViewController instead of NSViewController.