What's the meaning of the highlighted sentence below in [over.load]/1?
Asked Answered
C

1

12

What is the meaning of the highlighted sentence below? Does it have anything to do with function templates?

[over.load]/1:

Not all function declarations can be overloaded. Those that cannot be overloaded are specified here. A program is ill-formed if it contains two such non-overloadable declarations in the same scope. [ Note: This restriction applies to explicit declarations in a scope, and between such declarations and declarations made through a using-declaration ([namespace.udecl]). It does not apply to sets of functions fabricated as a result of name lookup (e.g., because of using-directives) or overload resolution (e.g., for operator functions). — end note ]

Celebrant answered 15/7, 2019 at 14:44 Comment(1)
Note: in addition to what you quote, it's worth noting that you also cannot overload on return values.Riobard
N
11

You can do something like this:

namespace N {
  void f(int);
}

namespace M {
  int f(int);
}

using namespace N; // ok
using namespace M; // ok
// even if both have conflicting f's

You aren't directly overloading anything here. The using directives allow name lookup to find both functions and it's at that point that the call is ambiguous.

Here the sets of functions contain two non-overloadable are in there, but since they are found by name lookup as per the quote, they're okay.

Nappie answered 15/7, 2019 at 15:32 Comment(11)
Note that the highlighted sentence in my question mentions using-directives, not using-declarations, which were used in your example. Nevertheless, I gave you the benefit of the doubt, in accepting your answer, given that the sentence says "e.g. because of using-directives" which could also be interpreted as "because of using-declarations". But now it dawned on me that a using-directive only does lookup for type names, not for function names. (to be continued in the next comment)Celebrant
Therefore, either there is another interpretation for the sentence above, in which case your answer is incorrect, or the standard has a defect, i.e., the reference to using-directives above is wrong and it should be replaced by using-declarations, in which case your answer is correct. Could you clarify?Celebrant
@Celebrant "a using-directive only does lookup for type names, not for function names." No that is incorrect. You can imagine a using directive to be a using declaration for every declaration inside the namespace. You can use using namespace N; using namespace M; instead to get the same result.Nappie
Well I didn't express myself correctly when I wrote "a using-directive only does lookup for type names, not for function names.". But still, a using-directive doesn't do lookups for any names in the named namespace.Celebrant
@Celebrant Well yeah, the declaration itself doesn't do any lookups itself, but name lookup uses it to look into the namespace. I don't understand your point, could you clarify.Nappie
This was extracted from your answer (emphasis is mine): "Here the sets of functions contain two non-overloadable are in there, but since they are found by name lookup as per the quote, they're okay."Celebrant
@Celebrant I mean the name lookup that happens when you call the function.Nappie
But that's different. With a using-declaration, like in your example, you generate sets of function fabricated as a result of name lookups started in each using-declaration, That doesn't occur with a using-directive.Celebrant
@Celebrant Yes. But those are not the same name lookups. You have one name lookup for each using declaration obviously to find out if the name actually exists. But then you have the set of functions found by name lookup when you call the function, and that is the set that the quote applies to.Nappie
As this compiles I have to agree with you. But [over.load]/1 is poorly written as it stands now. At least it should mention both, using-declaration and using-directives in the highlighted sentence.Celebrant
@Celebrant Actually, now I'm not sure. I'll just change it to using directives so that we know it's right :)Nappie

© 2022 - 2024 — McMap. All rights reserved.