[basic] - C++11 → C++14

Files changed (1) hide show

tmp/tmpfp9oq78c/{from.md → to.md} +355 -277

tmp/tmpfp9oq78c/{from.md → to.md} RENAMED Viewed

@@ -25,12 +25,12 @@ A *name* is a use of an *identifier* ([[lex.name]]),
 Every name that denotes an entity is introduced by a *declaration*.
 Every name that denotes a label is introduced either by a `goto`
 statement ([[stmt.goto]]) or a *labeled-statement* ([[stmt.label]]).
 A *variable* is introduced by the declaration of a reference other than
-a non-static data member or of an object. The variable’s name denotes
-the reference or object.
 Some names denote types or templates. In general, whenever a name is
 encountered it is necessary to determine whether that name denotes one
 of these entities before continuing to parse the program that contains
 it. The process that determines this is called *name lookup* (
@@ -39,12 +39,12 @@ it. The process that determines this is called *name lookup* (
 Two names are *the same* if
 - they are *identifier*s composed of the same character sequence, or
 - they are *operator-function-id*s formed with the same operator, or
 - they are *conversion-function-id*s formed with the same type, or
-- they are *template-id*s that refer to the same class or function (
-  [[temp.type]]), or
 - they are the names of literal operators ([[over.literal]]) formed
   with the same literal suffix identifier.
 A name used in more than one translation unit can potentially refer to
 the same entity in these translation units depending on the linkage (
@@ -157,47 +157,81 @@ an incomplete type ([[basic.types]]).
 No translation unit shall contain more than one definition of any
 variable, function, class type, enumeration type, or template.
 An expression is *potentially evaluated* unless it is an unevaluated
-operand (Clause  [[expr]]) or a subexpression thereof. A variable whose
-name appears as a potentially-evaluated expression is *odr-used* unless
-it is an object that satisfies the requirements for appearing in a
-constant expression ([[expr.const]]) and the lvalue-to-rvalue
-conversion ([[conv.lval]]) is immediately applied. `this` is 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 ([[class.mfct.non-static]])). A virtual member function is
-odr-used if it is not pure. A non-overloaded function whose name appears
-as a potentially-evaluated expression or a member of a set of candidate
-functions, if selected by overload resolution when referred to from a
-potentially-evaluated expression, is odr-used, unless it is a pure
-virtual function and its name is not explicitly qualified. This covers
-calls to named functions ([[expr.call]]), operator overloading (Clause
-[[over]]), user-defined conversions ([[class.conv.fct]]), allocation
-function for placement new ([[expr.new]]), as well as non-default
-initialization ([[dcl.init]]). A copy constructor or move constructor
-is odr-used even if the call is actually elided by the implementation.
-An allocation or deallocation function for a class is odr-used by a new
-expression appearing in a potentially-evaluated expression as specified
-in  [[expr.new]] and  [[class.free]]. A deallocation function for a
-class is odr-used by a delete expression appearing in a
-potentially-evaluated expression as specified in  [[expr.delete]] and
-[[class.free]]. A non-placement allocation or deallocation function for
-a class is odr-used by the definition of a constructor of that class. A
-non-placement deallocation function for a class is 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 (
-[[class.dtor]]).[^2] A copy-assignment function for a class is odr-used
-by an implicitly-defined copy-assignment function for another class as
-specified in  [[class.copy]]. A move-assignment function for a class is
-odr-used by an implicitly-defined move-assignment function for another
-class as specified in  [[class.copy]]. A default constructor for a class
-is odr-used by default initialization or value initialization as
-specified in  [[dcl.init]]. A constructor for a class is odr-used as
-specified in  [[dcl.init]]. A destructor for a class is odr-used as
-specified in  [[class.dtor]].
 Every program shall contain exactly one definition of every non-inline
 function or variable that is 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)
@@ -228,12 +262,12 @@ complete class types are required. A class type `T` must be complete if:
   object of type `T` ([[conv.lval]]), or
 - an expression is converted (either implicitly or explicitly) to type
   `T` (Clause  [[conv]], [[expr.type.conv]], [[expr.dynamic.cast]],
   [[expr.static.cast]], [[expr.cast]]), or
 - an expression that is not a null pointer constant, and has type other
-  than `void*`, is converted to the type pointer to `T` or reference to
-  `T` using an implicit conversion (Clause  [[conv]]), a
   `dynamic_cast` ([[expr.dynamic.cast]]) or a `static_cast` (
   [[expr.static.cast]]), or
 - a class member access operator is applied to an expression of type
   `T` ([[expr.ref]]), or
 - the `typeid` operator ([[expr.typeid]]) or the `sizeof` operator (
@@ -265,15 +299,15 @@ unit, then
 - in each definition of `D`, corresponding names, looked up according
   to  [[basic.lookup]], shall refer to an entity defined within the
   definition of `D`, or shall refer to the same entity, after overload
   resolution ([[over.match]]) and after matching of partial template
   specialization ([[temp.over]]), except that a name can refer to a
-  `const` object with internal or no linkage if the object has the same
-  literal type in all definitions of `D`, and the object is initialized
-  with a constant expression ([[expr.const]]), and the value (but not
- the address) of the object is used, and the object has the same value
- in all definitions of `D`; and
 - in each definition of `D`, corresponding entities shall have the same
   language linkage; and
 - in each definition of `D`, the overloaded operators referred to, the
   implicit calls to conversion functions, constructors, operator new
   functions and operator delete functions, shall refer to the same
@@ -313,12 +347,12 @@ unit, then
 If `D` is a template and is defined in more than one translation unit,
 then the preceding requirements shall apply both to names from the
 template’s enclosing scope used in the template definition (
 [[temp.nondep]]), and also to dependent names at the point of
 instantiation ([[temp.dep]]). If the definitions of `D` satisfy all
-these requirements, then the program shall behave as if there were a
-single definition of `D`. If the definitions of `D` do not satisfy these
 requirements, then the behavior is undefined.
 ## Scope <a id="basic.scope">[[basic.scope]]</a>
 ### Declarative regions and scopes <a id="basic.scope.declarative">[[basic.scope.declarative]]</a>
@@ -392,12 +426,12 @@ The name lookup rules are summarized in  [[basic.lookup]].
 The *point of declaration* for a name is immediately after its complete
 declarator (Clause  [[dcl.decl]]) and before its *initializer* (if any),
 except as noted below.
 ``` cpp
-int x = 12;
-{ int x = x; }
 ```
 Here the second `x` is initialized with its own (indeterminate) value.
 a name from an outer scope remains visible up to the point of
@@ -417,10 +451,14 @@ The point of declaration for an enumeration is immediately after the
 *identifier* (if any) in either its *enum-specifier* ([[dcl.enum]]) or
 its first *opaque-enum-declaration* ([[dcl.enum]]), whichever comes
 first. The point of declaration of an alias or alias template
 immediately follows the *type-id* to which the alias refers.
 The point of declaration for an enumerator is immediately after its
 *enumerator-definition*.
 ``` cpp
 const int x = 12;
@@ -492,11 +530,11 @@ block scope and variable declarations with the `extern` specifier at
 block scope refer to declarations that are members of an enclosing
 namespace, but they do not introduce new names into that scope.
 For point of instantiation of a template, see  [[temp.point]].
-### Block scope <a id="basic.scope.local">[[basic.scope.local]]</a>
 A name declared in a block ([[stmt.block]]) is local to that block; it
 has *block scope*. Its potential scope begins at its point of
 declaration ([[basic.scope.pdecl]]) and ends at the end of its block. A
 variable declared at block scope is a *local variable*.
@@ -588,12 +626,12 @@ namespace in a *using-directive;* see  [[namespace.qual]].
 The outermost declarative region of a translation unit is also a
 namespace, called the *global namespace*. A name declared in the global
 namespace has *global namespace scope* (also called *global scope*). The
 potential scope of such a name begins at its point of declaration (
 [[basic.scope.pdecl]]) and ends at the end of the translation unit that
-is its declarative region. Names with global namespace scope are said to
-be *global name*.
 ### Class scope <a id="basic.scope.class">[[basic.scope.class]]</a>
 The following rules describe the scope of names declared in classes.
@@ -814,12 +852,13 @@ void A::N::f() {
   // 4) global scope, before the definition of A::N::f
 }
 ```
 A name used in the definition of a class `X` outside of a member
-function body or nested class definition[^5] shall be declared in one of
-the following ways:
 - before its use in class `X` or be a member of a base class of `X` (
   [[class.member.lookup]]), or
 - if `X` is a nested class of class `Y` ([[class.nest]]), before the
   definition of `X` in `Y`, or shall be a member of a base class of `Y`
@@ -864,15 +903,16 @@ namespace scope are not considered; see  [[namespace.memdef]].
 names in a class definition. [[class.nest]] further describes the
 restrictions on the use of names in nested class definitions.
 [[class.local]] further describes the restrictions on the use of names
 in local class definitions.
-A name used in the definition of a member function ([[class.mfct]]) of
-class `X` following the function’s *declarator-id*[^7] or in the
 *brace-or-equal-initializer* of a non-static data member (
-[[class.mem]]) of class `X` shall be declared in one of the following
-ways:
 - before its use in the block in which it is used or in an enclosing
   block ([[stmt.block]]), or
 - shall be a member of class `X` or be a member of a base class of `X` (
   [[class.member.lookup]]), or
@@ -999,14 +1039,14 @@ The rules for name lookup in template definitions are described in
 ### Argument-dependent name lookup <a id="basic.lookup.argdep">[[basic.lookup.argdep]]</a>
 When the *postfix-expression* in a function call ([[expr.call]]) is an
 *unqualified-id*, other namespaces not considered during the usual
 unqualified lookup ([[basic.lookup.unqual]]) may be searched, and in
-those namespaces, namespace-scope friend function declarations (
-[[class.friend]]) not otherwise visible may be found. These
-modifications to the search depend on the types of the arguments (and
-for template template arguments, the namespace of the template
 argument).
 ``` cpp
 namespace N {
   struct S { };
@@ -1033,23 +1073,23 @@ way:
 - If `T` is a fundamental type, its associated sets of namespaces and
   classes are both empty.
 - If `T` is a class type (including unions), its associated classes are:
   the class itself; the class of which it is a member, if any; and its
   direct and indirect base classes. Its associated namespaces are the
-  namespaces of which its associated classes are members. Furthermore,
   if `T` is a class template specialization, its associated namespaces
   and classes also include: the namespaces and classes associated with
   the types of the template arguments provided for template type
   parameters (excluding template template parameters); the namespaces of
   which any template template arguments are members; and the classes of
   which any member templates used as template template arguments are
   members. Non-type template arguments do not contribute to the set of
   associated namespaces.
 - If `T` is an enumeration type, its associated namespace is the
- namespace in which it is defined. If it is class member, its
-  associated class is the member’s class; else it has no associated
-  class.
 - If `T` is a pointer to `U` or an array of `U`, its associated
   namespaces and classes are those associated with `U`.
 - If `T` is a function type, its associated namespaces and classes are
   those associated with the function parameter types and those
   associated with the return type.
@@ -1226,12 +1266,12 @@ lookup rule above are the following:
   the context in which the entire *postfix-expression* occurs.
 - the lookup for a name specified in a *using-declaration* (
   [[namespace.udecl]]) also finds class or enumeration names hidden
   within the same scope ([[basic.scope.hiding]]).
-In a lookup in which the constructor is an acceptable lookup result and
-the *nested-name-specifier* nominates a class `C`:
 - if the name specified after the *nested-name-specifier*, when looked
   up in `C`, is the injected-class-name of `C` (Clause  [[class]]), or
 - in a *using-declaration* ([[namespace.udecl]]) that is a
   *member-declaration*, if the name specified after the
@@ -1567,16 +1607,15 @@ If the *id-expression* in a class member access ([[expr.ref]]) is an
 *unqualified-id*, and the type of the object expression is of a class
 type `C`, the *unqualified-id* is looked up in the scope of class `C`.
 For a pseudo-destructor call ([[expr.pseudo]]), the *unqualified-id* is
 looked up in the context of the complete *postfix-expression*.
-If the *unqualified-id* is *\textasciitilde{}type-name*, the *type-name*
-is looked up in the context of the entire *postfix-expression*. If the
-type `T` of the object expression is of a class type `C`, the
-*type-name* is also looked up in the scope of class `C`. At least one of
-the lookups shall find a name that refers to (possibly cv-qualified)
-`T`.
 ``` cpp
 struct A { };
 struct B {
@@ -1662,13 +1701,13 @@ introduced by a declaration in another scope:
 A name having namespace scope ([[basic.scope.namespace]]) has internal
 linkage if it is the name of
 - a variable, function or function template that is explicitly declared
   `static`; or,
-- a variable that is explicitly declared `const` or `constexpr` and
-  neither explicitly declared `extern` nor previously declared to have
-  external linkage; or
 - a data member of an anonymous union.
 An unnamed namespace or a namespace declared directly or indirectly
 within an unnamed namespace has internal linkage. All other namespaces
 have external linkage. A name having namespace scope that has not been
@@ -1743,18 +1782,18 @@ namespace X {
 void q() { /* ... */ }         // some other, unrelated q
 ```
 Names not covered by these rules have no linkage. Moreover, except as
-noted, a name declared at block scope ([[basic.scope.local]]) has no
 linkage. A type is said to have linkage if and only if:
 - it is a class or enumeration type that is named (or has a name for
   linkage purposes ([[dcl.typedef]])) and the name has linkage; or
 - it is an unnamed class or enumeration member of a class with linkage;
   or
-- it is a specialization of a class template ([[temp]])[^9]; or
 - it is a fundamental type ([[basic.fundamental]]); or
 - it is a compound type ([[basic.compound]]) other than a class or
   enumeration, compounded exclusively from types that have linkage; or
 - it is a cv-qualified ([[basic.type.qualifier]]) version of a type
   that has linkage.
@@ -1830,37 +1869,33 @@ function. In a freestanding environment, start-up and termination is
 constructors for objects of namespace scope with static storage
 duration; termination contains the execution of destructors for objects
 with static storage duration.
 An implementation shall not predefine the `main` function. This function
-shall not be overloaded. It shall have a return type of type `int`, but
-otherwise its type is *implementation-defined*. All implementations
-shall allow both of the following definitions of `main`:
-``` cpp
-int main() { /* ... */ }
-```
-and
-``` cpp
-int main(int argc, char* argv[]) { /* ... */ }
-```
-In the latter form `argc` shall be the number of arguments passed to the
-program from the environment in which the program is run. If `argc` is
-nonzero these arguments shall be supplied in `argv[0]` through
-`argv[argc-1]` as pointers to the initial characters of null-terminated
-multibyte strings (NTMBS s) ([[multibyte.strings]]) and `argv[0]` shall
-be the pointer to the initial character of a NTMBSthat represents the
-name used to invoke the program or `""`. The value of `argc` shall be
-non-negative. The value of `argv[argc]` shall be 0. It is recommended
-that any further (optional) parameters be added after `argv`.
 The function `main` shall not be used within a program. The linkage (
 [[basic.link]]) of `main` is *implementation-defined*. A program that
-defines `main` as deleted or that declares `main` to be `inline,`
 `static`, or `constexpr` is ill-formed. The name `main` is not otherwise
 reserved. member functions, classes, and enumerations can be called
 `main`, as can entities in other namespaces.
 Terminating the program without leaving the current block (e.g., by
@@ -1890,29 +1925,29 @@ initiation. Non-local variables with thread storage duration are
 initialized as a consequence of thread execution. Within each of these
 phases of initiation, initialization occurs as follows.
 Variables with static storage duration ([[basic.stc.static]]) or thread
 storage duration ([[basic.stc.thread]]) shall be zero-initialized (
-[[dcl.init]]) before any other initialization takes place.
-*Constant initialization* is performed:
 - if each full-expression (including implicit conversions) that appears
   in the initializer of a reference with static or thread storage
   duration is a constant expression ([[expr.const]]) and the reference
   is bound to an lvalue designating an object with static storage
-  duration or to a temporary (see  [[class.temporary]]);
 - if an object with static or thread storage duration is initialized by
-  a constructor call, if the constructor is a `constexpr` constructor,
- if all constructor arguments are constant expressions (including
-  conversions), and if, after function invocation substitution (
-  [[dcl.constexpr]]), every constructor call and full-expression in the
-  *mem-initializer*s and in the *brace-or-equal-initializer*s for
-  non-static data members is a constant expression;
 - if an object with static or thread storage duration is not initialized
-  by a constructor call and if every full-expression that appears in its
-  initializer is a constant expression.
 Together, zero-initialization and constant initialization are called
 *static initialization*; all other initialization is *dynamic
 initialization*. Static initialization shall be performed before any
 dynamic initialization takes place. Dynamic initialization of a
@@ -1970,11 +2005,11 @@ double d1 = fd();   // may be initialized statically or dynamically to 1.0
 It is *implementation-defined* whether the dynamic initialization of a
 non-local variable with static storage duration is done before the first
 statement of `main`. If the initialization is deferred to some point in
 time after the first statement of `main`, it shall occur before the
 first odr-use ([[basic.def.odr]]) of any function or variable defined
-in the same translation unit as the variable to be initialized.[^10]
 ``` cpp
 // - File 1 -
 #include "a.h"
 #include "b.h"
@@ -2175,12 +2210,14 @@ implicitly declared in global scope in each translation unit of a
 program.
 ``` cpp
 void* operator new(std::size_t);
 void* operator new[](std::size_t);
-void operator delete(void*);
-void operator delete[](void*);
 ```
 These implicit declarations introduce only the function names `operator`
 `new`, `operator` `new[]`, `operator` `delete`, and `operator`
 `delete[]`. The implicit declarations do not introduce the names `std`,
@@ -2226,64 +2263,70 @@ storage allocated (until the storage is explicitly deallocated by a call
 to a corresponding deallocation function). Even if the size of the space
 requested is zero, the request can fail. If the request succeeds, the
 value returned shall be a non-null pointer value ([[conv.ptr]]) `p0`
 different from any previously returned value `p1`, unless that value
 `p1` was subsequently passed to an `operator` `delete`. The effect of
-dereferencing a pointer returned as a request for zero size is
-undefined.[^11]
 An allocation function that fails to allocate storage can invoke the
 currently installed new-handler function ([[new.handler]]), if any. A
 program-supplied allocation function can obtain the address of the
 currently installed `new_handler` using the `std::get_new_handler`
 function ([[set.new.handler]]). If an allocation function declared with
 a non-throwing *exception-specification* ([[except.spec]]) fails to
 allocate storage, it shall return a null pointer. Any other allocation
 function that fails to allocate storage shall indicate failure only by
-throwing an exception of a type that would match a handler (
-[[except.handle]]) of type `std::bad_alloc` ([[bad.alloc]]).
 A global allocation function is only called as the result of a new
 expression ([[expr.new]]), or called directly using the function call
 syntax ([[expr.call]]), or called indirectly through calls to the
 functions in the C++standard library. In particular, a global allocation
 function is not called to allocate storage for objects with static
 storage duration ([[basic.stc.static]]), for objects or references with
 thread storage duration ([[basic.stc.thread]]), for objects of type
-`std::type_info` ([[expr.typeid]]), or for the copy of an object thrown
-by a `throw` expression ([[except.throw]]).
 #### Deallocation functions <a id="basic.stc.dynamic.deallocation">[[basic.stc.dynamic.deallocation]]</a>
 Deallocation functions shall be class member functions or global
 functions; a program is ill-formed if deallocation functions are
 declared in a namespace scope other than global scope or declared static
 in global scope.
 Each deallocation function shall return `void` and its first parameter
 shall be `void*`. A deallocation function can have more than one
-parameter. If a class `T` has a member deallocation function named
-`operator` `delete` with exactly one parameter, then that function is a
-usual (non-placement) deallocation function. If class `T` does not
-declare such an `operator` `delete` but does declare a member
-deallocation function named `operator` `delete` with exactly two
-parameters, the second of which has type `std::size_t` (
-[[support.types]]), then this function is a usual deallocation function.
-Similarly, if a class `T` has a member deallocation function named
-`operator` `delete[]` with exactly one parameter, then that function is
-a usual (non-placement) deallocation function. If class `T` does not
-declare such an `operator` `delete[]` but does declare a member
-deallocation function named `operator` `delete[]` with exactly two
-parameters, the second of which has type `std::size_t`, then this
-function is a usual deallocation function. A deallocation function can
-be an instance of a function template. Neither the first parameter nor
-the return type shall depend on a template parameter. That is, a
-deallocation function template shall have a first parameter of type
-`void*` and a return type of `void` (as specified above). A deallocation
-function template shall have two or more function parameters. A template
-instance is never a usual deallocation function, regardless of its
-signature.
 If a deallocation function terminates by throwing an exception, the
 behavior is undefined. The value of the first argument supplied to a
 deallocation function may be a null pointer value; if so, and if the
 deallocation function is one supplied in the standard library, the call
@@ -2299,31 +2342,34 @@ invocation of either `operator` `new[](std::size_t)` or `operator`
 If the argument given to a deallocation function in the standard library
 is a pointer that is not the null pointer value ([[conv.ptr]]), the
 deallocation function shall deallocate the storage referenced by the
 pointer, rendering invalid all pointers referring to any part of the
-*deallocated storage*. The effect of using an invalid pointer value
-(including passing it to a deallocation function) is undefined.[^12]
 #### Safely-derived pointers <a id="basic.stc.dynamic.safety">[[basic.stc.dynamic.safety]]</a>
 A *traceable pointer object* is
 - an object of an object pointer type ([[basic.compound]]), or
 - an object of an integral type that is at least as large as
   `std::intptr_t`, or
-- a sequence of elements in an array of character type, where the size
- and alignment of the sequence match those of some object pointer type.
 A pointer value is a *safely-derived pointer* to a dynamic object only
 if it has an object pointer type and it is one of the following:
 - the value returned by a call to the C++standard library implementation
-  of `::operator new(std::size_t)`;[^13]
 - the result of taking the address of an object (or one of its
-  subobjects) designated by an lvalue resulting from dereferencing a
-  safely-derived pointer value;
 - the result of well-defined pointer arithmetic ([[expr.add]]) using a
   safely-derived pointer value;
 - the result of a well-defined pointer conversion ([[conv.ptr]],
   [[expr.cast]]) of a safely-derived pointer value;
 - the result of a `reinterpret_cast` of a safely-derived pointer value;
@@ -2350,16 +2396,16 @@ at least as large as `std::intptr_t` and it is one of the following:
   `reinterpret_cast<void*>(P)`.
 An implementation may have *relaxed pointer safety*, in which case the
 validity of a pointer value does not depend on whether it is a
 safely-derived pointer value. Alternatively, an implementation may have
-*strict pointer safety*, in which case a pointer value that is not a
-safely-derived pointer value is an invalid pointer value unless the
-referenced complete object is of dynamic storage duration and has
-previously been declared reachable ([[util.dynamic.safety]]). the
-effect of using an invalid pointer value (including passing it to a
-deallocation function) is undefined, see
 [[basic.stc.dynamic.deallocation]]. This is true even if the
 unsafely-derived pointer value might compare equal to some
 safely-derived pointer value. It is implementation defined whether an
 implementation has relaxed or strict pointer safety.
@@ -2414,31 +2460,32 @@ the destructor or if a *delete-expression* ([[expr.delete]]) is not
 used to release the storage, the destructor shall not be implicitly
 called and any program that depends on the side effects produced by the
 destructor has undefined behavior.
 Before the lifetime of an object has started but after the storage which
-the object will occupy has been allocated[^14] or, after the lifetime of
 an object has ended and before the storage which the object occupied is
 reused or released, any pointer that refers to the storage location
 where the object will be or was located may be used but only in limited
 ways. For an object under construction or destruction, see
 [[class.cdtor]]. Otherwise, such a pointer refers to allocated storage (
 [[basic.stc.dynamic.deallocation]]), and using the pointer as if the
-pointer were of type `void*`, is well-defined. Such a pointer may be
-dereferenced but the resulting lvalue may only be used in limited ways,
-as described below. The program has undefined behavior if:
 - the object will be or was of a class type with a non-trivial
   destructor and the pointer is used as the operand of a
   *delete-expression*,
 - the pointer is used to access a non-static data member or call a
   non-static member function of the object, or
 - the pointer is implicitly converted ([[conv.ptr]]) to a pointer to a
-  base class type, or
 - the pointer is used as the operand of a `static_cast` (
-  [[expr.static.cast]]) (except when the conversion is to `void*`, or to
-  `void*` and subsequently to `char*`, or `unsigned` `char*`), or
 - the pointer is used as the operand of a `dynamic_cast` (
   [[expr.dynamic.cast]]).
   ``` cpp
   #include <cstdlib>
@@ -2480,15 +2527,12 @@ undefined behavior if:
 - an lvalue-to-rvalue conversion ([[conv.lval]]) is applied to such a
   glvalue,
 - the glvalue is used to access a non-static data member or call a
   non-static member function of the object, or
-- the glvalue is implicitly converted ([[conv.ptr]]) to a reference to
- a base class type, or
-- the glvalue is used as the operand of a `static_cast` (
-  [[expr.static.cast]]) except when the conversion is ultimately to *cv*
-  `char&` or *cv* `unsigned` `char&`, or
 - the glvalue is used as the operand of a `dynamic_cast` (
   [[expr.dynamic.cast]]) or as the operand of `typeid`.
 If, after the lifetime of an object has ended and before the storage
 which the object occupied is reused or released, a new object is created
@@ -2531,11 +2575,11 @@ started, can be used to manipulate the new object, if:
   ```
 If a program ends the lifetime of an object of type `T` with static (
 [[basic.stc.static]]), thread ([[basic.stc.thread]]), or automatic (
 [[basic.stc.auto]]) storage duration and if `T` has a non-trivial
-destructor,[^15] the program must ensure that an object of the original
 type occupies that same storage location when the implicit destructor
 call takes place; otherwise the behavior of the program is undefined.
 This is true even if the block is exited with an exception.
 ``` cpp
@@ -2583,11 +2627,11 @@ objects ([[intro.object]]), references ([[dcl.ref]]), or functions (
 [[dcl.fct]]).
 For any object (other than a base-class subobject) of trivially copyable
 type `T`, whether or not the object holds a valid value of type `T`, the
 underlying bytes ([[intro.memory]]) making up the object can be copied
-into an array of `char` or `unsigned` `char`.[^16] If the content of the
 array of `char` or `unsigned` `char` is copied back into the object, the
 object shall subsequently hold its original value.
 ``` cpp
 #define N sizeof(T)
@@ -2600,11 +2644,11 @@ std::memcpy(&obj, buf, N);      // at this point, each subobject of obj of scala
 ```
 For any trivially copyable type `T`, if two pointers to `T` point to
 distinct `T` objects `obj1` and `obj2`, where neither `obj1` nor `obj2`
 is a base-class subobject, if the underlying bytes ([[intro.memory]])
-making up `obj1` are copied into `obj2`,[^17] `obj2` shall subsequently
 hold the same value as `obj1`.
 ``` cpp
 T* t1p;
 T* t2p;
@@ -2618,28 +2662,29 @@ The *object representation* of an object of type `T` is the sequence of
 *N* `unsigned` `char` objects taken up by the object of type `T`, where
 *N* equals `sizeof(T)`. The *value representation* of an object is the
 set of bits that hold the value of type `T`. For trivially copyable
 types, the value representation is a set of bits in the object
 representation that determines a *value*, which is one discrete element
-of an *implementation-defined* set of values.[^18]
-A class that has been declared but not defined, or an array of unknown
-size or of incomplete element type, is an incompletely-defined object
-type.[^19] Incompletely-defined object types and the void types are
-incomplete types ([[basic.fundamental]]). Objects shall not be defined
-to have an incomplete type.
 A class type (such as “`class X`”) might be incomplete at one point in a
 translation unit and complete later on; the type “`class X`” is the same
 type at both points. The declared type of an array object might be an
 array of incomplete class type and therefore incomplete; if the class
 type is completed later on in the translation unit, the array type
 becomes complete; the array type at those two points is the same type.
 The declared type of an array object might be an array of unknown size
 and therefore be incomplete at one point in a translation unit and
 complete later on; the array types at those two points (“array of
-unknown bound of `T`” and “array of N `T`”) are different types. The
 type of a pointer to array of unknown size, or of a type defined by a
 `typedef` declaration to be an array of unknown size, cannot be
 completed.
 ``` cpp
@@ -2678,37 +2723,35 @@ Arithmetic types ([[basic.fundamental]]), enumeration types, pointer
 types, pointer to member types ([[basic.compound]]), `std::nullptr_t`,
 and cv-qualified versions of these types ([[basic.type.qualifier]]) are
 collectively called *scalar types*. Scalar types, POD classes (Clause
 [[class]]), arrays of such types and *cv-qualified* versions of these
 types ([[basic.type.qualifier]]) are collectively called *POD types*.
-Scalar types, trivially copyable class types (Clause  [[class]]), arrays
-of such types, and cv-qualified versions of these types (
-[[basic.type.qualifier]]) are collectively called *trivially copyable
-types*. Scalar types, trivial class types (Clause  [[class]]), arrays of
-such types and cv-qualified versions of these types (
-[[basic.type.qualifier]]) are collectively called *trivial types*.
-Scalar types, standard-layout class types (Clause  [[class]]), arrays of
-such types and cv-qualified versions of these types (
 [[basic.type.qualifier]]) are collectively called *standard-layout
 types*.
 A type is a *literal type* if it is:
 - a scalar type; or
-- a reference type referring to a literal type; or
 - an array of literal type; or
 - a class type (Clause  [[class]]) that has all of the following
   properties:
   - it has a trivial destructor,
-  - every constructor call and full-expression in the
-    *brace-or-equal-initializer*s for non-static data members (if any)
-    is a constant expression ([[expr.const]]),
   - it is an aggregate type ([[dcl.init.aggr]]) or has at least one
     `constexpr` constructor or constructor template that is not a copy
     or move constructor, and
-  - all of its non-static data members and base classes are of literal
-    types.
 If two types `T1` and `T2` are the same type, then `T1` and `T2` are
 *layout-compatible* types. Layout-compatible enumerations are described
 in  [[dcl.enum]]. Layout-compatible standard-layout structs and
 standard-layout unions are described in  [[class.mem]].
@@ -2720,38 +2763,43 @@ any member of the implementation’s basic character set. If a character
 from this set is stored in a character object, the integral value of
 that character object is equal to the value of the single character
 literal form of that character. It is *implementation-defined* whether a
 `char` object can hold negative values. Characters can be explicitly
 declared `unsigned` or `signed`. Plain `char`, `signed char`, and
-`unsigned char` are three distinct types. A `char`, a `signed char`, and
-an `unsigned char` occupy the same amount of storage and have the same
-alignment requirements ([[basic.align]]); that is, they have the same
-object representation. For character types, all bits of the object
 representation participate in the value representation. For unsigned
-character types, all possible bit patterns of the value representation
-represent numbers. These requirements do not hold for other types. In
-any particular implementation, a plain `char` object can take on either
-the same values as a `signed char` or an `unsigned
-char`; which one is *implementation-defined*.
 There are five *standard signed integer types* : “`signed char`”,
 “`short int`”, “`int`”, “`long int`”, and “`long` `long` `int`”. In this
 list, each type provides at least as much storage as those preceding it
 in the list. There may also be *implementation-defined* *extended signed
 integer types*. The standard and extended signed integer types are
 collectively called *signed integer types*. Plain `int`s have the
 natural size suggested by the architecture of the execution
-environment[^20]; the other signed integer types are provided to meet
 special needs.
 For each of the standard signed integer types, there exists a
 corresponding (but different) *standard unsigned integer type*:
 “`unsigned char`”, “`unsigned short int`”, “`unsigned int`”,
 “`unsigned long int`”, and “`unsigned` `long` `long` `int`”, each of
 which occupies the same amount of storage and has the same alignment
 requirements ([[basic.align]]) as the corresponding signed integer
-type[^21]; that is, each signed integer type has the same object
 representation as its corresponding unsigned integer type. Likewise, for
 each of the extended signed integer types there exists a corresponding
 *extended unsigned integer type* with the same amount of storage and
 alignment requirements. The standard and extended unsigned integer types
 are collectively called *unsigned integer types*. The range of
@@ -2759,34 +2807,36 @@ non-negative values of a *signed integer* type is a subrange of the
 corresponding *unsigned integer* type, and the value representation of
 each corresponding signed/unsigned type shall be the same. The standard
 signed integer types and standard unsigned integer types are
 collectively called the *standard integer types*, and the extended
 signed integer types and extended unsigned integer types are
-collectively called the *extended integer types*.
-Unsigned integers, declared `unsigned`, shall obey the laws of
-arithmetic modulo 2ⁿ where n is the number of bits in the value
-representation of that particular size of integer.[^22]
 Type `wchar_t` is a distinct type whose values can represent distinct
 codes for all members of the largest extended character set specified
 among the supported locales ([[locale]]). Type `wchar_t` shall have the
 same size, signedness, and alignment requirements ([[basic.align]]) as
 one of the other integral types, called its *underlying type*. Types
 `char16_t` and `char32_t` denote distinct types with the same size,
 signedness, and alignment as `uint_least16_t` and `uint_least32_t`,
-respectively, in `<stdint.h>`, called the underlying types.
-Values of type `bool` are either `true` or `false`.[^23] There are no
 `signed`, `unsigned`, `short`, or `long bool` types or values. Values of
 type `bool` participate in integral promotions ([[conv.prom]]).
 Types `bool`, `char`, `char16_t`, `char32_t`, `wchar_t`, and the signed
 and unsigned integer types are collectively called *integral*
-types.[^24] A synonym for integral type is *integer type*. The
 representations of integral types shall define values by use of a pure
-binary numeration system.[^25] this International Standard permits 2’s
 complement, 1’s complement and signed magnitude representations for
 integral types.
 There are three *floating point* types: `float`, `double`, and
 `long double`. The type `double` provides at least as much precision as
@@ -2806,13 +2856,13 @@ incomplete type that cannot be completed. It is used as the return type
 for functions that do not return a value. Any expression can be
 explicitly converted to type *cv* `void` ([[expr.cast]]). An expression
 of type `void` shall be used only as an expression statement (
 [[stmt.expr]]), as an operand of a comma expression ([[expr.comma]]),
 as a second or third operand of `?:` ([[expr.cond]]), as the operand of
-`typeid` or `decltype`, as the expression in a return statement (
-[[stmt.return]]) for a function with the return type `void`, or as the
-operand of an explicit conversion to type cv `void`.
 A value of type `std::nullptr_t` is a null pointer constant (
 [[conv.ptr]]). Such values participate in the pointer and the pointer to
 member conversions ([[conv.ptr]], [[conv.mem]]).
 `sizeof(std::nullptr_t)` shall be equal to `sizeof(void*)`.
@@ -2841,16 +2891,18 @@ Compound types can be constructed in the following ways:
 - *unions*, which are classes capable of containing objects of different
   types at different times,  [[class.union]];
 - *enumerations*, which comprise a set of named constant values. Each
   distinct enumeration constitutes a different *enumerated type*,
   [[dcl.enum]];
-- *pointers to non-static* [^26] *class members*, which identify members
   of a given type within objects of a given class,  [[dcl.mptr]].
 These methods of constructing types can be applied recursively;
 restrictions are mentioned in  [[dcl.ptr]], [[dcl.array]], [[dcl.fct]],
-and  [[dcl.ref]].
 The type of a pointer to `void` or a pointer to an object type is called
 an *object pointer type*. A pointer to `void` does not have a
 pointer-to-object type, however, because `void` is not an object type.
 The type of a pointer that can designate a function is called a
@@ -2894,32 +2946,33 @@ A type mentioned in  [[basic.fundamental]] and  [[basic.compound]] is a
 *cv-unqualified type*. Each type which is a cv-unqualified complete or
 incomplete object type or is `void` ([[basic.types]]) has three
 corresponding cv-qualified versions of its type: a *const-qualified*
 version, a *volatile-qualified* version, and a
 *const-volatile-qualified* version. The term *object type* (
-[[intro.object]]) includes the cv-qualifiers specified when the object
-is created. The presence of a `const` specifier in a
-*decl-specifier-seq* declares an object of *const-qualified object
-type*; such object is called a *const object*. The presence of a
-`volatile` specifier in a *decl-specifier-seq* declares an object of
-*volatile-qualified* *object type*; such object is called a *volatile
-object*. The presence of both *cv-qualifiers* in a *decl-specifier-seq*
-declares an object of *const-volatile-qualified object type*; such
-object is called a *const volatile object*. The cv-qualified or
-cv-unqualified versions of a type are distinct types; however, they
-shall have the same representation and alignment requirements (
-[[basic.types]]).[^27]
 A compound type ([[basic.compound]]) is not cv-qualified by the
 cv-qualifiers (if any) of the types from which it is compounded. Any
 cv-qualifiers applied to an array type affect the array element type,
 not the array type ([[dcl.array]]).
-Each non-static, non-mutable, non-reference data member of a
-const-qualified class object is const-qualified, each non-static,
-non-reference data member of a volatile-qualified class object is
-volatile-qualified and similarly for members of a const-volatile class.
 See  [[dcl.fct]] and  [[class.this]] regarding function types that have
 *cv-qualifier*s.
 There is a partial ordering on cv-qualifiers, so that a type can be said
 to be *more cv-qualified* than another. Table
@@ -2941,13 +2994,22 @@ In this International Standard, the notation *cv* (or *cv1*, *cv2*,
 etc.), used in the description of types, represents an arbitrary set of
 cv-qualifiers, i.e., one of {`const`}, {`volatile`}, {`const`,
 `volatile`}, or the empty set. Cv-qualifiers applied to an array type
 attach to the underlying element type, so the notation “*cv* `T`,” where
 `T` is an array type, refers to an array whose elements are
-so-qualified. Such array types can be said to be more (or less)
-cv-qualified than other types based on the cv-qualification of the
-underlying element types.
 ## Lvalues and rvalues <a id="basic.lval">[[basic.lval]]</a>
 Expressions are categorized according to the taxonomy in Figure
 [[fig:categories]].
@@ -2964,11 +3026,12 @@ Expressions are categorized according to the taxonomy in Figure
   return type is an lvalue reference is an lvalue.
 - An *xvalue* (an “eXpiring” value) also refers to an object, usually
   near the end of its lifetime (so that its resources may be moved, for
   example). An xvalue is the result of certain kinds of expressions
   involving rvalue references ([[dcl.ref]]). The result of calling a
-  function whose return type is an rvalue reference is an xvalue.
 - A *glvalue* (“generalized” lvalue) is an lvalue or an xvalue.
 - An *rvalue* (so called, historically, because rvalues could appear on
   the right-hand side of an assignment expression) is an xvalue, a
   temporary object ([[class.temporary]]) or subobject thereof, or a
   value that is not associated with an object.
@@ -2995,14 +3058,15 @@ is not such a context; see  [[dcl.init.ref]].
 The discussion of reference initialization in  [[dcl.init.ref]] and of
 temporaries in  [[class.temporary]] indicates the behavior of lvalues
 and rvalues in other significant contexts.
-Class prvalues can have cv-qualified types; non-class prvalues always
-have cv-unqualified types. Unless otherwise indicated ([[expr.call]]),
-prvalues shall always have complete types or the `void` type; in
-addition to these types, glvalues can also have incomplete types.
 An lvalue for an object is necessary in order to modify the object
 except that an rvalue of class type can also be used to modify its
 referent under certain circumstances. a member function called for an
 object ([[class.mfct]]) can modify the object.
@@ -3023,11 +3087,11 @@ the expression is called *modifiable*. A program that attempts to modify
 an object through a nonmodifiable lvalue or rvalue expression is
 ill-formed.
 If a program attempts to access the stored value of an object through a
 glvalue of other than one of the following types the behavior is
-undefined:[^28]
 - the dynamic type of the object,
 - a cv-qualified version of the dynamic type of the object,
 - a type similar (as defined in  [[conv.qual]]) to the dynamic type of
   the object,
@@ -3092,14 +3156,14 @@ Alignments have an order from *weaker* to *stronger* or *stricter*
 alignments. Stricter alignments have larger alignment values. An address
 that satisfies an alignment requirement also satisfies any weaker valid
 alignment requirement.
 The alignment requirement of a complete type can be queried using an
-`alignof` expression ([[expr.alignof]]). Furthermore, the types `char`,
-`signed char`, and `unsigned char` shall have the weakest alignment
-requirement. This enables the character types to be used as the
-underlying type for an aligned memory area ([[dcl.align]]).
 Comparing alignments is meaningful and provides the obvious results:
 - Two alignments are equal when their numeric values are equal.
 - Two alignments are different when their numeric values are not equal.
@@ -3136,15 +3200,15 @@ allocation failure.
 [basic.lookup.udir]: #basic.lookup.udir
 [basic.lookup.unqual]: #basic.lookup.unqual
 [basic.lval]: #basic.lval
 [basic.namespace]: dcl.md#basic.namespace
 [basic.scope]: #basic.scope
 [basic.scope.class]: #basic.scope.class
 [basic.scope.declarative]: #basic.scope.declarative
 [basic.scope.enum]: #basic.scope.enum
 [basic.scope.hiding]: #basic.scope.hiding
-[basic.scope.local]: #basic.scope.local
 [basic.scope.namespace]: #basic.scope.namespace
 [basic.scope.pdecl]: #basic.scope.pdecl
 [basic.scope.proto]: #basic.scope.proto
 [basic.scope.temp]: #basic.scope.temp
 [basic.start]: #basic.start
@@ -3187,18 +3251,18 @@ allocation failure.
 [class.this]: class.md#class.this
 [class.union]: class.md#class.union
 [conv]: conv.md#conv
 [conv.array]: conv.md#conv.array
 [conv.func]: conv.md#conv.func
 [conv.lval]: conv.md#conv.lval
 [conv.mem]: conv.md#conv.mem
 [conv.prom]: conv.md#conv.prom
 [conv.ptr]: conv.md#conv.ptr
 [conv.qual]: conv.md#conv.qual
 [dcl.align]: dcl.md#dcl.align
 [dcl.array]: dcl.md#dcl.array
-[dcl.constexpr]: dcl.md#dcl.constexpr
 [dcl.dcl]: dcl.md#dcl.dcl
 [dcl.decl]: dcl.md#dcl.decl
 [dcl.enum]: dcl.md#dcl.enum
 [dcl.fct]: dcl.md#dcl.fct
 [dcl.fct.def]: dcl.md#dcl.fct.def
@@ -3207,17 +3271,20 @@ allocation failure.
 [dcl.init]: dcl.md#dcl.init
 [dcl.init.aggr]: dcl.md#dcl.init.aggr
 [dcl.init.ref]: dcl.md#dcl.init.ref
 [dcl.link]: dcl.md#dcl.link
 [dcl.mptr]: dcl.md#dcl.mptr
 [dcl.ptr]: dcl.md#dcl.ptr
 [dcl.ref]: dcl.md#dcl.ref
 [dcl.stc]: dcl.md#dcl.stc
 [dcl.type.cv]: dcl.md#dcl.type.cv
 [dcl.type.elab]: dcl.md#dcl.type.elab
 [dcl.type.simple]: dcl.md#dcl.type.simple
 [dcl.typedef]: dcl.md#dcl.typedef
 [except]: except.md#except
 [except.handle]: except.md#except.handle
 [except.spec]: except.md#except.spec
 [except.terminate]: except.md#except.terminate
 [except.throw]: except.md#except.throw
@@ -3230,12 +3297,14 @@ allocation failure.
 [expr.comma]: expr.md#expr.comma
 [expr.cond]: expr.md#expr.cond
 [expr.const]: expr.md#expr.const
 [expr.delete]: expr.md#expr.delete
 [expr.dynamic.cast]: expr.md#expr.dynamic.cast
 [expr.new]: expr.md#expr.new
 [expr.prim]: expr.md#expr.prim
 [expr.pseudo]: expr.md#expr.pseudo
 [expr.ref]: expr.md#expr.ref
 [expr.sizeof]: expr.md#expr.sizeof
 [expr.static.cast]: expr.md#expr.static.cast
 [expr.type.conv]: expr.md#expr.type.conv
@@ -3262,10 +3331,11 @@ allocation failure.
 [over]: over.md#over
 [over.literal]: over.md#over.literal
 [over.load]: over.md#over.load
 [over.match]: over.md#over.match
 [over.oper]: over.md#over.oper
 [ptr.align]: utilities.md#ptr.align
 [replacement.functions]: library.md#replacement.functions
 [set.new.handler]: language.md#set.new.handler
 [stmt.block]: stmt.md#stmt.block
 [stmt.dcl]: stmt.md#stmt.dcl
@@ -3324,93 +3394,101 @@ allocation failure.
 [^6]: This lookup applies whether the definition of `X` is nested within
     `Y`’s definition or whether `X`’s definition appears in a namespace
     scope enclosing `Y` ’s definition ([[class.nest]]).
 [^7]: That is, an unqualified name that occurs, for instance, in a type
- or default argument in the *parameter-declaration-clause* or in the
- function body.
 [^8]: This lookup applies whether the member function is defined within
     the definition of class `X` or whether the member function is
     defined in a namespace scope enclosing `X`’s definition.
-[^9]: A class template always has external linkage, and the requirements
- of  [[temp.arg.type]] and  [[temp.arg.nontype]] ensure that the
- template arguments will also have appropriate linkage.
-[^10]: A non-local variable with static storage duration having
     initialization with side-effects must be initialized even if it is
     not odr-used ([[basic.def.odr]],  [[basic.stc.static]]).
-[^11]: The intent is to have `operator new()` implementable by calling
     `std::malloc()` or `std::calloc()`, so the rules are substantially
     the same. C++differs from C in requiring a zero request to return a
     non-null pointer.
-[^12]: On some implementations, it causes a system-generated runtime
- fault.
-[^13]: This section does not impose restrictions on dereferencing
     pointers to memory not allocated by `::operator new`. This maintains
     the ability of many C++implementations to use binary libraries and
     components written in other languages. In particular, this applies
-    to C binaries, because dereferencing pointers to memory allocated by
-    `malloc` is not restricted.
-[^14]: For example, before the construction of a global object of
     non-POD class type ([[class.cdtor]]).
-[^15]: That is, an object for which a destructor will be called
     implicitly—upon exit from the block for an object with automatic
     storage duration, upon exit from the thread for an object with
     thread storage duration, or upon exit from the program for an object
     with static storage duration.
-[^16]: By using, for example, the library functions ([[headers]])
     `std::memcpy` or `std::memmove`.
-[^17]: By using, for example, the library functions ([[headers]])
     `std::memcpy` or `std::memmove`.
-[^18]: The intent is that the memory model of C++is compatible with that
     of ISO/IEC 9899 Programming Language C.
-[^19]: The size and layout of an instance of an incompletely-defined
     object type is unknown.
-[^20]: that is, large enough to contain any value in the range of
     `INT_MIN` and `INT_MAX`, as defined in the header `<climits>`.
-[^21]: See  [[dcl.type.simple]] regarding the correspondence between
     types and the sequences of *type-specifier*s that designate them.
-[^22]: This implies that unsigned arithmetic does not overflow because a
     result that cannot be represented by the resulting unsigned integer
     type is reduced modulo the number that is one greater than the
     largest value that can be represented by the resulting unsigned
     integer type.
-[^23]: Using a `bool` value in ways described by this International
     Standard as “undefined,” such as by examining the value of an
     uninitialized automatic object, might cause it to behave as if it is
     neither `true` nor `false`.
-[^24]: Therefore, enumerations ([[dcl.enum]]) are not integral;
     however, enumerations can be promoted to integral types as specified
     in  [[conv.prom]].
-[^25]: A positional representation for integers that uses the binary
     digits 0 and 1, in which the values represented by successive bits
     are additive, begin with 1, and are multiplied by successive
     integral power of 2, except perhaps for the bit with the highest
     position. (Adapted from the *American National Dictionary for
     Information Processing Systems*.)
-[^26]: Static class members are objects or functions, and pointers to
     them are ordinary pointers to objects or functions.
-[^27]: The same representation and alignment requirements are meant to
     imply interchangeability as arguments to functions, return values
     from functions, and non-static data members of unions.
-[^28]: The intent of this list is to specify those circumstances in
     which an object may or may not be aliased.

 Every name that denotes an entity is introduced by a *declaration*.
 Every name that denotes a label is introduced either by a `goto`
 statement ([[stmt.goto]]) or a *labeled-statement* ([[stmt.label]]).
 A *variable* is introduced by the declaration of a reference other than
+a non-static data member or of an object. The variable’s name, if any,
+denotes the reference or object.
 Some names denote types or templates. In general, whenever a name is
 encountered it is necessary to determine whether that name denotes one
 of these entities before continuing to parse the program that contains
 it. The process that determines this is called *name lookup* (
 Two names are *the same* if
 - they are *identifier*s composed of the same character sequence, or
 - they are *operator-function-id*s formed with the same operator, or
 - they are *conversion-function-id*s formed with the same type, or
+- they are *template-id*s that refer to the same class, function, or
+ variable ([[temp.type]]), or
 - they are the names of literal operators ([[over.literal]]) formed
   with the same literal suffix identifier.
 A name used in more than one translation unit can potentially refer to
 the same entity in these translation units depending on the linkage (
 No translation unit shall contain more than one definition of any
 variable, function, class type, enumeration type, or template.
 An expression is *potentially evaluated* unless it is an unevaluated
+operand (Clause  [[expr]]) or a subexpression thereof. The set of
+*potential results* of an expression `e` is defined as follows:
+- If `e` is an *id-expression* ([[expr.prim.general]]), the set
+  contains only `e`.
+- If `e` is a class member access expression ([[expr.ref]]), the set
+  contains the potential results of the object expression.
+- If `e` is a pointer-to-member expression ([[expr.mptr.oper]]) whose
+  second operand is a constant expression, the set contains the
+  potential results of the object expression.
+- If `e` has the form `(e1)`, the set contains the potential results of
+  `e1`.
+- If `e` is a glvalue conditional expression ([[expr.cond]]), the set
+  is the union of the sets of potential results of the second and third
+  operands.
+- If `e` is a comma expression ([[expr.comma]]), the set contains the
+  potential results of the right operand.
+- Otherwise, the set is empty.
+This set is a (possibly-empty) set of *id-expression*s, each of which is
+either `e` or a subexpression of `e`. In the following example, the set
+of potential results of the initializer of `n` contains the first `S::x`
+subexpression, but not the second `S::x` subexpression.
+``` cpp
+struct S { static const int x = 0; };
+const int &f(const int &r);
+int n = b ? (1, S::x)  // S::x is not odr-used here
+          : f(S::x);   // S::x is odr-used here, so
+                       // a definition is required
+```
+A variable `x` whose name appears as a potentially-evaluated expression
+`ex` is *odr-used* by `ex` unless applying the lvalue-to-rvalue
+conversion ([[conv.lval]]) to `x` yields a constant expression (
+[[expr.const]]) that does not invoke any non-trivial functions and, if
+`x` is an object, `ex` is an element of the set of potential results of
+an expression `e`, where either the lvalue-to-rvalue conversion (
+[[conv.lval]]) is applied to `e`, or `e` is a discarded-value
+expression (Clause [[expr]]). `this` is 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 (
+[[class.mfct.non-static]])). A virtual member function is odr-used if it
+is not pure. 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 ([[basic.lookup]],
+[[over.match]], [[over.over]]), unless it is a pure virtual function and
+its name is not explicitly qualified. This covers calls to named
+functions ([[expr.call]]), operator overloading (Clause  [[over]]),
+user-defined conversions ([[class.conv.fct]]), allocation function for
+placement new ([[expr.new]]), as well as non-default initialization (
+[[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 ([[class.copy]]). An allocation or deallocation function
+for a class is odr-used by a new expression appearing in a
+potentially-evaluated expression as specified in  [[expr.new]] and
+[[class.free]]. A deallocation function for a class is odr-used by a
+delete expression appearing in a potentially-evaluated expression as
+specified in  [[expr.delete]] and  [[class.free]]. A non-placement
+allocation or deallocation function for a class is odr-used by the
+definition of a constructor of that class. A non-placement deallocation
+function for a class is 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 ([[class.dtor]]).[^2] An assignment
+operator function in a class is odr-used by an implicitly-defined
+copy-assignment or move-assignment function for another class as
+specified in  [[class.copy]]. A default constructor for a class is
+odr-used by default initialization or value initialization as specified
+in  [[dcl.init]]. A constructor for a class is odr-used as specified in
+[[dcl.init]]. A destructor for a class is odr-used if it is potentially
+invoked ([[class.dtor]]).
 Every program shall contain exactly one definition of every non-inline
 function or variable that is 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)
   object of type `T` ([[conv.lval]]), or
 - an expression is converted (either implicitly or explicitly) to type
   `T` (Clause  [[conv]], [[expr.type.conv]], [[expr.dynamic.cast]],
   [[expr.static.cast]], [[expr.cast]]), or
 - an expression that is not a null pointer constant, and has type other
+  than *cv* `void*`, is converted to the type pointer to `T` or
+ reference to `T` using a standard conversion (Clause  [[conv]]), a
   `dynamic_cast` ([[expr.dynamic.cast]]) or a `static_cast` (
   [[expr.static.cast]]), or
 - a class member access operator is applied to an expression of type
   `T` ([[expr.ref]]), or
 - the `typeid` operator ([[expr.typeid]]) or the `sizeof` operator (
 - in each definition of `D`, corresponding names, looked up according
   to  [[basic.lookup]], shall refer to an entity defined within the
   definition of `D`, or shall refer to the same entity, after overload
   resolution ([[over.match]]) and after matching of partial template
   specialization ([[temp.over]]), except that a name can refer to a
+ non-volatile `const` object with internal or no linkage if the object
+ has the same literal type in all definitions of `D`, and the object is
+ initialized with a constant expression ([[expr.const]]), and the
+  object is not odr-used, and the object has the same value in all
+  definitions of `D`; and
 - in each definition of `D`, corresponding entities shall have the same
   language linkage; and
 - in each definition of `D`, the overloaded operators referred to, the
   implicit calls to conversion functions, constructors, operator new
   functions and operator delete functions, shall refer to the same
 If `D` is a template and is defined in more than one translation unit,
 then the preceding requirements shall apply both to names from the
 template’s enclosing scope used in the template definition (
 [[temp.nondep]]), and also to dependent names at the point of
 instantiation ([[temp.dep]]). If the definitions of `D` satisfy all
+these requirements, then the behavior is as if there were a single
+definition of `D`. If the definitions of `D` do not satisfy these
 requirements, then the behavior is undefined.
 ## Scope <a id="basic.scope">[[basic.scope]]</a>
 ### Declarative regions and scopes <a id="basic.scope.declarative">[[basic.scope.declarative]]</a>
 The *point of declaration* for a name is immediately after its complete
 declarator (Clause  [[dcl.decl]]) and before its *initializer* (if any),
 except as noted below.
 ``` cpp
+unsigned char x = 12;
+{ unsigned char x = x; }
 ```
 Here the second `x` is initialized with its own (indeterminate) value.
 a name from an outer scope remains visible up to the point of
 *identifier* (if any) in either its *enum-specifier* ([[dcl.enum]]) or
 its first *opaque-enum-declaration* ([[dcl.enum]]), whichever comes
 first. The point of declaration of an alias or alias template
 immediately follows the *type-id* to which the alias refers.
+The point of declaration of a *using-declaration* that does not name a
+constructor is immediately after the *using-declaration* (
+[[namespace.udecl]]).
 The point of declaration for an enumerator is immediately after its
 *enumerator-definition*.
 ``` cpp
 const int x = 12;
 block scope refer to declarations that are members of an enclosing
 namespace, but they do not introduce new names into that scope.
 For point of instantiation of a template, see  [[temp.point]].
+### Block scope <a id="basic.scope.block">[[basic.scope.block]]</a>
 A name declared in a block ([[stmt.block]]) is local to that block; it
 has *block scope*. Its potential scope begins at its point of
 declaration ([[basic.scope.pdecl]]) and ends at the end of its block. A
 variable declared at block scope is a *local variable*.
 The outermost declarative region of a translation unit is also a
 namespace, called the *global namespace*. A name declared in the global
 namespace has *global namespace scope* (also called *global scope*). The
 potential scope of such a name begins at its point of declaration (
 [[basic.scope.pdecl]]) and ends at the end of the translation unit that
+is its declarative region. A name with global namespace scope is said to
+be a *global name*.
 ### Class scope <a id="basic.scope.class">[[basic.scope.class]]</a>
 The following rules describe the scope of names declared in classes.
   // 4) global scope, before the definition of A::N::f
 }
 ```
 A name used in the definition of a class `X` outside of a member
+function body, default argument, *exception-specification*,
+*brace-or-equal-initializer* of a non-static data member, or nested
+class definition[^5] shall be declared in one of the following ways:
 - before its use in class `X` or be a member of a base class of `X` (
   [[class.member.lookup]]), or
 - if `X` is a nested class of class `Y` ([[class.nest]]), before the
   definition of `X` in `Y`, or shall be a member of a base class of `Y`
 names in a class definition. [[class.nest]] further describes the
 restrictions on the use of names in nested class definitions.
 [[class.local]] further describes the restrictions on the use of names
 in local class definitions.
+For the members of a class `X`, a name used in a member function body,
+in a default argument, in an *exception-specification*, in the
 *brace-or-equal-initializer* of a non-static data member (
+[[class.mem]]), or in the definition of a class member outside of the
+definition of `X`, following the member’s *declarator-id*[^7], shall be
+declared in one of the following ways:
 - before its use in the block in which it is used or in an enclosing
   block ([[stmt.block]]), or
 - shall be a member of class `X` or be a member of a base class of `X` (
   [[class.member.lookup]]), or
 ### Argument-dependent name lookup <a id="basic.lookup.argdep">[[basic.lookup.argdep]]</a>
 When the *postfix-expression* in a function call ([[expr.call]]) is an
 *unqualified-id*, other namespaces not considered during the usual
 unqualified lookup ([[basic.lookup.unqual]]) may be searched, and in
+those namespaces, namespace-scope friend function or function template
+declarations ([[class.friend]]) not otherwise visible may be found.
+These modifications to the search depend on the types of the arguments
+(and for template template arguments, the namespace of the template
 argument).
 ``` cpp
 namespace N {
   struct S { };
 - If `T` is a fundamental type, its associated sets of namespaces and
   classes are both empty.
 - If `T` is a class type (including unions), its associated classes are:
   the class itself; the class of which it is a member, if any; and its
   direct and indirect base classes. Its associated namespaces are the
+ innermost enclosing namespaces of its associated classes. Furthermore,
   if `T` is a class template specialization, its associated namespaces
   and classes also include: the namespaces and classes associated with
   the types of the template arguments provided for template type
   parameters (excluding template template parameters); the namespaces of
   which any template template arguments are members; and the classes of
   which any member templates used as template template arguments are
   members. Non-type template arguments do not contribute to the set of
   associated namespaces.
 - If `T` is an enumeration type, its associated namespace is the
+ innermost enclosing namespace of its declaration. If it is a class
+ member, its associated class is the member’s class; else it has no
+ associated class.
 - If `T` is a pointer to `U` or an array of `U`, its associated
   namespaces and classes are those associated with `U`.
 - If `T` is a function type, its associated namespaces and classes are
   those associated with the function parameter types and those
   associated with the return type.
   the context in which the entire *postfix-expression* occurs.
 - the lookup for a name specified in a *using-declaration* (
   [[namespace.udecl]]) also finds class or enumeration names hidden
   within the same scope ([[basic.scope.hiding]]).
+In a lookup in which function names are not ignored[^9] and the
+*nested-name-specifier* nominates a class `C`:
 - if the name specified after the *nested-name-specifier*, when looked
   up in `C`, is the injected-class-name of `C` (Clause  [[class]]), or
 - in a *using-declaration* ([[namespace.udecl]]) that is a
   *member-declaration*, if the name specified after the
 *unqualified-id*, and the type of the object expression is of a class
 type `C`, the *unqualified-id* is looked up in the scope of class `C`.
 For a pseudo-destructor call ([[expr.pseudo]]), the *unqualified-id* is
 looked up in the context of the complete *postfix-expression*.
+If the *unqualified-id* is `~`*type-name*, the *type-name* is looked up
+in the context of the entire *postfix-expression*. If the type `T` of
+the object expression is of a class type `C`, the *type-name* is also
+looked up in the scope of class `C`. At least one of the lookups shall
+find a name that refers to (possibly cv-qualified) `T`.
 ``` cpp
 struct A { };
 struct B {
 A name having namespace scope ([[basic.scope.namespace]]) has internal
 linkage if it is the name of
 - a variable, function or function template that is explicitly declared
   `static`; or,
+- a non-volatile variable that is explicitly declared `const` or
+ `constexpr` and neither explicitly declared `extern` nor previously
+ declared to have external linkage; or
 - a data member of an anonymous union.
 An unnamed namespace or a namespace declared directly or indirectly
 within an unnamed namespace has internal linkage. All other namespaces
 have external linkage. A name having namespace scope that has not been
 void q() { /* ... */ }         // some other, unrelated q
 ```
 Names not covered by these rules have no linkage. Moreover, except as
+noted, a name declared at block scope ([[basic.scope.block]]) has no
 linkage. A type is said to have linkage if and only if:
 - it is a class or enumeration type that is named (or has a name for
   linkage purposes ([[dcl.typedef]])) and the name has linkage; or
 - it is an unnamed class or enumeration member of a class with linkage;
   or
+- it is a specialization of a class template (Clause  [[temp]])[^10]; or
 - it is a fundamental type ([[basic.fundamental]]); or
 - it is a compound type ([[basic.compound]]) other than a class or
   enumeration, compounded exclusively from types that have linkage; or
 - it is a cv-qualified ([[basic.type.qualifier]]) version of a type
   that has linkage.
 constructors for objects of namespace scope with static storage
 duration; termination contains the execution of destructors for objects
 with static storage duration.
 An implementation shall not predefine the `main` function. This function
+shall not be overloaded. It shall have a declared return type of type
+`int`, but otherwise its type is *implementation-defined*. An
+implementation shall allow both
+- a function of `()` returning `int` and
+- a function of `(int`, pointer to pointer to `char)` returning `int`
+as the type of `main` ([[dcl.fct]]). In the latter form, for purposes
+of exposition, the first function parameter is called `argc` and the
+second function parameter is called `argv`, where `argc` shall be the
+number of arguments passed to the program from the environment in which
+the program is run. If `argc` is nonzero these arguments shall be
+supplied in `argv[0]` through `argv[argc-1]` as pointers to the initial
+characters of null-terminated multibyte strings (NTMBS s) (
+[[multibyte.strings]]) and `argv[0]` shall be the pointer to the initial
+character of a NTMBSthat represents the name used to invoke the program
+or `""`. The value of `argc` shall be non-negative. The value of
+`argv[argc]` shall be 0. It is recommended that any further (optional)
+parameters be added after `argv`.
 The function `main` shall not be used within a program. The linkage (
 [[basic.link]]) of `main` is *implementation-defined*. A program that
+defines `main` as deleted or that declares `main` to be `inline`,
 `static`, or `constexpr` is ill-formed. The name `main` is not otherwise
 reserved. member functions, classes, and enumerations can be called
 `main`, as can entities in other namespaces.
 Terminating the program without leaving the current block (e.g., by
 initialized as a consequence of thread execution. Within each of these
 phases of initiation, initialization occurs as follows.
 Variables with static storage duration ([[basic.stc.static]]) or thread
 storage duration ([[basic.stc.thread]]) shall be zero-initialized (
+[[dcl.init]]) before any other initialization takes place. A *constant
+initializer* for an object `o` is an expression that is a constant
+expression, except that it may also invoke `constexpr` constructors for
+`o` and its subobjects even if those objects are of non-literal class
+types such a class may have a non-trivial destructor . *Constant
+initialization* is performed:
 - if each full-expression (including implicit conversions) that appears
   in the initializer of a reference with static or thread storage
   duration is a constant expression ([[expr.const]]) and the reference
   is bound to an lvalue designating an object with static storage
+  duration, to a temporary (see  [[class.temporary]]), or to a function;
 - if an object with static or thread storage duration is initialized by
+  a constructor call, and if the initialization full-expression is a
+ constant initializer for the object;
 - if an object with static or thread storage duration is not initialized
+  by a constructor call and if either the object is value-initialized or
+ every full-expression that appears in its initializer is a constant
+  expression.
 Together, zero-initialization and constant initialization are called
 *static initialization*; all other initialization is *dynamic
 initialization*. Static initialization shall be performed before any
 dynamic initialization takes place. Dynamic initialization of a
 It is *implementation-defined* whether the dynamic initialization of a
 non-local variable with static storage duration is done before the first
 statement of `main`. If the initialization is deferred to some point in
 time after the first statement of `main`, it shall occur before the
 first odr-use ([[basic.def.odr]]) of any function or variable defined
+in the same translation unit as the variable to be initialized.[^11]
 ``` cpp
 // - File 1 -
 #include "a.h"
 #include "b.h"
 program.
 ``` cpp
 void* operator new(std::size_t);
 void* operator new[](std::size_t);
+void operator delete(void*) noexcept;
+void operator delete[](void*) noexcept;
+void operator delete(void*, std::size_t) noexcept;
+void operator delete[](void*, std::size_t) noexcept;
 ```
 These implicit declarations introduce only the function names `operator`
 `new`, `operator` `new[]`, `operator` `delete`, and `operator`
 `delete[]`. The implicit declarations do not introduce the names `std`,
 to a corresponding deallocation function). Even if the size of the space
 requested is zero, the request can fail. If the request succeeds, the
 value returned shall be a non-null pointer value ([[conv.ptr]]) `p0`
 different from any previously returned value `p1`, unless that value
 `p1` was subsequently passed to an `operator` `delete`. The effect of
+indirecting through a pointer returned as a request for zero size is
+undefined.[^12]
 An allocation function that fails to allocate storage can invoke the
 currently installed new-handler function ([[new.handler]]), if any. A
 program-supplied allocation function can obtain the address of the
 currently installed `new_handler` using the `std::get_new_handler`
 function ([[set.new.handler]]). If an allocation function declared with
 a non-throwing *exception-specification* ([[except.spec]]) fails to
 allocate storage, it shall return a null pointer. Any other allocation
 function that fails to allocate storage shall indicate failure only by
+throwing an exception ([[except.throw]]) of a type that would match a
+handler ([[except.handle]]) of type `std::bad_alloc` ([[bad.alloc]]).
 A global allocation function is only called as the result of a new
 expression ([[expr.new]]), or called directly using the function call
 syntax ([[expr.call]]), or called indirectly through calls to the
 functions in the C++standard library. In particular, a global allocation
 function is not called to allocate storage for objects with static
 storage duration ([[basic.stc.static]]), for objects or references with
 thread storage duration ([[basic.stc.thread]]), for objects of type
+`std::type_info` ([[expr.typeid]]), or for an exception object (
+[[except.throw]]).
 #### Deallocation functions <a id="basic.stc.dynamic.deallocation">[[basic.stc.dynamic.deallocation]]</a>
 Deallocation functions shall be class member functions or global
 functions; a program is ill-formed if deallocation functions are
 declared in a namespace scope other than global scope or declared static
 in global scope.
 Each deallocation function shall return `void` and its first parameter
 shall be `void*`. A deallocation function can have more than one
+parameter. The global `operator delete` with exactly one parameter is a
+usual (non-placement) deallocation function. The global
+`operator delete` with exactly two parameters, the second of which has
+type `std::size_t`, is a usual deallocation function. Similarly, the
+global `operator delete[]` with exactly one parameter is a usual
+deallocation function. The global `operator delete[]` with exactly two
+parameters, the second of which has type `std::size_t`, is a usual
+deallocation function.[^13] If a class `T` has a member deallocation
+function named `operator` `delete` with exactly one parameter, then that
+function is a usual deallocation function. If class `T` does not declare
+such an `operator` `delete` but does declare a member deallocation
+function named `operator` `delete` with exactly two parameters, the
+second of which has type `std::size_t`, then this function is a usual
+deallocation function. Similarly, if a class `T` has a member
+deallocation function named `operator` `delete[]` with exactly one
+parameter, then that function is a usual (non-placement) deallocation
+function. If class `T` does not declare such an `operator` `delete[]`
+but does declare a member deallocation function named `operator`
+`delete[]` with exactly two parameters, the second of which has type
+`std::size_t`, then this function is a usual deallocation function. A
+deallocation function can be an instance of a function template. Neither
+the first parameter nor the return type shall depend on a template
+parameter. That is, a deallocation function template shall have a first
+parameter of type `void*` and a return type of `void` (as specified
+above). A deallocation function template shall have two or more function
+parameters. A template instance is never a usual deallocation function,
+regardless of its signature.
 If a deallocation function terminates by throwing an exception, the
 behavior is undefined. The value of the first argument supplied to a
 deallocation function may be a null pointer value; if so, and if the
 deallocation function is one supplied in the standard library, the call
 If the argument given to a deallocation function in the standard library
 is a pointer that is not the null pointer value ([[conv.ptr]]), the
 deallocation function shall deallocate the storage referenced by the
 pointer, rendering invalid all pointers referring to any part of the
+deallocated storage. Indirection through an invalid pointer value and
+passing an invalid pointer value to a deallocation function have
+undefined behavior. Any other use of an invalid pointer value has
+implementation-defined behavior.[^14]
 #### Safely-derived pointers <a id="basic.stc.dynamic.safety">[[basic.stc.dynamic.safety]]</a>
 A *traceable pointer object* is
 - an object of an object pointer type ([[basic.compound]]), or
 - an object of an integral type that is at least as large as
   `std::intptr_t`, or
+- a sequence of elements in an array of narrow character type (
+ [[basic.fundamental]]), where the size and alignment of the sequence
+  match those of some object pointer type.
 A pointer value is a *safely-derived pointer* to a dynamic object only
 if it has an object pointer type and it is one of the following:
 - the value returned by a call to the C++standard library implementation
+  of `::operator new(std::size_t)`;[^15]
 - the result of taking the address of an object (or one of its
+  subobjects) designated by an lvalue resulting from indirection through
+ a safely-derived pointer value;
 - the result of well-defined pointer arithmetic ([[expr.add]]) using a
   safely-derived pointer value;
 - the result of a well-defined pointer conversion ([[conv.ptr]],
   [[expr.cast]]) of a safely-derived pointer value;
 - the result of a `reinterpret_cast` of a safely-derived pointer value;
   `reinterpret_cast<void*>(P)`.
 An implementation may have *relaxed pointer safety*, in which case the
 validity of a pointer value does not depend on whether it is a
 safely-derived pointer value. Alternatively, an implementation may have
+*strict pointer safety*, in which case a pointer value referring to an
+object with dynamic storage duration that is not a safely-derived
+pointer value is an invalid pointer value unless the referenced complete
+object has previously been declared reachable (
+[[util.dynamic.safety]]). the effect of using an invalid pointer value
+(including passing it to a deallocation function) is undefined, see
 [[basic.stc.dynamic.deallocation]]. This is true even if the
 unsafely-derived pointer value might compare equal to some
 safely-derived pointer value. It is implementation defined whether an
 implementation has relaxed or strict pointer safety.
 used to release the storage, the destructor shall not be implicitly
 called and any program that depends on the side effects produced by the
 destructor has undefined behavior.
 Before the lifetime of an object has started but after the storage which
+the object will occupy has been allocated[^16] or, after the lifetime of
 an object has ended and before the storage which the object occupied is
 reused or released, any pointer that refers to the storage location
 where the object will be or was located may be used but only in limited
 ways. For an object under construction or destruction, see
 [[class.cdtor]]. Otherwise, such a pointer refers to allocated storage (
 [[basic.stc.dynamic.deallocation]]), and using the pointer as if the
+pointer were of type `void*`, is well-defined. Indirection through such
+a pointer is permitted but the resulting lvalue may only be used in
+limited ways, as described below. The program has undefined behavior if:
 - the object will be or was of a class type with a non-trivial
   destructor and the pointer is used as the operand of a
   *delete-expression*,
 - the pointer is used to access a non-static data member or call a
   non-static member function of the object, or
 - the pointer is implicitly converted ([[conv.ptr]]) to a pointer to a
+ virtual base class, or
 - the pointer is used as the operand of a `static_cast` (
+  [[expr.static.cast]]), except when the conversion is to pointer to
+ *cv* `void`, or to pointer to *cv* `void` and subsequently to pointer
+  to either *cv* `char` or *cv* `unsigned char`, or
 - the pointer is used as the operand of a `dynamic_cast` (
   [[expr.dynamic.cast]]).
   ``` cpp
   #include <cstdlib>
 - an lvalue-to-rvalue conversion ([[conv.lval]]) is applied to such a
   glvalue,
 - the glvalue is used to access a non-static data member or call a
   non-static member function of the object, or
+- the glvalue is bound to a reference to a virtual base class (
+ [[dcl.init.ref]]), or
 - the glvalue is used as the operand of a `dynamic_cast` (
   [[expr.dynamic.cast]]) or as the operand of `typeid`.
 If, after the lifetime of an object has ended and before the storage
 which the object occupied is reused or released, a new object is created
   ```
 If a program ends the lifetime of an object of type `T` with static (
 [[basic.stc.static]]), thread ([[basic.stc.thread]]), or automatic (
 [[basic.stc.auto]]) storage duration and if `T` has a non-trivial
+destructor,[^17] the program must ensure that an object of the original
 type occupies that same storage location when the implicit destructor
 call takes place; otherwise the behavior of the program is undefined.
 This is true even if the block is exited with an exception.
 ``` cpp
 [[dcl.fct]]).
 For any object (other than a base-class subobject) of trivially copyable
 type `T`, whether or not the object holds a valid value of type `T`, the
 underlying bytes ([[intro.memory]]) making up the object can be copied
+into an array of `char` or `unsigned` `char`.[^18] If the content of the
 array of `char` or `unsigned` `char` is copied back into the object, the
 object shall subsequently hold its original value.
 ``` cpp
 #define N sizeof(T)
 ```
 For any trivially copyable type `T`, if two pointers to `T` point to
 distinct `T` objects `obj1` and `obj2`, where neither `obj1` nor `obj2`
 is a base-class subobject, if the underlying bytes ([[intro.memory]])
+making up `obj1` are copied into `obj2`,[^19] `obj2` shall subsequently
 hold the same value as `obj1`.
 ``` cpp
 T* t1p;
 T* t2p;
 *N* `unsigned` `char` objects taken up by the object of type `T`, where
 *N* equals `sizeof(T)`. The *value representation* of an object is the
 set of bits that hold the value of type `T`. For trivially copyable
 types, the value representation is a set of bits in the object
 representation that determines a *value*, which is one discrete element
+of an *implementation-defined* set of values.[^20]
+A class that has been declared but not defined, an enumeration type in
+certain contexts ([[dcl.enum]]), or an array of unknown size or of
+incomplete element type, is an *incompletely-defined object type*.[^21]
+Incompletely-defined object types and the void types are *incomplete
+types* ([[basic.fundamental]]). Objects shall not be defined to have an
+incomplete type.
 A class type (such as “`class X`”) might be incomplete at one point in a
 translation unit and complete later on; the type “`class X`” is the same
 type at both points. The declared type of an array object might be an
 array of incomplete class type and therefore incomplete; if the class
 type is completed later on in the translation unit, the array type
 becomes complete; the array type at those two points is the same type.
 The declared type of an array object might be an array of unknown size
 and therefore be incomplete at one point in a translation unit and
 complete later on; the array types at those two points (“array of
+unknown bound of `T`” and “array of `N` `T`”) are different types. The
 type of a pointer to array of unknown size, or of a type defined by a
 `typedef` declaration to be an array of unknown size, cannot be
 completed.
 ``` cpp
 types, pointer to member types ([[basic.compound]]), `std::nullptr_t`,
 and cv-qualified versions of these types ([[basic.type.qualifier]]) are
 collectively called *scalar types*. Scalar types, POD classes (Clause
 [[class]]), arrays of such types and *cv-qualified* versions of these
 types ([[basic.type.qualifier]]) are collectively called *POD types*.
+Cv-unqualified scalar types, trivially copyable class types (Clause
+[[class]]), arrays of such types, and non-volatile const-qualified
+versions of these types ([[basic.type.qualifier]]) are collectively
+called *trivially copyable types*. Scalar types, trivial class types
+(Clause  [[class]]), arrays of such types and cv-qualified versions of
+these types ([[basic.type.qualifier]]) are collectively called *trivial
+types*. Scalar types, standard-layout class types (Clause  [[class]]),
+arrays of such types and cv-qualified versions of these types (
 [[basic.type.qualifier]]) are collectively called *standard-layout
 types*.
 A type is a *literal type* if it is:
+- `void`; or
 - a scalar type; or
+- a reference type; or
 - an array of literal type; or
 - a class type (Clause  [[class]]) that has all of the following
   properties:
   - it has a trivial destructor,
   - it is an aggregate type ([[dcl.init.aggr]]) or has at least one
     `constexpr` constructor or constructor template that is not a copy
     or move constructor, and
+  - all of its non-static data members and base classes are of
+ non-volatile literal types.
 If two types `T1` and `T2` are the same type, then `T1` and `T2` are
 *layout-compatible* types. Layout-compatible enumerations are described
 in  [[dcl.enum]]. Layout-compatible standard-layout structs and
 standard-layout unions are described in  [[class.mem]].
 from this set is stored in a character object, the integral value of
 that character object is equal to the value of the single character
 literal form of that character. It is *implementation-defined* whether a
 `char` object can hold negative values. Characters can be explicitly
 declared `unsigned` or `signed`. Plain `char`, `signed char`, and
+`unsigned char` are three distinct types, collectively called *narrow
+character types*. A `char`, a `signed char`, and an `unsigned char`
+occupy the same amount of storage and have the same alignment
+requirements ([[basic.align]]); that is, they have the same object
+representation. For narrow character types, all bits of the object
 representation participate in the value representation. For unsigned
+narrow character types, all possible bit patterns of the value
+representation represent numbers. These requirements do not hold for
+other types. In any particular implementation, a plain `char` object can
+take on either the same values as a `signed char` or an `unsigned
+char`; which one is *implementation-defined*. For each value *i* of type
+`unsigned char` in the range 0 to 255 inclusive, there exists a value
+*j* of type `char` such that the result of an integral conversion (
+[[conv.integral]]) from *i* to `char` is *j*, and the result of an
+integral conversion from *j* to `unsigned char` is *i*.
 There are five *standard signed integer types* : “`signed char`”,
 “`short int`”, “`int`”, “`long int`”, and “`long` `long` `int`”. In this
 list, each type provides at least as much storage as those preceding it
 in the list. There may also be *implementation-defined* *extended signed
 integer types*. The standard and extended signed integer types are
 collectively called *signed integer types*. Plain `int`s have the
 natural size suggested by the architecture of the execution
+environment[^22]; the other signed integer types are provided to meet
 special needs.
 For each of the standard signed integer types, there exists a
 corresponding (but different) *standard unsigned integer type*:
 “`unsigned char`”, “`unsigned short int`”, “`unsigned int`”,
 “`unsigned long int`”, and “`unsigned` `long` `long` `int`”, each of
 which occupies the same amount of storage and has the same alignment
 requirements ([[basic.align]]) as the corresponding signed integer
+type[^23]; that is, each signed integer type has the same object
 representation as its corresponding unsigned integer type. Likewise, for
 each of the extended signed integer types there exists a corresponding
 *extended unsigned integer type* with the same amount of storage and
 alignment requirements. The standard and extended unsigned integer types
 are collectively called *unsigned integer types*. The range of
 corresponding *unsigned integer* type, and the value representation of
 each corresponding signed/unsigned type shall be the same. The standard
 signed integer types and standard unsigned integer types are
 collectively called the *standard integer types*, and the extended
 signed integer types and extended unsigned integer types are
+collectively called the *extended integer types*. The signed and
+unsigned integer types shall satisfy the constraints given in the C
+standard, section 5.2.4.2.1.
+Unsigned integers shall obey the laws of arithmetic modulo 2ⁿ where n is
+the number of bits in the value representation of that particular size
+of integer.[^24]
 Type `wchar_t` is a distinct type whose values can represent distinct
 codes for all members of the largest extended character set specified
 among the supported locales ([[locale]]). Type `wchar_t` shall have the
 same size, signedness, and alignment requirements ([[basic.align]]) as
 one of the other integral types, called its *underlying type*. Types
 `char16_t` and `char32_t` denote distinct types with the same size,
 signedness, and alignment as `uint_least16_t` and `uint_least32_t`,
+respectively, in `<cstdint>`, called the underlying types.
+Values of type `bool` are either `true` or `false`.[^25] There are no
 `signed`, `unsigned`, `short`, or `long bool` types or values. Values of
 type `bool` participate in integral promotions ([[conv.prom]]).
 Types `bool`, `char`, `char16_t`, `char32_t`, `wchar_t`, and the signed
 and unsigned integer types are collectively called *integral*
+types.[^26] A synonym for integral type is *integer type*. The
 representations of integral types shall define values by use of a pure
+binary numeration system.[^27] this International Standard permits 2’s
 complement, 1’s complement and signed magnitude representations for
 integral types.
 There are three *floating point* types: `float`, `double`, and
 `long double`. The type `double` provides at least as much precision as
 for functions that do not return a value. Any expression can be
 explicitly converted to type *cv* `void` ([[expr.cast]]). An expression
 of type `void` shall be used only as an expression statement (
 [[stmt.expr]]), as an operand of a comma expression ([[expr.comma]]),
 as a second or third operand of `?:` ([[expr.cond]]), as the operand of
+`typeid`, `noexcept`, or `decltype`, as the expression in a return
+statement ([[stmt.return]]) for a function with the return type `void`,
+or as the operand of an explicit conversion to type cv `void`.
 A value of type `std::nullptr_t` is a null pointer constant (
 [[conv.ptr]]). Such values participate in the pointer and the pointer to
 member conversions ([[conv.ptr]], [[conv.mem]]).
 `sizeof(std::nullptr_t)` shall be equal to `sizeof(void*)`.
 - *unions*, which are classes capable of containing objects of different
   types at different times,  [[class.union]];
 - *enumerations*, which comprise a set of named constant values. Each
   distinct enumeration constitutes a different *enumerated type*,
   [[dcl.enum]];
+- *pointers to non-static* [^28] *class members*, which identify members
   of a given type within objects of a given class,  [[dcl.mptr]].
 These methods of constructing types can be applied recursively;
 restrictions are mentioned in  [[dcl.ptr]], [[dcl.array]], [[dcl.fct]],
+and  [[dcl.ref]]. Constructing a type such that the number of bytes in
+its object representation exceeds the maximum value representable in the
+type `std::size_t` ([[support.types]]) is ill-formed.
 The type of a pointer to `void` or a pointer to an object type is called
 an *object pointer type*. A pointer to `void` does not have a
 pointer-to-object type, however, because `void` is not an object type.
 The type of a pointer that can designate a function is called a
 *cv-unqualified type*. Each type which is a cv-unqualified complete or
 incomplete object type or is `void` ([[basic.types]]) has three
 corresponding cv-qualified versions of its type: a *const-qualified*
 version, a *volatile-qualified* version, and a
 *const-volatile-qualified* version. The term *object type* (
+[[intro.object]]) includes the cv-qualifiers specified in the
+*decl-specifier-seq* ([[dcl.spec]]), *declarator* (Clause
+[[dcl.decl]]), *type-id* ([[dcl.name]]), or *new-type-id* (
+[[expr.new]]) when the object is created.
+- A *const object* is an object of type `const T` or a non-mutable
+  subobject of such an object.
+- A *volatile object* is an object of type `volatile T`, a subobject of
+  such an object, or a mutable subobject of a const volatile object.
+- A *const volatile object* is an object of type `const volatile T`, a
+  non-mutable subobject of such an object, a const subobject of a
+  volatile object, or a non-mutable volatile subobject of a const
+  object.
+The cv-qualified or cv-unqualified versions of a type are distinct
+types; however, they shall have the same representation and alignment
+requirements ([[basic.align]]).[^29]
 A compound type ([[basic.compound]]) is not cv-qualified by the
 cv-qualifiers (if any) of the types from which it is compounded. Any
 cv-qualifiers applied to an array type affect the array element type,
 not the array type ([[dcl.array]]).
 See  [[dcl.fct]] and  [[class.this]] regarding function types that have
 *cv-qualifier*s.
 There is a partial ordering on cv-qualifiers, so that a type can be said
 to be *more cv-qualified* than another. Table
 etc.), used in the description of types, represents an arbitrary set of
 cv-qualifiers, i.e., one of {`const`}, {`volatile`}, {`const`,
 `volatile`}, or the empty set. Cv-qualifiers applied to an array type
 attach to the underlying element type, so the notation “*cv* `T`,” where
 `T` is an array type, refers to an array whose elements are
+so-qualified. An array type whose elements are cv-qualified is also
+considered to have the same cv-qualifications as its elements.
+``` cpp
+typedef char CA[5];
+typedef const char CC;
+CC arr1[5] = { 0 };
+const CA arr2 = { 0 };
+```
+The type of both `arr1` and `arr2` is “array of 5 `const char`,” and the
+array type is considered to be `const`-qualified.
 ## Lvalues and rvalues <a id="basic.lval">[[basic.lval]]</a>
 Expressions are categorized according to the taxonomy in Figure
 [[fig:categories]].
   return type is an lvalue reference is an lvalue.
 - An *xvalue* (an “eXpiring” value) also refers to an object, usually
   near the end of its lifetime (so that its resources may be moved, for
   example). An xvalue is the result of certain kinds of expressions
   involving rvalue references ([[dcl.ref]]). The result of calling a
+  function whose return type is an rvalue reference to an object type is
+  an xvalue ([[expr.call]]).
 - A *glvalue* (“generalized” lvalue) is an lvalue or an xvalue.
 - An *rvalue* (so called, historically, because rvalues could appear on
   the right-hand side of an assignment expression) is an xvalue, a
   temporary object ([[class.temporary]]) or subobject thereof, or a
   value that is not associated with an object.
 The discussion of reference initialization in  [[dcl.init.ref]] and of
 temporaries in  [[class.temporary]] indicates the behavior of lvalues
 and rvalues in other significant contexts.
+Unless otherwise indicated ([[expr.call]]), prvalues shall always have
+complete types or the `void` type; in addition to these types, glvalues
+can also have incomplete types. class and array prvalues can have
+cv-qualified types; other prvalues always have cv-unqualified types. See
+Clause  [[expr]].
 An lvalue for an object is necessary in order to modify the object
 except that an rvalue of class type can also be used to modify its
 referent under certain circumstances. a member function called for an
 object ([[class.mfct]]) can modify the object.
 an object through a nonmodifiable lvalue or rvalue expression is
 ill-formed.
 If a program attempts to access the stored value of an object through a
 glvalue of other than one of the following types the behavior is
+undefined:[^30]
 - the dynamic type of the object,
 - a cv-qualified version of the dynamic type of the object,
 - a type similar (as defined in  [[conv.qual]]) to the dynamic type of
   the object,
 alignments. Stricter alignments have larger alignment values. An address
 that satisfies an alignment requirement also satisfies any weaker valid
 alignment requirement.
 The alignment requirement of a complete type can be queried using an
+`alignof` expression ([[expr.alignof]]). Furthermore, the narrow
+character types ([[basic.fundamental]]) shall have the weakest
+alignment requirement. This enables the narrow character types to be
+used as the underlying type for an aligned memory area ([[dcl.align]]).
 Comparing alignments is meaningful and provides the obvious results:
 - Two alignments are equal when their numeric values are equal.
 - Two alignments are different when their numeric values are not equal.
 [basic.lookup.udir]: #basic.lookup.udir
 [basic.lookup.unqual]: #basic.lookup.unqual
 [basic.lval]: #basic.lval
 [basic.namespace]: dcl.md#basic.namespace
 [basic.scope]: #basic.scope
+[basic.scope.block]: #basic.scope.block
 [basic.scope.class]: #basic.scope.class
 [basic.scope.declarative]: #basic.scope.declarative
 [basic.scope.enum]: #basic.scope.enum
 [basic.scope.hiding]: #basic.scope.hiding
 [basic.scope.namespace]: #basic.scope.namespace
 [basic.scope.pdecl]: #basic.scope.pdecl
 [basic.scope.proto]: #basic.scope.proto
 [basic.scope.temp]: #basic.scope.temp
 [basic.start]: #basic.start
 [class.this]: class.md#class.this
 [class.union]: class.md#class.union
 [conv]: conv.md#conv
 [conv.array]: conv.md#conv.array
 [conv.func]: conv.md#conv.func
+[conv.integral]: conv.md#conv.integral
 [conv.lval]: conv.md#conv.lval
 [conv.mem]: conv.md#conv.mem
 [conv.prom]: conv.md#conv.prom
 [conv.ptr]: conv.md#conv.ptr
 [conv.qual]: conv.md#conv.qual
 [dcl.align]: dcl.md#dcl.align
 [dcl.array]: dcl.md#dcl.array
 [dcl.dcl]: dcl.md#dcl.dcl
 [dcl.decl]: dcl.md#dcl.decl
 [dcl.enum]: dcl.md#dcl.enum
 [dcl.fct]: dcl.md#dcl.fct
 [dcl.fct.def]: dcl.md#dcl.fct.def
 [dcl.init]: dcl.md#dcl.init
 [dcl.init.aggr]: dcl.md#dcl.init.aggr
 [dcl.init.ref]: dcl.md#dcl.init.ref
 [dcl.link]: dcl.md#dcl.link
 [dcl.mptr]: dcl.md#dcl.mptr
+[dcl.name]: dcl.md#dcl.name
 [dcl.ptr]: dcl.md#dcl.ptr
 [dcl.ref]: dcl.md#dcl.ref
+[dcl.spec]: dcl.md#dcl.spec
 [dcl.stc]: dcl.md#dcl.stc
 [dcl.type.cv]: dcl.md#dcl.type.cv
 [dcl.type.elab]: dcl.md#dcl.type.elab
 [dcl.type.simple]: dcl.md#dcl.type.simple
 [dcl.typedef]: dcl.md#dcl.typedef
+[diff.cpp11.basic]: compatibility.md#diff.cpp11.basic
 [except]: except.md#except
 [except.handle]: except.md#except.handle
 [except.spec]: except.md#except.spec
 [except.terminate]: except.md#except.terminate
 [except.throw]: except.md#except.throw
 [expr.comma]: expr.md#expr.comma
 [expr.cond]: expr.md#expr.cond
 [expr.const]: expr.md#expr.const
 [expr.delete]: expr.md#expr.delete
 [expr.dynamic.cast]: expr.md#expr.dynamic.cast
+[expr.mptr.oper]: expr.md#expr.mptr.oper
 [expr.new]: expr.md#expr.new
 [expr.prim]: expr.md#expr.prim
+[expr.prim.general]: expr.md#expr.prim.general
 [expr.pseudo]: expr.md#expr.pseudo
 [expr.ref]: expr.md#expr.ref
 [expr.sizeof]: expr.md#expr.sizeof
 [expr.static.cast]: expr.md#expr.static.cast
 [expr.type.conv]: expr.md#expr.type.conv
 [over]: over.md#over
 [over.literal]: over.md#over.literal
 [over.load]: over.md#over.load
 [over.match]: over.md#over.match
 [over.oper]: over.md#over.oper
+[over.over]: over.md#over.over
 [ptr.align]: utilities.md#ptr.align
 [replacement.functions]: library.md#replacement.functions
 [set.new.handler]: language.md#set.new.handler
 [stmt.block]: stmt.md#stmt.block
 [stmt.dcl]: stmt.md#stmt.dcl
 [^6]: This lookup applies whether the definition of `X` is nested within
     `Y`’s definition or whether `X`’s definition appears in a namespace
     scope enclosing `Y` ’s definition ([[class.nest]]).
 [^7]: That is, an unqualified name that occurs, for instance, in a type
+    in the *parameter-declaration-clause* or in the
+ *exception-specification*.
 [^8]: This lookup applies whether the member function is defined within
     the definition of class `X` or whether the member function is
     defined in a namespace scope enclosing `X`’s definition.
+[^9]: Lookups in which function names are ignored include names
+ appearing in a *nested-name-specifier*, an
+ *elaborated-type-specifier*, or a *base-specifier*.
+[^10]: A class template always has external linkage, and the
+    requirements of  [[temp.arg.type]] and  [[temp.arg.nontype]] ensure
+    that the template arguments will also have appropriate linkage.
+[^11]: A non-local variable with static storage duration having
     initialization with side-effects must be initialized even if it is
     not odr-used ([[basic.def.odr]],  [[basic.stc.static]]).
+[^12]: The intent is to have `operator new()` implementable by calling
     `std::malloc()` or `std::calloc()`, so the rules are substantially
     the same. C++differs from C in requiring a zero request to return a
     non-null pointer.
+[^13]: This deallocation function precludes use of an allocation
+ function `void operator new(std::size_t, std::size_t)` as a
+    placement allocation function ([[diff.cpp11.basic]]).
+[^14]: Some implementations might define that copying an invalid pointer
+    value causes a system-generated runtime fault.
+[^15]: This section does not impose restrictions on indirection through
     pointers to memory not allocated by `::operator new`. This maintains
     the ability of many C++implementations to use binary libraries and
     components written in other languages. In particular, this applies
+    to C binaries, because indirection through pointers to memory
+ allocated by `std::malloc` is not restricted.
+[^16]: For example, before the construction of a global object of
     non-POD class type ([[class.cdtor]]).
+[^17]: That is, an object for which a destructor will be called
     implicitly—upon exit from the block for an object with automatic
     storage duration, upon exit from the thread for an object with
     thread storage duration, or upon exit from the program for an object
     with static storage duration.
+[^18]: By using, for example, the library functions ([[headers]])
     `std::memcpy` or `std::memmove`.
+[^19]: By using, for example, the library functions ([[headers]])
     `std::memcpy` or `std::memmove`.
+[^20]: The intent is that the memory model of C++is compatible with that
     of ISO/IEC 9899 Programming Language C.
+[^21]: The size and layout of an instance of an incompletely-defined
     object type is unknown.
+[^22]: that is, large enough to contain any value in the range of
     `INT_MIN` and `INT_MAX`, as defined in the header `<climits>`.
+[^23]: See  [[dcl.type.simple]] regarding the correspondence between
     types and the sequences of *type-specifier*s that designate them.
+[^24]: This implies that unsigned arithmetic does not overflow because a
     result that cannot be represented by the resulting unsigned integer
     type is reduced modulo the number that is one greater than the
     largest value that can be represented by the resulting unsigned
     integer type.
+[^25]: Using a `bool` value in ways described by this International
     Standard as “undefined,” such as by examining the value of an
     uninitialized automatic object, might cause it to behave as if it is
     neither `true` nor `false`.
+[^26]: Therefore, enumerations ([[dcl.enum]]) are not integral;
     however, enumerations can be promoted to integral types as specified
     in  [[conv.prom]].
+[^27]: A positional representation for integers that uses the binary
     digits 0 and 1, in which the values represented by successive bits
     are additive, begin with 1, and are multiplied by successive
     integral power of 2, except perhaps for the bit with the highest
     position. (Adapted from the *American National Dictionary for
     Information Processing Systems*.)
+[^28]: Static class members are objects or functions, and pointers to
     them are ordinary pointers to objects or functions.
+[^29]: The same representation and alignment requirements are meant to
     imply interchangeability as arguments to functions, return values
     from functions, and non-static data members of unions.
+[^30]: The intent of this list is to specify those circumstances in
     which an object may or may not be aliased.

Diff to HTML by rtfpessoa