# SE-0470: Global-actor isolated conformances

**URL:** <https://forums.swift.org/t/se-0470-global-actor-isolated-conformances/78704>\
**Category:** Proposal Reviews\
**Created:** [March 21, 2025, 4:56am UTC](https://forums.swift.org/t/se-0470-global-actor-isolated-conformances/78704 "2025-03-21T04:56:58Z")\
**Posts on this page:** 17\
**Page:** 1

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [March 21, 2025, 4:56am UTC](https://forums.swift.org/t/se-0470-global-actor-isolated-conformances/78704/1 "2025-03-21T04:56:58Z")

</div>

Hi everyone,

The review of [SE-0470: Global-actor isolated conformances](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0470-isolated-conformances.md) begins now and runs through **April 3, 2025**.

This proposal is another one of those contemplated in the recently approved [vision document](https://github.com/swiftlang/swift-evolution/blob/main/visions/approachable-concurrency.md) to improve the approachability of Swift's data-race safety facilities.

Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager via the forum messaging feature. When contacting the review manager directly, please keep the proposal link at the top of the message.

#### Trying it out

If you'd like to try this proposal out, you can [download a toolchain supporting it](https://www.swift.org/download/). You will need to use a recent main development snapshot and to enable the experimental feature flags outlined in the proposal.

#### What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

- What is your evaluation of the proposal?
- Is the problem being addressed significant enough to warrant a change to Swift?
- Does this proposal fit well with the feel and direction of Swift?
- If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
- How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at [swift-evolution/process.md at main · swiftlang/swift-evolution · GitHub](https://github.com/apple/swift-evolution/blob/main/process.md).

Thank you,

Xiaodi Wu  
Review Manager

---

<div class="post-metadata">

**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\
**Post date:** [March 21, 2025, 6:23pm UTC](https://forums.swift.org/t/se-0470-global-actor-isolated-conformances/78704/2 "2025-03-21T18:23:21Z")

</div>

Really happy to see something along these lines. 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). 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.

---

<div class="post-metadata">

**Author:** ![8675309](https://avatars.discourse-cdn.com/v4/letter/8/ea5d25/32.png) [@8675309](https://forums.swift.org/u/8675309)\
**Post date:** [March 21, 2025, 6:57pm UTC](https://forums.swift.org/t/se-0470-global-actor-isolated-conformances/78704/3 "2025-03-21T18:57:36Z")

</div>

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:

```swift
protocol DataProviding: Sendable {
   func identifier() -> String
}

class MutableFoo, @Sendable DataProviding {
   private var mutData: Any
   private let someInternalStr: String

   // sendable impl
   func identifier() -> String {
      return someInternalStr
   } 
}

```

I also have to agree with the above comment regarding `SendableMetatype`. It's role in the proposal was quite confusing.

---

<div class="post-metadata">

**Author:** ![grynspan](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/grynspan/32/15315_2.png) [@grynspan](https://forums.swift.org/u/grynspan)\
**Post date:** [March 22, 2025, 3:44am UTC](https://forums.swift.org/t/se-0470-global-actor-isolated-conformances/78704/4 "2025-03-22T03:44:43Z")

</div>

The proposal makes sense to me, however this paragraph worries me:

> Initial testing of an implementation of this proposal found very little code that relied on `Sendable` metatypes where the corresponding type was not also `Sendable`. Therefore, this proposal suggests to accept this as a source-breaking change with strict concurrency (as a warning in Swift 5, error in Swift 6) rather than staging the change through an upcoming feature or alternative language mode.

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?

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`)? I don't have a specific idea of such a thing offhand, but my lack of imagination isn't worth much.

---

<div class="post-metadata">

**Author:** ![Nickolas\_Pohilets](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nickolas_pohilets/32/10659_2.png) [@Nickolas\_Pohilets](https://forums.swift.org/u/Nickolas_Pohilets)\
**Post date:** [March 22, 2025, 1:28pm UTC](https://forums.swift.org/t/se-0470-global-actor-isolated-conformances/78704/5 "2025-03-22T13:28:10Z")

</div>

Moving this discussion from pitch thread to here:

> [@\[Pitch\] Isolated conformances](https://forums.swift.org/t/pitch-isolated-conformances/77726/51):
>
> > [@\[Pitch\] Isolated conformances](https://forums.swift.org/t/pitch-isolated-conformances/77726/48):
> >
> > 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.

Our app still targets iOS 15, so it cannot use `DispatchSerialQueue`. Instead there are custom executor implementations that attempt to wrap `DispatchQueue` (non-main). Since underlying Dispatch API implementing `isIsolatingCurrentContext()` is private, custom implementations won't be able to implement it. They can only implement `checkIsolated()`. But even if implemented, `checkIsolated()` won't be called in pre-iOS 18 runtimes.

Assuming X is the runtime version where this feature becomes available:

| Min Version | Runtime Version | Behavior |
| --- | --- | --- |
| \< iOS 17 | \< iOS 18 | Custom executor; `assumeIsolated()` fails; dynamic cast ignoring current executor could be used as a workaround. |
| \< iOS 17 | \>= iOS 18, \< X | Custom executor; `assumeIsolated()` passes; dynamic cast ignores custom executor. |
| \< iOS 17 | \>= X | Custom executor; `assumeIsolated()` passes; dynamic cast checks custom executor without `isIsolatingCurrentContext()`. ⚠ |
| \>= iOS 17 | \< iOS 18. | `DispatchSerialQueue`; `assumeIsolated()` fails; dynamic cast ignoring current executor could be used as a workaround. |
| \>= iOS 17 | \>= iOS 18, \< X | `DispatchSerialQueue`; `assumeIsolated()` passes; dynamic cast ignores custom executor. |
| \>= iOS 17 | \>= X | `DispatchSerialQueue`; `assumeIsolated()` passes; dynamic cast checks custom executor, with `isIsolatingCurrentContext()` provided by `DispatchSerialQueue`. |

There is still one problematic case. I don't think we should let conditional casts silently pass, but not being able to use force casts can become a blocker.

I don't like idea of `as!` and `as?` having different behavior. We can keep their behavior in sync, if there is another way of asserting the current actor, that can be combined with dynamic casts.

And there is already one - it is `assumeIsolated()`. But currently it does not dynamically store the isolation that has been recovered. If it starts doing so, and dynamic casts can be used inside the closure passed to the `assumeIsolated()` - I think it will cover the remaining problematic use case.

Can this be done as part of SE-0470?

---

<div class="post-metadata">

**Author:** ![Nickolas\_Pohilets](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nickolas_pohilets/32/10659_2.png) [@Nickolas\_Pohilets](https://forums.swift.org/u/Nickolas_Pohilets)\
**Post date:** [March 23, 2025, 9:01am UTC](https://forums.swift.org/t/se-0470-global-actor-isolated-conformances/78704/6 "2025-03-23T09:01:00Z")

</div>

I've found a problem with down casting, but it is not specific to global-actor isolated conformances, but rather a general problem with marker protocols:

Normally it is not possible to cast to `Sendable`:

```swift
print(x as? Sendable) // error: marker protocol 'Sendable' cannot be used in a conditional cast

```

But if you ask nicely, it becomes possible:

```swift
func castPlease<T>(_ x: Any, to: T.Type) -> T? {
  return x as? T
}

protocol P {
  func foo() 
}

@MainActor
class MA: @MainActor P {
    func foo() {}
}

class NS {}

@MainActor
func test() {
  print(ObjectIdentifier((any P).self))
  print(ObjectIdentifier((any P & Sendable).self))
  print(castPlease(MA(), to: (any P & Sendable).self))
  print(ObjectIdentifier(Any.self))
  print(ObjectIdentifier((any Sendable).self))
  print(castPlease(NS(), to: (any Sendable).self))
}

// Prints:
// ObjectIdentifier(0x000000010456d340)
// ObjectIdentifier(0x000000010456d340)
// Optional(foo.MA)
// ObjectIdentifier(0x0000000104529de0)
// ObjectIdentifier(0x0000000104529de0)
// Optional(foo.NS)

```

Since metatypes with and without `Sendable` look the same in the runtime, this cannot be solved within the scope of the global-actor isolated conformances. I guess this could be solved by introducing another marker protocol (e.g. `Castable`), but that is out of scope of this feature.

---

<div class="post-metadata">

**Author:** ![Douglas\_Gregor](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/douglas_gregor/32/1362_2.png) [@Douglas\_Gregor](https://forums.swift.org/u/Douglas_Gregor)\
**Post date:** [March 25, 2025, 1:04am UTC](https://forums.swift.org/t/se-0470-global-actor-isolated-conformances/78704/7 "2025-03-25T01:04:22Z")

</div>

> [@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](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0470-isolated-conformances.md#isolated-conformance-requirements). 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:

```swift
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:

```swift
/*@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.,

```swift
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](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0470-isolated-conformances.md#non-sendable-terminology-instead-of-isolated-conformances), 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

---

<div class="post-metadata">

**Author:** ![Douglas\_Gregor](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/douglas_gregor/32/1362_2.png) [@Douglas\_Gregor](https://forums.swift.org/u/Douglas_Gregor)\
**Post date:** [March 25, 2025, 1:19am UTC](https://forums.swift.org/t/se-0470-global-actor-isolated-conformances/78704/8 "2025-03-25T01:19:30Z")

</div>

> [@Nickolas\_Pohilets](#):
>
> Our app still targets iOS 15, so it cannot use `DispatchSerialQueue`. Instead there are custom executor implementations that attempt to wrap `DispatchQueue` (non-main). Since underlying Dispatch API implementing `isIsolatingCurrentContext()` is private, custom implementations won't be able to implement it. They can only implement `checkIsolated()`. But even if implemented, `checkIsolated()` won't be called in pre-iOS 18 runtimes.

Generally speaking, we try to keep back-deployment considerations out of the design of language features, because they are vendor-specific and if taken to the extreme, can negatively affect the long-term language design.

> [@Nickolas\_Pohilets](#):
>
> There is still one problematic case. I don't think we should let conditional casts silently pass, but not being able to use force casts can become a blocker.

The dynamic casting machinery is part of the runtime, and "force cast" is effectively a conditional cast + a force unwrap. We can encode the requirements of an isolated conformance in a manner that they will cause an older runtime to always reject the conformance (so it never works dynamically) or always accept the conformance (so it will always work dynamically). The implementation currently does the latter, which admits data races. The only alternative I can think of that wasn't taken would be to inject an otherwise-unused `assumeIsolated {}` into each of the functions that satisfies a requirement in an isolated conformance, but only do so when back-deploying. That way the cast (whether conditional or forced) would succeed (ugh), but you'd get a fatal error at runtime rather than a data race.

> [@Nickolas\_Pohilets](#):
>
> I've found a problem with down casting, but it is not specific to global-actor isolated conformances, but rather a general problem with marker protocols:
> 
> Normally it is not possible to cast to `Sendable`:
> 
> ```swift
> print(x as? Sendable) // error: marker protocol 'Sendable' cannot be used in a conditional cast
> 
> ```
> 
> But if you ask nicely, it becomes possible

Sneaky! The prototype implementation does not implement it yet, but the [last paragraph on data-race safety](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0470-isolated-conformances.md#data-race-safety-issues) in the proposal indicates that we will need to communicate the `Sendable`-ness of an existential type down to the runtime so it can refuse to use an isolated conformance for a cast to (e.g.)`any P & Sendable`. I believe that covers this case.

Doug

---

<div class="post-metadata">

**Author:** ![Nickolas\_Pohilets](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nickolas_pohilets/32/10659_2.png) [@Nickolas\_Pohilets](https://forums.swift.org/u/Nickolas_Pohilets)\
**Post date:** [March 25, 2025, 1:15pm UTC](https://forums.swift.org/t/se-0470-global-actor-isolated-conformances/78704/9 "2025-03-25T13:15:43Z")

</div>

> [@Douglas\_Gregor](#):
>
> Generally speaking, we try to keep back-deployment considerations out of the design of language features, because they are vendor-specific and if taken to the extreme, can negatively affect the long-term language design.

| Min Version | Runtime Version | Behavior |
| --- | --- | --- |
| \< iOS 17 | \>= X | Custom executor; `assumeIsolated()` passes; dynamic cast checks custom executor without `isIsolatingCurrentContext()`. ⚠ |

The case that I've described uses modern SDK and latest runtime version, so it is a not back-deployment. It's more about backward-compatibility and adoption strategy.

On the second thought, the root cause of problem seems to be the fact that availability of the `SerialDispatchQueue` is not controlled by the runtime version, but by the minimum deployment version at compile time. If `if #available` machinery could be used with `SerialDispatchQueue` this solves the problem and reduces 6 cases that I've described into 3.

```swift
actor MyActor {
    private let executor: any SerialExecutor

    @available(iOS 17, *)
    init(queue: DispatchSerialQueue) {
        // Has isIsolatingCurrentContext() when it is needed
        self.executor = queue // error: Cannot assign value of type 'DispatchSerialQueue' to type 'any SerialExecutor'
    }

    init(queue: DispatchQueue) {
        // No isIsolatingCurrentContext(), but it is not needed
        self.executor = CustomQueueExecutor(queue: queue)
    }
}

```

> [@Douglas\_Gregor](#):
>
> The dynamic casting machinery is part of the runtime, and "force cast" is effectively a conditional cast + a force unwrap. We can encode the requirements of an isolated conformance in a manner that they will cause an older runtime to always reject the conformance (so it never works dynamically) or always accept the conformance (so it will always work dynamically). The implementation currently does the latter, which admits data races. The only alternative I can think of that wasn't taken would be to inject an otherwise-unused `assumeIsolated {}` into each of the functions that satisfies a requirement in an isolated conformance, but only do so when back-deploying. That way the cast (whether conditional or forced) would succeed (ugh), but you'd get a fatal error at runtime rather than a data race.

Again, back-deployment is not the case that I was talking about, but I like the idea. Some runtime diagnostics would be great. And if it could be configurable that would be fantastic! E.g. we would probably prefer to silently send event to Crashlytics, rather than crash in production.

> [@Douglas\_Gregor](#):
>
> Sneaky! The prototype implementation does not implement it yet, but the [last paragraph on data-race safety](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0470-isolated-conformances.md#data-race-safety-issues) in the proposal indicates that we will need to communicate the `Sendable`-ness of an existential type down to the runtime so it can refuse to use an isolated conformance for a cast to (e.g.)`any P & Sendable`. I believe that covers this case.

That would require being able to distinguish between `(any P).self` and `(any P & Sendable).self` in the runtime. Does that mean that `Sendable` stops being a marker protocol? Does that mean that restriction for casting to `Sendable` can be lifted everywhere (e.g. including the non-sneaky example)?

---

<div class="post-metadata">

**Author:** ![Douglas\_Gregor](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/douglas_gregor/32/1362_2.png) [@Douglas\_Gregor](https://forums.swift.org/u/Douglas_Gregor)\
**Post date:** [March 25, 2025, 5:22pm UTC](https://forums.swift.org/t/se-0470-global-actor-isolated-conformances/78704/10 "2025-03-25T17:22:12Z")

</div>

> [@Nickolas\_Pohilets](#):
>
> > [@Douglas\_Gregor](#):
> >
> > Sneaky! The prototype implementation does not implement it yet, but the [last paragraph on data-race safety](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0470-isolated-conformances.md#data-race-safety-issues) in the proposal indicates that we will need to communicate the `Sendable`-ness of an existential type down to the runtime so it can refuse to use an isolated conformance for a cast to (e.g.)`any P & Sendable`. I believe that covers this case.
> 
> That would require being able to distinguish between `(any P).self` and `(any P & Sendable).self` in the runtime. Does that mean that `Sendable` stops being a marker protocol? Does that mean that restriction for casting to `Sendable` can be lifted everywhere (e.g. including the non-sneaky example)?

Oh, this is tricky. I was thinking of it as something we would do specifically for the casts themselves, because changing the identity of existential types (such as `any Sendable & P` is distinct from `any P` at runtime) can have far-ranging implications. But that means that my approach here _won't_ fix this existing issue with marker protocols.

Doug

---

<div class="post-metadata">

**Author:** ![Douglas\_Gregor](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/douglas_gregor/32/1362_2.png) [@Douglas\_Gregor](https://forums.swift.org/u/Douglas_Gregor)\
**Post date:** [March 25, 2025, 5:41pm UTC](https://forums.swift.org/t/se-0470-global-actor-isolated-conformances/78704/11 "2025-03-25T17:41:28Z")

</div>

> [@Nickolas\_Pohilets](#):
>
> On the second thought, the root cause of problem seems to be the fact that availability of the `SerialDispatchQueue` is not controlled by the runtime version, but by the minimum deployment version at compile time. If `if #available` machinery could be used with `SerialDispatchQueue` this solves the problem and reduces 6 cases that I've described into 3.

Ah, I see that in the Dispatch headers. This is outside of the Swift project's scope; please do file a Feedback .

Doug

---

<div class="post-metadata">

**Author:** ![Douglas\_Gregor](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/douglas_gregor/32/1362_2.png) [@Douglas\_Gregor](https://forums.swift.org/u/Douglas_Gregor)\
**Post date:** [March 27, 2025, 4:21am UTC](https://forums.swift.org/t/se-0470-global-actor-isolated-conformances/78704/12 "2025-03-27T04:21:33Z")

</div>

> [@xwu](#):
>
> If you'd like to try this proposal out, you can [download a toolchain supporting it](https://www.swift.org/download/). You will need to use a recent main development snapshot and to enable the experimental feature flags outlined in the proposal.

For folks looking to do this, grab a recent toolchain (e.g., one published on March 25th). There are three (!) separate experimental flags that can be enabled:

- `IsolatedConformances` to enable this feature

- `InferIsolatedConformances` for the upcoming feature that infers global-actor isolation for conformances of a global-actor-isolated type to a non-isolated protocol

- `StrictSendableMetatypes` to treat a metatype like `T.Type` as not being `Sendable` when `T` has a `SendableMetatype` constraint on it (related to the [discussion here](https://forums.swift.org/t/se-0470-global-actor-isolated-conformances/78704/7)). Enabling this with strict concurrency gives one an over-approximation of the source compatibility issues introduced in the proposal.

---

<div class="post-metadata">

**Author:** ![Douglas\_Gregor](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/douglas_gregor/32/1362_2.png) [@Douglas\_Gregor](https://forums.swift.org/u/Douglas_Gregor)\
**Post date:** [March 28, 2025, 5:35am UTC](https://forums.swift.org/t/se-0470-global-actor-isolated-conformances/78704/13 "2025-03-28T05:35:38Z")

</div>

> [@Douglas\_Gregor](#):
>
> 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.

I've written up a [change to the proposal under review](https://github.com/swiftlang/swift-evolution/pull/2763) that does the above. Specifically, rather than try to treat conformances as isolated within generic functions, we instead say that a metatype `T.Type` is only considered `Sendable` when `T: MetatypeSendable`. This is a simpler model than the one in the proposal as stated, but we don't lose much flexibility.

Doug

---

<div class="post-metadata">

**Author:** ![8675309](https://avatars.discourse-cdn.com/v4/letter/8/ea5d25/32.png) [@8675309](https://forums.swift.org/u/8675309)\
**Post date:** [April 6, 2025, 6:56pm UTC](https://forums.swift.org/t/se-0470-global-actor-isolated-conformances/78704/14 "2025-04-06T18:56:14Z")

</div>

Does this proposal also allow for a global-actor isolation conformance on a non-global actor isolated type or actor?

```swift
@MainActor protocol MainProtocol {
   // ...
}

actor a: @MainActor MainProtocol {

}

```

---

<div class="post-metadata">

**Author:** ![Douglas\_Gregor](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/douglas_gregor/32/1362_2.png) [@Douglas\_Gregor](https://forums.swift.org/u/Douglas_Gregor)\
**Post date:** [April 8, 2025, 3:13pm UTC](https://forums.swift.org/t/se-0470-global-actor-isolated-conformances/78704/15 "2025-04-08T15:13:53Z")

</div>

> [@8675309](#):
>
> Does this proposal also allow for a global-actor isolation conformance on a non-global actor isolated type or actor?
> 
> ```swift
> @MainActor protocol MainProtocol {
> // ...
> }
> 
> actor a: @MainActor MainProtocol {
> 
> }
> 
> ```

Yes, any type can have a global-actor-isolated conformance. Note that, in your example, you don’t need the protocol to be isolated to the main actor, and in general it won’t be.

Doug

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [April 9, 2025, 3:22pm UTC](https://forums.swift.org/t/se-0470-global-actor-isolated-conformances/78704/16 "2025-04-09T15:22:32Z")

</div>

Thank you all. The language steering group has decided to [accept](https://forums.swift.org/t/accepted-se-0470-global-actor-isolated-conformances/79189) this proposal.

---

<div class="post-metadata">

**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\
**Post date:** [April 9, 2025, 4:18pm UTC](https://forums.swift.org/t/se-0470-global-actor-isolated-conformances/78704/17 "2025-04-09T16:18:05Z")

</div>

Closed on April 9, 2025, 4:18pm UTC