I’m using default actor isolation of MainActor as well as approachable concurrency. But when I have a protocol conforming to Equatable, I still need to use @MainActor on conforming types:
protocol P1: Equatable { } struct S1: P1 { } // Error: Conformance of 'S1' to protocol 'P1' crosses into main actor-isolated code an can cause data races struct S1Workaround: @MainActor P1 { } // OK // Another potential workaround if `Equatable` conformance can be moved to the conforming type. protocol P2 { } struct S2: Equatable, P2 { } // OK
I filed Issue 83610 last week but not responses yet. Thus, posting here to see if anyone has insights to include if this is perhaps working as expected. Thank you.
@Douglas_Gregor Any insights here would be most appreciated. I’m trying to figure out if this is an issue with the Swift compiler, or a legitimate case of still having to use @MainActor when default isolation is MainActor. Thank you.
I was expecting to see the error you indicated with S1. I did not. The project built just fine.
Am I holding this wrong?
Well, right (-:
This is a slightly more modern Swift than your bug report:
% DEVELOPER_DIR=/Users/quinn/XcodeZone/Xcode-beta.app/Contents/Developer xcrun swift --version swift-driver version: 1.127.14.1 Apple Swift version 6.2 (swiftlang-6.2.0.19.9 clang-1700.3.19.1) Target: arm64-apple-macosx15.0
Thanks for the reply, Quinn! One key difference is that by default, new projects are still configured to use Swift 5. If you switch your build settings to Swift 6, you should then see the error.
I also now have the same Xcode 26 beta version; issue is still there.
One key difference is that by default, new projects are still configured to use Swift 5.
D’oh! I always fall into that trap. Normally I created projects from my own custom templates that have Swift 6 enabled, but in this case I wanted to stick with a built-in template because it’s the standard.
So, yeah, once I switched the language mode to 6 I see the error as well.
As to the issue itself, it definitely seem bugworthy to me, but I’m hardly the definitive source here.
Can anyone tell me why I need to use @MainActor Equatable on my types that need to conform to Equatable? I thought the purpose of approachable concurrency and default actor isolation of MainActor would not require these workarounds.
Default MainActor isolation acts as if you'd typed @MainActor on everything, so instead of having to add MainActor to the things you want isolated, you have to add nonisolated to the things you don't want isolated, like simple model types that conform to Equatable. Personally, those types of models are far more common than MainActor stuff (especially when using SwiftUI, which inherits @MainActor on the view bodies automatically), so I keep the setting off. And frankly, it's simpler to explain adding @MainActor than nonisolated, so that's my general recommendation too.
I just tried adding in nonisolated, but that turned out to be a huge mess. I don’t have many of these @MainActor workarounds in place, so I’ll leave it.
I still like the default actor isolation and approachable concurrency features as they have led to quite a bit of cleanup throughout my code.
Update: I ended up filing a DTS incident to get clarity on this issue and it’s indeed a bug.
With that said, no idea when this will get fixed. The issue I filed against this in swiftlang on GitHub (Aug 8th) is now buried on page 5. Don’t give it much hope since so many other issues (amongst the 5,000+) seem to go unaddressed.
Hoping it does get fixed though as any developer making use of default actor isolation will no doubt run into this. And while the workaround is trivial, it’s sad to force so many developers in applying it. Far less time/energy taken if it’s simply just fixed.