Xcode produces a lot of "Cannot form key path that captures non-sendable type..." warnings when using sheet(unwrapping:)
#138
-
Hey 👋, I love this package and what it can do in combination with I've been using it pretty extensively in an app I'm building and it is working flawlessly. The only thing that is strange is a growing set of warnings that Xcode produces:
I have dozens of those accumulated in my project and I'm not sure how to get rid of them, assuming that's even possible (if I remember correctly, It seems that this kind of warning appears for each @CasePathable
enum Presentation: Sendable {
case test
}
// ...
@State var presentation: Presentation?
// ...
.sheet(unwrapping: $presentation.test) { _ in
Text("Sheet")
} Funnily enough, the warning is only produced when you're not in the file (that's probably some strange Xcode bug). You have to go to a different file and compile for the waning to appear. I have created a minimal example (see below) that produces this error (at least for me). I use Xcode 15.2 with the Concurrency Checker set to "Complete". One "fix" I have found is this: extension KeyPath: @unchecked Sendable {} But that feels wrong 😅 Have you encountered this warning before? If so, is there a nicer workaround than an Demo ProjectJust go to Full Code
import SwiftUI
@main
struct CasePathsWarningDemoApp: App {
var body: some Scene {
WindowGroup {
ContentView()
}
}
}
import CasePaths
import SwiftUI
import SwiftUINavigation
@CasePathable
enum Presentation: Sendable { // I also tried removing Sendable here
case test
}
struct ContentView: View {
@State var destination: Presentation?
var body: some View {
Color.clear
.sheet(unwrapping: $destination.test) { _ in
Text("Sheet")
}
}
} |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 4 replies
-
Hi @SwiftDevDennis, this is a limitation of Swift currently, and a recently accepted proposal will fix the issue. For now you can ignore those warnings.
|
Beta Was this translation helpful? Give feedback.
Hi @SwiftDevDennis, this is a limitation of Swift currently, and a recently accepted proposal will fix the issue. For now you can ignore those warnings.
Since this is not an issue with the library I am going to convert it to a discussion. Feel free to follow up with any questions over there.Oops sorry, this is already a discussion! I thought it was an issue.