> On Mar 29, 2017, at 4:52 PM, Brent Royal-Gordon <[email protected]>
> wrote:
>
>> On Mar 29, 2017, at 4:13 PM, Michael J LeHew Jr via swift-evolution
>> <[email protected] <mailto:[email protected]>> 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
