[Pitch] Isolated conformances

[Douglas_Gregor]

@Slava_Pestov

@hborla

Inference rules like this have downsides, e.g. it can be difficult to determine when they've applied and why, it's easy to inadvertently change inference, etc, so the convenience might not be worth it. There may also be technical tradeoffs to making conformance isolation dependent on witness matching.

Yeah, I think if the isolation of the conformance can only be deduced by looking at all witnesses, then we would need to do more work than is otherwise necessary when the conformance is declared in a secondary file.

I'd also be concerned about recursion: we have to look at associated conformances as well as witnesses to determine if the isolation is correct, and it's possible that we need the same conformance to satisfy one of the associated conformances (possibly through some other intermediate conformance whose isolation is also being inferred).

I don't think we should go down the route of inferring isolation from witnesses/associated conformances because of the technical complexity.

Doug

[Andropov (Raúl Montón)]

@Douglas_Gregor

Since the default today is "nonisolated", we'd have to do this as part of an upcoming feature or language mode. That's not out of the question, but it's part of the reason why I am suggesting that this inference come along with "main actor inference" (should we get that).

Fair. The reason I brought this up in the first place was because with the original isolated spelling, settling on a default felt more like an irreversible decision (isolating the conformances to the type by default in the future would remove any reason for the standalone isolated spelling to exist) while now with the @MainActor spelling the syntax would remain relevant even if a future language version were to adopt isolated conformances for GAITs by default.

@Douglas_Gregor

The other reason is because inferring "isolated" when you didn't expect it can make your conformance unnecessarily restricted, whereas inferring "nonisolated" will produce an error if one of your witnesses is isolated and is easy to fix.

For that issue, maybe cases where inferring an isolated conformance results in a needlessly restricted conformance could be diagnosed? Thinking something like:

@MainActor 
struct Foo: Equatable {
            `warning: protocol `Equatable` inherits main actor isolation from the type, but its implementation is `nonisolated`
            `note: Did you mean `nonisolated Equatable`?

    nonisolated static func == (
         lhs: Foo, 
         rhs: Foo
    ) -> Bool {
    // ...
} 

Just an idea. I admit it would be odd to diagnose something like that given there's nothing wrong with providing a nonisolated implementation for a @MainActor isolated conformance, it's just unlikely to be what you want. But then in such unlikely scenarios maybe the warning could be suppressed by explicitly opting into an isolated conformance (ie @MainActor Equatable).

[Douglas_Gregor]

@Andropov

For that issue, maybe cases where inferring an isolated conformance results in a needlessly restricted conformance could be diagnosed? Thinking something like:

@MainActor 
struct Foo: Equatable {
            `warning: protocol `Equatable` inherits main actor isolation from the type, but its implementation is `nonisolated`
            `note: Did you mean `nonisolated Equatable`?

    nonisolated static func == (
         lhs: Foo, 
         rhs: Foo
    ) -> Bool {
    // ...
} 

Just an idea.

Yes, this is possible to do in the compiler. It has the potential to be really annoying, because the compiler is complaining about something it inferred itself and asking the user to write more code to silence it.

Doug

[xwu (Xiaodi Wu)]

For example, one could try to produce an any Equatable from a value of unknown type in any isolation domain:

func tryEquatable(_ lhs: Any, rhs: Any) -> Bool {
  if let eLHS = lhs as? any Equatable {
	  // use Equatable.==
  } else {
    return false
  }
}

The Any value could contain MyModelType, in which case the conformance to Equatable will be isolated. In such cases, the as? operation will check whether the code is running on the executor associated with the conformance's isolation. If so, the cast can succeed; otherwise, the case will fail (and produce nil).

I haven't worked this totally through, but once you have eLHS in hand as a value of any Equatable, is there some way to compose this with implicit existential opening to somehow lose track of the isolated nature of the conformance?

[Douglas_Gregor]

@xwu

For example, one could try to produce an any Equatable from a value of unknown type in any isolation domain:

func tryEquatable(_ lhs: Any, rhs: Any) -> Bool {
  if let eLHS = lhs as? any Equatable {
	  // use Equatable.==
  } else {
    return false
  }
}

The Any value could contain MyModelType, in which case the conformance to Equatable will be isolated. In such cases, the as? operation will check whether the code is running on the executor associated with the conformance's isolation. If so, the cast can succeed; otherwise, the case will fail (and produce nil).

I haven't worked this totally through, but once you have eLHS in hand as a value of any Equatable, is there some way to compose this with implicit existential opening to somehow lose track of the isolated nature of the conformance?

There are two checks that happen here with the as? when the Equatable conformance is isolated to a global actor:

• That the code is currently running on that global actor

• That Equatable itself does not imply SendableMetatype

