> On Mar 29, 2017, at 4:52 PM, Brent Royal-Gordon <br...@architechies.com> > wrote: > >> On Mar 29, 2017, at 4:13 PM, Michael J LeHew Jr via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> Thanks for the feedback everyone! We have pushed a changed a bit ago to the >> proposal reflecting these desires. >> >> https://github.com/apple/swift-evolution/pull/644/files >> <https://github.com/apple/swift-evolution/pull/644/files> > Quoting from the proposal: > >> luke[keyPath: #keyPath(.friends[0].name)] > > Really? I can understand marking one or the other, but both, even when > there's no ambiguity?
I had the same reaction initially -- but then after talking with Joe, he reminded me that this is the kind of code that only comes up in a 'this is how it works' context. Typically the key path will be a value and the syntax looks like: luke[keyPath: somePath] That example is a touch contrived to show that we'll be able to do the type inference where possible, > > 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: > > struct Person { > var friends: [Person] > var name: String > } > > Implies this: > > extension PartialKeyPath where Root == Person { > static let friends: WritableKeyPath<Person, [Person]> > static let name: WritableKeyPath<Person, String> > } > > And this: > > #keyPath(Person, .friends[0].name) > > Desugars to this: > > PartialKeyPath<Person>.friends[0].name > > So in a context where you already know you're passing a key path, you can > simply write this: > > luke[keyPath: .friends[0].name] > > Which applies normal "unresolved member" logic to look it up in > `PartialKeyPath`. > > 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. > > Would that work for people? I'll let Joe speak to this aspect since this touches a lot more on implementation. > > -- > Brent Royal-Gordon > Architechies >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution