Key path sendability warning should be suppressed

[stephencelis]

Description

The sendability story for key paths is not complete right now, and so users can encounter sendability warnings for them when turning up concurrency warnings in their project. Ideally the warnings a user encounters should highlight problems that can be addressed in their code bases, and not unsolved problems in the language. And yet, key paths emit these warnings nonetheless, and these warnings will persist and cannot be suppressed short of turning down concurrency warnings in the entire project.

Steps to reproduce

We can see the problem by turning up concurrency warnings and compiling the following code:

import SwiftUI

@dynamicMemberLookup struct Box<Value> {
    var value: Value
    subscript<T>(dynamicMember keyPath: WritableKeyPath<Value, T>) -> T {
        get { value[keyPath: keyPath] }
        set { value[keyPath: keyPath] = newValue }
    }
}

struct Dog {
    var id: Int?
    var name: String = ""
}

struct ContentView: View {
    @State private var state = Box(value: Dog())

    var body: some View {
        TextField("", text: $state.name)  // ⚠️
    }
}

Warning
Cannot form key path that captures non-sendable type 'WritableKeyPath<Dog, String>'

(Thanks @sidepelican for this example.)

Expected behavior

I expect no warning, or for there to be a way to avoid the warning while still having concurrency warnings turned up.

Environment

• Swift compiler version info

  swift-driver version: 1.87.1 Apple Swift version 5.9 (swiftlang-5.9.0.128.108 clang-1500.0.40.1)
  Target: arm64-apple-macosx14.0
  

• Xcode version info

  Xcode 15.0
  Build version 15A240d
  

• Deployment target: N/A

[stephencelis]

@xedin I believe you said that this issue should be resolved in Swift 6 here, but I'm sadly still seeing the problem in the Xcode 16 beta.

[stephencelis]

Or scratch that. Updating to Swift 6 language mode fixes. I guess building for <6 still preserves the old warnings?

[xedin]

Yeah, InferSendableFromCaptures feature is enabled starting from swift language mode 6, you can enable it manually via -Xfrontend -enable-upcoming-feature -Xfrontend InferSendableFromCaptures as well.

[stephencelis]

@xedin Thanks for confirming! I'll close this now unless you think there's anything outstanding.

[xedin]

Nothing outstanding, thanks!

[stephencelis]

@xedin Just came across this key path sendability error in Swift 6:

@MainActor
class Foo: NSObject {
  var bar = 0
  var observation: NSKeyValueObservation?

  func f<Value>(_ keyPath: ReferenceWritableKeyPath<Foo, Value>) {
    observation = observe(keyPath) { foo, _ in
      print(foo[keyPath: keyPath])  // 🛑
    }
  }

  func g() {
    f(\.bar)
  }
}

🛑 Capture of 'keyPath' with non-sendable type 'ReferenceWritableKeyPath<Foo, Value>' in a @Sendable closure

Is this an incorrect diagnosis?

I can add & Sendable to the f function, but that breaks the g:

@MainActor
class Foo: NSObject {
  var bar = 0
  var observation: NSKeyValueObservation?

  func f<Value>(_ keyPath: ReferenceWritableKeyPath<Foo, Value> & Sendable) {
    observation = observe(keyPath) { foo, _ in
      print(foo[keyPath: keyPath])  // ✅
    }
  }

  func g() {
    f(\.bar)  // 🛑
  }
}

🛑 Type 'ReferenceWritableKeyPath<Foo, Int>' does not conform to the 'Sendable' protocol

In this case it seems like it should infer the \.bar literal to be sendable, no?

Is there another way to write the above?

[xedin]

This is correct because isolation makes key paths non-Sendable.

[stephencelis]

@xedin Ah, so this specifically because of the @MainActor isolation? I suppose if I traffic a @MainActor key path over sendable boundaries but only use it in a @MainActor scope it's my responsibility to use nonisolated(unsafe) wisely?

[xedin]

Indeed, key path is non-Sendable because all of the isolation information is erased effectively which means that it’s not safe to use it anywhere but where it was created.

[paul1893]

Very interesting subject 🤤! Reading your thread leads me to wonder if using nonisolated(unsafe) is always the right path to follow in such scenarios to help the compiler ?

---

For example let's imagine a case where you can't change a function signature for some reason (because this comes from an Apple native library for example).

Let's take a concrete/common example with Binding that you can't change for example:

// From Apple
@frozen @propertyWrapper @dynamicMemberLookup public struct Binding<Value> {
	...
    @preconcurrency public init(get: @escaping @isolated(any) @Sendable () -> Value, set: @escaping @isolated(any) @Sendable (Value) -> Void)
    ...

// Our sample code
// Usage: `TextEditor(text: foo.bind(\.property))` where foo is an ObservableViewModel

@dynamicMemberLookup @MainActor
final class ObservableViewModel<Model: Sendable>: ObservableObject, Sendable {
    @Published var value: Model

    init(model: Model) {
        self.value = model
    }

