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

Nevin Brackett-Rozinsky nevin.brackettrozinsky at gmail.com
Sun Nov 12 21:14:02 CST 2017


On Sun, Nov 12, 2017 at 8:44 PM, Slava Pestov <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.



> If this can be implemented in a clever way without impacting compile time,
> I’ll be all for this change.
>
> 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
>
> var type = …
>
> type(of: foo)
>
> 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.
>
> 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.
>

Pardon my lack of imagination, but could you provide an example of a call
site that would become ambiguous?

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/21218763/attachment.html>


More information about the swift-evolution mailing list