<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 12, 2017, at 7:14 PM, Nevin Brackett-Rozinsky <<a href="mailto:nevin.brackettrozinsky@gmail.com" class="">nevin.brackettrozinsky@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Sun, Nov 12, 2017 at 8:44 PM, Slava Pestov <span dir="ltr" class=""><<a href="mailto:spestov@apple.com" target="_blank" class="">spestov@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class="">Yeah, this is an unfortunate wart. Right now unqualified lookup starts at the innermost scope and stops when it finds a candidate which matches the name being looked up. Overload sets are only formed if there are multiple candidates inside the same scope, not in different scopes.<div class=""><br class=""></div><div class="">It would be nice to fix this but note that it might have a compile-time performance impact, because now we will be looking up names in more scopes. In particular, this means almost every name lookup will have to look at all imported modules.</div></div></blockquote><div class=""><br class=""></div><div class="">Well, the fact that it currently gives a different error message if you delete the global function, tells me that *something* in the compiler is already looking at both the member function and the global function.</div></div></div></div></div></blockquote><div><br class=""></div>Yeah, if we fail to solve the constraint system with the innermost candidate as the choice of overload, the diagnostics pass performs an additional name lookup to try to figure out what the user meant. However this doesn’t mean we’re performing the global lookup in the normal path.</div><div><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">Pardon my lack of imagination, but could you provide an example of a call site that would become ambiguous?</div></div></div></div></blockquote><div><br class=""></div><div>protocol P {}</div><div>protocol Q {}</div>struct S : P, Q {}</div><div><br class=""></div><div>struct Outer {</div><div> static func foo(_: P) {}</div><div><br class=""></div><div> struct Inner {</div><div> static func foo(_: Q) {}</div><div><br class=""></div><div> static func bar() {</div><div> foo(S())</div><div> }</div><div> }</div><div>}</div><div><br class=""></div><div>Slava</div><div><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">The change I am proposing has the effect of taking something that is currently a compiler error (calling a global function when a member function has the same base name but a different signature) and making it not-an-error (since the global function is the only one whose signature matches the call site).</div><div class=""><br class=""></div><div class="">Nevin</div></div></div></div>
</blockquote></div><br class=""></body></html>