Title
Type matching in address of overloaded function
Status
c++11
Section
12.3 [over.over]
Submitter
US

Created on 2010-08-03.00:00:00 last changed 130 months ago

Messages

Date: 2010-11-15.00:00:00

[Voted into the WP at the November, 2010 meeting.]

Date: 2010-09-15.00:00:00

Proposed resolution (September, 2010):

  1. Change 12.3 [over.over] paragraph 1 as follows:

  2. ...The function selected is the one whose type matches is identical to the function type of the target type required in the context. [Note: That is, the class of which the function is a member is ignored when matching a pointer-to-member-function type. —end note] The target can be...
  3. Change 12.3 [over.over] paragraph 3 as follows:
  4. Non-member functions and static member functions match targets of type “pointer-to-function” or “reference- to-function.” Nonstatic member functions match targets of type “pointer-to-member-function;.the function type of the pointer to member is used to select the member function from the set of overloaded member functions. If a non-static member function is selected, the reference to the overloaded function name is required to have the form of a pointer to member as described in 7.6.2.2 [expr.unary.op].
Date: 2010-08-15.00:00:00

Notes from the August, 2010 meeting:

CWG observed that the only case in which the types might not match exactly was for pointers to member functions. In this case, the approach should be to ignore the class of which the functions are members and just match (exactly) on the function type.

Date: 2010-08-03.00:00:00
N3092 comment US 68

Overload resolution within the operand of a unary & operator is done by selecting the function “whose type matches the target type required in the context.” The criterion for determining whether the types match, however, is not defined. At least three possibilities suggest themselves:

  1. The types are identical.

  2. The source type can be implicitly converted to the target type.

  3. The expression would be well-formed if the function under consideration were not overloaded.

This question arises for pointer-to-member types, where there is an implicit conversion from a pointer-to-base-member to a pointer-to-derived-member, as well as when the context is an explicit type conversion (which allows, for static_cast, a conversion from pointer-to-derived-member to a pointer-to-base-member and, in the reinterpret_cast interpretation of functional and old-style casts, essentially any conversion).

History
Date User Action Args
2014-03-03 00:00:00adminsetstatus: fdis -> c++11
2011-04-10 00:00:00adminsetstatus: dr -> fdis
2010-11-29 00:00:00adminsetmessages: + msg3194
2010-11-29 00:00:00adminsetstatus: tentatively ready -> dr
2010-10-18 00:00:00adminsetmessages: + msg2990
2010-10-18 00:00:00adminsetstatus: drafting -> tentatively ready
2010-08-23 00:00:00adminsetmessages: + msg2862
2010-08-03 00:00:00admincreate