SE-0313: Require `Sendable` for types involved in `nonisolated` declarations

Hey all,

I posted a small amendment to SE-0313 that requires any nonisolated declaration to only involve Sendable types. This eliminates the potential for data races due to non-Sendable values being accessible from any actor, e.g.,

class SomeClass {
  var counter = 0
}

actor A {
  nonisolated let sc: SomeClass = SomeClass() // with amendment, error: SomeClass is not Sendable
}

func f(a: A) {
  a.sc.counter += 1 // ill-formed with amendment, data race without it
}

Doug

19 Likes

Sounds good to me, we had just discussed some use cases that needed non isolated things and indeed the type there would have been Sendable because it was safe to access afterall.

I keep wondering how long we’ll get away without offering the unsafe non isolated variant but so far it seems we’re getting away with it hmm… maybe we’ll never have to - since it’s easy enough to wrap a type with a small unchecked Sendable wrapper if for some reason I’d know “it’s fine”.

7 Likes

yes, this sounds like an obvious "bug fix" that we should have caught as part of the nonisolated proposal.

4 Likes

The use of isolated protocol conformances would require a number of other restrictions to ensure that the protocol conformance cannot be used on non-isolated instances of the actor. For example, this means that a non-isolated conformance can never be used along with Sendable on the same type, because that would permit a non-isolated instance of the actor to be passed outside of the actor's isolation domain along with a protocol conformance that assumes it is within the actor's isolation domain.

I am a little confused with the above paragraph now specially “non-isolated conformance can never be used along with Sendable on the same type”. Could this paragraph be clarified around the amendment?

It's actually disjoint from the amendment, but we can try to clarify.

Doug

1 Like

The Core Team discussed this amendment and has accepted it as an obvious bug fix.

Doug

4 Likes