<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br>Sent from my iPhone</div><div><br>On Mar 29, 2017, at 4:52 PM, Brent Royal-Gordon <<a href="mailto:brent@architechies.com">brent@architechies.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><div><blockquote type="cite" class=""><div class="">On Mar 29, 2017, at 4:13 PM, Michael J LeHew Jr 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; line-break: after-white-space;" class="">Thanks for the feedback everyone! We have pushed a changed a bit ago to the proposal reflecting these desires.<br class=""><div class=""><br class=""></div><div class=""><a href="https://github.com/apple/swift-evolution/pull/644/files" class="">https://github.com/apple/swift-evolution/pull/644/files</a></div></div></div></blockquote><br class=""></div><div>Quoting from the proposal:</div><div><br class=""></div><div><blockquote type="cite" class="">luke[keyPath: #keyPath(.friends[0].name)]</blockquote><br class=""></div><div>Really? I can understand marking one or the other, but both, even when there's no ambiguity?</div><div><br class=""></div><div>Let's pretend we're the type checker here. The `luke[keyPath: _]` part will create a context where we know we have an `AnyKeyPath`, `PartialKeyPath<Person>`, `KeyPath<Person, U>`, or `WritableKeyPath<Person, U>`. So if the core team's concern is about namespace clashes between `Person`'s static members and key paths, why not hang the key paths off the various `KeyPath` types? That is, this:</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>struct Person {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>var friends: [Person]</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>var name: String</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div><br class=""></div><div>Implies this:</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>extension PartialKeyPath where Root == Person {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>static let friends: WritableKeyPath<Person, [Person]></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>static let name: WritableKeyPath<Person, String></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div><br class=""></div><div>And this:</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>#keyPath(Person, .friends[0].name)</div><div><br class=""></div><div>Desugars to this:</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>PartialKeyPath<Person>.friends[0].name</div><div><br class=""></div><div>So in a context where you already know you're passing a key path, you can simply write this:</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>luke[keyPath: .friends[0].name]</div><div><br class=""></div><div>Which applies normal "unresolved member" logic to look it up in `PartialKeyPath`.</div></div></blockquote><div><br></div>Yes, this can be done via "unresolved member lookup". It's a little different---unresolved member lookup usually can't handle chaining---but the type checker could support it. <div><br><blockquote type="cite"><div><br class=""></div><div>The result would be that you would have to explicitly, syntactically mark key paths except when the context already implied you were looking for one. In an unconstrained generic context, you would not get a key path without using `#keyPath` or explicitly naming a key path type. You would only need to worry about clashes if a call was overloaded to accept *both* `T` and `PartialKeyPath<T>`; if we found that possibility troubling, we could penalize unresolved member lookups that resolve to key paths, so type inference would favor static members over key paths even in those cases.</div><div class=""><br class=""></div><div class="">Would that work for people? </div></blockquote><div><br></div>It's technically feasible. It makes ".foo" more contextually sensitive, which is probably fine. </div><div><br></div><div> - Doug</div><div><br><blockquote type="cite"><div class=""><span class="Apple-style-span" style="border-collapse: separate; font-variant-ligatures: normal; font-variant-east-asian: normal; font-variant-position: normal; line-height: normal; border-spacing: 0px;"><div class=""><div style="font-size: 12px; " class=""><br></div></div></span></div></blockquote></div></body></html>