Shouldn't a KeyPath be Sendable?

Hi,

I have a variable, which is a KeyPath, in a "Sendable" struct . Like so:
let children: KeyPath<ParentObj, Set<Child>> = \.notes

This gives me the warning, that the KeyPath is a non-sendable type. Shouldn't a KeyPath always be Sendable?

Thanks for any hints!

Cheers, Michael

4 Likes

A related topic: should key paths be constructible from async properties? how bout properties of actors? Right now the actor side of things is disallowed. But if the key path was sendable and accounted for async then perhaps that could be doable. To me that seems quite useful.

5 Likes

IMHO, it should.

I am having the same issue, where the KeyPath's getter function is passed through to another function as a closure parameter which needs to be Sendable and escaping. The Swift compiler reminds me of the potential problem:

"Converting non-sendable function value to '@Sendable (ParentEnvironment) -> Environment' may introduce data races"

Well, yes - that's true.

I am wondering if there are use cases, which do not require an escaping closure to be sendable.

So, eventually, all closures will need to be Sendable?

I think key paths should be expanded into something like “member paths”. This way, more member declarations could be supported, like methods, enum cases, subscripts without Hashable parameters, etc. This should also allow for more flexibility regarding Sendable.