<html>
<head>
<title>Expanding the meaning of variable</title>
</head>

<body>
N2993 = 09-0183<br/>
Jens Maurer &lt;Jens.Maurer@gmx.net><br/>
2009-10-21

<h1>Expanding the meaning of variable</h1>

This paper presents working paper changes to address the following
core issues:
<ul>
<li>core issue 633 "Specifications for variables that should also apply to references"</li>
<li>core issue 570 "Are references subject to the ODR?"</li>
</ul>

It also addresses N2800 comment UK 26 and N2800 comment UK 22.
<p>
The goal of these changes is to expand the meaning of "variable" to
encompass both named objects and references, and to apply the term
consistently wherever feasible.  While doing so, the following
miscellaneous issues found during review were also addressed
<ul>
<li>3.3.11 basic.scope.hiding paragraph 2 improperly described hiding
inside a class.</li>
<li>3.6.2 basic.start.init and 3.7.1 basic.start.term were not
addressing static data members.</li>
<li>3.6.2 basic.start.init, 15.5.1 except.terminate were not
addressing exceptions thrown from the construction of temporaries.</li>
<li>A note in 5.1 expr.prim was incorrectly using the term "identifier".</li>
</ul>

<p>

<h2>Proposed changes</h2>
No change in 1.3.10 defns.parameter.
<p>

Change 1.10 intro.multithread paragraph 5 as follows:
<blockquote>
... [ Note: ... In general this will be impossible since different
threads may observe modifications to different <del>variables</del>
<ins>objects</ins> in inconsistent orders. -- end note ]
</blockquote>

Change 1.10 intro.multithread paragraph 7 as follows:
<blockquote>
... [ Note: ... For atomic <del>variables</del> <ins>objects</ins>,
the definition is clear. ... -- end note ]
</blockquote>

Change 1.10 intro.multithread paragraph 12 as follows:
<blockquote>
... [ Note: This states that operations
on ordinary <del>variables</del> <ins>objects</ins> are not visibly
reordered. ... -- end note ]
</blockquote>

Change 2.1 lex.phases paragraph 1, number 9 as follows:
<blockquote>
9. All external <del>object and function</del> <ins>entity</ins> references are
resolved.  Library components are linked to satisfy external references
to <del>functions and objects</del> <ins>entities</ins> not defined in the current
translation...
</blockquote>

Change 3 basic paragraph 3:
<blockquote>
An <em>entity</em> is a value, object, <del>variable,</del> reference,
function, enumerator, type, class member, template, template
specialization, namespace, parameter pack, concept, or concept map.
</blockquote>

Change 3 basic paragraph 6:
<blockquote>
A <em>variable</em> is introduced by the declaration of
<ins>a reference other than a non-static data member or of</ins> an
object.  The variable's name denotes the object <ins>or
reference</ins>.
</blockquote>

No change in 3.2 basic.def.odr paragraph 1.
<p>

Change 3.2 basic.def.odr paragraph 2 as follows:
<blockquote>
... <del>An object</del> <ins>A variable</ins> or non-overloaded
function whose name appears as a potentially-evaluated expression is
<em>used</em> unless it is an object that satisfies the requirements for
appearing in a constant expression...
</blockquote>

Change 3.2 basic.def.odr paragraph 3 as follows:
<blockquote>
Every program shall contain exactly one definition of every non-inline
function or <del>object</del> <ins>variable</ins> that is used in that
program...
</blockquote>

Change 3.3 basic.scope paragraph 4, bullet 2 as follows:
<blockquote>
<ul>
<li>exactly one declaration shall declare a class name or enumeration
name that is not a typedef name and the other declarations shall all
refer to the same <del>object, </del> <ins>variable</ins> or enumerator, or all
refer to functions and function templates...</li>
</ul>
</blockquote>

