This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 116a. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.

2024-12-19

2020. Inadequate description of odr-use of implicitly-invoked functions

Section: 6.3  [basic.def.odr]     Status: CD5     Submitter: Richard Smith     Date: 2014-10-08

[Accepted as a DR at the February, 2019 meeting.]

According to 6.3 [basic.def.odr] paragraph 3,

A function whose name appears as a potentially-evaluated expression is odr-used if it is the unique lookup result or the selected member of a set of overloaded functions (6.5 [basic.lookup], 12.2 [over.match], 12.3 [over.over]), unless it is a pure virtual function and its name is not explicitly qualified. [Note: This covers calls to named functions (7.6.1.3 [expr.call]), operator overloading (Clause 12 [over]), user-defined conversions (11.4.8.3 [class.conv.fct]), allocation function for placement new (7.6.2.8 [expr.new]), as well as non-default initialization (9.4 [dcl.init]). A constructor selected to copy or move an object of class type is odr-used even if the call is actually elided by the implementation (11.4.5.3 [class.copy.ctor]). —end note] An allocation or deallocation function for a class is odr-used by a new expression appearing in a potentially-evaluated expression as specified in 7.6.2.8 [expr.new] and 11.4.11 [class.free]. A deallocation function for a class is odr-used by a delete expression appearing in a potentially-evaluated expression as specified in 7.6.2.9 [expr.delete] and 11.4.11 [class.free].

There are a couple of problems with this specification. First, contrary to the note, the names of overloaded operators, conversion functions, etc., do not appear in potentially-evaluated expressions, so the normative text does not make the note true. Also, the “as specified in” references do not cover odr-use explicitly, only the invocation of the functions.

One possible way of addressing these deficiencies would be a blanket rule like,

A function is odr-used if it is invoked by a potentially-evaluated expression.

(The existing wording about appearing in a potentially-evaluated expression would still be needed for non-call references.)

Proposed resolution (January, 2019):

  1. Change 6.3 [basic.def.odr] paragraph 2 as follows:

    2. An expression or conversion is potentially evaluated unless it is an unevaluated operand (7.2 [expr.prop]), or a subexpression thereof, or a conversion in an initialization or conversion sequence in such a context. The set of potential results of an expression e is defined as follows:...

  2. Cbange 6.3 [basic.def.odr] paragraph 3 as follows:

    3. A function is named by an expression an expression or conversion as follows:

  3. Change 6.3 [basic.def.odr] paragraph 7 as follows:

    4. A virtual member function is odr-used if it is not pure. A function is odr-used if it is named by a potentially-evaluated expression or conversion. A non-placement...