Jens Maurer
2010-10-16
N3154=10-0144

US 19: Ambiguous use of "use"

This paper presents the wording changes to address NB comment US 19. The NB comment reads:
It is not always clear when the term "use" is intended as a reference to the definition in 3.2 and when it has its normal English meaning. For example, 3 paragraph 4 reads, "A name is a use of an identifier..."
with a proposed resolution
Replace all occurrences of the word "use" that are not intended as references to 3.2 with some other term, such as "occurrence" or "appearance" or "reference to".
The progress of the NB comment is tracked in Core issue 1109, but due to the volume of changes, they will not be incorporated into the Core issues list.

The proposal presented here is to replace all uses of "use" in the ODR sense with the term "odr-use".

Proposed Resolution

Change all occurrences of the word "use" to "odr-use" in 3.2 basic.def.odr paragraph 2:
An expression is potentially evaluated unless it is an unevaluated operand (Clause 5 expr) or a subexpression thereof. A variable or non-overloaded function whose name appears as a potentially-evaluated expression is used odr-used unless it is an object that satisfies the requirements for appearing in a constant expression (5.19 expr.const) and the lvalue-to-rvalue conversion (4.1 conv.lval) is immediately applied. this is used odr-used if it appears as a potentially-evaluated expression (including as the result of the implicit transformation in the body of a non-static member function (9.3.1 class.mfc.non-static)). A virtual member function is used odr-used if it is not pure. An overloaded function A member of a set of candidate functions is used odr-used if it is selected by overload resolution when referred to from a potentially-evaluated expression. [ Note: ... A copy constructor or move constructor is used odr-used even if the call is actually elided by the implementation. -- end note ] An allocation or deallocation function for a class is used odr-used by a new expression appearing in a potentially-evaluated expression as specified in 5.3.4 and 12.5. A deallocation function for a class is used odr-used by a delete expression appearing in a potentially-evaluated expression as specified in 5.3.5 and 12.5. A non-placement allocation or deallocation function for a class is used odr-used by the definition of a constructor of that class. A non-placement deallocation function for a class is used odr-used by the definition of the destructor of that class, or by being selected by the lookup at the point of definition of a virtual destructor (12.4). [ Footnote: ... ] A copy-assignment function for a class is used odr-used by an implicitly-defined copy-assignment function for another class as specified in 12.8 class.copy. A move-assignment function for a class is used odr-used by an implicitly-defined move-assignment function for another class as specified in 12.8 class.copy. A default constructor for a class is used odr-used by default initialization or value initialization as specified in 8.5 dcl.init. A constructor for a class is used odr-used as specified in 8.5. A destructor for a class is used odr-used as specified in 12.4 class.dtor.
Change all occurrences of the word "use" to "odr-use" in 3.2 basic.def.odr paragraph 3:
Every program shall contain exactly one definition of every non-inline function or variable that is used odr-used in that program; no diagnostic required. The definition can appear explicitly in the program, it can be found in the standard or a user-defined library, or (when appropriate) it is implicitly defined (see 12.1, 12.4 and 12.8). An inline function shall be defined in every translation unit in which it is used odr-used.
Change in 3.2 basic.def.odr paragraph 5 bullet 5:
Change in 3.5 basic.link paragraph 8:
[ Note: ... An entity with external linkage declared using such a type could not correspond to any other entity in another translation unit of the program and thus must be defined in the translation unit if it is used odr-used. ... ]
Change in 3.6.1 basic.start.main paragraph 3:
The function main shall not be used odr-used (3.2) within a program. ...
Change in 3.6.2 basic.start.init paragraph 4:
... If the initialization is deferred to some point in time after the first statement of main, it shall occur before the first use odr-use (3.2 basic.def.odr) of any function or variable defined in the same translation unit as the variable to be initialized. [ Footnote: A non-local variable with static storage duration having initialization with side-effects must be initialized even if it is not used odr-used (3.2 basic.def.odr, 3.7.1 basic.stc.static). ] [ Example: ... It is implementation-defined whether either a or b is initialized before main is entered or whether the initializations are delayed until a is first used odr-used in main. In particular, if a is initialized before main is entered, it is not guaranteed that b will be initialized before it is used odr-used by the initialization of a, is, before A::A is called. ... -- end example ]
Change in 3.6.2 basic.start.init paragraph 5:
... If the initialization is deferred to some point in time after the first statement of the initial function of the thread, it shall occur before the first use odr-use (3.2 basic.def.odr) of any variable with thread storage duration defined in the same translation unit as the variable to be initialized.
No changes in 3.6.3 basic.start.term paragraph 4.

Change in 3.7.2 basic.stc.thread paragraph 2:

