[basic.lookup.argdep#3.sentence-5] Refers to "associated entities" of members of an overload set, rather than of call arguments

[RealLitb]

Full name of submitter (unless configured in github; will be published with the issue): Johannes Schaub

Reference (section label): http://eel.is/c++draft/basic.lookup.argdep#3.sentence-5

Issue description: The text says

In addition, if the argument is an overload set or the address of such a set, its associated entities are the union of those associated with each of the members of the set, i.e., the entities associated with its parameter types and return type.

We have a description on how to collect associated entities of (argument expression) types, but not of functions or function templates. If a member of the set is a member function, do we consider the class to be an associated entity?

There's implementation deviance. GCC adds the class to be an associated entity. Clang (which is normatively correct, I think) only considers the parameters and return type. That's what the normative wording also says explicitly, even though the reference to "associated entities" is at odds.

Testcase: https://godbolt.org/z/Grcj3Toof (change the ifdef from 0 to 1 to 0 to toggle).

Suggested resolution: Change the text as follows:

In addition, if the argument is an overload set or the address of such a set, its associated entities are the union of those associated with the type of the members of the set, i.e., the entities associated with its parameter types and return type. [Note: the type of a non-static member function is an ordinary function type -- end Note].

[languagelawyer]

IDK about CWG members, but this feels editorial to me

[RealLitb]

We have a description on how to collect associated entities of (argument expression) types, but not of functions or function templates.

Excuse me? If T is a function type, its associated entities are those associated with the function parameter types and those associated with the return type

It defines the associated entities of a function type. But if I refer to an overload set, I refer to a set of functions/function templates, not to their types. Maybe we could infer what is meant by interpreting "The set of entities is determined entirely by the types of the function arguments ..." to apply also to the types of members of the overload set. But that's not obvious, because those members are not expressions themselves. Even less obvious if the argument expression that refers to the overload set has the form &Class::memberfunction.

[RealLitb]

IDK about CWG members, but this feels editorial to me

I do agree, because the normative text is clear that only the parameters and the return type is checked. The little odd reference to collect the associated entities of the members, instead of the type of the members, of the overload set, can maybe be clarified by adding a note similar to the above. So that it is clear that "the class of any member function" wasn't omitted accidentally, but on purpose.

[RealLitb]

I'm sorry, I thought I was on the draft/ repository. So I wasn't noticing the intent of the above comment that felt the issue to be editorial.

Also, Lénárd Szolnoki on Discord makes a good point: If you remove one of the overloads, such that &Class::memberfunction is not anymore an overload set, then the type becomes "pointer to member .." and ADL will consider the Class to be an associated class. So adding an overload will reduce the set of associated classes - that feels weird, and maybe should be checked by CWG for non-editorialness.