nonisolated GAIT initializers should behave more like synchronous actor initializers

[jamieQ]

Description

per SE-327:

A non-isolated initializer of a global-actor isolated type (GAIT) is in the same situation as a non-async actor initializer, in that it must bootstrap the instance without the executor's protection. ... To solve this race, we propose to apply flow-sensitive actor isolation to the initializers of GAITs that are marked as non-isolated.

however, nonisolated GAIT inits seem to error out during typechecking and don't make it to flow isolation in some cases where synchronous actor initializers do not. specifically, you cannot seem to initialize stored properties of non-sendable type in the GAIT case.

Reproduction

open class NS {}

@MainActor
final class GAIT {
    let ns: NS

    nonisolated init() {
      self.ns = NS() // 🛑
    }
}
/*
<source>:8:14: error: main actor-isolated property 'ns' can not be mutated from a nonisolated context [actor_isolated_non_self_reference]
 3 | @MainActor
 4 | final class GAIT {
 5 |     let ns: NS
   |         `- note: mutation of this property is only permitted within the actor [actor_mutable_state]
 6 | 
 7 | 	nonisolated init() {
 8 |         self.ns = NS()
   |              `- error: main actor-isolated property 'ns' can not be mutated from a nonisolated context [actor_isolated_non_self_reference]
 9 | 	}
10 | }
Compiler returned: 1
*/

Expected behavior

the behavior should generally match how synchronous actor initializers work:

actor A {
    let ns: NS

    init() {
      self.ns = NS() // ✅
    }
}

Environment

Swift version 6.2-dev (LLVM ca4ccf35b901178, Swift 5754397)
Target: x86_64-unknown-linux-gnu

compiled using -swift-version 6 (but seems to affect other configurations as well)

Additional information

No response

[jamieQ]

cc @hborla – the proximate cause seems like something in the checkReference() method in ActorIsolationChecker handles the nonisolated GAIT init and synchronous actor init cases differently. curious to hear any insights you may have on this issue!

[davedelong]

Another trivial reproduction of this is to make a nonisolated initializer of an @Observable and @MainActor-bound class with var properties:

@Observable
@MainActor
class Foo {
    var name: String
    
    nonisolated init(name: String) {
        self.name = name // error: Main actor-isolated property 'name' can not be mutated from a nonisolated context
    }
}

[hborla]

@jamieQ yes, this is an artificial restriction and you're right that this should be handled by flow isolation or region isolation to lift limitations. The behavior is still slightly different from synchronous actor initializers, because actor initializers always effectively accept sending parameters, but this is too restrictive for global-actor-isolated initializers because there would be more restrictions when initializing from a main actor isolated context. This only impacts non-Sendable parameters though; initializing a @MainActor-isolated field from a nonisolated initializer should always be safe if the type of the field is Sendable.

Removing the check in Sema is not sufficient - we need to explicitly handle this in the region isolation pass. There's a bit more context on this here: #81915 (the PR was closed because it was incorrect). We don't have enough information in Sema to determine whether an assignment in an init is initialization of the field or a call to a setter, so we can't determine whether the assignment is safe in Sema even if the property type is Sendable.