Title
Inadequate description of odr-use of implicitly-invoked functions
Status
cd5
Section
6.3 [basic.def.odr]
Submitter
Richard Smith

Created on 2014-10-08.00:00:00 last changed 7 months ago

Messages

Date: 2019-01-15.00:00:00

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:...
  3. Cbange 6.3 [basic.def.odr] paragraph 3 as follows:

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

    • A function whose name appears in an expression is named by that an expression or conversion if it is the unique lookup result of a name lookup or the selected member of a set of overloaded functions (6.5 [basic.lookup], 12.2 [over.match], 12.3 [over.over]) in an overload resolution performed as part of forming that expression or conversion, unless it is a pure virtual function and either its name is not the expression is not an id-expression naming the function with anexplicitly qualified name or the expression forms a pointer to member (7.6.2.2 [expr.unary.op]). [Note: This covers taking the address of functions (7.3.4 [conv.func], 7.6.2.2 [expr.unary.op]), calls to named functions (7.6.1.3 [expr.call]), operator overloading (Clause Clause 12 [over]), user-defined conversions (11.4.8.3 [class.conv.fct]), allocation functions for placement new-expressions (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 considered to be named by an expression or conversion even if the call is actually elided by the implementation (11.9.6 [class.copy.elision]). —end note]

    • An allocation or deallocation function for a class is named by a new-expression if it is the single matching deallocation function for the allocation function selected by o verload resolution, as specified in 7.6.2.8 [expr.new] and 11.11 [class.free].

    • A deallocation function for a class is named by a delete expression delete-expression if it is the selected usual deallocation function as specified in 7.6.2.9 [expr.delete] and 11.11 [class.free].

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

  6. 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...
Date: 2019-02-15.00:00:00

[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 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 (_N4750_.15.8 [class.copy]). —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.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.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.)

History
Date User Action Args
2020-12-15 00:00:00adminsetmessages: + msg6346
2020-12-15 00:00:00adminsetstatus: drafting -> cd5
2014-10-08 00:00:00admincreate