Change 3.3.1 basic.scope.pdecl paragraph 9 as follows:
<blockquote>
Function declarations at block scope and <del>object</del>
<ins>variable</ins> declarations with the <code>extern</code>
specifier at block scope refer to declarations that are members of an
enclosing namespace...
</blockquote>

Change 3.3.11 basic.scope.hiding paragraph 2 as follows:
<blockquote>
A class name (9.1 class.name) or enumeration name (7.2 dcl.enum) can
be hidden by the name of <del>an object</del> <ins>a variable,
data member</ins>, function,
or enumerator declared in the same scope. If a class or enumeration
name and <del>an object</del> <ins>a variable, data member</ins>, function, or enumerator are
declared in the same scope (in any order) with the same name, the
class or enumeration name is hidden wherever the <del>object</del>
<ins>variable, data member</ins>, function, or enumerator name is visible.
</blockquote>

Change 3.4.1 basic.lookup.unqual paragraph 14 as follows:

<blockquote>
If a variable member of a namespace is defined
outside of the scope of its namespace then any name <del>used</del>
<ins>that appears</ins> in the
definition of the <del>variable</del> member (after the
<em>declarator-id</em>) is looked up as if the definition of the
<del>variable</del> member occurred in its namespace. ...
</blockquote>

Change 3.4.3 basic.lookup.qual paragraph 1 as follows:

<blockquote>
...During the lookup for a name preceding the :: scope resolution
operator, <del>object</del> <ins>variable</ins>, function, and
enumerator names are ignored...
</blockquote>

Change 3.4.3.2 namespace.qual paragraph 5 as follows:

<blockquote>
During the lookup of a qualified namespace member name, if the lookup
finds more than one declaration of the member, and if one declaration
introduces a class name or enumeration name and the other declarations
either introduce the same <del>object</del> <ins>variable</ins>, the
same enumerator or a set of functions, the non-type name hides the
class or enumeration name if
and only if the declarations are from the same namespace; otherwise
(the declarations are from different namespaces), the program is
ill-formed. ...
</blockquote>

No change in 3.5 basic.link paragraph 2.
<p>

Change 3.5 basic.link paragraph 3 as follows:
<blockquote>
A name having namespace scope (3.3.6 basic.scope.namespace) has
internal linkage if it is the name of
<ul>
<li><del>an object, reference</del> <ins>a variable</ins>, function or
function template that is explicitly declared static...</li>
<li><del>an object or reference</del> <ins>a variable</ins> that is
explicitly declared const and neither explicitly declared extern nor
previously declared to have external linkage; or</li>
<li>...</li>
</ul>
</blockquote>

Change 3.5 basic.link paragraph 4 as follows:
<blockquote>
A name having namespace scope has external linkage if it is the name of
<ul>
<li><del>an object or reference</del> <ins>a variable</ins>, unless it
has internal linkage; or
<li>...
</ul>
</blockquote>

Change 3.5 basic.link paragraph 6 as follows:
<blockquote>
The name of a function declared in block scope and the name of <del>an
object</del> <ins>a variable</ins> declared by a block scope
<code>extern</code> declaration have linkage. ...
</blockquote>

Change 3.5 basic.link paragraph 8 as follows:

<blockquote>
... A type without linkage shall not be used as the type of a
variable or function with linkage, unless
<del>the variable or function</del> <ins>that entity</ins> has extern
"C" linkage (7.5), or ...
</blockquote>

Change 3.5 basic.link paragraph 9 as follows:
<blockquote>
Two names that are the same (clause 3) and that are declared in
different scopes shall denote the same <del>object, reference</del>
<ins>variable</ins>, function, type, enumerator, template or namespace
if ...
</blockquote>

Change 3.5 basic.link paragraph 10 as follows:

<blockquote>
...the types specified by all declarations referring to a given
<del>object</del> <ins>variable</ins> or function shall be
identical...
</blockquote>

Change the section heading of 3.6.2 basic.start.init as follows:
<blockquote>
3.6.2 Initialization of non-local <del>objects</del> <ins>variables</ins>
</blockquote>

