<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=""><br class=""><div><blockquote type="cite" class=""><div class="">Le 20 mars 2017 à 15:52, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><blockquote type="cite" 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;" class=""><br class="Apple-interchange-newline">On Mar 20, 2017, at 9:23 AM, Christopher Kornher via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><br class=""><br class=""><blockquote type="cite" class="">On Mar 20, 2017, at 5:12 AM, David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><br class=""><br class=""><blockquote type="cite" class="">On 20 Mar 2017, at 10:39, Jonathan Hull via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">+1. This is my favorite solution so far.<span class="Apple-converted-space"> </span><br class=""><br class="">With ‘Person.keypath.name' it is obvious that we are creating a key path. There is no ambiguity for the reader. With autocomplete it will be very little extra typing anyway…<br class=""></blockquote><br class="">But that adds a lot of verbosity. They disregarded #keyPath because it was too verbose.<br class=""></blockquote><br class="">The syntax in the original proposal is terse and elegant, and will probably be fine when a developer who is experienced with Swift and a particular codebase is first writing the code. Using “key path” or “keypaths” of perhaps a shorter term or even a single leading character (`#` ?) will make this feature more discoverable, tool-friendly and its usages more maintainable.<br class=""></blockquote><br 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-stroke-width: 0px;" class=""><span 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-stroke-width: 0px; float: none; display: inline !important;" class="">It also makes it inconsistent with how unbound methods behave. I have yet to hear a convincing argument about why key paths should be treated different syntactically.</span><br 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-stroke-width: 0px;" class=""></div></blockquote><div><br class=""></div>Because they are two different beasts. Are you arguing that we should allow unbound method as subscript parameter to be consistent with key path ?</div><div><br class=""></div></body></html>