<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Nov 12, 2017 at 8:44 PM, Slava Pestov <span dir="ltr">&lt;<a href="mailto:spestov@apple.com" target="_blank">spestov@apple.com</a>&gt;</span> wrote:<br><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">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><br></div><div>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><br></div><div>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><br></div><div> </div><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"><div>If this can be implemented in a clever way without impacting compile time, I’ll be all for this change.</div><div><br></div><div>However, note that the most common way in which people hit this is with type(of:) vs a local name named type — I think this can be solved without fundamentally changing unqualified lookup, by having unqualified lookup look at the DeclName rather than an Identifier. So if you have</div><div><br></div><div>var type = …</div><div><br></div><div>type(of: foo)</div><div><br></div><div>We would not consider the ‘var type’ at all, since it doesn’t match the DeclName type(of:). This might also address min vs Collection.min if we consider the number of arguments when performing the lookup too.</div><div><br></div><div><div>Either way I think an evolution proposal is a good idea, this has source compatibility impact since it can introduce ambiguity at call sites that were formerly unambiguous. But we should be careful not to impact compile time.</div></div></div></blockquote><div><br></div><div>Pardon my lack of imagination, but could you provide an example of a call site that would become ambiguous?</div><div><br></div><div>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><br></div><div>Nevin</div></div></div></div>