[swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

Karl Wagner razielim at gmail.com
Sun Apr 9 05:57:14 CDT 2017


> On 7 Apr 2017, at 03:28, Rick Mann via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I tend to dislike the backslash as well, but can't suggest a good alternative.
> 

The quirky thing I like about the backslash is that it almost looks like a URL. It might be nice to concatenate keypaths in that way (replacing the append methods):

let firstFriend = \Person.friends.first!
let name = \Person.name
let firstFriendNameLength = luke[keyPath: firstFriend\name\.characters.count] // 8 (“Han Solo”)

> Does any of this allow for operations within the key path? e.g. Department.employees. at sum.salary?
> 
> Also, in this example:
> 
> let firstFriendsNameKeyPath = \Person.friends[0].name
> let firstFriend = luke[keyPath: firstFriendsNameKeyPath] // "Han Solo”
> 

> Can't we do without the keyPath: argument name? The compiler knows it's a keypath, it would be nicer to write
> 
> let firstFriend = luke[firstFriendsNameKeyPath] // "Han Solo"


That could be ambiguous if you had some kind of collection which was indexed by keypaths. For example, you might have a dictionary of [KeyPath : String] for some kind of mapping.

I agree that the subscript is ugly - it makes key-path access feel second class to direct access (via the dot operator). Perhaps it could be replaced by an instance method (on KeyPath) or get its own operator.

- Karl


More information about the swift-evolution mailing list