On Sun, Nov 12, 2017 at 8:44 PM, Slava Pestov <[email protected]> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