Change 3.6.2 basic.start.init paragraph 1 as follows:
<blockquote>
There are two broad classes of named non-local <del>objects</del>
<ins>variables</ins>: those with static storage duration (3.7.1
basic.stc.static) and those with thread storage duration (3.7.2
basic.stc.thread). Non-local <del>objects</del> <ins>variables</ins>
with static storage duration are initialized as a consequence of
program initiation. Non-local <del>objects</del> <ins>variables</ins>
with thread storage duration are initialized as a consequence of
thread execution. ...
</blockquote>

Change 3.6.2 basic.start.init paragraph 2 as follows:
<blockquote>
<del>Objects</del> <ins>Variables</ins> with static storage duration
(3.7.1 basic.stc.static) or thread storage duration (3.7.2
basic.stc.thread) shall be zero-initialized (8.5 dcl.init)
before any other initialization takes place.
<p>
... Dynamic initialization of a non-local <del>object</del>
<ins>variable</ins> with static storage duration is either ordered or
unordered.  Definitions of explicitly specialized class template
static data members have ordered initialization.  Other class template
static data members (i.e., implicitly or explicitly instantiated
specializations) have unordered initialization.  Other
<del>objects defined in namespace scope</del>
<ins>non-local variables with static storage duration</ins>
have ordered initialization.  <del>Objects</del> <ins>Variables</ins>
with ordered initialization defined within a single translation unit
shall be initialized in the order of their definitions in the
translation unit. If a program starts a thread (30.2 thread.threads),
the subsequent initialization of <del>an object</del> <ins>a variable</ins> is
unsequenced with respect to the initialization of <del>an object</del>
<ins>a variable</ins> defined in a different translation unit.  Otherwise,
the initialization of <del>an object</del> <ins>a variable</ins> is
indeterminately sequenced with respect to the initialization of
<del>an object</del> <ins>a variable</ins> defined in a different
translation unit.  If a program starts a thread, the subsequent
unordered initialization of <del>an object</del> <ins>a variable</ins>
is unsequenced with respect to every other dynamic initialization.
Otherwise, the unordered initialization of <del>an object</del> <ins>a
variable</ins> is indeterminately sequenced with respect to every
other dynamic initialization.
[ Note: This definition permits initialization of a sequence of
ordered <del>objects</del> <ins>variables</ins> concurrently with another
sequence. -- end note ] [ Note: <del>8.5.1 dcl.init.aggr describes the
order in which aggregate members are initialized.</del>
The initialization of local static <del>objects</del>
<ins>variables</ins> is described in 6.7 stmt.dcl. -- end note ]
</blockquote>

Change 3.6.2 basic.start.init paragraph 3 as follows:

<blockquote>
An implementation is permitted to perform the initialization of
<del>an object of namespace scope</del> <ins>a non-local variable with static storage duration</ins> as a
static initialization even if such initialization is not required to
be done statically, provided that
<ul>
<li>the dynamic version of the initialization does not change the
value of any other object of namespace scope prior to its
initialization, and</li>
<li>the static version of the initialization produces the same value
in the initialized <del>object</del> <ins>variable</ins> as would be
produced by the dynamic initialization if all <del>objects</del>
<ins>variables</ins> not required to be initialized statically were
initialized dynamically.
</blockquote>

Change 3.6.2 basic.start.init paragraph 4 as follows:

<blockquote>
It is implementation-defined whether the dynamic initialization <del>(8.5
dcl.init, 9.4 class.static, 12.1 class.ctor, 12.6.1 class.expl.init)</del>
of <del>an object of namespace scope</del> <ins>a non-local
variable</ins>
with static storage duration is done before the first statement of
<code>main</code>. If the initialization is deferred to some point in
time after the first statement of <code>main</code>, it shall occur
before the first use of any function or <del>object</del>
<ins>variable</ins> defined in the same translation unit as the
<del>object</del> <ins>variable</ins> to be initialized.
[ Footnote: <del>An object defined in
namespace scope</del> <ins>A non-local variable with static storage
duration</ins> having initialization with side-effects must be
initialized even if it is not used (3.7.1 basic.stc.static). ] ...
</blockquote>

