[swift-evolution] Smart KeyPaths

[Charles Srstka]

> On Mar 29, 2017, at 7:12 PM, James Berry via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> Referencing Key Paths
>> 
>> Forming a KeyPath borrows from the same syntax added in Swift 3 to confirm the existence of a given key path, only now producing concrete values instead of Strings. Optionals are handled via optional-chaining. Multiply dotted expressions are allowed as well, and work just as if they were composed via the appending methods on KeyPath.
>> 
>> There is no change or interaction with the #keyPath() syntax introduced in Swift 3. #keyPath(Person.bestFriend.name) will still produce a String, whereas #keyPath(Person, .bestFriend.name) will produce a KeyPath<Person, String>.
> 
> This distinction seems arbitrary and confusing. The user is supposed tor remember that the #keyPath(Person.bestFriend.name) form produces a string while the #keyPath(Person, .bestFriend.name) form produces a key path object? I don’t think we’re advancing here. What would be the effect if just the former was valid, and (always/now) produced a keypath object that was convertible to string? How bad would the breakage be?

This definitely sounds like the better option to me. Just change the Objective-C bridge so that a key path bridges to a string, and make the various Cocoa APIs such as value(forKeyPath:) and friends take key paths.

Charles

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170329/b4408365/attachment.html>