[Pitch] Global actors

[Douglas_Gregor]

@bjhomer

• An overridden declaration propagates its global actor attribute (if any) to its overrides mandatorily. Other forms of propagation do not apply to overrides. It is an error if a declaration with a global actor attribute overrides a declaration without an attribute.

I assume this means that overridden declarations from a non-isolated superclass are not actor-isolated to the global actor, which would mean that in the following code, viewDidAppear would not be actor-isolated:

@MainActor
class IconViewController: UIViewController {
  var url: URL?

  override func viewDidAppear() {
    // Error: cannot access actor-isolated property 'url'
    // from non-isolated context
    self.url = URL(string: "https://example.org")!
  }
}

This seems annoying, since viewDidAppear is always going to be called on the main thread (as per the UIKit/AppKit framework). Is there any mechanism proposed whereby ObjC code can declare a type as actor-isolated?

Yes, one can use __attribute__((swift_attr("@MainActor"))) to state that an Objective-C declaration will always be called on the main actor. Of course, we can't verify that from the Objective-C side, but it makes annotation possible. This is documented in SE-0297, albeit somewhat indirectly because we hadn't written up the global-actors pitch fully at that time.

@bjhomer

This won't be exposed to ObjC because it's private . But if it were not private, what would such a declaration look like in ObjC? Is the actor-isolation preserved in any way when exposed to ObjC? If so, how? If not, does that expose a potentially source of unsafety, where a caller might access a @MainActor property from a background thread in ObjC?

Ignoring the private, the declaration in Objective-C could use the attribute I mentioned above. And yes, it's completely unsafe from the Objective-C side--we've had to live with that in Swift since day 1, where (Objective-)C code can freely violate the safety guarantees otherwise provided by Swift, and I think it's okay to do the same thing here.

I'll bring some discussion of this into the proposal, thank you!

Doug