  Doug

[Nickolas_Pohilets (Nickolas Pokhylets)]

Will it be possible to have a protocol that refines isolated version of another protocol? Currently it is not rejected at the point of refinement, but does not work when trying to implement the requirements.

protocol P {
  // note: mark the protocol requirement 'foo()' 'async' to allow actor-isolated conformances
  func foo() 
}

protocol Q: @MainActor P {}

class NS: Q {
    // error: main actor-isolated instance method 'foo()' cannot be used to satisfy nonisolated requirement from protocol 'P'
    @MainActor func foo() {}
}

This case might be a bit too restrictive, but is sound:

protocol P {
  func foo() 
}

protocol Q: P {}

// error: conformance of 'NS' to 'Q' depends on main actor-isolated conformance of 'NS' to 'P'; mark it as '@MainActor'
class NS: Q, @MainActor P {
    @MainActor func foo() {}
}

But if made a bit more complicated, diagnostics fails:

protocol Q: P {}
protocol R: P {}

class NS: Q, @MainActor R {
    // error: main actor-isolated instance method 'foo()' cannot be used to satisfy nonisolated requirement from protocol 'P'
    @MainActor func foo() {}
}

And this one crashes the compiler:

class NS: @AnotherActor Q, @MainActor R {
    func foo() {}
}

[Douglas_Gregor]

@Nickolas_Pohilets

Will it be possible to have a protocol that refines isolated version of another protocol?

I suppose it could be allowed if the refining protocol was on that same global actor, e.g.,

@MainActor protocol Q: @MainActor P { }

However, "refinement" is really just another way to spell a generic requirement. This would fit in as part of a (significant) expansion to allow requirements themselves to be global-actor-isolated, e.g., Self: @MainActor P.

@Nickolas_Pohilets

This case might be a bit too restrictive, but is sound:

protocol P {
  func foo() 
}

protocol Q: P {}

// error: conformance of 'NS' to 'Q' depends on main actor-isolated conformance of 'NS' to 'P'; mark it as '@MainActor'
class NS: Q, @MainActor P {
    @MainActor func foo() {}
}

Right, we have to reject this because otherwise NS: Q could be used off of the main actor, but make its way to the main-actor isolated conformance Q: P.

@Nickolas_Pohilets

But if made a bit more complicated, diagnostics fails:

protocol Q: P {}
protocol R: P {}

class NS: Q, @MainActor R {
    // error: main actor-isolated instance method 'foo()' cannot be used to satisfy nonisolated requirement from protocol 'P'
    @MainActor func foo() {}
}

Here, there's an ambiguity in the conformance of NS to P: is it meant to be nonisolated (as Q implies) or main-actor isolated (as P implies). When there's an ambiguity, the compiler should either pick nonisolated (it seemed to do that here) or ask the user to be more specific. You can't choose @MainActor P here without breaking the nonisolated conformance to Q, though.

@Nickolas_Pohilets

class NS: @AnotherActor Q, @MainActor R {
    func foo() {}
}

Thanks for testing the compiler ;). This needs to be rejected (without crashing), because we need a consistent answer for the isolation of the conformance to P.

Doug

[Nickolas_Pohilets (Nickolas Pokhylets)]

How does dynamic casting isolated conformances integrates with swift-evolution/proposals/NNNN-SerialExecutor-isIsolated.md at wip-isIsolated · ktoso/swift-evolution · GitHub?

When doing as? we cannot use checkIsolated(), but isIsolatingCurrentContext() could be used. But when doing as! it is even possible to use checkIsolated(). But I'm not sure if it is a good idea to have different behavior for as? vs as!.

[bbrk24]

@Douglas_Gregor

Thanks for testing the compiler ;). This needs to be rejected (without crashing), because we need a consistent answer for the isolation of the conformance to P.

Could it have a nonisolated conformance to P, then differently-isolated conformances to Q and R?

[xwu (Xiaodi Wu)]

Great ongoing comments here--thanks everyone! The proposal is now under active review and I'd encourage everyone to continue the conversation over in that thread.

Xiaodi Wu
Review Manager

[Douglas_Gregor]

Per Xiaodi's request, I'm going to reply here but ask future questions to go to the review thread.

@Nickolas_Pohilets

How does dynamic casting isolated conformances integrates with swift-evolution/proposals/NNNN-SerialExecutor-isIsolated.md at wip-isIsolated · ktoso/swift-evolution · GitHub?

The implementation essentially depends on that proposal to be able to handle custom executors.

@Nickolas_Pohilets

When doing as? we cannot use checkIsolated(), but isIsolatingCurrentContext() could be used. But when doing as! it is even possible to use checkIsolated(). But I'm not sure if it is a good idea to have different behavior for as? vs as!.

Right. If we end up with a custom executor that doesn't support isIsolatingCurrentContext(), we're somewhat stuck with as?: we could let it pass (that's a data race), possibly with a runtime warning about what's happening, or we could reject it and make conformances isolated to a global actor with a -pre-isIsolatingCurrentContext() executor unusable.

@bbrk24

@Douglas_Gregor

Thanks for testing the compiler ;). This needs to be rejected (without crashing), because we need a consistent answer for the isolation of the conformance to P.

Could it have a nonisolated conformance to P, then differently-isolated conformances to Q and R?

Yes, that's fine. Nonisolated conformances can be used from anywhere (just like nonisolated everything else).

Doug