<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="">You may also want to consider how this works with collection operators such as @sum and @unionOfObjects: <a href="https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/KeyValueCoding/Articles/CollectionOperators.html" class="">https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/KeyValueCoding/Articles/CollectionOperators.html</a><div class=""><br class=""></div><div class="">Jack</div><div class=""><div><blockquote type="cite" class=""><div class="">On Mar 9, 2016, at 11:52 PM, David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I updated my proposal to mention value-expressions, but I since saw that my self. proposition was a bit stupid.<div class=""><br class=""></div><div class=""><a href="https://github.com/hartbit/swift-evolution/blob/objc-keypaths/proposals/XXXX-objc-keypaths.md" class="">https://github.com/hartbit/swift-evolution/blob/objc-keypaths/proposals/XXXX-objc-keypaths.md</a><br class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 08 Mar 2016, at 08:21, David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div class="">If we went this route, I would suggest changing a few things here.<br class=""><br class="">1. #keypath should be equivalent to a string literal, not necessarily a `Swift.String`. That would allow you to store it into StaticString or other StringLiteralConvertible types. (If you had an enum corresponding to the available properties, you might even be able to conform it to StringLiteralConvertible and use this feature with it.)<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">Sounds good to me!</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">2. We *may* want to consider calling it something that's slightly less tied to Cocoa terminology, like #name or #property. (#key might be a good compromise between the two.) I don't think this is *necessary*, but we might want to consider it.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">I don’t think this is a good idea because:</div><div class="">- #name, #property, #key all hide the ability to chain properties for a “key path”.</div><div class="">- #keypath already has prior meaning to so many developers.</div><div class=""><br class=""></div><div class="">Even if #keypath exists without the Objective-C runtime, I think that the name is strong enough meaning to keep it’s weight. What do you think?</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">3. It would be nice if you could easily get a name for a property on `self`, and it might even make sense to allow you to easily get a name for a property on any variable. Maybe the syntax (assuming that this code is inside a `Person`) would be more like:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>print(#key(Person.bestFriend.firstName))<span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>// => bestFriend.firstName<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>print(#key(chris.bestFriend.firstName))<span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>// => bestFriend.firstName<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>print(#key(bestFriend.firstName)<span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>// => bestFriend.firstName<br class=""><br class="">Note that that last form has a slightly tricky rule: because the only visible `bestFriend` is a property, `#name(bestFriend.firstName)` is actually `#name(self.bestFriend.firstName)`, so the `self` is what's stripped off. A small redesign would disambiguate:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>print(Person.#key(bestFriend.firstName))<span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>// => bestFriend.firstName<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>print(chris.#key(bestFriend.firstName))<span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>// => bestFriend.firstName<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>print(#key(bestFriend.firstName)<span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>// => bestFriend.firstName<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">I understand the reasoning behind this modification, I would also like to be able to reference properties from variables (instead of by type), but I find both propositions confusing. I agree that with the first version, it is very tricky on first sight to understand what is being “keypathed”. But I find the second variation syntactically very surprising for Swift and I think many people in the mailing list would have problems with it.</div><div class=""><br class=""></div><div class="">Here’s a potential solution: force explicit self. inside #keypath expressions:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class="">print(#keypath(Person.bestFriend.firstName))<span class="Apple-tab-span" style="white-space:pre"> </span>// => bestFriend.firstName<br class="">print(#keypath(chris.bestFriend.firstName))<span class="Apple-tab-span" style="white-space:pre"> </span>// => bestFriend.firstName<br class="">print(#keypath(self.bestFriend.firstName)<span class="Apple-tab-span" style="white-space:pre"> </span>// => bestFriend.firstName</font></div><div class=""><br class=""></div><div class="">Better?</div><div class=""><br class=""></div><div class="">David.</div></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>