[swift-evolution] When exactly 1 function matches a call site, should it be called or cause a compiler error?

[Slava Pestov]

> On Nov 12, 2017, at 7:14 PM, Nevin Brackett-Rozinsky <nevin.brackettrozinsky at gmail.com> wrote:
> 
> On Sun, Nov 12, 2017 at 8:44 PM, Slava Pestov <spestov at apple.com <mailto:spestov at apple.com>> wrote:
> 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.
> 
> 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.
> 
> 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.

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.

> 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())
    }
  }
}

Slava

> 
> 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).
> 
> Nevin

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