Is there any guidance on how to deal with concurrency warnings?

[Rion-Kaneshiro]

If you set concurrency warnings to full, a lot of warnings start creeping up.

My Package definition contains the following setup:

for target in package.targets where target.type != .system {
  target.swiftSettings = target.swiftSettings ?? []
  target.swiftSettings?.append(
    .unsafeFlags([
      "-Xfrontend", "-warn-concurrency",
      "-Xfrontend", "-enable-actor-data-race-checks",
    ])
  )
}

I noticed that having set that, warnings like

Cannot form key path that captures non-sendable type 'KeyPath<AppFeature.Action.AllCasePaths, AnyCasePath<AppFeature.Action, Feature.Action>>'

start showing up a lot with the newest version of the Composable Architecture.

I checked all my model types and added Sendable to them and further added .sendable to @Reducer(state:action:) where ever it was possible which reduced the number of warnings in some places, but was ultimately unable to eliminate all of them.

Two places stuck out the most, namely the static properties of dependencies required by DependencyKey, which result in

Static property 'testValue' is not concurrency-safe because it is non-isolated global shared mutable state; this is an error in Swift 6

and the usage of said dependency within the reducer itself which results in

await send(.taskResponse(Result { try await self.client.fetch() }))
// Capture of 'self' with non-sendable type 'Feature' in a `@Sendable` closure
// Consider making struct 'Feature' conform to the 'Sendable' protocol

Of cause you could actually attach Sendable to the Reducer itself, but I'm not sure what's the "blessed" way might be to deal with all the warnings.

Do you have any guidance on this topic?

[wltrup]

Hello. 👋

I came over to post a similar message. I, too, have a fairly large number of such warnings. In addition to those you already mentioned, I also have this one

Main actor-isolated class 'AppFeatureTests' has different actor isolation from nonisolated superclass 'XCTestCase'; this is an error in Swift 6

which appears in test files when you mark the XCTestCase subclass as @MainActor, as recommended by a tip in one of the guides:

@MainActor
final class AppFeatureTests: XCTestCase {

   func test_something() async { ... }

}

A work-around to remove this warning, however, is not to mark the subclass as @MainActor but to mark each individual test function as such. That removes the warning.

final class AppFeatureTests: XCTestCase {

   @MainActor
   func test_something() async { ... }

}

[Rion-Kaneshiro]

That one I noticed, too. The fix is rather simple, although a bit unfortunate to have to mark every single function with @MainActor.

I'm more concerned with warnings I can't fix easily. Maybe there need to be some changes to the libraries themselves to fix some of them.

[jshier]

No, most of them are language limitations that are still being filled in by Apple. This includes things like the KeyPath warnings which should be fixed in Swift 6 (https://github.com/apple/swift-evolution/blob/main/proposals/0418-inferring-sendable-for-methods.md).

[stephencelis]

I noticed that having set that, warnings like

Cannot form key path that captures non-sendable type 'KeyPath<AppFeature.Action.AllCasePaths, AnyCasePath<AppFeature.Action, Feature.Action>>'

start showing up a lot with the newest version of the Composable Architecture.

I checked all my model types and added Sendable to them and further added .sendable to @Reducer(state:action:) where ever it was possible which reduced the number of warnings in some places, but was ultimately unable to eliminate all of them.

As @jshier notes, this is a bug in Swift that's fixed on main and will hopefully be incorporated into the next Swift release, if not the release after.

Two places stuck out the most, namely the static properties of dependencies required by DependencyKey, which result in

Static property 'testValue' is not concurrency-safe because it is non-isolated global shared mutable state; this is an error in Swift 6

This can happen for a non-sendable global when you define it as a static let. One fix would be to make the type Sendable, and if that isn't possible, use a computed static var instead.

and the usage of said dependency within the reducer itself which results in

await send(.taskResponse(Result { try await self.client.fetch() }))
// Capture of 'self' with non-sendable type 'Feature' in a `@Sendable` closure
// Consider making struct 'Feature' conform to the 'Sendable' protocol

Of cause you could actually attach Sendable to the Reducer itself, but I'm not sure what's the "blessed" way might be to deal with all the warnings.

I believe this is what Swift wants you to do. Generally it should infer it automatically within the module, though, so it might be worth asking on the Swift forums or opening up an issue on the Swift project.