Xcode “cannot convert value of type ‘KeyPath & Sendable>’” in Swift 6.4

With Apple Swift 6.4 in Xcode 27.0, a project that still uses Swift 5 language mode can fail to compile after enabling the upcoming feature InferSendableFromCaptures. The failure affects generic APIs that accept a nested key path, and the compiler reports cannot convert value of type ... even though the same source type-checks without the feature. This article explains the confirmed reproduction from Swift issue #92832, the underlying inference mismatch, the safest workaround, alternatives, and a verification procedure.

The diagnostic

The issue can be reproduced when the value of an outer KeyPath is itself a WritableKeyPath:

struct State {
    var value = 0
}

struct Paths {
    let value = \State.value
}

func observe<Value>(
    _ path: KeyPath<Paths, WritableKeyPath<State, Value>>
) {}

observe(\.value)

When InferSendableFromCaptures is enabled, the compiler emits diagnostics similar to these:

error: cannot convert value of type
'KeyPath<Paths, any WritableKeyPath<State, Int> & Sendable>'
to expected argument type
'KeyPath<Paths, WritableKeyPath<State, Value>>'

note: arguments to generic parameter 'Value'
('any WritableKeyPath<State, Int> & Sendable'
and 'WritableKeyPath<State, Value>')
are expected to be equal

error: generic parameter 'Value' could not be inferred

Cause

This is not simply a typo in State.value or in the generic function. With InferSendableFromCaptures enabled, the inner WritableKeyPath<State, Int> is inferred as the existential type any WritableKeyPath<State, Int> & Sendable. That existential cannot be equated with the concrete WritableKeyPath<State, Value> required by the function, so inference of Value fails as a consequence.

Swift Evolution proposal SE-0418 introduced Sendable inference for method references and key-path literals. The feature is intended to improve concurrency safety, but Swift issue #92832 documents an unresolved inference problem for nested key paths when the upcoming feature is enabled in Swift 5 language mode.

Affected versions and conditions

• Xcode 27.0, build 27A266a
• Apple Swift 6.4, swiftlang-6.4.0.34.1
• Swift 5 language mode, selected with -swift-version 5
• -enable-upcoming-feature InferSendableFromCaptures is enabled
• A nested type such as KeyPath<Outer, WritableKeyPath<Root, Value>> is passed to a generic API

Recommended workaround

1. Disable this upcoming feature in Swift 5 mode

If the project does not require the feature immediately, return to the configuration that the official reproduction confirms will type-check:

# This configuration succeeds
xcrun swiftc -typecheck -swift-version 5 repro.swift

# This configuration reproduces the issue
xcrun swiftc -typecheck -swift-version 5 \
  -enable-upcoming-feature InferSendableFromCaptures \
  repro.swift

In Xcode, inspect the target’s Build Settings and remove only this entry from SWIFT_UPCOMING_FEATURE_FLAGS, from the setting corresponding to “Upcoming Feature: Infer Sendable From Captures,” or from OTHER_SWIFT_FLAGS if it was added manually. In a Swift package, temporarily remove .enableUpcomingFeature("InferSendableFromCaptures") from swiftSettings.

2. Verify the compiler invocation

Deleting DerivedData does not remove a compiler feature flag. Inspect the Swift compiler command in the build log and confirm that -enable-upcoming-feature InferSendableFromCaptures is gone. Then clean the build folder and rebuild.

Alternative approaches

Provide an explicit contextual type

SE-0418 specifies that contextual type information affects whether a key-path literal is inferred as Sendable. Binding the literal to the exact non-existential type first may therefore avoid the problematic inference:

let path: KeyPath<Paths, WritableKeyPath<State, Int>> = \.value
observe(path)

Split the nested key path at the API boundary

Another temporary design option is to avoid asking the compiler to infer the outer and inner key paths in one generic conversion. Resolve the inner key path first, then pass a concrete WritableKeyPath<State, Value> to a separate function. This changes the API shape, so reserve it for projects that cannot disable the feature and test all callers carefully.

How to verify the workaround

1. Save the minimal example above as repro.swift.
2. Run the command without the feature and verify an exit status of zero.
3. Run the command with the feature and confirm the reported type mismatch.
4. Remove the flag from the project and confirm that it no longer appears in the build log.
5. Rebuild the app and test targets, including runtime paths that use the affected key paths.

After an official fix is released, keep the minimal reproducer and run it with the new toolchain. Re-enable the feature in production settings only after both the reproducer and the full test suite pass.

Important cautions

• Do not hide the mismatch with forced casts such as as!; that discards useful type safety.
• Adding @unchecked Sendable to unrelated model types does not address this existential-versus-concrete nested-key-path mismatch.
• The Swift language mode and compiler version are separate settings. The reported combination is the Swift 6.4 compiler running source in Swift 5 mode.
• Disabling the feature also removes its Sendable inference elsewhere in the target. Re-run concurrency-related tests and diagnostics.

Summary

The error occurs because InferSendableFromCaptures infers the inner component of a nested key path as any ... & Sendable. That existential no longer matches the concrete WritableKeyPath<State, Value> required by the generic function, so Value cannot be inferred. Until the Swift project confirms a fixed release, the safest response in affected Swift 5 configurations is to disable this upcoming feature and retain a minimal regression test.

Official references

• Swift issue #92832: InferSendableFromCaptures causes generic nested key path inference to fail in Swift 5 mode
• Swift Evolution SE-0418: Inferring Sendable for methods and key path literals
• Apple Developer Documentation: Sendable