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 <[email protected]> wrote: > >> >> On Mar 17, 2017, at 2:53 PM, Michael LeHew <[email protected] >> <mailto:[email protected]>> wrote: >> >> >>> On Mar 17, 2017, at 2:21 PM, BJ Homer <[email protected] >>> <mailto:[email protected]>> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