Change 3.6.2 basic.start.init paragraph 5 as follows:

<blockquote>
It is implementation-defined whether the dynamic initialization <del>(8.5
dcl.init, 9.4 class.static, 12.1 class.ctor, 12.6.1 class.expl.init)</del>
of <del>an object of namespace scope</del> <ins>a non-local variable
with static or thread storage duration</ins> <del>and
with thread storage duration</del> is done before the first statement of the
initial function of the thread.  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 of any
<del>object</del> <ins>variable</ins> with thread storage duration
defined in the same translation unit as the <del>object</del>
<ins>variable</ins> to be initialized.
</blockquote>


Change 3.6.2 basic.start.init paragraph 6 as follows:
<blockquote>
<del>If construction or destruction of a non-local static or thread
duration object ends in throwing an uncaught exception, the result is
to call <code>std::terminate</code> (18.7.3.3 terminate)</del>
<ins>[ Note: If the initialization of a non-local variable with static
or thread storage duration terminates by throwing an exception,
<code>std::terminate</code> is called (see 15.5.1
except.terminate). ]</ins>
</blockquote>

<em>Drafting note: This change (together with the corresponding change
in 15.5.1) addresses  <code>const A& a = ( B(), A() )</code> ; assume
B() throws an exception: the B() temporary is not lifetime-extended,
so it's not the "construction of a non-local static duration object",
so the wording falls into a black hole.  The next change addresses the
"destruction" case.</em>

<p>

Add at the end of 3.6.3 basic.start.term paragraph 1:
<blockquote>
... <ins>[ Note: If the destruction of a non-local object with static
or thread storage duration terminates by throwing an exception,
<code>std::terminate</code> is called (see 15.5.1
except.terminate). ]</ins>
</blockquote>

No change in the rest of 3.6.3: references don't have destructors and
temporaries would be lifetime-extended so that "object with
static/thread storage duration" fits them.
<p>

Change 3.7.1 basic.stc.static paragraphs 1 and 2 as follows:
<blockquote>
All <del>objects</del> <ins>variables</ins> which do not have dynamic
storage duration, do not have thread storage duration, and are not
local have static storage duration.  The storage for these
<del>objects</del> <ins>entities</ins> shall last for the duration of
the program (3.6.2 basic.start.init, 3.6.3 basic.start.term).
<p>
If <del>an object of</del> <ins>a variable with</ins> static storage
duration has initialization or a
destructor with side effects, it shall not be eliminated even if it
appears to be unused, except that a class object or its copy may be
eliminated as specified in 12.8 class.copy.
</blockquote>

No change in 3.7.1 basic.stc.static paragraph 3.
<p>

Change 3.7.2 basic.stc.thread paragraphs 1 and 2 as follows:
<blockquote>
All <del>objects and references</del> <ins>variables</ins> declared
with the <code>thread_local</code> keyword have thread storage
duration.  The storage for these <del>objects and references</del>
<ins>entities</ins> shall last for the duration of the thread in which
they are created.  There is a distinct object or reference per thread,
and use of the declared name refers to the <del>object or
reference</del> <ins>entitiy</ins> associated with the current thread.
<p>
<del>An object or reference</del> <ins>A variable</ins> with thread
storage duration shall be initialized before its first use and, if
constructed, shall be destroyed on thread exit.
</blockquote>

Change 3.7.3 basic.stc.auto paragraphs 1, 2, and 3 as follows:
<blockquote>
Local <del>objects</del> <ins>variables</ins> explicitly declared
<code>register</code> or not explicitly declared <code>static</code>
or <code>extern</code> have automatic storage duration. The storage
for these <del>objects</del> <ins>entities</ins> lasts until the block
in which they are created exits.
<p>
[ Note: these <del>objects</del> <ins>variables</ins> are initialized
and destroyed as described in 6.7. -- end note ]
<p>
If a <del>named automatic object</del> <ins>variable with automatic
storage duration</ins> has initialization or
a destructor with side effects, it shall not be destroyed
before the end of its block, nor shall it be eliminated as an
optimization even if it appears to be unused, except that a class
object or its copy may be eliminated as specified in 12.8 class.copy.

</blockquote>


Change 3.9.1 basic.fundamental paragraph 6 as follows:
<blockquote>
Values of type <code>bool</code> are either <code>true</code> or <code>false</code>. [ Footnote:
Using a <code>bool</code> value in ways described by this
International Standard as "undefined," such as by examining the value
of an uninitialized automatic <del>variable</del> <ins>object</ins>,
might cause it to behave as if it is neither <code>true</code> nor
<code>false</code>. ] ...
</blockquote>

Change 5.1 expr.prim paragraph 4 as follows:

<blockquote>
... [ Note: the use of :: allows <del>a type, an object, a function,
an enumerator, or a namespace</del> <ins>an entity</ins> declared in
the global namespace to be referred to even if its
<del>identifier</del> <ins>name</ins> has been hidden (3.4.3
basic.lookup.qual).  -- end note ]
</blockquote>

<em>Drafting note: This is an en passant fix.</em>

<p>

No change in 5.1 expr.prim paragraph 7.
<p>
No change in 5.1 expr.prim paragraph 8.
<p>

