[swift-evolution] Smart KeyPaths

[BJ Homer]

So then this would be disambiguated like this?

let staticValue = Foo.bar // Defaults to accessing the static value, when there is ambiguity

let value:   Bar                       = Foo.bar
let keyPath: WritableKeyPath<Foo, Bar> = Foo.bar

It’s a little unfortunately to have to spell out WritableKeyPath<Foo, Bar> there, but as long as there’s some way to do it, I don’t think it’s a problem. This is likely a rare edge case.

-BJ Homer

> On Mar 17, 2017, at 3:56 PM, Joe Groff <jgroff at apple.com> wrote:
> 
>> 
>> On Mar 17, 2017, at 2:53 PM, Michael LeHew <lehewjr at apple.com <mailto:lehewjr at apple.com>> wrote:
>> 
>> 
>>> On Mar 17, 2017, at 2:21 PM, BJ Homer <bjhomer at gmail.com <mailto:bjhomer at gmail.com>> wrote:
>>> 
>>> This looks great!
>>> 
>>> What happens in the case when there is a static property by the same name as an instance property? e.g.
>>> 
>>> struct Foo {
>>>     static var bar: Bar
>>>     var bar: Bar
>>> }
>>> 
>>> Foo.bar // What is this?
>>> 
>>> Is it still possible to reference both the static property and a KeyPath to the instance method? 
>> 
>> This is essentially the same question that I arrived at in my reply to Vladimir.  I think Joe might be best able to answer here.
> 
> We already encounter this situation with static vs instance methods, since `Foo.bar` can refer to either a static method `bar` or an unbound instance method `bar`. We use type context to disambiguate, favoring the static member if context doesn't help:
> 
> struct X {
>   static func foo() {}
>   func foo() {}
> }
> 
> let foo1 = X.foo // Defaults to static member
> let foo2: () -> () = X.foo // Picks static member by type context
> let foo3: (X) -> () -> () = X.foo // Picks instance member by type context
> 
> -Joe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170317/d3ef7bb1/attachment.html>