[swift-evolution] Smart KeyPaths
cocoadev at charlessoft.com
Wed Mar 29 19:26:41 CDT 2017
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution