<html>
<head>
<title>US 19: Ambiguous use of "use"</title>

<style type="text/css">
  ins { text-decoration:none; font-weight:bold; background-color:#A0FFA0 }
  del { text-decoration:line-through; background-color:#FFA0A0 }
</style>
</head>

<body>
Jens Maurer<br>
2010-10-16<br>
N3154=10-0144

<h1>US 19: Ambiguous use of "use"</h1>

This paper presents the wording changes to address NB comment US 19.
The NB comment reads:
<blockquote>
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..."
</blockquote>

with a proposed resolution
<blockquote>
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". 
</blockquote>

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.
<p>
The proposal presented here is to replace all uses of "use" in the ODR
sense with the term "odr-use".
<p>

<h2>Proposed Resolution</h2>

Change all occurrences of the word "use" to "odr-use" in 3.2
basic.def.odr paragraph 2:
<blockquote>
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 <del><em>used</em></del> <ins><em>odr-used</em></ins> 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. <code>this</code> is
<del>used</del> <ins>odr-used</ins> 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
<del>used</del> <ins>odr-used</ins> if it is not pure. <del>An overloaded
function</del>
<ins>A member of a set of candidate functions</ins> is
 <del>used</del> <ins>odr-used</ins> if it
is selected by overload resolution when referred to from a
potentially-evaluated expression. [ Note: ... A copy constructor or
move constructor is <del>used</del> <ins>odr-used</ins> even if the
call is actually elided by the implementation. -- end note ]
An allocation or deallocation function for a class is <del>used</del>
<ins>odr-used</ins> 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
<del>used</del> <ins>odr-used</ins> 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 <del>used</del> <ins>odr-used</ins> by the
definition of a constructor of that class. A non-placement deallocation
function for a class is <del>used</del> <ins>odr-used</ins> 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
<del>used</del> <ins>odr-used</ins>
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 <del>used</del> <ins>odr-used</ins> by an implicitly-defined
move-assignment function for another class as specified
in 12.8 class.copy. A default constructor for a class is
<del>used</del> <ins>odr-used</ins> by default initialization or value
initialization as specified in 8.5 dcl.init. A constructor for a class is
<del>used</del> <ins>odr-used</ins>
as specified in 8.5. A destructor for a class is <del>used</del>
<ins>odr-used</ins> as specified in 12.4 class.dtor.
</blockquote>

Change all occurrences of the word "use" to "odr-use" in 3.2 basic.def.odr paragraph 3:

<blockquote>
Every program shall contain exactly one definition of every non-inline
function or variable that is <del>used</del> <ins>odr-used</ins> 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 <del>used</del>
<ins>odr-used</ins>.
</blockquote>

Change in 3.2 basic.def.odr paragraph 5 bullet 5:
<blockquote>
<ul>
<li>if D is a class with an implicitly-declared constructor (12.1
class.ctor), it is as if the constructor was implicitly defined in
every translation unit where it is <del>used</del>
<ins>odr-used</ins>, and the implicit definition in every translation
unit shall call the same constructor for a base class or a class
member of D. [ Example: ... ]</li>
</ul>
</blockquote>

Change in 3.5 basic.link paragraph 8:
<blockquote>
<ul>
<li>...</li>
<li>the entity is not <del>used</del> <ins>odr-used</ins> (3.2
basic.def.odr) or is defined in the same translation unit.</li>
</ul>
[ 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 <del>used</del> <ins>odr-used</ins>.  ... ]
</blockquote>

Change in 3.6.1 basic.start.main paragraph 3:
<blockquote>
The function <code>main</code> shall not be <del>used</del>
<ins>odr-used</ins> (3.2) within a program. ...
</blockquote>

Change in 3.6.2 basic.start.init paragraph 4:
<blockquote>
... If the initialization is deferred to some point in time
after the first statement of <code>main</code>, it shall occur before
the first <del>use</del> <ins>odr-use (3.2 basic.def.odr)</ins> 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 <del>used</del> <ins>odr-used</ins>
(<ins>3.2 basic.def.odr,</ins> 3.7.1 basic.stc.static). ] [ Example: ... 
It is implementation-defined whether either a or b is initialized
before <code>main</code> is entered or whether the initializations are
delayed until a is first <del>used</del> <ins>odr-used</ins> in
<code>main</code>. In particular, if a is initialized before main is
entered, it is not guaranteed that b will be initialized before it is
<del>used</del> <ins>odr-used</ins> by the initialization of a,  is,
before A::A is called. ... -- end example ]
</blockquote>

Change in 3.6.2 basic.start.init paragraph 5:
<blockquote>
... 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
<del>use</del> <ins>odr-use (3.2 basic.def.odr)</ins> of any variable
with thread storage duration defined in the same translation unit as
the variable to be initialized.
</blockquote>

No changes in 3.6.3 basic.start.term paragraph 4.

<p>

Change in 3.7.2 basic.stc.thread paragraph 2:
<blockquote>
A variable with thread storage duration shall be initialized before
its first <del>use</del> <ins>odr-use (3.2 basic.def.odr)</ins> and,
if constructed, shall be destroyed on thread exit.
</blockquote>

Change in 5.1.2 expr.prim.lambda paragraph 11:
<blockquote>
If a <em>lambda-expression</em> has an associated
<em>capture-default</em> and its <em>compound-statement</em>
<del>uses</del> <ins>odr-uses</ins> (3.2 basic.def.odr) <code>this</code> or a
variable with automatic storage duration and the <del>used</del>
<ins>odr-used</ins> entity is not explicitly captured, then the
<del>used</del> <ins>odr-used</ins> entity is said to be implicitly
captured; such entities shall be declared within the reaching scope of
the lambda expression. [ Note: ... Implicit <del>uses</del>
<ins>odr-uses</ins> of <code>this</code> can result in implicit capture. ]
</blockquote>

Change in 5.1.2 expr.prim.lambda paragraph 12:
<blockquote>
An entity is captured if it is captured explicitly or implicitly. An
entity captured by a <em>lambda-expression</em> is <del>used</del>
<ins>odr-used</ins> (3.2 basic.def.odr) in the scope containing the
<em>lambda-expression</em>. If <code>this</code> is captured by a
local lambda expression, its nearest enclosing function shall be a
non-static member function. If a <em>lambda-expression</em>
<del>uses</del> <ins>odr-uses</ins> (3.2 basic.def.odr) <code>this</code>
or a variable with automatic storage duration from its reaching scope,
that entity shall be captured by the <em>lambda-expression</em>. ... [
Example:
<pre>
...
int x[N][M]; // OK: N and M are not <del>"used"</del> <ins>odr-used</ins>
...
</pre>
</blockquote>

Change in 5.1.2 expr.prim.lambda paragraph 17:
<blockquote>
Every <em>id-expression</em> that is <del>a use</del> <ins>an
odr-use</ins> (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 <code>this</code> is captured, each <del>use</del>
<ins>odr-use</ins> of <code>this</code> is transformed into an access to the corresponding unnamed data member of the closure type, cast (5.4) to the
type of <code>this</code>. ...
</blockquote>

Change in 5.1.2 expr.prim.lambda paragraph 18:
<blockquote>
Every occurrence of <code>decltype((x))</code> where <code>x</code> is
a possibly parenthesized <code>id-expression</code> that names an
entity of automatic storage duration is treated as if <code>x</code>
were transformed into an access to a corresponding data member of the
closure type that would have been declared if <code>x</code> were
<del>a use</del> <ins>an odr-use (3.2 basic.def.odr)</ins> of the
denoted entity. [ Example:
<pre>
...
[=] { // x and r are not captured (appearance in a decltype operand is not <del>a "use"</del> <ins>an odr-use</ins>)
...
</pre>
]
</blockquote>

Change in 7.1.2 dcl.fct.spec paragraph 4:

<blockquote>
An inline function shall be defined in every translation unit in which
it is <del>used</del> <ins>odr-used</ins> and shall have exactly the same
definition in every case (3.2 basic.def.odr).
[ Note: ... ]
</blockquote>

Change in 8.4.1 dcl.fct.def.general paragraph 8:

<blockquote>
... 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 <del>used</del> <ins>odr-used</ins> (3.2
basic.def.odr), its string value need not be present in the program
image. ]
</blockquote>


Change in 9.4.2 class.static.data paragraph 3:

<blockquote>
... The member shall still be defined in a namespace scope if it is
<del>used</del> <ins>odr-used (3.2 basic.def.odr)</ins> in the program
and the namespace scope definition shall not contain an
<em>initializer</em>.
</blockquote>

Change in 9.4.2 class.static.data paragraph 4:

<blockquote>
<ins>[ Note:</ins> There shall be exactly one definition of a static data
member that is <del>used</del> <ins>odr-used (3.2 basic.def.odr)</ins>
in a program; no diagnostic is required<del>; see 3.2</del>. <ins>
 -- end note ]</ins> Unnamed classes and classes contained directly
or indirectly within unnamed classes shall not contain static data
members.
</blockquote>

Change in 12 special paragraph 1:
<blockquote>
... The implementation will implicitly define them if they are
<del>used</del> <ins>odr-used (3.2 basic.def.odr)</ins>. ...
</blockquote>

Change in 12.1 class.ctor paragraph 6:
<blockquote>
A default constructor that is defaulted and not defined as deleted is
implicitly defined when it is <del>used</del> <ins>odr-used</ins> (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. ...
</blockquote>

No change in 12.1 class.ctor paragraph 7:
<blockquote>
... A program is ill-formed if the default constructor for an object
is implicitly used and the constructor is not accessible (Clause 11).
</blockquote>

Change 12.8 class.copy paragraph 14:
<blockquote>
A copy/move constructor that is defaulted and not defined as deleted
is implicitly defined if it is <del>used</del> <ins>odr-used (3.2
basic.def.odr)</ins> 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
<del>use</del> <ins>odr-use</ins> (<ins>3.2 basic.def.odr,</ins> 12.2
class.temporary). -- end note ]
</blockquote>

Change in 12.9 class.inhctor paragraph 6:
<blockquote>
[ Example:
...
<ul>
<li>D1(), implicitly-declared default constructor, ill-formed if <del>used</del> <ins>odr-used</ins> </li>
<li>...</li>
</ul>
...
]
</blockquote>

Change in 12.9 class.inhctor paragraph 8:
<blockquote>
An inheriting constructor for a class is implicitly defined when it is
<del>used</del> <ins>odr-used</ins> (3.2 basic.def.odr) to create an
object of its class type (1.8). ...
</blockquote>


Change 14.5.4 temp.friend paragraph 4:

<blockquote>
When a function is defined in a friend function declaration in a class
template, the function is instantiated when the function is
<del>used</del> <ins>odr-used (3.2 basic.def.odr)</ins>. The same
restrictions on multiple declarations and definitions that apply to
non-template function declarations and definitions also apply to these
implicit definitions.
</blockquote>

No change in 14.5.5.3 temp.class.spec.mfunc paragraph 1 (nested
classes are not subject to odr-use).
<p>

Change in 14.5.6 temp.fct paragraph 2:

<blockquote>
... [ 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 <del>used</del> <ins>odr-used (3.2 basic.def.odr)</ins> in a program, it must be defined; it will not
be implicitly instantiated using the function template definition. ]
</blockquote>

Change in 14.7.1 temp.inst paragraph 1:
<blockquote>
... 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 <del>used in a way that requires the definition of the static
data member to exist</del> <ins>odr-used</ins>.
</blockquote>

Change in 14.7.2 temp.explicit paragraph 9:
<blockquote>
... [ Note: The intent is that an inline function that is the subject
of an explicit instantiation declaration will still be implicitly
instantiated when <del>used</del> <ins>odr-used (3.2
basic.def.odr)</ins> 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 ]
</blockquote>

Change in 14.7.2 temp.explicit paragraph 10:

<blockquote>
... An entity that is the subject of an explicit instantiation
declaration and that is also <del>used</del> <ins>odr-used (3.2
basic.def.odr)</ins> 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. ...
</blockquote>

No change in 14.7.2 temp.explicit paragraph 12.
<p>

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

<p>

Change in 20.3.4 declval paragraph 2:

<blockquote>
<em>Remarks:</em> If this function is <del>used (as defined by (3.2))</del> <ins>odr-used (see 3.2 basic.def.odr)</ins>, the program is ill-formed.
</blockquote>


</body>
</html>