Change 5.1.2 expr.prim.lambda paragraph 9 as follows:
<blockquote>
A <em>lambda-expression</em>'s <em>compound-statement</em> can use
(see above) <code>this</code> from an immediately-enclosing member
function definition, as well as variables <del>and references</del>
with automatic storage duration from an immediately-enclosing
function definition or <em>lambda-expression</em>, provided these
entities are captured (as described below).  Any other
use (3.2 basic.def.odr) of a variable <del>or reference</del> with
automatic storage duration declared outside the
<em>lambda-expression</em> is ill-formed. [ Example: ...
</blockquote>

Change 5.1.2 expr.prim.lambda paragraph 10 as follows:
<blockquote>
The identifiers in a <em>capture-list</em> are looked up using the
usual rules for unqualified name lookup (3.4.1 basic.lookup.unqual); each
such lookup shall find a variable <del>or reference</del> with
automatic storage duration. An entity (i.e. a variable<del>, a
reference,</del> or <code>this</code>) is said to be explicitly
captured if it appears in the <em>lambda-expression</em>'s
<em>capture-list</em>.  An explicitly captured entity is used (3.2
basic.def.odr).
</blockquote>

Change 5.1.2 expr.prim.lambda paragraph 11 as follows:
<blockquote>
If a <em>lambda-expression</em> has an associated
<em>capture-default</em> and its <em>compound-statement</em> uses (3.2
basic.def.odr) <code>this</code> or a variable <del>or reference</del>
with automatic storage duration declared in an enclosing function or
<em>lambda-expression</em> and the used entity is not explicitly
captured, then the used entity is said to be implicitly captured. ...
</blockquote>

Change 5.2.9 expr.static.cast paragraph 5 as follows:
<blockquote>
... [ Note: however, if the value is in a temporary
<del>variable</del> <ins>object</ins> (12.2 class.temporary), the
destructor for that <del>variable</del> <ins>object</ins> is not
executed until the usual time, and the value of the
<del>variable</del> <ins>object</ins> is preserved for the purpose of
executing the destructor. -- end note ] ...
</blockquote>

Change 5.19 expr.const paragraph 2 bullet 4 sub-bullet 1 as follows:
<blockquote>
<ul>
<li>...
<ul><li>an lvalue of effective integral type that refers to a
non-volatile const <del>variable or static data member</del>
<ins>object</ins> initialized with constant expressions, or</li>
</ul></li>
</ul>

</blockquote>


Change 6.5.1 stmt.while paragraph 2 as follows:

<blockquote>
The <del>object</del> <ins>variable</ins> created in a condition is
destroyed and created with each iteration of the loop...
</blockquote>

Change 6.6 stmt.jump paragraph 2 as follows:
<blockquote>
On exit from a scope (however accomplished), <del>variables</del>
<ins>objects</ins> with automatic storage duration (3.7.3) that have
been constructed in that scope are destroyed in the reverse order of
their construction. ... Transfer out of a loop, out of a block, or
back past an initialized variable with automatic storage duration
involves the destruction of <del>variables</del> <ins>objects</ins>
with automatic storage duration that are in scope at the point
transferred from but not at the point transferred to. ...
</blockquote>

No change in 6.7 stmt.dcl paragraph 2.
<p>
No change in 6.7 stmt.dcl paragraph 3.
<p>

Change 6.7 stmt.dcl paragraph 4:

<blockquote>
The zero-initialization (8.5 dcl.init) of all local <del>objects</del>
<ins>variables</ins> with static storage duration (3.7.1
basic.stc.static) or thread storage duration (3.7.2 basic.stc.thread)
is performed before any other initialization takes place. ...
  An implementation is permitted to perform early
initialization of other local <del>objects</del> <ins>variables</ins> with
static or thread storage duration under the same conditions that an
implementation is permitted to statically initialize <del>an
object</del> <ins>a variable</ins> with static or thread storage
duration in namespace scope (3.6.2 basic.start.init).  Otherwise such
<del>an object</del> <ins>a variable</ins> is initialized the first
time control passes through its declaration; such an object is
considered initialized upon the completion of its initialization. ...
 If control enters the declaration
concurrently while the <del>object</del> <ins>variable</ins> is being
initialized, the concurrent execution shall wait for completion of the
initialization. [ Footnote: ... ]  If control re-enters the
declaration recursively while the <del>object</del>
<ins>variable</ins> is being initialized, the behavior is undefined.
...
</blockquote>

Change 6.7 stmt.dcl paragraph 5 as follows:
<blockquote>
The destructor for a local object with static or thread storage
duration will be executed if and only if <del>the variable</del>
<ins>it</ins> was constructed. ...
</blockquote>

Change 7.1.1 dcl.stc paragraphs 1-8 as follows:

<blockquote>
... If <code>thread_local</code> appears in any declaration of <del>an
object or reference</del> <ins>a variable</ins> it shall be present in
all declarations of that <del>object or reference</del>
<ins>entity</ins>. ...
<p>
The register specifier shall be applied only to names of
<del>objects</del> <ins>variables</ins>
declared in a block (6.3 stmt.block) or to function
parameters (8.4 dcl.fct.def).  It specifies that the named
<del>object</del> <ins>variable</ins> has
automatic storage duration (3.7.3 basic.stc.auto). <del>An
object</del> <ins>A variable</ins> declared without a
<em>storage-class-specifier</em> at block scope or declared as a
function parameter has automatic storage duration by default.
<p>
A <code>register</code> specifier is a hint to the implementation that
the <del>object</del> <ins>variable</ins> so declared will be heavily
used. [ Note: the hint can be ignored and in most implementations it
will be ignored if the address of the <del>object</del>
<ins>variable</ins> is taken. -- end note ]
<p>
The <code>thread_local</code> specifier shall be applied only to the
names of <del>objects or references</del> <ins>variables</ins> of
namespace scope and to the names of <del>objects or references</del>
<ins>variables</ins> of block scope that also specify <code>static</code>.  It
specifies that the named <del>object or reference</del>
<ins>entity</ins> has thread storage duration (3.7.2
basic.stc.thread).
<p>
The <code>static</code> specifier can be applied only to names of
<del>objects</del> <ins>variables</ins> and functions and to anonymous
unions (9.5 class.union).  There can be no static function
declarations within a block, nor any static function parameters.  A static
specifier used in the declaration of <del>an object</del> <ins>a
variable</ins> declares the <del>object</del> <ins>variable</ins> to
have static storage duration (3.7.1 basic.stc.static), unless
accompanied by the <code>thread_local</code> specifier, which declares
the object to have thread storage duration (3.7.2 basic.stc.thread).
A <code>static</code> specifier can be used in declarations of class
members; 9.4 class.static describes its effect.  For
the linkage of a name declared with a static specifier, see 3.5
basic.link.
<p>
The <code>extern</code> specifier can be applied only to the names of
<del>objects</del> <ins>variables</ins> and functions. The
<code>extern</code> specifier cannot be used in the declaration of
class members or function parameters.  For the linkage of a name declared with
an <code>extern</code> specifier, see 3.5 basic.link. [ Note: The <code>extern</code> keyword can also be used in <em>explicit-instantiations</em> and
<em>linkage-specifications</em>, but it is not a
<em>storage-class-specifier</em> in such contexts. -- end note ]
<p>
A name declared in a namespace scope without a
<em>storage-class-specifier</em> has external linkage unless it has
internal linkage because of a previous declaration and provided it is
not declared <code>const</code>.  Objects declared
<code>const</code> and not explicitly declared <code>extern</code>
have internal linkage.
<p>
The linkages implied by successive declarations for a given entity
shall agree. That is, within a given scope, each declaration declaring
the same <del>object</del> <ins>variable</ins> name or the same
overloading of a function name shall imply the same linkage.  Each
function in a given set of overloaded functions can have a different
linkage, however. ...
</blockquote>

No change required for 7.1.2 dcl.fct.spec paragraph 4:

<blockquote>
A static local variable in an extern inline function always refers to
the same object.
</blockquote>

Change 7.1.6.4 dcl.spec.auto paragraph 1 as follows:
x
<blockquote>
The <code>auto</code> <em>type-specifier</em> signifies that the type
of <del>an object</del> <ins>a variable</ins> being declared shall be
deduced from its initializer or specified explicitly at the end of a
function declarator.
</blockquote>

Change 7.1.6.4 dcl.spec.auto paragraph 3 as follows:

<blockquote>
Otherwise, the type of the <del>object</del> <ins>variable</ins> is
deduced from its initializer.  The name of the <del>object</del>
<ins>variable</ins> being declared shall not appear in the initializer
expression.  This use of <code>auto</code> is allowed when declaring
<del>objects</del> <ins>variables</ins> in a block (6.3 stmt.block),
in namespace scope (3.3.6 basic.scope.namespace), and in a
for-init-statement (6.5.3 stmt.for). ...
</blockquote>

Change 7.1.6.4 dcl.spec.auto paragraph 4 as follows:

<blockquote>
The <code>auto</code> <em>type-specifier</em> can also be used in
declaring <del>an object</del> <ins>a variable</ins> in the
<em>condition</em> of a selection statement...
</blockquote>

Change 7.3.1.1 namespace.unnamed paragraph 2 as follows:

<blockquote>
The use of the <code>static</code> keyword is deprecated when
declaring <del>objects</del> <ins>variables</ins> in a namespace scope
(see annex D depr); the <em>unnamed-namespace</em> provides a superior
alternative.
</blockquote>

Change 7.3.4 namespace.udir paragraph 6 as follows:

<blockquote>
[ Note: in particular, the name of <del>an object</del> <ins>a
variable</ins>, function or enumerator does not hide the name of a
class or enumeration declared in a different namespace. ... ]
</blockquote>

No change in 7.5 dcl.link paragraph 1, effectively expanding language
linkage to (non-member) references.
<p>

No change in 7.6.2 dcl.align paragraph 1, effectively expanding
alignment to non-member references.
<p>

Change 8 dcl.decl paragraph 1 as follows:
<blockquote>
A declarator declares a single <del>object</del> <ins>variable</ins>,
function, or type, within a declaration. ...
</blockquote>

Change 8 dcl.decl paragraph 2 as follows:

<blockquote>
The specifiers indicate the type, storage class or other properties of
the <del>objects, functions or typedefs</del> <ins>entities</ins>
being declared.  The declarators specify the names of these
<del>objects, functions or typedefs</del> <ins>entities</ins>,
and (optionally) modify the type of the specifiers with operators such
as * (pointer to) and () (function returning). ...
</blockquote>

Change 8.1 dcl.name paragraph 1 as follows:

<blockquote>
... This can be done with a <em>type-id</em>, which is syntactically a
declaration for <del>an object</del> <ins>a variable</ins>
or function of that type that omits the name of the <del>object or
function</del> <ins>entity</ins>.
</blockquote>

Change 8.5 dcl.init paragraph 1:
<blockquote>
... The identifier designates <del>an object or reference</del> <ins>a
variable</ins> being initialized. ...
</blockquote>

No change in 8.5 dcl.init paragraph 2.
<p>

Change 8.5 dcl.init paragraphs 4 as follows:

<blockquote>
The order of initialization of <del>static objects</del>
<ins>variables with static storage duration</ins> is described in 3.6
basic.start and 6.7 stmt.dcl. -- end note ]
</blockquote>