A variable with thread storage duration shall be initialized before its first use odr-use (3.2 basic.def.odr) and, if constructed, shall be destroyed on thread exit.
Change in 5.1.2 expr.prim.lambda paragraph 11:
If a lambda-expression has an associated capture-default and its compound-statement uses odr-uses (3.2 basic.def.odr) this or a variable with automatic storage duration and the used odr-used entity is not explicitly captured, then the used odr-used entity is said to be implicitly captured; such entities shall be declared within the reaching scope of the lambda expression. [ Note: ... Implicit uses odr-uses of this can result in implicit capture. ]
Change in 5.1.2 expr.prim.lambda paragraph 12:
An entity is captured if it is captured explicitly or implicitly. An entity captured by a lambda-expression is used odr-used (3.2 basic.def.odr) in the scope containing the lambda-expression. If this is captured by a local lambda expression, its nearest enclosing function shall be a non-static member function. If a lambda-expression uses odr-uses (3.2 basic.def.odr) this or a variable with automatic storage duration from its reaching scope, that entity shall be captured by the lambda-expression. ... [ Example:
...
int x[N][M]; // OK: N and M are not "used" odr-used
...
Change in 5.1.2 expr.prim.lambda paragraph 17:
Every id-expression that is a use an odr-use (3.2 basic.def.odr) of an entity captured by copy is transformed into an access to the corresponding unnamed data member of the closure type. If this is captured, each use odr-use of this is transformed into an access to the corresponding unnamed data member of the closure type, cast (5.4) to the type of this. ...
Change in 5.1.2 expr.prim.lambda paragraph 18:
Every occurrence of decltype((x)) where x is a possibly parenthesized id-expression that names an entity of automatic storage duration is treated as if x were transformed into an access to a corresponding data member of the closure type that would have been declared if x were a use an odr-use (3.2 basic.def.odr) of the denoted entity. [ Example:
...
[=] { // x and r are not captured (appearance in a decltype operand is not a "use" an odr-use)
...
]
Change in 7.1.2 dcl.fct.spec paragraph 4:
An inline function shall be defined in every translation unit in which it is used odr-used and shall have exactly the same definition in every case (3.2 basic.def.odr). [ Note: ... ]
Change in 8.4.1 dcl.fct.def.general paragraph 8:
... It is unspecified whether suchna variable has an address distinct from that of any other object in the program. [ Footnote: ... If a predefined variable is not used odr-used (3.2 basic.def.odr), its string value need not be present in the program image. ]
Change in 9.4.2 class.static.data paragraph 3:
... The member shall still be defined in a namespace scope if it is used odr-used (3.2 basic.def.odr) in the program and the namespace scope definition shall not contain an initializer.
Change in 9.4.2 class.static.data paragraph 4:
[ Note: There shall be exactly one definition of a static data member that is used odr-used (3.2 basic.def.odr) in a program; no diagnostic is required; see 3.2. -- end note ] Unnamed classes and classes contained directly or indirectly within unnamed classes shall not contain static data members.
Change in 12 special paragraph 1:
... The implementation will implicitly define them if they are used odr-used (3.2 basic.def.odr). ...
Change in 12.1 class.ctor paragraph 6:
A default constructor that is defaulted and not defined as deleted is implicitly defined when it is used odr-used (3.2 basic.def.odr) to create an object of its class type (1.8) or when it is explicitly defaulted after its first declaration. ...
No change in 12.1 class.ctor paragraph 7:
... A program is ill-formed if the default constructor for an object is implicitly used and the constructor is not accessible (Clause 11).
Change 12.8 class.copy paragraph 14:
A copy/move constructor that is defaulted and not defined as deleted is implicitly defined if it is used odr-used (3.2 basic.def.odr) to initialize an object of its class type from a copy of an object of its class type or of a class type derived from its class type [ Footnote: ... ] or when it is explicitly defaulted after its first declaration. [ Note: the copy/move constructor is implicitly defined even if the implementation elided its use odr-use (3.2 basic.def.odr, 12.2 class.temporary). -- end note ]
Change in 12.9 class.inhctor paragraph 6:
[ Example: ... ... ]
Change in 12.9 class.inhctor paragraph 8:
An inheriting constructor for a class is implicitly defined when it is used odr-used (3.2 basic.def.odr) to create an object of its class type (1.8). ...
Change 14.5.4 temp.friend paragraph 4:
When a function is defined in a friend function declaration in a class template, the function is instantiated when the function is used odr-used (3.2 basic.def.odr). The same restrictions on multiple declarations and definitions that apply to non-template function declarations and definitions also apply to these implicit definitions.
No change in 14.5.5.3 temp.class.spec.mfunc paragraph 1 (nested classes are not subject to odr-use).

Change in 14.5.6 temp.fct paragraph 2:

... [ Footnote: That is, declarations of non-template functions do not merely guide overload resolution of function template specializations with the same name. If such a non-template function is used odr-used (3.2 basic.def.odr) in a program, it must be defined; it will not be implicitly instantiated using the function template definition. ]
Change in 14.7.1 temp.inst paragraph 1:
... Unless a member of a class template or a member template has been explicitly instantiated or explicitly specialized, the specialization of the member is implicitly instantiated when the specialization is referenced in a context that requires the member definition to exist; in particular, the initialization (and any associated side-effects) of a static data member does not occur unless the static data member is itself used in a way that requires the definition of the static data member to exist odr-used.
Change in 14.7.2 temp.explicit paragraph 9:
... [ Note: The intent is that an inline function that is the subject of an explicit instantiation declaration will still be implicitly instantiated when used odr-used (3.2 basic.def.odr) so that the body can be considered for inlining, but that no out-of-line copy of the inline function would be generated in the translation unit. -- end note ]
Change in 14.7.2 temp.explicit paragraph 10:
... An entity that is the subject of an explicit instantiation declaration and that is also used odr-used (3.2 basic.def.odr) in the translation unit shall be the subject of an explicit instantiation definition somewhere in the program; otherwise the program is ill-formed, no diagnostic required. ...
No change in 14.7.2 temp.explicit paragraph 12.

No change in 14.7.3 temp.expl.spec paragraph 6.

Change in 20.3.4 declval paragraph 2:

Remarks: If this function is used (as defined by (3.2)) odr-used (see 3.2 basic.def.odr), the program is ill-formed.