    subscript<T>(dynamicMember keyPath: KeyPath<Model, T>) -> T {
        value[keyPath: keyPath]
    }

    subscript<T>(dynamicMember keyPath: WritableKeyPath<Model, T>) -> T {
        get {
            value[keyPath: keyPath]
        }
        set {
            value[keyPath: keyPath] = newValue
        }
    }
}

extension ObservableViewModel {
    func bind<Value: Sendable>(
       _ keyPath: ReferenceWritableKeyPath<ObservableViewModel, Value>
    ) -> Binding<Value> {
        Binding(self, to: keyPath)
    }
}

private extension Binding where Value: Sendable {
    init<T: AnyObject & Sendable>(
    	_ object: T,
    	to keyPath: ReferenceWritableKeyPath<T, Value>
    ) {
        self.init {
            object[keyPath: keyPath] /* 🔴 Capture of 'keyPath' with non-sendable type 'ReferenceWritableKeyPath<T, Value>' in a `@Sendable` closure; this is an error in the Swift 6 language mode */
        } set: { newValue in
            object[keyPath: keyPath] = newValue /* 🔴 Capture of 'keyPath' with non-sendable type 'ReferenceWritableKeyPath<T, Value>' in a `@Sendable` closure; this is an error in the Swift 6 language mode */
        }
    }
}

I first naively thinking to write:

extension ReferenceWritableKeyPath: @unchecked @retroactive Sendable where Root: Sendable, Value: Sendable {}

to make the warnings disappear but feeling it wrong to me so I decided to do some research and found your conversation.

It feels wrong to me because we're explicitly defining ReferenceWritableKeyPath to be Sendable in all possible scenarios which is a strong assertion even in potential other context where it is not used with an ObservableViewModel (which is annotated @MainActor) somewhere else in the codebase. But may be I'm wrong ?

Should we prefer ?:

private extension Binding where Value: Sendable {
     init<T: AnyObject & Sendable>(
     	_ object: T,
     	to keyPath: ReferenceWritableKeyPath<T, Value>
     ) {
         /// KeyPath is non-Sendable because all of the isolation information is erased from the compiler use nonisolated(unsafe) wisely
         /// https://github.com/swiftlang/swift/issues/68943#issuecomment-2162221451
         nonisolated(unsafe) let get = {
             object[keyPath: keyPath]
         }
         nonisolated(unsafe) let set = { newValue in
             object[keyPath: keyPath] = newValue
         }
         self.init {
            get()
         } set: { newValue in
             set(newValue)
         }
     }
 }

PS:
I noticed that simplifying the code to just what's below 👇, seems to satisfy the compiler but can't figure it out why yet. But I feel like it would help me understand and answer my questions.

extension ObservableViewModel {
    func bind<Value: Sendable>(
        _ keyPath: ReferenceWritableKeyPath<ObservableViewModel, Value>
    ) -> Binding<Value> {
        return Binding {
            self[keyPath: keyPath] // Why compiler is not complaining here, ReferenceWritableKeyPath is still not Sendable 🤷‍♂️. I suppose the compiler is smart enough to know that ObservableViewModel is annotated `@MainActor` so access is OK here.
        } set: { newValue in
            self[keyPath: keyPath] = newValue // Why compiler is not complaining here, ReferenceWritableKeyPath is still not Sendable 🤷‍♂️. I suppose the compiler is smart enough to know that ObservableViewModel is annotated `@MainActor` so access is OK here.
        }
    }
}

[dannys42]

I still see this issue on Xcode Version 16.1 (16B40) RC. Example:

@Query(sort: [ SortDescriptor(\Project.viewOrder, order: .forward) ]) private var projects: [Project]

Swift Language Version = 6
Strict Concurrency Checking = Complete or Targeted will show this warning.

[andrebraga]

It feels wrong to me because we're explicitly defining ReferenceWritableKeyPath to be Sendable in all possible scenarios which is a strong assertion even in potential other context where it is not used with an ObservableViewModel (which is annotated @MainActor) somewhere else in the codebase. But may be I'm wrong ?

Too strong indeed...

PS: I noticed that simplifying the code to just what's below 👇, seems to satisfy the compiler but can't figure it out why yet. But I feel like it would help me understand and answer my questions.

Because your working code creates closures in the context of ObservableViewModel (@MainActor) isolation.

Regarding your code example,

extension ObservableViewModel {
    func bind<Value: Sendable>(
       _ keyPath: any Sendable & ReferenceWritableKeyPath<ObservableViewModel, Value>
    ) -> Binding<Value> {
        Binding(self, to: keyPath)
    }
}

private extension Binding where Value: Sendable {
    init<T: AnyObject & Sendable>(
    	_ object: T,
    	to keyPath: any Sendable & ReferenceWritableKeyPath<T, Value>
    ) {
        self.init {
            object[keyPath: keyPath]
        } set: { newValue in
            object[keyPath: keyPath] = newValue
        }
    }
}

will satisfy the sendability requirements and make it all compile.