[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