> On Mar 29, 2017, at 7:12 PM, James Berry via swift-evolution > <[email protected]> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
