<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><blockquote type="cite" class="">On Mar 29, 2017, at 7:12 PM, James Berry via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></blockquote><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><span class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;">Referencing Key Paths<br class=""><br class="">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.<br class=""><br class="">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>.<br class=""></blockquote></span><span class=""><br class=""></span><span class=""></span><span class="">This distinction seems arbitrary and confusing. The user is supposed tor remember that the </span><span class="">#keyPath(Person.bestFriend.name) form produces a string while the </span><span class="">#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?</span></div></div></blockquote></div><br class=""><div class="">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.</div><div class=""><br class=""></div><div class="">Charles</div><div class=""><br class=""></div></body></html>