[Pitch] Control default actor isolation inference

Evolution Pitches
21

I strongly believe that the SPM manifest API shape should be using a new enum type with mainActor as one of its cases instead of (any GlobalActor.Type)?.

We can't expect build configuration code to have access to types in the code that is being built, nor could that work anyways since this ultimately has to be translated to a compiler flag. Worse, it might give people the wrong idea that the build configuration somehow should be able to get access to your own types.

22

To be clear, I am not proposing that. The type of the argument in the proposal is MainActor.Type, and the only valid arguments are MainActor.self and nil. Allowing custom global actors is in the alternatives considered section, and I updated the proposal to remove a version of the API that accepts an existential type.

1 Like
23

Still, it seems inconsistent to the rest of the SPM manifest API that we'd use a type like MainActor.Type here versus an enum. Can you elaborate on why exactly you're proposing this instead of a dedicated enum type? What's the strong case for this one to be different from other build settings?

1 Like
24

I still don't believe this is necessary; that is:

  • it only saves you from writing @MainActor; there's no dramatic reduction in complexity here.
  • it's basically only relevant on Apple platforms
  • the number of @MainActor that this can realistically elide is small, since most declarations in small app codebases for Apple platforms are already implicitly @MainActor (eg. {UI,NS}View{Controller,} subclasses, View types).

Essentially, the only place where it's going to help are

  • ViewModel-type classes, where anecdotally I think most projects have a superclass or protocol for VMs to conform to which could add an implicit @MainActor already, and by and large it doesn't make a difference since they're rarely calling @MainActor APIs anyway, but sure. Maybe there's something to be said here.
  • global variables, which… I think "making global variables usable" should be an anti-goal of anything. That doesn't help anyone. Just remove mutable globals from the language entirely.

And the cost of it is, that you can never know from any Swift code snippet, whether that code is correct (because it can depend on the dialect), and copy-pasting an answer to a forum post into your app might not work (in either dialectal direction). Every Swift Q&A ever asked will probably have to state which dialect they assume.

A couple thoughts for "ways it could be less divisive":

  • make the implicit global actor only apply to class types and global variables: most other types of declaration, it doesn't matter, and these two types of declaration specifically are what's hard to concurr-icize. Most value types are already fine, actors are already fine, most free functions are already fine.
  • infer the implicit global actor only for non-public declarations: same rule as Sendable; make the author explicitly declare intent if they're making something other people can depend upon.

All that said though, if this is considered necessary (and it seems like that ship has sailed, sadly), I think this is pitched the right way around — an easy opt-in for people who want it (possibly including "new Xcode projects"), whilst most OSS (swift package init, etc) get the more general language by default.