Why KeyPath?

[rayx (Huan Xiong)]

I stumbled upon an answer on reddit a while back and I like it.

It's a form of indirection. You may want to refer to the variable itself, not the value inside it. For example an API like "notify me when view.frame changes". In that case you'd need to pass a KeyPath to your notification API.

I doubt if it's right to understand keypath as a closure. Just because it can be used as a shortcut for closure doesn't mean it's. Below is from SE-0294:

Occurrences of \Root.value are implicitly converted to key path applications of { $0[keyPath: \Root.value] } wherever (Root) -> Value functions are expected. For example:

users.map(.email)

Is equivalent to:

users.map { $0[keyPath: \User.email] }

In the translated code, the function behavior comes from subscript, not keypath. Keypath serves as an identifier.

@Hacksaw

I like the idea of being to change structures without screwing up the interface. But isn't that served by simply keeping your basic data members private and providing getters, setters, and conforming to protocols like Equatable and Comparable?

I suppose it's just an example to demonstrate keypath usage and doesn't necessarily mean it's the only or best approach for that scenario. I have another (trivial but useful) example here. In general features like keypath helps one to write more abstract code.