<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></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="">On 30 Mar 2017, at 14:12, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div style="position: relative;" 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-stroke-width: 0px;" class=""><div class=""><div class="">On 30 Mar 2017, at 01:13, Michael J LeHew Jr via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class="">I'm not a fan of the new syntax for creating key paths. To me, it feels like they've been demoted to second class citizens of the language simply because of how more verbose it now is. The new syntax is also too confusingly similar to string key paths: I had to look closely at the code to see the difference. Is there no symbol we can use to make it ambiguous? Ideas:</div><div class=""><br class=""></div><div class="">Person::friend.lastName</div><div class="">Person/friend.lastName</div><div class="">Person#friend.lastName</div><div class=""><br class=""></div><div class="">I'm a fan of the first one as it has similarities to names pacing in C++.</div></div></blockquote><div 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=""><br class=""></div><div 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="">I'm a big fan of the last one. I argued for it earlier as the best syntax to use if we deviated from the initial proposal. I like it for several reasons:</div><div 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=""><br class=""></div><div 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="">- # suggests compiler magic is at work which is the case here.</div><div 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="">- #friend.lastName works nicely as a shorthand in contexts expecting a key path with a fixed Root</div><div 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="">- # would work for unbound methods solving the no arguments case. IMO all unbound members should be accessed using the same syntax.</div><div 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="">- # enables the possibility of mixing property access and method calls in the path as a future enhancement</div><div 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=""><br class=""></div><div 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="">The arguments supporting this approach are pretty strong to me. I agree with David that the #keyPath syntax makes it feel more like a second class citizen, not just because of the verbosity but also because it is directly borrowed from an Objective-C interop feature. This is a very powerful feature that deserves to be a first class syntactic citizen every bit as much as unbound methods do.</div></div></div></blockquote><br class=""></div><div>Personally I'd prefer the use of a leading dollar sign for this, for example:</div><div><br class=""></div><div><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>$Person.friend.lastName</font></div><div><br class=""></div><div>I find a symbol midway through the path a bit strange, plus the leading dollar sign already implies compiler magic in the same way as anonymous parameters in closures. In fact you can think of anonymous parameters as a kind of special key-path of sorts, and there should be no ambiguity.</div><div><br class=""></div><div>I prefer this to the hash symbol for compiler directives, since those feel more like things that are done once during compilation, rather than something you actually use at run-time, so I like the distinction of another symbol for that.</div></body></html>