> On Nov 12, 2017, at 7:27 PM, Nevin Brackett-Rozinsky > <nevin.brackettrozin...@gmail.com> wrote: > > On Sun, Nov 12, 2017 at 10:16 PM, Slava Pestov <spes...@apple.com > <mailto:spes...@apple.com>> wrote: >> Pardon my lack of imagination, but could you provide an example of a call >> site that would become ambiguous? > > protocol P {} > protocol Q {} > struct S : P, Q {} > > struct Outer { > static func foo(_: P) {} > > struct Inner { > static func foo(_: Q) {} > > static func bar() { > foo(S()) > } > } > } > > Resolves to Inner.foo just like it does today. > > We would still start from the innermost scope and work our way outward until > we find a match. The only difference is we no longer stop partway up the > chain *without* finding a match.
That’s not implementable as described. Right now we find all possible overloads for a call site up front, then evaluate every combination of overloads at all call sites in an expression. The valid solutions are then ranked and the “best” one chosen, or an ambiguity is diagnosed. This means you can’t “stop” evaluating overloads, you need some way to disambiguate them and you have to consider all of them. Slava > > If we do find a match then yes, of course we stop there and use it. > > Nevin
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
