SE-0470: Global-actor isolated conformances

[Douglas_Gregor]

@John_McCall

I'm confused about the role of SendableMetatype in the current proposal, though. In previous drafts, I know that this was imagined as a real sendability constraint on the type value which prevented the type from being e.g. captured in a sendable closure. In the current proposal, however, it seems to function solely as a way of preventing isolated conformances from being passed (thus granting the function the ability to use the conformance in a sendable closure, even if the conforming type isn't sendable).

I think the SendableMetatype name isn't a good one for the role this (marker) protocol plays any more. Something like NonisolatedConformances would be more accurate to what it does.

@John_McCall

This seems like a strange way to write this — it looks like some kind of type restriction, which it doesn't actually seem to be anymore. Wouldn't the following be both a clearer and a more general way to express this?

1. A conformance requirement can be explicitly declared nonisolated, e.g. where T: nonisolated P.
2. Conformance requirements are implicitly nonisolated when the conforming type is constrained to be Sendable.
3. Clients may not use a global-actor-isolated conformance to satisfy a nonisolated conformance requirement.

It's more general, yes, and something similar is described in future work. Note that your #2, which infers nonisolated on conformance requirements T: P when T is Sendable, is effectively a type restriction from the user perspective... but it's implemented as an inference rule that desugars down to the conformance restrictions.

My main concern is around the complexity of introducing a new kind of requirement, T: nonisolated P, into the language/formal model/implementation. I don't really know yet how it's going to work out; new kinds of requirements can have ripple effects.

Stepping back a little bit, this proposal involves a source-breaking change that will start to reject some generic code that carries conformances across an isolation boundary. We think that:

a. Most generic code never crosses any isolation boundaries, so it is unaffected, and
b. Most generic code that does carry a conformance T: P across an isolation boundary also carries a value of the conforming type across an isolation boundary, so it will also have a constraint T: Sendable.

Under these assumptions, the source-breaking change has very little practical impact. The code that does break looks a bit like this:

protocol P {
  static func f()
}

func callF<T: P>(_: T.Type) {
  Task.detached {
    T.f() // needs to error, because it carries T: P across an isolation boundary
  }
}

We need a type-checking model that produces that error, and a way to describe to that model that T:P must not be allowed to use an isolated conformance so we can fix callF. According to (b), that could be T: Sendable, but that's a stronger constraint than we really want for this code. So we're seeking the constraint in between.

Something like T: SendableMetatype or T: NonisolatedConformances expresses it as a type-based property, the same way T: Sendable does. The inference rule for Sendable is then encoded in protocol inheritance:

/*@marker*/ protocol SendableMetatype { }
/*@marker*/ protocol Sendable: SendableMetatype { }

Your suggested nonisolated conformances express it as a conformance property. This is more general when there are multiple conformances involved, e.g.,

protocol P {
  static func f()
}

protocol Q {
  static func G()
}

func callFG<T>(_: T.Type) where T: P, T: nonisolated Q {
  Task.detached {
    T.f() // needs to error, because it carries T: P across an isolation boundary
    T.g() // okay, because `T` has a nonisolated conformance to Q
  }
}

In the proposal's model (T: NonisolatedConformances or T: SendableMetatype), there's no way to express that T: P can be isolated but T: nonisolated Q cannot. I suspect we don't need this flexibility, and would rather not introduce the complexity of this model into the system if we don't need it.

In writing this, I'm convincing myself that I prefer the non-sendable-metatype model from earlier pitches, rather than the partial implementation of your nonisolated conformance requirements that is in the proposal as under review. I don't think we need the complexity of the model you propose, and the non-sendable-metatype model fits neatly into the Sendable design we have today.

@8675309

I think this will bring a huge usability improvement for protocols, however I think the biggest win is naturally extending this to include @Sendable protocol conformances as well:

As noted in future directions, I think your "sendable protocol conformances" are equivalent to "nonisolated conformances", but that the isolation terminology is better here.

@grynspan

Swift Testing relies on macros that expand and reference somewhat arbitrary types from within nonisolated helper functions. Did you do any testing to see if the @Test or @Suite macros would break?

Yes, some of the code tested used Swift Testing.

@grynspan

As well (apologies if this is in the proposal and I missed it), is there a mechanism to opt a protocol out of this functionality, e.g. if it models some concept that cannot function correctly when arbitrarily isolated (but which also does not imply Sendable)?

You could make the protocol inherit from SendableMetatype, which would prevent an isolated conformance to it.

Doug