[Moved to DR at October 2002 meeting.]

Proposed resolution (04/01):

1. Change the indicated text in 12.2.2.2 [over.match.call] paragraph 3:

   The fourth case arises from a postfix-expression of the form &F, where F names a set of overloaded functions. In the context of a function call, the set of functions named by F shall contain only non-member functions and static member functions. [Footnote: If F names a non-static member function, &F is a pointer-to-member, which cannot be used with the function call syntax.] And in this context using &F behaves the same as using &F is treated the same as the name F by itself. Thus, (&F)(expression-list_opt) is simply (F)(expression-list_opt), which is discussed in 12.2.2.2.2 [over.call.func]. If the function selected by overload resolution according to 12.2.2.2.2 [over.call.func] is a nonstatic member function, the program is ill-formed. [Footnote: When F is a nonstatic member function, a reference of the form &A::F is a pointer-to-member, which cannot be used with the function-call syntax, and a reference of the form &F is an invalid use of the "&" operator on a nonstatic member function.] (The resolution of &F in other contexts is described in 12.3 [over.over].)

12.2.2.2 [over.match.call] paragraph 3 says that when a call of the form

   (&C::f)()

This is clear, it's implementable, and it doesn't directly contradict anything else in the standard. However, I'm not sure it's consistent with some similar cases.

In 12.3 [over.over] paragraph 5, second example, it is made amply clear that when &C::f is used as the address of a function, e.g.,

   int (*pf)(int) = &C::f;

Similarly, 12.2.2.2.2 [over.call.func] paragraph 3 makes it clear that

   C::f();

Those paragraphs seem to suggest the general rule that you do overload resolution first and then you interpret the construct you have according to the function selected. The fact that there are static and nonstatic functions in the overload set is irrelevant; it's only necessary that the chosen function be static or nonstatic to match the context.

Given that, I think it would be more consistent if the (&C::f)() case would also do overload resolution first. If a nonstatic member is chosen, the program would be ill-formed.