No change in 8.5.3 dcl.init.ref paragraph 1.
<p>

Change 9.1 class.name paragraph 2:

<blockquote>
A class declaration introduces the class name into the scope where it
is declared and hides any class, <del>object</del> <ins>variable</ins>,
function, or other declaration of that name in an enclosing scope (3.3
basic.scope).  If a class name is declared in a scope where <del>an
object</del> <ins>a variable</ins>, function, or enumerator of the
same name is also declared, then when both declarations are in scope,
the class can be referred to only using an
<em>elaborated-type-specifier</em> (3.4.4 basic.lookup.elab). ...
</blockquote>

Change 9.4.2 class.static.data paragraph 6 as follows:

<blockquote>
Static data members are initialized and destroyed exactly like
non-local <del>objects</del> <ins>variables</ins> (3.6.2
basic.start.init, 3.6.3 basic.start.term). 
</blockquote>

No change in 9.8 class.local paragraph 1.
<p>
Change 10.2 class.member.lookup paragraph 4 as follows:

<blockquote>
... [ Note: Looking up a name in an <em>elaborated-type-specifier</em>
(3.4.4 basic.lookup.elab) or <em>base-specifier</em> (clause 10
class.derived), for instance, ignores all non-type declarations, while
looking up a name in a <em>nested-name-specifier</em> (3.4.3
basic.lookup.qual) ignores function, <del>object</del>
<ins>variable</ins>, and enumerator declarations. ... 
</blockquote>

No change to 13.4 over.over paragraph 1 bullet 1.
<p>

Change 14 temp paragraph 5 as follows:
<blockquote>
A class template shall not have the same name as any other template,
class, function, <del>object</del> <ins>variable</ins>, reference,
enumeration, enumerator, namespace, or type in the same scope... 
</blockquote>

No change in 14.8 temp.fct.spec paragraph 2.
<p>


Change 15.5.1 except.terminate paragraph 1 bullet 4 as follows:
<blockquote>
<ul>
<li>when <del>construction</del> <ins>initialization</ins> or
destruction of a non-local <del>object</del> <ins>variable</ins>
with static or thread storage duration <ins>(3.6.2 basic.start.init,
3.6.3 basic.start.term)</ins> <del>exits using</del> <ins>terminates
by throwing</ins> an exception <del>(3.6.2 basic.start.init)</del>,
or</li>
</ul>

</blockquote>

</body>
</html>
