[basic] - C++20 → C++23

Files changed (1) hide show

tmp/tmpubp60ij6/{from.md → to.md} +1945 -1954

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

@@ -17,19 +17,38 @@ Clauses. — *end note*]
 An *entity* is a value, object, reference, structured binding, function,
 enumerator, type, class member, bit-field, template, template
 specialization, namespace, or pack.
-A *name* is a use of an *identifier* [[lex.name]],
-*operator-function-id* [[over.oper]], *literal-operator-id*
-[[over.literal]], *conversion-function-id* [[class.conv.fct]], or
-*template-id* [[temp.names]] that denotes an entity or label (
-[[stmt.goto]], [[stmt.label]]).
-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.
@@ -46,27 +65,27 @@ 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 *literal-operator-id*s [[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
 [[basic.link]] of the name specified in each translation unit.
 ## Declarations and definitions <a id="basic.def">[[basic.def]]</a>
-A declaration [[dcl.dcl]] may introduce one or more names into a
-translation unit or redeclare names introduced by previous declarations.
-If so, the declaration specifies the interpretation and semantic
-properties of these names. A declaration may also have effects
-including:
 - a static assertion [[dcl.pre]],
 - controlling template instantiation [[temp.explicit]],
 - guiding template argument deduction for constructors
   [[temp.deduct.guide]],
@@ -79,16 +98,16 @@ declaration unless:
 - it declares a function without specifying the function’s body
   [[dcl.fct.def]],
 - it contains the `extern` specifier [[dcl.stc]] or a
   *linkage-specification*[^1] [[dcl.link]] and neither an *initializer*
   nor a *function-body*,
-- it declares a non-inline static data member in a class definition (
-  [[class.mem]], [[class.static]]),
 - it declares a static data member outside a class definition and the
   variable was defined within the class with the `constexpr` specifier
   (this usage is deprecated; see [[depr.static.constexpr]]),
-- it is introduced by an *elaborated-type-specifier* [[class.name]],
 - it is an *opaque-enum-declaration* [[dcl.enum]],
 - it is a *template-parameter* [[temp.param]],
 - it is a *parameter-declaration* [[dcl.fct]] in a function declarator
   that is not the *declarator* of a *function-definition*,
 - it is a `typedef` declaration [[dcl.typedef]],
@@ -190,22 +209,31 @@ struct C {
 [*Note 2*: A class name can also be implicitly declared by an
 *elaborated-type-specifier* [[dcl.type.elab]]. — *end note*]
 In the definition of an object, the type of that object shall not be an
-incomplete type [[basic.types]], an abstract class type
-[[class.abstract]], or a (possibly multi-dimensional) array thereof.
 ## One-definition rule <a id="basic.def.odr">[[basic.def.odr]]</a>
 No translation unit shall contain more than one definition of any
-variable, function, class type, enumeration type, template, default
-argument for a parameter (for a function in a given scope), or default
-template argument.
 An expression or conversion is *potentially evaluated* unless it is an
-unevaluated operand [[expr.prop]], a subexpression thereof, or a
 conversion in an initialization or conversion sequence in such a
 context. The set of *potential results* of an expression E is defined as
 follows:
 - If E is an *id-expression* [[expr.prim.id]], the set contains only E.
@@ -250,52 +278,55 @@ int n = b ? (1, S::x)           // S::x is not odr-used here
 — *end note*]
 A function is *named by* an expression or conversion as follows:
 - A function is named by an expression or conversion if it is the
-  selected member of an overload set ([[basic.lookup]], [[over.match]],
-  [[over.over]]) in an overload resolution performed as part of forming
- that expression or conversion, unless it is a pure virtual function
-  and either the expression is not an *id-expression* naming the
- function with an explicitly qualified name or the expression forms a
-  pointer to member [[expr.unary.op]]. \[*Note 2*: This covers taking
-  the address of functions ([[conv.func]], [[expr.unary.op]]), calls to
- named functions [[expr.call]], operator overloading [[over]],
- user-defined conversions [[class.conv.fct]], allocation functions for
- *new-expression*s [[expr.new]], as well as non-default initialization
-  [[dcl.init]]. A constructor selected to copy or move an object of
- class type is considered to be named by an expression or conversion
- even if the call is actually elided by the implementation
   [[class.copy.elision]]. — *end note*]
 - A deallocation function for a class is named by a *new-expression* if
   it is the single matching deallocation function for the allocation
   function selected by overload resolution, as specified in
   [[expr.new]].
 - A deallocation function for a class is named by a *delete-expression*
   if it is the selected usual deallocation function as specified in
   [[expr.delete]] and  [[class.free]].
-A variable `x` whose name appears as a potentially-evaluated expression
-E is *odr-used* by E unless
 - `x` is a reference that is usable in constant expressions
   [[expr.const]], or
 - `x` is a variable of non-reference type that is usable in constant
   expressions and has no mutable subobjects, and E is an element of the
   set of potential results of an expression of non-volatile-qualified
   non-class type to which the lvalue-to-rvalue conversion [[conv.lval]]
   is applied, or
 - `x` is a variable of non-reference type, and E is an element of the
-  set of potential results of a discarded-value expression [[expr.prop]]
-  to which the lvalue-to-rvalue conversion is not applied.
 A structured binding is odr-used if it appears as a
 potentially-evaluated expression.
 `*this` is odr-used if `this` 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 is
 odr-used if it is named by a potentially-evaluated expression or
 conversion. A non-placement allocation or deallocation function for a
 class is odr-used by the definition of a constructor of that class. A
@@ -308,29 +339,29 @@ 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.assign]]. 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]].
-A local entity [[basic.pre]] is *odr-usable* in a declarative region
-[[basic.scope.declarative]] if:
 - either the local entity is not `*this`, or an enclosing class or
   non-lambda function parameter scope exists and, if the innermost such
   scope is a function parameter scope, it corresponds to a non-static
   member function, and
-- for each intervening declarative region [[basic.scope.declarative]]
- between the point at which the entity is introduced and the region
- (where `*this` is considered to be introduced within the innermost
- enclosing class or non-lambda function definition scope), either:
-  - the intervening declarative region is a block scope, or
-  - the intervening declarative region is the function parameter scope
- of a *lambda-expression* that has a *simple-capture* naming the
- entity or has a *capture-default*, and the block scope of the
-    *lambda-expression* is also an intervening declarative region.
-If a local entity is odr-used in a declarative region in which it is not
-odr-usable, the program is ill-formed.
 [*Example 2*:
 ``` cpp
 void f(int n) {
@@ -345,15 +376,15 @@ void f(int n) {
 }
 ```
 — *end example*]
-Every program shall contain exactly one definition of every non-inline
-function or variable that is odr-used in that program outside of a
-discarded statement [[stmt.if]]; no diagnostic required. The definition
-can appear explicitly in the program, it can be found in the standard or
-a user-defined library, or (when appropriate) it is implicitly defined
 (see  [[class.default.ctor]], [[class.copy.ctor]], [[class.dtor]], and
 [[class.copy.assign]]).
 [*Example 3*:
@@ -377,13 +408,12 @@ A *definition domain* is a *private-module-fragment* or the portion of a
 translation unit excluding its *private-module-fragment* (if any). A
 definition of an inline function or variable shall be reachable from the
 end of every definition domain in which it is odr-used outside of a
 discarded statement.
-A definition of a class is required to be reachable in every context in
-which the class is used in a way that requires the class type to be
-complete.
 [*Example 4*:
 The following complete translation unit is well-formed, even though it
 never defines `X`:
@@ -407,12 +437,13 @@ complete class types are required. A class type `T` must be complete if:
 - `T` is used as the allocated type or array element type in a
   *new-expression* [[expr.new]], or
 - an lvalue-to-rvalue conversion is applied to a glvalue referring to an
   object of type `T` [[conv.lval]], or
 - an expression is converted (either implicitly or explicitly) to type
-  `T` ([[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 [[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`
@@ -428,26 +459,23 @@ complete class types are required. A class type `T` must be complete if:
 - an *exception-declaration* has type `T`, reference to `T`, or pointer
   to `T` [[except.handle]].
 — *end note*]
-There can be more than one definition of a
-- class type [[class]],
-- enumeration type [[dcl.enum]],
-- inline function or variable [[dcl.inline]],
-- templated entity [[temp.pre]],
-- default argument for a parameter (for a function in a given scope)
-  [[dcl.fct.default]], or
-- default template argument [[temp.param]]
-in a program provided that each definition appears in a different
-translation unit and the definitions satisfy the following requirements.
-Given such an entity `D` defined in more than one translation unit, for
-all definitions of `D`, or, if `D` is an unnamed enumeration, for all
-definitions of `D` that are reachable at any given program point, the
-following requirements shall be satisfied.
 - Each such definition shall not be attached to a named module
   [[module.unit]].
 - Each such definition shall consist of the same sequence of tokens,
   where the definition of a closure type is considered to consist of the
@@ -470,22 +498,28 @@ following requirements shall be satisfied.
 - In each such definition, except within the default arguments and
   default template arguments of `D`, corresponding *lambda-expression*s
   shall have the same closure type (see below).
 - In each such definition, corresponding entities shall have the same
   language linkage.
 - In each such definition, the overloaded operators referred to, the
   implicit calls to conversion functions, constructors, operator new
   functions and operator delete functions, shall refer to the same
   function.
 - In each such definition, a default argument used by an (implicit or
   explicit) function call or a default template argument used by an
   (implicit or explicit) *template-id* or *simple-template-id* is
   treated as if its token sequence were present in the definition of
   `D`; that is, the default argument or default template argument is
   subject to the requirements described in this paragraph (recursively).
-- If `D` is a class with an implicitly-declared constructor (
-  [[class.default.ctor]], [[class.copy.ctor]]), it is as if the
   constructor was implicitly defined in every translation unit where it
   is odr-used, and the implicit definition in every translation unit
   shall call the same constructor for a subobject of `D`.
   \[*Example 5*:
   ``` cpp
@@ -520,33 +554,27 @@ following requirements shall be satisfied.
   implicit definition in every translation unit shall call the same
   comparison operators for each subobject of `D`.
 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]]. These requirements also apply to
-corresponding entities defined within each definition of `D` (including
-the closure types of *lambda-expression*s, but excluding entities
-defined within default arguments or default template arguments of either
-`D` or an entity not defined within `D`). For each such entity and for
-`D` itself, the behavior is as if there is a single entity with a single
-definition, including in the application of these requirements to other
-entities.
 [*Note 4*: The entity is still declared in multiple translation units,
 and [[basic.link]] still applies to these declarations. In particular,
 *lambda-expression*s [[expr.prim.lambda]] appearing in the type of `D`
-may result in the different declarations having distinct types, and
-*lambda-expression*s appearing in a default argument of `D` may still
 denote different types in different translation units. — *end note*]
-If these definitions do not satisfy these requirements, then the program
-is ill-formed; a diagnostic is required only if the entity is attached
-to a named module and a prior definition is reachable at the point where
-a later definition occurs.
 [*Example 6*:
 ``` cpp
 inline void f(bool cond, void (*p)()) {
   if (cond) f(false, []{});
@@ -579,92 +607,209 @@ first enumerator name and do not have typedef names for linkage purposes
 [[dcl.enum]], those unnamed enumeration types shall be the same; no
 diagnostic required.
 ## Scope <a id="basic.scope">[[basic.scope]]</a>
-### Declarative regions and scopes <a id="basic.scope.declarative">[[basic.scope.declarative]]</a>
-Every name is introduced in some portion of program text called a
-*declarative region*, which is the largest part of the program in which
-that name is valid, that is, in which that name may be used as an
-unqualified name to refer to the same entity. In general, each
-particular name is valid only within some possibly discontiguous portion
-of program text called its *scope*. To determine the scope of a
-declaration, it is sometimes convenient to refer to the *potential
-scope* of a declaration. The scope of a declaration is the same as its
-potential scope unless the potential scope contains another declaration
-of the same name. In that case, the potential scope of the declaration
-in the inner (contained) declarative region is excluded from the scope
-of the declaration in the outer (containing) declarative region.
 [*Example 1*:
-In
 ``` cpp
-int j = 24;
-int main() {
-  int i = j, j;
-  j = 42;
 }
 ```
-the identifier `j` is declared twice as a name (and used twice). The
-declarative region of the first `j` includes the entire example. The
-potential scope of the first `j` begins immediately after that `j` and
-extends to the end of the program, but its (actual) scope excludes the
-text between the `,` and the `}`. The declarative region of the second
-declaration of `j` (the `j` immediately before the semicolon) includes
-all the text between `{` and `}`, but its potential scope excludes the
-declaration of `i`. The scope of the second declaration of `j` is the
-same as its potential scope.
 — *end example*]
-The names declared by a declaration are introduced into the scope in
-which the declaration occurs, except that the presence of a `friend`
-specifier [[class.friend]], certain uses of the
-*elaborated-type-specifier* [[dcl.type.elab]], and *using-directive*s
-[[namespace.udir]] alter this general behavior.
-Given a set of declarations in a single declarative region, each of
-which specifies the same unqualified name,
-- they shall all refer to the same entity, or all refer to functions and
-  function templates; or
-- exactly one declaration shall declare a class name or enumeration name
-  that is not a typedef name and the other declarations shall all refer
-  to the same variable, non-static data member, or enumerator, or all
-  refer to functions and function templates; in this case the class name
-  or enumeration name is hidden [[basic.scope.hiding]]. \[*Note 1*: A
-  structured binding [[dcl.struct.bind]], namespace name
-  [[basic.namespace]], or class template name [[temp.pre]] must be
-  unique in its declarative region. — *end note*]
-[*Note 2*: These restrictions apply to the declarative region into
-which a name is introduced, which is not necessarily the same as the
-region in which the declaration occurs. In particular,
-*elaborated-type-specifier*s [[dcl.type.elab]] and friend declarations
-[[class.friend]] may introduce a (possibly not visible) name into an
-enclosing namespace; these restrictions apply to that region. Local
-extern declarations [[basic.link]] may introduce a name into the
-declarative region where the declaration appears and also introduce a
-(possibly not visible) name into an enclosing namespace; these
-restrictions apply to both regions. — *end note*]
-For a given declarative region *R* and a point *P* outside *R*, the set
-of *intervening* declarative regions between *P* and *R* comprises all
-declarative regions that are or enclose *R* and do not enclose *P*.
-[*Note 3*: The name lookup rules are summarized in
-[[basic.lookup]]. — *end note*]
 ### Point of declaration <a id="basic.scope.pdecl">[[basic.scope.pdecl]]</a>
-The *point of declaration* for a name is immediately after its complete
-declarator [[dcl.decl]] and before its *initializer* (if any), except as
-noted below.
 [*Example 1*:
 ``` cpp
 unsigned char x = 12;
@@ -677,12 +822,12 @@ because the initializer accesses the second `x` outside its lifetime
 — *end example*]
 [*Note 1*:
-A name from an outer scope remains visible up to the point of
-declaration of the name that hides it.
 [*Example 2*:
 ``` cpp
 const int  i = 2;
@@ -693,25 +838,21 @@ declares a block-scope array of two integers.
 — *end example*]
 — *end note*]
-The point of declaration for a class or class template first declared by
-a *class-specifier* is immediately after the *identifier* or
-*simple-template-id* (if any) in its *class-head* [[class.pre]]. 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 *defining-type-id* to which the alias refers.
-The point of declaration of a *using-declarator* that does not name a
-constructor is immediately after the *using-declarator*
-[[namespace.udecl]].
-The point of declaration for an enumerator is immediately after its
-*enumerator-definition*.
 [*Example 3*:
 ``` cpp
 const int x = 12;
@@ -721,113 +862,125 @@ const int x = 12;
 Here, the enumerator `x` is initialized with the value of the constant
 `x`, namely 12.
 — *end example*]
-After the point of declaration of a class member, the member name can be
-looked up in the scope of its class.
 [*Note 2*:
-This is true even if the class is an incomplete class. For example,
 ``` cpp
 struct X {
   enum E { z = 16 };
   int b[X::z];          // OK
 };
 ```
 — *end note*]
-The point of declaration of a class first declared in an
-*elaborated-type-specifier* is as follows:
-- for a declaration of the form
-  ``` bnf
-  class-key attribute-specifier-seqₒₚₜ identifier ';'
-  ```
-  the *identifier* is declared to be a *class-name* in the scope that
-  contains the declaration, otherwise
-- for an *elaborated-type-specifier* of the form
-  ``` bnf
-  class-key identifier
-  ```
-  if the *elaborated-type-specifier* is used in the *decl-specifier-seq*
-  or *parameter-declaration-clause* of a function defined in namespace
-  scope, the *identifier* is declared as a *class-name* in the namespace
-  that contains the declaration; otherwise, except as a friend
-  declaration, the *identifier* is declared in the smallest namespace or
-  block scope that contains the declaration.
-  \[*Note 3*: These rules also apply within templates. — *end note*]
-  \[*Note 4*: Other forms of *elaborated-type-specifier* do not declare
-  a new name, and therefore must refer to an existing *type-name*. See
-  [[basic.lookup.elab]] and  [[dcl.type.elab]]. — *end note*]
-The point of declaration for an injected-class-name [[class.pre]] is
 immediately following the opening brace of the class definition.
-The point of declaration for a function-local predefined variable
-[[dcl.fct.def.general]] is immediately before the *function-body* of a
-function definition.
-The point of declaration of a structured binding [[dcl.struct.bind]] is
-immediately after the *identifier-list* of the structured binding
 declaration.
-The point of declaration for the variable or the structured bindings
-declared in the *for-range-declaration* of a range-based `for` statement
 [[stmt.ranged]] is immediately after the *for-range-initializer*.
-The point of declaration for a template parameter is immediately after
-its complete *template-parameter*.
-[*Example 4*:
 ``` cpp
 typedef unsigned char T;
 template<class T
-  = T               // lookup finds the typedef name of unsigned char
   , T               // lookup finds the template parameter
     N = 0> struct A { };
 ```
 — *end example*]
-[*Note 5*: Friend declarations refer to functions or classes that are
-members of the nearest enclosing namespace, but they do not introduce
-new names into that namespace [[namespace.memdef]]. Function
-declarations at 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. — *end note*]
 [*Note 6*: For point of instantiation of a template, see
 [[temp.point]]. — *end note*]
 ### 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 name declared in an *exception-declaration* is local to the
-*handler* and shall not be redeclared in the outermost block of the
-*handler*.
-Names declared in the *init-statement*, the *for-range-declaration*, and
-in the *condition* of `if`, `while`, `for`, and `switch` statements are
-local to the `if`, `while`, `for`, or `switch` statement (including the
-controlled statement), and shall not be redeclared in a subsequent
-condition of that statement nor in the outermost block (or, for the `if`
-statement, any of the outermost blocks) of the controlled statement.
 [*Example 1*:
 ``` cpp
 if (int x = f()) {
   int x;            // error: redeclaration of x
 }
 else {
@@ -837,364 +990,574 @@ else {
 — *end example*]
 ### Function parameter scope <a id="basic.scope.param">[[basic.scope.param]]</a>
-A function parameter (including one appearing in a *lambda-declarator*)
-or function-local predefined variable [[dcl.fct.def]] has *function
-parameter scope*. The potential scope of a parameter or function-local
-predefined variable begins at its point of declaration. If the nearest
-enclosing function declarator is not the declarator of a function
-definition, the potential scope ends at the end of that function
-declarator. Otherwise, if the function has a *function-try-block* the
-potential scope ends at the end of the last associated handler.
-Otherwise the potential scope ends at the end of the outermost block of
-the function definition. A parameter name shall not be redeclared in the
-outermost block of the function definition nor in the outermost block of
-any handler associated with a *function-try-block*.
-### Function scope <a id="basic.funscope">[[basic.funscope]]</a>
-Labels [[stmt.label]] have *function scope* and may be used anywhere in
-the function in which they are declared. Only labels have function
-scope.
 ### Namespace scope <a id="basic.scope.namespace">[[basic.scope.namespace]]</a>
-The declarative region of a *namespace-definition* is its
-*namespace-body*. Entities declared in a *namespace-body* are said to be
-*members* of the namespace, and names introduced by these declarations
-into the declarative region of the namespace are said to be *member
-names* of the namespace. A namespace member name has namespace scope.
-Its potential scope includes its namespace from the name’s point of
-declaration [[basic.scope.pdecl]] onwards; and for each
-*using-directive* [[namespace.udir]] that nominates the member’s
-namespace, the member’s potential scope includes that portion of the
-potential scope of the *using-directive* that follows the member’s point
-of declaration.
 [*Example 1*:
 ``` cpp
-namespace N {
- int i;
- int g(int a) { return a; }
-  int j();
-  void q();
   }
-namespace { int l=1; }
-// the potential scope of l is from its point of declaration to the end of the translation unit
-namespace N {
-  int g(char a) {   // overloads N::g(int)
-    return l+a;     // l is from unnamed namespace
-  }
-  int i;            // error: duplicate definition
-  int j();          // OK: duplicate function declaration
-  int j() {         // OK: definition of N::j()
-    return g(i);    // calls N::g(int)
-  }
-  int q();          // error: different return type
 }
 ```
 — *end example*]
-If a translation unit Q is imported into a translation unit R
-[[module.import]], the potential scope of a name X declared with
-namespace scope in Q is extended to include the portion of the
-corresponding namespace scope in R following the first
-*module-import-declaration* or *module-declaration* in R that imports Q
-(directly or indirectly) if
-- X does not have internal linkage, and
-- X is declared after the *module-declaration* in Q (if any), and
-- either X is exported or Q and R are part of the same module.
-[*Note 1*:
-A *module-import-declaration* imports both the named translation unit(s)
-and any modules named by exported *module-import-declaration*s within
-them, recursively.
-[*Example 2*:
-Translation unit #1
-``` cpp
-export module Q;
-export int sq(int i) { return i*i; }
-```
-Translation unit #2
-``` cpp
-export module R;
-export import Q;
-```
-Translation unit #3
-``` cpp
-import R;
-int main() { return sq(9); }    // OK: sq from module Q
-```
-— *end example*]
-— *end note*]
-A namespace member can also be referred to after the `::` scope
-resolution operator [[expr.prim.id.qual]] applied to the name of its
-namespace or the name of a namespace which nominates the member’s
-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. 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 potential scope of a name declared in a class consists not only of
-the declarative region following the name’s point of declaration, but
-also of all complete-class contexts [[class.mem]] of that class.
-A name `N` used in a class `S` shall refer to the same declaration in
-its context and when re-evaluated in the completed scope of `S`. No
-diagnostic is required for a violation of this rule.
-A name declared within a member function hides a declaration of the same
-name whose scope extends to or past the end of the member function’s
-class.
-The potential scope of a declaration in a class that extends to or past
-the end of a class definition also extends to the regions defined by its
-member definitions, even if the members are defined lexically outside
-the class (this includes static data member definitions, nested class
-definitions, and member function definitions, including the member
-function body and any portion of the declarator part of such definitions
-which follows the *declarator-id*, including a
-*parameter-declaration-clause* and any default arguments
-[[dcl.fct.default]]).
 [*Example 1*:
 ``` cpp
-typedef int  c;
-enum { i = 1 };
-class X {
-  char  v[i];                       // error: i refers to ::i but when reevaluated is X::i
-  int  f() { return sizeof(c); }    // OK: X::c
-  char  c;
-  enum { i = 2 };
-};
-typedef char*  T;
-struct Y {
-  T  a;                             // error: T refers to ::T but when reevaluated is Y::T
-  typedef long  T;
-  T  b;
 };
-typedef int I;
-class D {
-  typedef I I;                      // error, even though no reordering involved
-};
 ```
 — *end example*]
-The name of a class member shall only be used as follows:
-- in the scope of its class (as described above) or a class derived
-  [[class.derived]] from its class,
-- after the `.` operator applied to an expression of the type of its
-  class [[expr.ref]] or a class derived from its class,
-- after the `->` operator applied to a pointer to an object of its class
-  [[expr.ref]] or a class derived from its class,
-- after the `::` scope resolution operator [[expr.prim.id.qual]] applied
-  to the name of its class or a class derived from its class.
 ### Enumeration scope <a id="basic.scope.enum">[[basic.scope.enum]]</a>
-The name of a scoped enumerator [[dcl.enum]] has *enumeration scope*.
-Its potential scope begins at its point of declaration and terminates at
-the end of the *enum-specifier*.
 ### Template parameter scope <a id="basic.scope.temp">[[basic.scope.temp]]</a>
-The declarative region of the name of a template parameter of a template
-*template-parameter* is the smallest *template-parameter-list* in which
-the name was introduced.
-The declarative region of the name of a template parameter of a template
-is the smallest *template-declaration* in which the name was introduced.
-Only template parameter names belong to this declarative region; any
-other kind of name introduced by the *declaration* of a
-*template-declaration* is instead introduced into the same declarative
-region where it would be introduced as a result of a non-template
-declaration of the same name.
-[*Example 1*:
-``` cpp
-namespace N {
-  template<class T> struct A { };               // #1
-  template<class U> void f(U) { }               // #2
-  struct B {
-    template<class V> friend int g(struct C*);  // #3
-  };
-}
-```
-The declarative regions of `T`, `U` and `V` are the
-*template-declaration*s on lines \#1, \#2, and \#3, respectively. But
-the names `A`, `f`, `g` and `C` all belong to the same declarative
-region — namely, the *namespace-body* of `N`. (`g` is still considered
-to belong to this declarative region in spite of its being hidden during
-qualified and unqualified name lookup.)
-— *end example*]
-The potential scope of a template parameter name begins at its point of
-declaration [[basic.scope.pdecl]] and ends at the end of its declarative
-region.
-[*Note 1*:
-This implies that a *template-parameter* can be used in the declaration
-of subsequent *template-parameter*s and their default arguments but
-cannot be used in preceding *template-parameter*s or their default
-arguments. For example,
-``` cpp
-template<class T, T* p, class U = T> class X { ... };
-template<class T> void f(T* p = new T);
-```
-This also implies that a *template-parameter* can be used in the
-specification of base classes. For example,
-``` cpp
-template<class T> class X : public Array<T> { ... };
-template<class T> class Y : public T { ... };
-```
-The use of a template parameter as a base class implies that a class
-used as a template argument must be defined and not just declared when
-the class template is instantiated.
-— *end note*]
-The declarative region of the name of a template parameter is nested
-within the immediately-enclosing declarative region.
-[*Note 2*:
-As a result, a *template-parameter* hides any entity with the same name
-in an enclosing scope [[basic.scope.hiding]].
-[*Example 2*:
-``` cpp
-typedef int N;
-template<N X, typename N, template<N Y> class T> struct A;
-```
-Here, `X` is a non-type template parameter of type `int` and `Y` is a
-non-type template parameter of the same type as the second template
-parameter of `A`.
-— *end example*]
-— *end note*]
-[*Note 3*: Because the name of a template parameter cannot be
-redeclared within its potential scope [[temp.local]], a template
-parameter’s scope is often its potential scope. However, it is still
-possible for a template parameter name to be hidden; see
-[[temp.local]]. — *end note*]
-### Name hiding <a id="basic.scope.hiding">[[basic.scope.hiding]]</a>
-A declaration of a name in a nested declarative region hides a
-declaration of the same name in an enclosing declarative region; see
-[[basic.scope.declarative]] and [[basic.lookup.unqual]].
-If a class name [[class.name]] or enumeration name [[dcl.enum]] and a
-variable, data member, function, or enumerator are declared in the same
-declarative region (in any order) with the same name (excluding
-declarations made visible via *using-directive*s
-[[basic.lookup.unqual]]), the class or enumeration name is hidden
-wherever the variable, data member, function, or enumerator name is
-visible.
-In a member function definition, the declaration of a name at block
-scope hides the declaration of a member of the class with the same name;
-see  [[basic.scope.class]]. The declaration of a member in a derived
-class [[class.derived]] hides the declaration of a member of a base
-class of the same name; see  [[class.member.lookup]].
-During the lookup of a name qualified by a namespace name, declarations
-that would otherwise be made visible by a *using-directive* can be
-hidden by declarations with the same name in the namespace containing
-the *using-directive*; see  [[namespace.qual]].
-If a name is in scope and is not hidden it is said to be *visible*.
 ## Name lookup <a id="basic.lookup">[[basic.lookup]]</a>
 The name lookup rules apply uniformly to all names (including
 *typedef-name*s [[dcl.typedef]], *namespace-name*s [[basic.namespace]],
 and *class-name*s [[class.name]]) wherever the grammar allows such names
 in the context discussed by a particular rule. Name lookup associates
 the use of a name with a set of declarations [[basic.def]] of that name.
-If the declarations found by name lookup all denote functions or
-function templates, the declarations are said to form an *overload set*.
-The declarations found by name lookup shall either all denote the same
-entity or form an overload set. Overload resolution ([[over.match]],
-[[over.over]]) takes place after name lookup has succeeded. The access
-rules [[class.access]] are considered only once name lookup and function
-overload resolution (if applicable) have succeeded. Only after name
-lookup, function overload resolution (if applicable) and access checking
-have succeeded are the semantic properties introduced by the name’s
-declaration and its reachable [[module.reach]] redeclarations used
-further in expression processing [[expr]].
-A name “looked up in the context of an expression” is looked up in the
-scope where the expression is found.
-The injected-class-name of a class [[class.pre]] is also considered to
-be a member of that class for the purposes of name hiding and lookup.
-[*Note 1*:  [[basic.link]] discusses linkage issues. The notions of
-scope, point of declaration and name hiding are discussed in
-[[basic.scope]]. — *end note*]
 ### Unqualified name lookup <a id="basic.lookup.unqual">[[basic.lookup.unqual]]</a>
-In all the cases listed in  [[basic.lookup.unqual]], the scopes are
-searched for a declaration in the order listed in each of the respective
-categories; name lookup ends as soon as a declaration is found for the
-name. If no declaration is found, the program is ill-formed.
-The declarations from the namespace nominated by a *using-directive*
-become visible in a namespace enclosing the *using-directive*; see
-[[namespace.udir]]. For the purpose of the unqualified name lookup rules
-described in  [[basic.lookup.unqual]], the declarations from the
-namespace nominated by the *using-directive* are considered members of
-that enclosing namespace.
-The lookup for an unqualified name used as the *postfix-expression* of a
-function call is described in  [[basic.lookup.argdep]].
 [*Note 1*:
 For purposes of determining (during parsing) whether an expression is a
 *postfix-expression* for a function call, the usual name lookup rules
@@ -1210,17 +1573,17 @@ namespace N {
   template <class T> int f(T);
   template <class T> int g(T);
   template <class T> int h(T);
 }
-int x = f<N::A>(N::A());        // OK: lookup of f finds nothing, f treated as template name
-int y = g<N::A>(N::A());        // OK: lookup of g finds a function, g treated as template name
 int z = h<N::A>(N::A());        // error: h< does not begin a template-id
 ```
-The rules in  [[basic.lookup.argdep]] have no effect on the syntactic
-interpretation of an expression. For example,
 ``` cpp
 typedef int f;
 namespace N {
   struct A {
@@ -1231,398 +1594,79 @@ namespace N {
     }
   };
 }
 ```
-Because the expression is not a function call, the argument-dependent
-name lookup [[basic.lookup.argdep]] does not apply and the friend
-function `f` is not found.
 — *end note*]
-A name used in global scope, outside of any function, class or
-user-declared namespace, shall be declared before its use in global
-scope.
-A name used in a user-declared namespace outside of the definition of
-any function or class shall be declared before its use in that namespace
-or before its use in a namespace enclosing its namespace.
-In the definition of a function that is a member of namespace `N`, a
-name used after the function’s *declarator-id*[^3] shall be declared
-before its use in the block in which it is used or in one of its
-enclosing blocks [[stmt.block]] or shall be declared before its use in
-namespace `N` or, if `N` is a nested namespace, shall be declared before
-its use in one of `N`’s enclosing namespaces.
-[*Example 1*:
-``` cpp
-namespace A {
-  namespace N {
-    void f();
-  }
-}
-void A::N::f() {
-  i = 5;
-  // The following scopes are searched for a declaration of i:
-  // 1) outermost block scope of A::N::f, before the use of i
-  // 2) scope of namespace N
-  // 3) scope of namespace A
-  // 4) global scope, before the definition of A::N::f
-}
-```
-— *end example*]
-A name used in the definition of a class `X` [^4] outside of a
-complete-class context [[class.mem]] of `X` 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`
-  (this lookup applies in turn to `Y`’s enclosing classes, starting with
-  the innermost enclosing class),[^5] or
-- if `X` is a local class [[class.local]] or is a nested class of a
-  local class, before the definition of class `X` in a block enclosing
-  the definition of class `X`, or
-- if `X` is a member of namespace `N`, or is a nested class of a class
-  that is a member of `N`, or is a local class or a nested class within
-  a local class of a function that is a member of `N`, before the
-  definition of class `X` in namespace `N` or in one of `N`’s enclosing
-  namespaces.
-[*Example 2*:
-``` cpp
-namespace M {
-  class B { };
-}
-```
-``` cpp
-namespace N {
-  class Y : public M::B {
-    class X {
-      int a[i];
-    };
-  };
-}
-// The following scopes are searched for a declaration of i:
-// 1) scope of class N::Y::X, before the use of i
-// 2) scope of class N::Y, before the definition of N::Y::X
-// 3) scope of N::Y's base class M::B
-// 4) scope of namespace N, before the definition of N::Y
-// 5) global scope, before the definition of N
-```
-— *end example*]
-[*Note 2*: When looking for a prior declaration of a class or function
-introduced by a friend declaration, scopes outside of the innermost
-enclosing namespace scope are not considered; see
-[[namespace.memdef]]. — *end note*]
-[*Note 3*:  [[basic.scope.class]] further describes the restrictions on
-the use of 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. — *end note*]
-For the members of a class `X`, a name used in a complete-class context
-[[class.mem]] of `X` or in the definition of a class member outside of
-the definition of `X`, following the member’s *declarator-id*[^6], 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
-- if `X` is a nested class of class `Y` [[class.nest]], shall be a
-  member of `Y`, or shall be a member of a base class of `Y` (this
-  lookup applies in turn to `Y`’s enclosing classes, starting with the
-  innermost enclosing class),[^7] or
-- if `X` is a local class [[class.local]] or is a nested class of a
-  local class, before the definition of class `X` in a block enclosing
-  the definition of class `X`, or
-- if `X` is a member of namespace `N`, or is a nested class of a class
-  that is a member of `N`, or is a local class or a nested class within
-  a local class of a function that is a member of `N`, before the use of
-  the name, in namespace `N` or in one of `N`’s enclosing namespaces.
-[*Example 3*:
-``` cpp
-class B { };
-namespace M {
-  namespace N {
-    class X : public B {
-      void f();
-    };
-  }
-}
-void M::N::X::f() {
-  i = 16;
-}
-// The following scopes are searched for a declaration of i:
-// 1) outermost block scope of M::N::X::f, before the use of i
-// 2) scope of class M::N::X
-// 3) scope of M::N::X's base class B
-// 4) scope of namespace M::N
-// 5) scope of namespace M
-// 6) global scope, before the definition of M::N::X::f
-```
-— *end example*]
-[*Note 4*:  [[class.mfct]] and  [[class.static]] further describe the
-restrictions on the use of names in member function definitions.
-[[class.nest]] further describes the restrictions on the use of names in
-the scope of nested classes. [[class.local]] further describes the
-restrictions on the use of names in local class
-definitions. — *end note*]
-Name lookup for a name used in the definition of a friend function
-[[class.friend]] defined inline in the class granting friendship shall
-proceed as described for lookup in member function definitions. If the
-friend function is not defined in the class granting friendship, name
-lookup in the friend function definition shall proceed as described for
-lookup in namespace member function definitions.
-In a friend declaration naming a member function, a name used in the
-function declarator and not part of a *template-argument* in the
-*declarator-id* is first looked up in the scope of the member function’s
-class [[class.member.lookup]]. If it is not found, or if the name is
-part of a *template-argument* in the *declarator-id*, the look up is as
-described for unqualified names in the definition of the class granting
-friendship.
-[*Example 4*:
-``` cpp
-struct A {
-  typedef int AT;
-  void f1(AT);
-  void f2(float);
-  template <class T> void f3();
-};
-struct B {
-  typedef char AT;
-  typedef float BT;
-  friend void A::f1(AT);        // parameter type is A::AT
-  friend void A::f2(BT);        // parameter type is B::BT
-  friend void A::f3<AT>();      // template argument is B::AT
-};
-```
-— *end example*]
-During the lookup for a name used as a default argument
-[[dcl.fct.default]] in a function *parameter-declaration-clause* or used
-in the *expression* of a *mem-initializer* for a constructor
-[[class.base.init]], the function parameter names are visible and hide
-the names of entities declared in the block, class or namespace scopes
-containing the function declaration.
-[*Note 5*:  [[dcl.fct.default]] further describes the restrictions on
-the use of names in default arguments. [[class.base.init]] further
-describes the restrictions on the use of names in a
-*ctor-initializer*. — *end note*]
-During the lookup of a name used in the *constant-expression* of an
-*enumerator-definition*, previously declared *enumerator*s of the
-enumeration are visible and hide the names of entities declared in the
-block, class, or namespace scopes containing the *enum-specifier*.
-A name used in the definition of a `static` data member of class `X`
-[[class.static.data]] (after the *qualified-id* of the static member) is
-looked up as if the name was used in a member function of `X`.
-[*Note 6*:  [[class.static.data]] further describes the restrictions on
-the use of names in the definition of a `static` data
-member. — *end note*]
-If a variable member of a namespace is defined outside of the scope of
-its namespace then any name that appears in the definition of the member
-(after the *declarator-id*) is looked up as if the definition of the
-member occurred in its namespace.
-[*Example 5*:
-``` cpp
-namespace N {
-  int i = 4;
-  extern int j;
-}
-int i = 2;
-int N::j = i;       // N::j == 4
-```
-— *end example*]
-A name used in the handler for a *function-try-block* [[except.pre]] is
-looked up as if the name was used in the outermost block of the function
-definition. In particular, the function parameter names shall not be
-redeclared in the *exception-declaration* nor in the outermost block of
-a handler for the *function-try-block*. Names declared in the outermost
-block of the function definition are not found when looked up in the
-scope of a handler for the *function-try-block*.
-[*Note 7*: But function parameter names are found. — *end note*]
-[*Note 8*: The rules for name lookup in template definitions are
-described in  [[temp.res]]. — *end note*]
-### 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).
-[*Example 1*:
-``` cpp
-namespace N {
-  struct S { };
-  void f(S);
-}
-void g() {
-  N::S s;
-  f(s);             // OK: calls N::f
-  (f)(s);           // error: N::f not considered; parentheses prevent argument-dependent lookup
-}
-```
-— *end example*]
 For each argument type `T` in the function call, there is a set of zero
-or more *associated namespaces* and a set of zero or more *associated
-entities* (other than namespaces) to be considered. The sets of
-namespaces and entities are determined entirely by the types of the
-function arguments (and the namespace of any template template
-argument). Typedef names and *using-declaration*s used to specify the
-types do not contribute to this set. The sets of namespaces and entities
-are determined in the following way:
-- If `T` is a fundamental type, its associated sets of namespaces and
-  entities are both empty.
 - If `T` is a class type (including unions), its associated entities
   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 entities.
- Furthermore, if `T` is a class template specialization, its associated
- namespaces and entities also include: the namespaces and entities
- associated with the types of the template arguments provided for
-  template type parameters (excluding template template parameters); the
- templates used as template template arguments; 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.
- \[*Note 1*: Non-type template arguments do not contribute to the set
-  of associated namespaces. — *end note*]
-- If `T` is an enumeration type, its associated namespace is the
-  innermost enclosing namespace of its declaration, and its associated
- entities are `T` and, if it is a class member, the member’s class.
-- If `T` is a pointer to `U` or an array of `U`, its associated
-  namespaces and entities are those associated with `U`.
-- If `T` is a function type, its associated namespaces and entities are
-  those associated with the function parameter types and those
-  associated with the return type.
 - If `T` is a pointer to a member function of a class `X`, its
-  associated namespaces and entities are those associated with the
- function parameter types and return type, together with those
-  associated with `X`.
 - If `T` is a pointer to a data member of class `X`, its associated
- namespaces and entities are those associated with the member type
- together with those associated with `X`.
-If an associated namespace is an inline namespace [[namespace.def]], its
-enclosing namespace is also included in the set. If an associated
-namespace directly contains inline namespaces, those inline namespaces
-are also included in the set. In addition, if the argument is the name
-or address of an overload set, its associated entities and namespaces
-are the union of those associated with each of the members of the set,
-i.e., the entities and namespaces associated with its parameter types
-and return type. Additionally, if the aforementioned overload set is
-named with a *template-id*, its associated entities and namespaces also
-include those of its type *template-argument*s and its template
-*template-argument*s.
-Let *X* be the lookup set produced by unqualified lookup
-[[basic.lookup.unqual]] and let *Y* be the lookup set produced by
-argument dependent lookup (defined as follows). If *X* contains
-- a declaration of a class member, or
-- a block-scope function declaration that is not a *using-declaration*,
-  or
-- a declaration that is neither a function nor a function template
-then *Y* is empty. Otherwise *Y* is the set of declarations found in the
-namespaces associated with the argument types as described below. The
-set of declarations found by the lookup of the name is the union of *X*
-and *Y*.
-[*Note 2*: The namespaces and entities associated with the argument
-types can include namespaces and entities already considered by the
-ordinary unqualified lookup. — *end note*]
 [*Example 2*:
-``` cpp
-namespace NS {
-  class T { };
-  void f(T);
-  void g(T, int);
-}
-NS::T parm;
-void g(NS::T, float);
-int main() {
-  f(parm);                      // OK: calls NS::f
-  extern void g(NS::T, float);
-  g(parm, 1);                   // OK: calls g(NS::T, float)
-}
-```
-— *end example*]
-When considering an associated namespace `N`, the lookup is the same as
-the lookup performed when `N` is used as a qualifier [[namespace.qual]]
-except that:
-- Any *using-directive*s in `N` are ignored.
-- All names except those of (possibly overloaded) functions and function
-  templates are ignored.
-- Any namespace-scope friend functions or friend function templates
-  [[class.friend]] declared in classes with reachable definitions in the
-  set of associated entities are visible within their respective
-  namespaces even if they are not visible during an ordinary lookup
-  [[namespace.memdef]].
-- Any exported declaration `D` in `N` declared within the purview of a
-  named module `M` [[module.interface]] is visible if there is an
-  associated entity attached to `M` with the same innermost enclosing
-  non-inline namespace as `D`.
-- If the lookup is for a dependent name ([[temp.dep]],
-  [[temp.dep.candidate]]), any declaration `D` in `N` is visible if `D`
-  would be visible to qualified name lookup [[namespace.qual]] at any
-  point in the instantiation context [[module.context]] of the lookup,
-  unless `D` is declared in another translation unit, attached to the
-  global module, and is either discarded [[module.global.frag]] or has
-  internal linkage.
-[*Example 3*:
 Translation unit #1
 ``` cpp
 export module M;
 namespace R {
@@ -1666,21 +1710,42 @@ void test() {
 }
 ```
 — *end example*]
 ### Qualified name lookup <a id="basic.lookup.qual">[[basic.lookup.qual]]</a>
-The name of a class or namespace member or enumerator can be referred to
-after the `::` scope resolution operator [[expr.prim.id.qual]] applied
-to a *nested-name-specifier* that denotes its class, namespace, or
-enumeration. If a `::` scope resolution operator in a
-*nested-name-specifier* is not preceded by a *decltype-specifier*,
-lookup of the name preceding that `::` considers only namespaces, types,
-and templates whose specializations are types. If the name found does
-not designate a namespace or a class, enumeration, or dependent type,
-the program is ill-formed.
 [*Example 1*:
 ``` cpp
 class A {
@@ -1690,70 +1755,137 @@ public:
 int main() {
   int A;
   A::n = 42;            // OK
   A b;                  // error: A does not name a type
 }
 ```
 — *end example*]
-[*Note 1*: Multiply qualified names, such as `N1::N2::N3::n`, can be
-used to refer to members of nested classes [[class.nest]] or members of
-nested namespaces. — *end note*]
-In a declaration in which the *declarator-id* is a *qualified-id*, names
-used before the *qualified-id* being declared are looked up in the
-defining namespace scope; names following the *qualified-id* are looked
-up in the scope of the member’s class or namespace.
 [*Example 2*:
 ``` cpp
-class X { };
-class C {
-  class X { };
-  static const int number = 50;
-  static X arr[number];
-};
-X C::arr[number];   // error:
-                    // equivalent to ::X C::arr[C::number];
-                    // and not to C::X C::arr[C::number];
 ```
 — *end example*]
-A name prefixed by the unary scope operator `::` [[expr.prim.id.qual]]
-is looked up in global scope, in the translation unit where it is used.
-The name shall be declared in global namespace scope or shall be a name
-whose declaration is visible in global scope because of a
-*using-directive* [[namespace.qual]]. The use of `::` allows a global
-name to be referred to even if its identifier has been hidden
-[[basic.scope.hiding]].
-A name prefixed by a *nested-name-specifier* that nominates an
-enumeration type shall represent an *enumerator* of that enumeration.
-In a *qualified-id* of the form:
-``` bnf
-nested-name-specifierₒₚₜ type-name '::' '~' type-name
-```
-the second *type-name* is looked up in the same scope as the first.
 [*Example 3*:
 ``` cpp
 struct C {
   typedef int I;
 };
 typedef int I1, I2;
 extern int* p;
 extern int* q;
   p->C::I::~I();        // I is looked up in the scope of C
-q->I1::~I2(); // I2 is looked up in the scope of the postfix-expression
 struct A {
   ~A();
 };
 typedef A AB;
 int main() {
@@ -1762,55 +1894,22 @@ int main() {
 }
 ```
 — *end example*]
-[*Note 2*:  [[basic.lookup.classref]] describes how name lookup
-proceeds after the `.` and `->` operators. — *end note*]
 #### Class members <a id="class.qual">[[class.qual]]</a>
-If the *nested-name-specifier* of a *qualified-id* nominates a class,
-the name specified after the *nested-name-specifier* is looked up in the
-scope of the class [[class.member.lookup]], except for the cases listed
-below. The name shall represent one or more members of that class or of
-one of its base classes [[class.derived]].
-[*Note 1*: A class member can be referred to using a *qualified-id* at
-any point in its potential scope [[basic.scope.class]]. — *end note*]
-The exceptions to the name lookup rule above are the following:
-- the lookup for a destructor is as specified in  [[basic.lookup.qual]];
-- a *conversion-type-id* of a *conversion-function-id* is looked up in
-  the same manner as a *conversion-type-id* in a class member access
-  (see  [[basic.lookup.classref]]);
-- the names in a *template-argument* of a *template-id* are looked up in
-  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[^8] 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` [[class.pre]], or
-- in a *using-declarator* of a *using-declaration* [[namespace.udecl]]
-  that is a *member-declaration*, if the name specified after the
-  *nested-name-specifier* is the same as the *identifier* or the
-  *simple-template-id*’s *template-name* in the last component of the
-  *nested-name-specifier*,
-the name is instead considered to name the constructor of class `C`.
-[*Note 2*: For example, the constructor is not an acceptable lookup
-result in an *elaborated-type-specifier* so the constructor would not be
-used in place of the injected-class-name. — *end note*]
-Such a constructor name shall be used only in the *declarator-id* of a
-declaration that names a constructor or in a *using-declaration*.
 [*Example 1*:
 ``` cpp
 struct A { A(); };
@@ -1824,39 +1923,21 @@ A::A a;             // error: A::A is not a type name
 struct A::A a2;     // object of type A
 ```
 — *end example*]
-A class member name hidden by a name in a nested declarative region or
-by the name of a derived class member can still be found if qualified by
-the name of its class followed by the `::` operator.
 #### Namespace members <a id="namespace.qual">[[namespace.qual]]</a>
-If the *nested-name-specifier* of a *qualified-id* nominates a namespace
-(including the case where the *nested-name-specifier* is `::`, i.e.,
-nominating the global namespace), the name specified after the
-*nested-name-specifier* is looked up in the scope of the namespace. The
-names in a *template-argument* of a *template-id* are looked up in the
-context in which the entire *postfix-expression* occurs.
-For a namespace `X` and name `m`, the namespace-qualified lookup set
-S(X, m) is defined as follows: Let S'(X, m) be the set of all
-declarations of `m` in `X` and the inline namespace set of `X`
-[[namespace.def]] whose potential scope [[basic.scope.namespace]] would
-include the namespace in which `m` is declared at the location of the
-*nested-name-specifier*. If S'(X, m) is not empty, S(X, m) is S'(X, m);
-otherwise, S(X, m) is the union of S(Nᵢ, m) for all namespaces Nᵢ
-nominated by *using-directive*s in `X` and its inline namespace set.
-Given `X::m` (where `X` is a user-declared namespace), or given `::m`
-(where X is the global namespace), if S(X, m) is the empty set, the
-program is ill-formed. Otherwise, if S(X, m) has exactly one member, or
-if the context of the reference is a *using-declaration*
-[[namespace.udecl]], S(X, m) is the required set of declarations of `m`.
-Otherwise if the use of `m` is not one that allows a unique declaration
-to be chosen from S(X, m), the program is ill-formed.
 [*Example 1*:
 ``` cpp
 int x;
@@ -1910,11 +1991,11 @@ void h()
 }
 ```
 — *end example*]
-[*Note 1*:
 The same declaration found more than once is not an ambiguity (because
 it is still a unique declaration).
 [*Example 2*:
@@ -1937,11 +2018,11 @@ namespace BC {
   using namespace C;
 }
 void f()
 {
-  BC::a++;          // OK: S is { `A::a`, `A::a` }
 }
 namespace D {
   using A::a;
 }
@@ -1951,11 +2032,11 @@ namespace BD {
   using namespace D;
 }
 void g()
 {
-  BD::a++;          // OK: S is { `A::a`, `A::a` }
 }
 ```
 — *end example*]
@@ -1980,26 +2061,21 @@ namespace B {
   using namespace A;
 }
 void f()
 {
-  A::a++;           // OK: a declared directly in A, S is { `A::a` }
-  B::a++;           // OK: both A and B searched (once), S is { `A::a` }
-  A::b++;           // OK: both A and B searched (once), S is { `B::b` }
-  B::b++;           // OK: b declared directly in B, S is { `B::b` }
 }
 ```
 — *end example*]
-During the lookup of a qualified namespace member name, if the lookup
-finds more than one declaration of the member, and if one declaration
-introduces a class name or enumeration name and the other declarations
-introduce either the same variable, the same enumerator, or a set of
-functions, the non-type name hides the class or enumeration name if and
-only if the declarations are from the same namespace; otherwise (the
-declarations are from different namespaces), the program is ill-formed.
 [*Example 4*:
 ``` cpp
 namespace A {
@@ -2020,221 +2096,55 @@ namespace C {
 }
 ```
 — *end example*]
-In a declaration for a namespace member in which the *declarator-id* is
-a *qualified-id*, given that the *qualified-id* for the namespace member
-has the form
-``` bnf
-nested-name-specifier unqualified-id
-```
-the *unqualified-id* shall name a member of the namespace designated by
-the *nested-name-specifier* or of an element of the inline namespace set
-[[namespace.def]] of that namespace.
-[*Example 5*:
-``` cpp
-namespace A {
-  namespace B {
-    void f1(int);
-  }
-  using namespace B;
-}
-void A::f1(int){ }  // error: f1 is not a member of A
-```
-— *end example*]
-However, in such namespace member declarations, the
-*nested-name-specifier* may rely on *using-directive*s to implicitly
-provide the initial part of the *nested-name-specifier*.
-[*Example 6*:
-``` cpp
-namespace A {
-  namespace B {
-    void f1(int);
-  }
-}
-namespace C {
-  namespace D {
-    void f1(int);
-  }
-}
-using namespace A;
-using namespace C::D;
-void B::f1(int){ }  // OK, defines A::B::f1(int)
-```
-— *end example*]
 ### Elaborated type specifiers <a id="basic.lookup.elab">[[basic.lookup.elab]]</a>
-An *elaborated-type-specifier* [[dcl.type.elab]] may be used to refer to
-a previously declared *class-name* or *enum-name* even though the name
-has been hidden by a non-type declaration [[basic.scope.hiding]].
-If the *elaborated-type-specifier* has no *nested-name-specifier*, and
-unless the *elaborated-type-specifier* appears in a declaration with the
-following form:
-``` bnf
-class-key attribute-specifier-seqₒₚₜ identifier ';'
-```
-the *identifier* is looked up according to  [[basic.lookup.unqual]] but
-ignoring any non-type names that have been declared. If the
-*elaborated-type-specifier* is introduced by the `enum` keyword and this
-lookup does not find a previously declared *type-name*, the
-*elaborated-type-specifier* is ill-formed. If the
-*elaborated-type-specifier* is introduced by the *class-key* and this
-lookup does not find a previously declared *type-name*, or if the
-*elaborated-type-specifier* appears in a declaration with the form:
-``` bnf
-class-key attribute-specifier-seqₒₚₜ identifier ';'
-```
-the *elaborated-type-specifier* is a declaration that introduces the
-*class-name* as described in  [[basic.scope.pdecl]].
-If the *elaborated-type-specifier* has a *nested-name-specifier*,
-qualified name lookup is performed, as described in
-[[basic.lookup.qual]], but ignoring any non-type names that have been
-declared. If the name lookup does not find a previously declared
-*type-name*, the *elaborated-type-specifier* is ill-formed.
 [*Example 1*:
 ``` cpp
 struct Node {
-  struct Node* Next;            // OK: Refers to injected-class-name Node
-  struct Data* Data;            // OK: Declares type Data at global scope and member Data
 };
 struct Data {
-  struct Node* Node;            // OK: Refers to Node at global scope
   friend struct ::Glob;         // error: Glob is not declared, cannot introduce a qualified type[dcl.type.elab]
-  friend struct Glob;           // OK: Refers to (as yet) undeclared Glob at global scope.
   ...
 };
 struct Base {
-  struct Data;                  // OK: Declares nested Data
-  struct ::Data*     thatData;  // OK: Refers to ::Data
-  struct Base::Data* thisData;  // OK: Refers to nested Data
-  friend class ::Data;          // OK: global Data is a friend
-  friend class Data;            // OK: nested Data is a friend
   struct Data { ... };    // Defines nested Data
 };
-struct Data;                    // OK: Redeclares Data at global scope
 struct ::Data;                  // error: cannot introduce a qualified type[dcl.type.elab]
 struct Base::Data;              // error: cannot introduce a qualified type[dcl.type.elab]
 struct Base::Datum;             // error: Datum undefined
-struct Base::Data* pBase;       // OK: refers to nested Data
-```
-— *end example*]
-### Class member access <a id="basic.lookup.classref">[[basic.lookup.classref]]</a>
-In a class member access expression [[expr.ref]], if the `.` or `->`
-token is immediately followed by an *identifier* followed by a `<`, the
-identifier must be looked up to determine whether the `<` is the
-beginning of a template argument list [[temp.names]] or a less-than
-operator. The identifier is first looked up in the class of the object
-expression [[class.member.lookup]]. If the identifier is not found, it
-is then looked up in the context of the entire *postfix-expression* and
-shall name a template whose specializations are types.
-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`
-[[class.member.lookup]].
-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 cv `T`.
-[*Example 1*:
-``` cpp
-struct A { };
-struct B {
-  struct A { };
-  void f(::A* a);
-};
-void B::f(::A* a) {
-  a->~A();                      // OK: lookup in *a finds the injected-class-name
-}
-```
-— *end example*]
-If the *id-expression* in a class member access is a *qualified-id* of
-the form
-``` cpp
-class-name-or-namespace-name::...
-```
-the `class-name-or-namespace-name` following the `.` or `->` operator is
-first looked up in the class of the object expression
-[[class.member.lookup]] and the name, if found, is used. Otherwise it is
-looked up in the context of the entire *postfix-expression*.
-[*Note 1*: See  [[basic.lookup.qual]], which describes the lookup of a
-name before `::`, which will only find a type or namespace
-name. — *end note*]
-If the *qualified-id* has the form
-``` cpp
-::class-name-or-namespace-name::...
-```
-the `class-name-or-namespace-name` is looked up in global scope as a
-*class-name* or *namespace-name*.
-If the *nested-name-specifier* contains a *simple-template-id*
-[[temp.names]], the names in its *template-argument*s are looked up in
-the context in which the entire *postfix-expression* occurs.
-If the *id-expression* is a *conversion-function-id*, its
-*conversion-type-id* is first looked up in the class of the object
-expression [[class.member.lookup]] and the name, if found, is used.
-Otherwise it is looked up in the context of the entire
-*postfix-expression*. In each of these lookups, only names that denote
-types or templates whose specializations are types are considered.
-[*Example 2*:
-``` cpp
-struct A { };
-namespace N {
-  struct A {
-    void g() { }
-    template <class T> operator T();
-  };
-}
-int main() {
-  N::A a;
-  a.operator A();               // calls N::A::operator N::A
-}
 ```
 — *end example*]
 ### Using-directives and namespace aliases <a id="basic.lookup.udir">[[basic.lookup.udir]]</a>
@@ -2253,11 +2163,11 @@ declarations.
 translation-unit:
     declaration-seqₒₚₜ
     global-module-fragmentₒₚₜ module-declaration declaration-seqₒₚₜ private-module-fragmentₒₚₜ
 ```
-A name is said to have *linkage* when it might denote the same object,
 reference, function, type, template, namespace or value as a name
 introduced by a declaration in another scope:
 - When a name has *external linkage*, the entity it denotes can be
   referred to by names from scopes of other translation units or from
@@ -2269,30 +2179,33 @@ introduced by a declaration in another scope:
 - When a name has *internal linkage*, the entity it denotes can be
   referred to by names from other scopes in the same translation unit.
 - When a name has *no linkage*, the entity it denotes cannot be referred
   to by names from other scopes.
-A name having namespace scope [[basic.scope.namespace]] has internal
-linkage if it is the name of
 - a variable, variable template, function, or function template that is
   explicitly declared `static`; or
 - a non-template variable of non-volatile const-qualified type, unless
   - it is explicitly declared `extern`, or
-  - it is inline or exported, or
   - it was previously declared and the prior declaration did not have
     internal linkage; or
 - a data member of an anonymous union.
 [*Note 1*: An instantiated variable template that has const-qualified
 type can have external or module linkage, even if not declared
 `extern`. — *end note*]
 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
-given internal linkage above and that is the name of
 - a variable; or
 - a function; or
 - a named class [[class.pre]], or an unnamed class defined in a typedef
   declaration in which the class has the typedef name for linkage
@@ -2311,112 +2224,71 @@ has its linkage determined as follows:
 - otherwise, if the declaration of the name is attached to a named
   module [[module.unit]] and is not exported [[module.interface]], the
   name has module linkage;
 - otherwise, the name has external linkage.
-In addition, a member function, static data member, a named class or
-enumeration of class scope, or an unnamed class or enumeration defined
-in a class-scope typedef declaration such that the class or enumeration
-has the typedef name for linkage purposes [[dcl.typedef]], has the same
-linkage, if any, as the name of the class of which it is a member.
-The name of a function declared in block scope and the name of a
-variable declared by a block scope `extern` declaration have linkage. If
-such a declaration is attached to a named module, the program is
-ill-formed. If there is a visible declaration of an entity with linkage,
-ignoring entities declared outside the innermost enclosing namespace
-scope, such that the block scope declaration would be a (possibly
-ill-formed) redeclaration if the two declarations appeared in the same
-declarative region, the block scope declaration declares that same
-entity and receives the linkage of the previous declaration. If there is
-more than one such matching entity, the program is ill-formed.
-Otherwise, if no matching entity is found, the block scope entity
-receives external linkage. If, within a translation unit, the same
-entity is declared with both internal and external linkage, the program
-is ill-formed.
 [*Example 1*:
 ``` cpp
 static void f();
 extern "C" void h();
 static int i = 0;               // #1
-void g() {
   extern void f();              // internal linkage
   extern void h();              // C language linkage
   int i;                        // #2: i has no linkage
   {
     extern void f();            // internal linkage
-    extern int i;               // #3: external linkage, ill-formed
   }
 }
 ```
-Without the declaration at line \#2, the declaration at line \#3 would
-link with the declaration at line \#1. Because the declaration with
-internal linkage is hidden, however, \#3 is given external linkage,
-making the program ill-formed.
-— *end example*]
-When a block scope declaration of an entity with linkage is not found to
-refer to some other declaration, then that entity is a member of the
-innermost enclosing namespace. However such a declaration does not
-introduce the member name in its namespace scope.
-[*Example 2*:
-``` cpp
-namespace X {
-  void p() {
-    q();                        // error: q not yet declared
-    extern void q();            // q is a member of namespace X
-  }
-  void middle() {
-    q();                        // error: q not yet declared
-  }
-  void q() { ... }        // definition of X::q
-}
-void q() { ... }          // some other, unrelated q
-```
 — *end example*]
 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.
-Two names that are the same [[basic.pre]] and that are declared in
-different scopes shall denote the same variable, function, type,
-template or namespace if
-- both names have external or module linkage and are declared in
-  declarations attached to the same module, or else both names have
- internal linkage and are declared in the same translation unit; and
-- both names refer to members of the same namespace or to members, not
-  by inheritance, of the same class; and
-- when both names denote functions or function templates, the
-  signatures ([[defns.signature]], [[defns.signature.templ]]) are the
-  same.
-If multiple declarations of the same name with external linkage would
-declare the same entity except that they are attached to different
-modules, the program is ill-formed; no diagnostic is required.
-[*Note 2*: *using-declaration*s, typedef declarations, and
-*alias-declaration*s do not declare entities, but merely introduce
-synonyms. Similarly, *using-directive*s do not declare entities.
-Enumerators do not have linkage, but may serve as the name of an
-enumeration with linkage [[dcl.enum]]. — *end note*]
-If a declaration would redeclare a reachable declaration attached to a
-different module, the program is ill-formed.
-[*Example 3*:
 \`"decls.h"\`
 ``` cpp
 int f();            // #1, attached to the global module
@@ -2427,11 +2299,11 @@ Module interface of \`M\`
 ``` cpp
 module;
 #include "decls.h"
 export module M;
-export using ::f;   // OK: does not declare an entity, exports #1
 int g();            // error: matches #2, but attached to M
 export int h();     // #3
 export int k();     // #4
 ```
@@ -2447,32 +2319,62 @@ int k();            // error: matches #4
 As a consequence of these rules, all declarations of an entity are
 attached to the same module; the entity is said to be *attached* to that
 module.
-After all adjustments of types (during which typedefs [[dcl.typedef]]
-are replaced by their definitions), the types specified by all
-declarations referring to a given variable or function shall be
-identical, except that declarations for an array object can specify
-array types that differ by the presence or absence of a major array
-bound [[dcl.array]]. A violation of this rule on type identity does not
-require a diagnostic.
-[*Note 3*: Linkage to non-C++ declarations can be achieved using a
 *linkage-specification* [[dcl.link]]. — *end note*]
 A declaration D *names* an entity E if
 - D contains a *lambda-expression* whose closure type is E,
 - E is not a function or function template and D contains an
   *id-expression*, *type-specifier*, *nested-name-specifier*,
   *template-name*, or *concept-name* denoting E, or
 - E is a function or function template and D contains an expression that
   names E [[basic.def.odr]] or an *id-expression* that refers to a set
-  of overloads that contains E. \[*Note 4*: Non-dependent names in an
   instantiated declaration do not refer to a set of overloads
-  [[temp.nondep]]. — *end note*]
 A declaration is an *exposure* if it either names a TU-local entity
 (defined below), ignoring
 - the *function-body* for a non-inline function or function template
@@ -2482,18 +2384,18 @@ A declaration is an *exposure* if it either names a TU-local entity
 - the *initializer* for a variable or variable template (but not the
   variable’s type),
 - friend declarations in a class definition, and
 - any reference to a non-volatile const object or reference with
   internal or no linkage initialized with a constant expression that is
-  not an odr-use [[basic.def.odr]],
 or defines a constexpr variable initialized to a TU-local value (defined
 below).
-[*Note 5*: An inline function template can be an exposure even though
-explicit specializations of it might be usable in other translation
-units. — *end note*]
 An entity is *TU-local* if it is
 - a type, function, variable, or template that
   - has a name with internal linkage, or
@@ -2504,17 +2406,17 @@ An entity is *TU-local* if it is
   *defining-type-specifier* that is used to declare only TU-local
   entities,
 - a specialization of a TU-local template,
 - a specialization of a template with any TU-local template argument, or
 - a specialization of a template whose (possibly instantiated)
-  declaration is an exposure. \[*Note 6*: The specialization might have
- been implicitly or explicitly instantiated. — *end note*]
 A value or object is *TU-local* if either
 - it is, or is a pointer to, a TU-local function or the object
-  associated with a TU-local variable,
 - it is an object of class or array type and any of its subobjects or
   any of the objects or functions to which its non-static data members
   of reference type refer is TU-local and is usable in constant
   expressions.
@@ -2560,11 +2462,11 @@ namespace N {
   void adl(A);
   static void adl(int);
 }
 void adl(double);
-inline void h(auto x) { adl(x); }   // OK, but a specialization might be an exposure
 ```
 Translation unit #2
 ``` cpp
@@ -2585,24 +2487,29 @@ void other() {
 ## Memory and objects <a id="basic.memobj">[[basic.memobj]]</a>
 ### Memory model <a id="intro.memory">[[intro.memory]]</a>
 The fundamental storage unit in the C++ memory model is the *byte*. A
-byte is at least large enough to contain any member of the basic
-execution character set [[lex.charset]] and the eight-bit code units of
-the Unicode UTF-8 encoding form and is composed of a contiguous sequence
-of bits,[^9] the number of which is *implementation-defined*. The least
-significant bit is called the *low-order bit*; the most significant bit
-is called the *high-order bit*. The memory available to a C++ program
-consists of one or more sequences of contiguous bytes. Every byte has a
-unique address.
 [*Note 1*: The representation of types is described in
-[[basic.types]]. — *end note*]
-A *memory location* is either an object of scalar type or a maximal
-sequence of adjacent bit-fields all having nonzero width.
 [*Note 2*: Various features of the language, such as references and
 virtual functions, might involve additional memory locations that are
 not accessible to programs but are managed by the
 implementation. — *end note*]
@@ -2630,11 +2537,11 @@ struct {
   int b:5,
   c:11,
   :0,
   d:8;
   struct {int ee:8;} e;
-}
 ```
 contains four separate memory locations: The member `a` and bit-fields
 `d` and `e.ee` are each separate memory locations, and can be modified
 concurrently without interfering with each other. The bit-fields `b` and
@@ -2649,27 +2556,27 @@ can be.
 The constructs in a C++ program create, destroy, refer to, access, and
 manipulate objects. An *object* is created by a definition
 [[basic.def]], by a *new-expression* [[expr.new]], by an operation that
 implicitly creates objects (see below), when implicitly changing the
 active member of a union [[class.union]], or when a temporary object is
-created ([[conv.rval]], [[class.temporary]]). An object occupies a
-region of storage in its period of construction [[class.cdtor]],
-throughout its lifetime [[basic.life]], and in its period of destruction
 [[class.cdtor]].
 [*Note 1*: A function is not an object, regardless of whether or not it
 occupies storage in the way that objects do. — *end note*]
 The properties of an object are determined when the object is created.
 An object can have a name [[basic.pre]]. An object has a storage
 duration [[basic.stc]] which influences its lifetime [[basic.life]]. An
-object has a type [[basic.types]]. Some objects are polymorphic
-[[class.virtual]]; the implementation generates information associated
-with each such object that makes it possible to determine that object’s
-type during program execution. For other objects, the interpretation of
-the values found therein is determined by the type of the *expression*s
-[[expr.compound]] used to access them.
 Objects can contain other objects, called *subobjects*. A subobject can
 be a *member subobject* [[class.mem]], a *base class subobject*
 [[class.derived]], or an array element. An object that is not a
 subobject of any other object is called a *complete object*. If an
@@ -2687,13 +2594,14 @@ another object *e* of type “array of N `unsigned char`” or of type
 “array of N `std::byte`” [[cstddef.syn]], that array *provides storage*
 for the created object if:
 - the lifetime of *e* has begun and not ended, and
 - the storage for the new object fits entirely within *e*, and
-- there is no smaller array object that satisfies these constraints.
-[*Note 2*: If that portion of the array previously provided storage for
 another object, the lifetime of that object ends because its storage was
 reused [[basic.life]]. — *end note*]
 [*Example 1*:
@@ -2734,12 +2642,12 @@ of* `x`, determined as follows:
 - If `x` is a complete object, then the complete object of `x` is
   itself.
 - Otherwise, the complete object of `x` is the complete object of the
   (unique) object that contains `x`.
-If a complete object, a data member [[class.mem]], or an array element
-is of class type, its type is considered the *most derived class*, to
 distinguish it from the class type of any base class subobject; an
 object of a most derived class type or of a non-class type is called a
 *most derived object*.
 A *potentially-overlapping subobject* is either:
@@ -2752,27 +2660,28 @@ An object has nonzero size if it
 - is not a potentially-overlapping subobject, or
 - is not of class type, or
 - is of a class type with virtual member functions or virtual base
   classes, or
-- has subobjects of nonzero size or bit-fields of nonzero length.
 Otherwise, if the object is a base class subobject of a standard-layout
 class type with no non-static data members, it has zero size. Otherwise,
 the circumstances under which the object has zero size are
 *implementation-defined*. Unless it is a bit-field [[class.bit]], an
 object with nonzero size shall occupy one or more bytes of storage,
 including every byte that is occupied in full or in part by any of its
 subobjects. An object of trivially copyable or standard-layout type
-[[basic.types]] shall occupy contiguous bytes of storage.
 Unless an object is a bit-field or a subobject of zero size, the address
 of that object is the address of the first byte it occupies. Two objects
 with overlapping lifetimes that are not bit-fields may have the same
 address if one is nested within the other, or if at least one is a
 subobject of zero size and they are of different types; otherwise, they
-have distinct addresses and occupy disjoint bytes of storage.[^10]
 [*Example 2*:
 ``` cpp
 static const char test1 = 'x';
@@ -2788,18 +2697,18 @@ subobject.
 Some operations are described as *implicitly creating objects* within a
 specified region of storage. For each operation that is specified as
 implicitly creating objects, that operation implicitly creates and
 starts the lifetime of zero or more objects of implicit-lifetime types
-[[basic.types]] in its specified region of storage if doing so would
-result in the program having defined behavior. If no such set of objects
-would give the program defined behavior, the behavior of the program is
-undefined. If multiple such sets of objects would give the program
-defined behavior, it is unspecified which such set of objects is
 created.
-[*Note 3*: Such operations do not start the lifetimes of subobjects of
 such objects that are not themselves of implicit-lifetime
 types. — *end note*]
 Further, after implicitly creating objects within a specified region of
 storage, some operations are described as producing a pointer to a
@@ -2830,44 +2739,44 @@ X *make_x() {
 }
 ```
 — *end example*]
-An operation that begins the lifetime of an array of `char`,
-`unsigned char`, or `std::byte` implicitly creates objects within the
-region of storage occupied by the array.
-[*Note 4*: The array object provides storage for these
 objects. — *end note*]
 Any implicit or explicit invocation of a function named `operator new`
 or `operator new[]` implicitly creates objects in the returned region of
 storage and returns a pointer to a suitable created object.
-[*Note 5*: Some functions in the C++ standard library implicitly create
-objects ([[allocator.traits.members]], [[c.malloc]], [[cstring.syn]],
-[[bit.cast]]). — *end note*]
 ### Lifetime <a id="basic.life">[[basic.life]]</a>
 The *lifetime* of an object or reference is a runtime property of the
 object or reference. A variable is said to have *vacuous initialization*
 if it is default-initialized and, if it is of class type or a (possibly
-multi-dimensional) array thereof, that class type has a trivial default
 constructor. The lifetime of an object of type `T` begins when:
 - storage with the proper alignment and size for type `T` is obtained,
   and
 - its initialization (if any) is complete (including vacuous
   initialization) [[dcl.init]],
 except that if the object is a union member or subobject thereof, its
 lifetime only begins if that union member is the initialized member in
-the union ([[dcl.init.aggr]], [[class.base.init]]), or as described in
-[[class.union]] and [[class.copy.ctor]], and except as described in
-[[allocator.members]]. The lifetime of an object *o* of type `T` ends
-when:
 - if `T` is a non-class type, the object is destroyed, or
 - if `T` is a class type, the destructor call starts, or
 - the storage which the object occupies is released, or is reused by an
   object that is not nested within *o* [[intro.object]].
@@ -2882,43 +2791,44 @@ member subobjects. — *end note*]
 The properties ascribed to objects and references throughout this
 document apply for a given object or reference only during its lifetime.
 [*Note 2*: In particular, before the lifetime of an object starts and
 after its lifetime ends there are significant restrictions on the use of
-the object, as described below, in  [[class.base.init]] and in
 [[class.cdtor]]. Also, the behavior of an object under construction and
-destruction might not be the same as the behavior of an object whose
-lifetime has started and not ended. [[class.base.init]] and
-[[class.cdtor]] describe the behavior of an object during its periods of
-construction and destruction. — *end note*]
-A program may end the lifetime of any object by reusing the storage
-which the object occupies or by explicitly calling a destructor or
-pseudo-destructor [[expr.prim.id.dtor]] for the object. For an object of
-a class type, the program is not required to call the destructor
-explicitly before the storage which the object occupies is reused or
-released; however, if there is no explicit call to the destructor or if
-a *delete-expression* [[expr.delete]] is not used to release the
-storage, the destructor is not 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[^11] or, after the lifetime of
-an object has ended and before the storage which the object occupied is
-reused or released, any pointer that represents the address of 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.allocation]], 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`
@@ -2950,12 +2860,12 @@ void B::mutate() {
 void g() {
   void* p = std::malloc(sizeof(D1) + sizeof(D2));
   B* pb = new (p) D1;
   pb->mutate();
-  *pb;              // OK: pb points to valid memory
-  void* q = pb;     // OK: pb points to valid memory
   pb->f();          // undefined behavior: lifetime of *pb has ended
 }
 ```
 — *end example*]
@@ -2990,11 +2900,11 @@ object o₁ is *transparently replaceable* by an object o₂ if:
 - the storage that o₂ occupies exactly overlays the storage that o₁
   occupied, and
 - o₁ and o₂ are of the same type (ignoring the top-level cv-qualifiers),
   and
-- o₁ is not a complete const object, and
 - neither o₁ nor o₂ is a potentially-overlapping subobject
   [[intro.object]], and
 - either o₁ and o₂ are both complete objects, or o₁ and o₂ are direct
   subobjects of objects p₁ and p₂, respectively, and p₁ is transparently
   replaceable by p₂.
@@ -3023,21 +2933,23 @@ c1 = c2;                        // well-defined
 c1.f();                         // well-defined; c1 refers to a new object of type C
 ```
 — *end example*]
-[*Note 3*: If these conditions are not met, a pointer to the new object
 can be obtained from a pointer that represents the address of its
 storage by calling `std::launder` [[ptr.launder]]. — *end note*]
 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,[^12] 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.
 [*Example 3*:
 ``` cpp
 class T { };
@@ -3051,11 +2963,11 @@ void h() {
 }                               // undefined behavior at block exit
 ```
 — *end example*]
-Creating a new object within the storage that a const complete object
 with static, thread, or automatic storage duration occupies, or within
 the storage that such a const object used to occupy before its lifetime
 ended, results in undefined behavior.
 [*Example 4*:
@@ -3077,11 +2989,11 @@ void h() {
 — *end example*]
 In this subclause, “before” and “after” refer to the “happens before”
 relation [[intro.multithread]].
-[*Note 4*: Therefore, undefined behavior results if an object that is
 being constructed in one thread is referenced from another thread
 without adequate synchronization. — *end note*]
 ### Indeterminate values <a id="basic.indet">[[basic.indet]]</a>
@@ -3100,13 +3012,13 @@ undefined except in the following cases:
   [[basic.fundamental]] or `std::byte` type [[cstddef.syn]] is produced
   by the evaluation of:
   - the second or third operand of a conditional expression
     [[expr.cond]],
   - the right operand of a comma expression [[expr.comma]],
-  - the operand of a cast or conversion ([[conv.integral]],
-    [[expr.type.conv]], [[expr.static.cast]], [[expr.cast]]) to an
-    unsigned ordinary character type or `std::byte` type
     [[cstddef.syn]], or
   - a discarded-value expression [[expr.context]],
   then the result of the operation is an indeterminate value.
 - If an indeterminate value of unsigned ordinary character type or
@@ -3137,10 +3049,12 @@ int f(bool b) {
 — *end example*]
 ### Storage duration <a id="basic.stc">[[basic.stc]]</a>
 The *storage duration* is the property of an object that defines the
 minimum potential lifetime of the storage containing the object. The
 storage duration is determined by the construct used to create the
 object and is one of the following:
@@ -3160,33 +3074,35 @@ When the end of the duration of a region of storage is reached, the
 values of all pointers representing the address of any part of that
 region of storage become invalid pointer values [[basic.compound]].
 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.[^13]
 #### Static storage duration <a id="basic.stc.static">[[basic.stc.static]]</a>
-All variables which do not have dynamic storage duration, do not have
-thread storage duration, and are not local have *static storage
-duration*. The storage for these entities lasts for the duration of the
-program ([[basic.start.static]], [[basic.start.term]]).
 If a variable with static storage duration has initialization or a
 destructor with side effects, it shall not be eliminated even if it
 appears to be unused, except that a class object or its copy/move may be
 eliminated as specified in  [[class.copy.elision]].
-The keyword `static` can be used to declare a local variable with static
-storage duration.
-[*Note 1*:  [[stmt.dcl]] describes the initialization of local `static`
-variables; [[basic.start.term]] describes the destruction of local
-`static` variables. — *end note*]
-The keyword `static` applied to a class data member in a class
-definition gives the data member static storage duration.
 #### Thread storage duration <a id="basic.stc.thread">[[basic.stc.thread]]</a>
 All variables declared with the `thread_local` keyword have
 *thread storage duration*. The storage for these entities lasts for the
@@ -3199,13 +3115,14 @@ specified in  [[basic.start.static]], [[basic.start.dynamic]], and
 [[stmt.dcl]] and, if constructed, is destroyed on thread exit
 [[basic.start.term]]. — *end note*]
 #### Automatic storage duration <a id="basic.stc.auto">[[basic.stc.auto]]</a>
-Block-scope variables not explicitly declared `static`, `thread_local`,
-or `extern` have *automatic storage duration*. The storage for these
-entities lasts until the block in which they are created exits.
 [*Note 1*: These variables are initialized and destroyed as described
 in  [[stmt.dcl]]. — *end note*]
 If a variable with automatic storage duration has initialization or a
@@ -3214,30 +3131,33 @@ before the end of its block nor eliminate it as an optimization, even if
 it appears to be unused, except that a class object or its copy/move may
 be eliminated as specified in  [[class.copy.elision]].
 #### Dynamic storage duration <a id="basic.stc.dynamic">[[basic.stc.dynamic]]</a>
 Objects can be created dynamically during program execution
 [[intro.execution]], using *new-expression*s [[expr.new]], and destroyed
 using *delete-expression*s [[expr.delete]]. A C++ implementation
 provides access to, and management of, dynamic storage via the global
-*allocation functions* `operator new` and `operator
-new[]` and the global *deallocation functions* `operator
-delete` and `operator delete[]`.
 [*Note 1*: The non-allocating forms described in
 [[new.delete.placement]] do not perform allocation or
 deallocation. — *end note*]
 The library provides default definitions for the global allocation and
 deallocation functions. Some global allocation and deallocation
-functions are replaceable [[new.delete]]. A C++ program shall provide at
-most one definition of a replaceable allocation or deallocation
-function. Any such function definition replaces the default version
-provided in the library [[replacement.functions]]. The following
-allocation and deallocation functions [[support.dynamic]] are implicitly
-declared in global scope in each translation unit of a program.
 ``` cpp
 [[nodiscard]] void* operator new(std::size_t);
 [[nodiscard]] void* operator new(std::size_t, std::align_val_t);
@@ -3253,22 +3173,24 @@ void operator delete[](void*) noexcept;
 void operator delete[](void*, std::size_t) noexcept;
 void operator delete[](void*, std::align_val_t) noexcept;
 void operator delete[](void*, std::size_t, std::align_val_t) noexcept;
 ```
-These implicit declarations introduce only the function names `operator`
-`new`, `operator` `new[]`, `operator` `delete`, and `operator`
-`delete[]`.
 [*Note 2*: The implicit declarations do not introduce the names `std`,
 `std::size_t`, `std::align_val_t`, or any other names that the library
 uses to declare these names. Thus, a *new-expression*,
 *delete-expression*, or function call that refers to one of these
-functions without importing or including the header `<new>` is
-well-formed. However, referring to `std` or `std::size_t` or
-`std::align_val_t` is ill-formed unless the name has been declared by
-importing or including the appropriate header. — *end note*]
 Allocation and/or deallocation functions may also be declared and
 defined for any class [[class.free]].
 If the behavior of an allocation or deallocation function does not
@@ -3276,22 +3198,21 @@ satisfy the semantic constraints specified in
 [[basic.stc.dynamic.allocation]] and
 [[basic.stc.dynamic.deallocation]], the behavior is undefined.
 ##### Allocation functions <a id="basic.stc.dynamic.allocation">[[basic.stc.dynamic.allocation]]</a>
-An allocation function shall be a class member function or a global
-function; a program is ill-formed if an allocation function is declared
-in a namespace scope other than global scope or declared static in
-global scope. The return type shall be `void*`. The first parameter
-shall have type `std::size_t` [[support.types]]. The first parameter
-shall not have an associated default argument [[dcl.fct.default]]. The
-value of the first parameter is interpreted as the requested size of the
-allocation. An allocation function can be a function template. Such a
-template shall declare its return type and first parameter as specified
-above (that is, template parameter types shall not be used in the return
-type and first parameter type). Template allocation functions shall have
-two or more parameters.
 An allocation function attempts to allocate the requested amount of
 storage. If it is successful, it returns the address of the start of a
 block of storage whose length in bytes is at least as large as the
 requested size. The order, contiguity, and initial value of storage
@@ -3303,11 +3224,11 @@ from any previously returned value `p1`, unless that value `p1` was
 subsequently passed to a replaceable deallocation function. Furthermore,
 for the library allocation functions in  [[new.delete.single]] and
 [[new.delete.array]], `p0` represents the address of a block of storage
 disjoint from the storage for any other object accessible to the caller.
 The effect of indirecting through a pointer returned from a request for
-zero size is undefined.[^14]
 For an allocation function other than a reserved placement allocation
 function [[new.delete.placement]], the pointer returned on a successful
 call shall represent the address of storage that is aligned as follows:
@@ -3347,14 +3268,12 @@ duration [[basic.stc.thread]], for objects of type `std::type_info`
 [[expr.typeid]], or for an exception object
 [[except.throw]]. — *end note*]
 ##### 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.
 A deallocation function is a *destroying operator delete* if it has at
 least two parameters and its second parameter is of type
 `std::destroying_delete_t`. A destroying operator delete shall be a
 class member function named `operator delete`.
@@ -3368,11 +3287,11 @@ first parameter shall be `C*`; otherwise, the type of its first
 parameter shall be `void*`. A deallocation function may have more than
 one parameter. A *usual deallocation function* is a deallocation
 function whose parameters after the first are
 - optionally, a parameter of type `std::destroying_delete_t`, then
-- optionally, a parameter of type `std::size_t` [^15], then
 - optionally, a parameter of type `std::align_val_t`.
 A destroying operator delete shall be a usual deallocation function. A
 deallocation function may be an instance of a function template. Neither
 the first parameter nor the return type shall depend on a template
@@ -3389,95 +3308,30 @@ has no effect.
 If the argument given to a deallocation function in the standard library
 is a pointer that is not the null pointer value [[basic.compound]], the
 deallocation function shall deallocate the storage referenced by the
 pointer, ending the duration of the region of storage.
-##### 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 an object with dynamic
-storage duration only if the pointer value has an object pointer type
-and is one of the following:
-- the value returned by a call to the C++ standard library
-  implementation of `::operator new(std::{}size_t)` or
-  `::operator new(std::size_t, std::align_val_t)` ;[^16]
-- 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.type.conv]], [[expr.static.cast]], [[expr.cast]]) of a
-  safely-derived pointer value;
-- the result of a `reinterpret_cast` of a safely-derived pointer value;
-- the result of a `reinterpret_cast` of an integer representation of a
-  safely-derived pointer value;
-- the value of an object whose value was copied from a traceable pointer
-  object, where at the time of the copy the source object contained a
-  copy of a safely-derived pointer value.
-An integer value is an *integer representation of a safely-derived
-pointer* only if its type is at least as large as `std::intptr_t` and it
-is one of the following:
-- the result of a `reinterpret_cast` of a safely-derived pointer value;
-- the result of a valid conversion of an integer representation of a
-  safely-derived pointer value;
-- the value of an object whose value was copied from a traceable pointer
-  object, where at the time of the copy the source object contained an
-  integer representation of a safely-derived pointer value;
-- the result of an additive or bitwise operation, one of whose operands
-  is an integer representation of a safely-derived pointer value `P`, if
-  that result converted by `reinterpret_cast<void*>` would compare equal
-  to a safely-derived pointer computable from
-  `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]].
-[*Note 6*: The effect of using an invalid pointer value (including
-passing it to a deallocation function) is undefined, see  [[basic.stc]].
-This is true even if the unsafely-derived pointer value might compare
-equal to some safely-derived pointer value. — *end note*]
-It is *implementation-defined* whether an implementation has relaxed or
-strict pointer safety.
 #### Duration of subobjects <a id="basic.stc.inherit">[[basic.stc.inherit]]</a>
 The storage duration of subobjects and reference members is that of
 their complete object [[intro.object]].
 ### Alignment <a id="basic.align">[[basic.align]]</a>
-Object types have *alignment requirements* ([[basic.fundamental]],
-[[basic.compound]]) which place restrictions on the addresses at which
-an object of that type may be allocated. An *alignment* is an
-*implementation-defined* integer value representing the number of bytes
-between successive addresses at which a given object can be allocated.
-An object type imposes an alignment requirement on every object of that
-type; stricter alignment can be requested using the alignment specifier
-[[dcl.align]].
 A *fundamental alignment* is represented by an alignment less than or
 equal to the greatest alignment supported by the implementation in all
 contexts, which is equal to `alignof(std::max_align_t)`
-[[support.types]]. The alignment required for a type might be different
 when it is used as the type of a complete object and when it is used as
 the type of a subobject.
 [*Example 1*:
@@ -3535,57 +3389,55 @@ Comparing alignments is meaningful and provides the obvious results:
 - Two alignments are different when their numeric values are not equal.
 - When an alignment is larger than another it represents a stricter
   alignment.
 [*Note 3*: The runtime pointer alignment function [[ptr.align]] can be
-used to obtain an aligned pointer within a buffer; the aligned-storage
-templates in the library [[meta.trans.other]] can be used to obtain
-aligned storage. — *end note*]
 If a request for a specific extended alignment in a specific context is
 not supported by an implementation, the program is ill-formed.
 ### Temporary objects <a id="class.temporary">[[class.temporary]]</a>
 Temporary objects are created
 - when a prvalue is converted to an xvalue [[conv.rval]],
 - when needed by the implementation to pass or return an object of
-  trivially-copyable type (see below), and
 - when throwing an exception [[except.throw]]. \[*Note 1*: The lifetime
   of exception objects is described in  [[except.throw]]. — *end note*]
 Even when the creation of the temporary object is unevaluated
-[[expr.prop]], all the semantic restrictions shall be respected as if
 the temporary object had been created and later destroyed.
 [*Note 2*: This includes accessibility [[class.access]] and whether it
 is deleted, for the constructor selected and for the destructor.
 However, in the special case of the operand of a *decltype-specifier*
-[[expr.call]], no temporary is introduced, so the foregoing does not
-apply to such a prvalue. — *end note*]
 The materialization of a temporary object is generally delayed as long
 as possible in order to avoid creating unnecessary temporary objects.
 [*Note 3*:
 Temporary objects are materialized:
-- when binding a reference to a prvalue ([[dcl.init.ref]],
-  [[expr.type.conv]], [[expr.dynamic.cast]], [[expr.static.cast]],
-  [[expr.const.cast]], [[expr.cast]]),
-- when performing member access on a class prvalue ([[expr.ref]],
-  [[expr.mptr.oper]]),
 - when performing an array-to-pointer conversion or subscripting on an
-  array prvalue ([[conv.array]], [[expr.sub]]),
 - when initializing an object of type `std::initializer_list<T>` from a
   *braced-init-list* [[dcl.init.list]],
-- for certain unevaluated operands ([[expr.typeid]], [[expr.sizeof]]),
-  and
 - when a prvalue that has type other than cv `void` appears as a
-  discarded-value expression [[expr.prop]].
 — *end note*]
 [*Example 1*:
@@ -3642,38 +3494,38 @@ object).
 [*Note 4*: This latitude is granted to allow objects of class type to
 be passed to or returned from functions in registers. — *end note*]
 When an implementation introduces a temporary object of a class that has
-a non-trivial constructor ([[class.default.ctor]],
-[[class.copy.ctor]]), it shall ensure that a constructor is called for
-the temporary object. Similarly, the destructor shall be called for a
-temporary with a non-trivial destructor [[class.dtor]]. Temporary
-objects are destroyed as the last step in evaluating the full-expression
-[[intro.execution]] that (lexically) contains the point where they were
-created. This is true even if that evaluation ends in throwing an
-exception. The value computations and side effects of destroying a
-temporary object are associated only with the full-expression, not with
-any specific subexpression.
-There are three contexts in which temporaries are destroyed at a
 different point than the end of the full-expression. The first context
 is when a default constructor is called to initialize an element of an
 array with no corresponding initializer [[dcl.init]]. The second context
 is when a copy constructor is called to copy an element of an array
-while the entire array is copied ([[expr.prim.lambda.capture]],
-[[class.copy.ctor]]). In either case, if the constructor has one or more
-default arguments, the destruction of every temporary created in a
-default argument is sequenced before the construction of the next array
-element, if any.
-The third context is when a reference is bound to a temporary
-object.[^17] The temporary object to which the reference is bound or the
-temporary object that is the complete object of a subobject to which the
-reference is bound persists for the lifetime of the reference if the
-glvalue to which the reference is bound was obtained through one of the
-following:
 - a temporary materialization conversion [[conv.rval]],
 - `(` *expression* `)`, where *expression* is one of these expressions,
 - subscripting [[expr.sub]] of an array operand, where that operand is
   one of these expressions,
@@ -3712,11 +3564,11 @@ int&& c = cond ? id<int[3]>{1, 2, 3}[i] : static_cast<int&&>(0);
 — *end example*]
 [*Note 5*:
-An explicit type conversion ([[expr.type.conv]], [[expr.cast]]) is
 interpreted as a sequence of elementary casts, covered above.
 [*Example 3*:
 ``` cpp
@@ -3759,35 +3611,43 @@ The exceptions to this lifetime rule are:
   `return` statement [[stmt.return]] is not extended; the temporary is
   destroyed at the end of the full-expression in the `return` statement.
 - A temporary bound to a reference in a *new-initializer* [[expr.new]]
   persists until the completion of the full-expression containing the
   *new-initializer*.
-  \[*Note 7*: This may introduce a dangling reference. — *end note*]
   \[*Example 5*:
   ``` cpp
   struct S { int mi; const std::pair<int,int>& mp; };
   S a { 1, {2,3} };
   S* p = new S{ 1, {2,3} };       // creates dangling reference
   ```
   — *end example*]
-The destruction of a temporary whose lifetime is not extended by being
-bound to a reference is sequenced before the destruction of every
-temporary which is constructed earlier in the same full-expression. If
-the lifetime of two or more temporaries to which references are bound
-ends at the same point, these temporaries are destroyed at that point in
-the reverse order of the completion of their construction. In addition,
-the destruction of temporaries bound to references shall take into
-account the ordering of destruction of objects with static, thread, or
-automatic storage duration ([[basic.stc.static]], [[basic.stc.thread]],
-[[basic.stc.auto]]); that is, if `obj1` is an object with the same
-storage duration as the temporary and created before the temporary is
-created the temporary shall be destroyed before `obj1` is destroyed; if
-`obj2` is an object with the same storage duration as the temporary and
-created after the temporary is created the temporary shall be destroyed
-after `obj2` is destroyed.
 [*Example 6*:
 ``` cpp
 struct S {
@@ -3821,23 +3681,26 @@ destroyed before `obj1`.
 — *end example*]
 ## Types <a id="basic.types">[[basic.types]]</a>
 [*Note 1*:  [[basic.types]] and the subclauses thereof impose
 requirements on implementations regarding the representation of types.
 There are two kinds of types: fundamental types and compound types.
 Types describe objects [[intro.object]], references [[dcl.ref]], or
 functions [[dcl.fct]]. — *end note*]
 For any object (other than a potentially-overlapping 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`, `unsigned char`, or
-`std::byte` [[cstddef.syn]]. [^18] If the content of that array is
-copied back into the object, the object shall subsequently hold its
-original value.
 [*Example 1*:
 ``` cpp
 constexpr std::size_t N = sizeof(T);
@@ -3847,15 +3710,16 @@ std::memcpy(buf, &obj, N);      // between these two calls to std::memcpy, obj m
 std::memcpy(&obj, buf, N);      // at this point, each subobject of obj of scalar type holds its original value
 ```
 — *end example*]
-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 potentially-overlapping subobject, if the underlying bytes
-[[intro.memory]] making up `obj1` are copied into `obj2`,[^19] `obj2`
-shall subsequently hold the same value as `obj1`.
 [*Example 2*:
 ``` cpp
 T* t1p;
@@ -3874,32 +3738,38 @@ The *object representation* of an object of type `T` is the sequence of
 `T` is the set of bits that participate in representing a value of type
 `T`. Bits in the object representation that are not part of the value
 representation are *padding bits*. 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 bound or of
-incomplete element type, is an *incompletely-defined object type*. [^21]
 Incompletely-defined object types and cv `void` 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 bound
 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 bound, or of a type defined by a
-`typedef` declaration to be an array of unknown bound, cannot be
-completed.
 [*Example 3*:
 ``` cpp
 class X;                        // X is an incomplete type
@@ -3910,28 +3780,28 @@ UNKA* arrp;                     // arrp is a pointer to an incomplete type
 UNKA** arrpp;
 void foo() {
   xp++;                         // error: X is incomplete
   arrp++;                       // error: incomplete type
-  arrpp++;                      // OK: sizeof UNKA* is known
 }
 struct X { int i; };            // now X is a complete type
 int  arr[10];                   // now the type of arr is complete
 X x;
 void bar() {
   xp = &x;                      // OK; type is ``pointer to X''
-  arrp = &arr;                  // error: different types
-  xp++;                         // OK:  X is complete
   arrp++;                       // error: UNKA can't be completed
 }
 ```
 — *end example*]
-[*Note 2*: The rules for declarations and expressions describe in which
 contexts incomplete types are prohibited. — *end note*]
 An *object type* is a (possibly cv-qualified) type that is not a
 function type, not a reference type, and not cv `void`.
@@ -3957,27 +3827,30 @@ A type is a *literal type* if it is:
 - a reference type; or
 - an array of literal type; or
 - a possibly cv-qualified class type [[class]] that has all of the
   following properties:
   - it has a constexpr destructor [[dcl.constexpr]],
-  - it is either a closure type [[expr.prim.lambda.closure]], an
- aggregate type [[dcl.init.aggr]], or has at least one constexpr
-    constructor or constructor template (possibly inherited
- [[namespace.udecl]] from a base class) that is not a copy or move
- constructor,
-  - if it is a union, at least one of its non-static data members is of
-    non-volatile literal type, and
-  - if it is not a union, all of its non-static data members and base
-    classes are of non-volatile literal types.
-[*Note 3*: A literal type is one for which it might be possible to
 create an object within a constant expression. It is not a guarantee
 that it is possible to create such an object, nor is it a guarantee that
 any object of that type will be usable in a constant
 expression. — *end note*]
-Two types *cv1* `T1` and *cv2* `T2` are *layout-compatible* types if
 `T1` and `T2` are the same type, layout-compatible enumerations
 [[dcl.enum]], or layout-compatible standard-layout class types
 [[class.mem]].
 ### Fundamental types <a id="basic.fundamental">[[basic.fundamental]]</a>
@@ -4013,32 +3886,32 @@ arithmetic yields undefined behavior [[expr.pre]]. — *end note*]
 An unsigned integer type has the same object representation, value
 representation, and alignment requirements [[basic.align]] as the
 corresponding signed integer type. For each value x of a signed integer
 type, the value of the corresponding unsigned integer type congruent to
 x modulo 2ᴺ has the same value of corresponding bits in its value
-representation.[^22]
 [*Example 1*: The value -1 of a signed integer type has the same
 representation as the largest value of the corresponding unsigned
 type. — *end example*]
 **Table: Minimum width** <a id="basic.fundamental.width">[basic.fundamental.width]</a>
 | Type            | Minimum width $N$ |
-| ------------- | ----------------- |
 | `signed char`   | 8                 |
-| `short` | 16                |
 | `int`           | 16                |
-| `long` | 32                |
-| `long long` | 64                |
 The width of each signed integer type shall not be less than the values
 specified in [[basic.fundamental.width]]. The value representation of a
 signed or unsigned integer type comprises N bits, where N is the
 respective width. Each set of values for any padding bits
-[[basic.types]] in the object representation are alternative
 representations of the value specified by the value representation.
 [*Note 3*: Padding bits have unspecified value, but cannot cause traps.
 In contrast, see ISO C 6.2.6.2. — *end note*]
@@ -4065,30 +3938,25 @@ representation, alignment requirements [[basic.align]], and range of
 representable values as the underlying type. Further, each value has the
 same representation in both types.
 Type `char` is a distinct type that has an *implementation-defined*
 choice of “`signed char`” or “`unsigned char`” as its underlying type.
-The values of type `char` can represent distinct codes for all members
-of the implementation’s basic character set. The three types `char`,
-`signed char`, and `unsigned char` are collectively called *ordinary
-character types*. The ordinary character types and `char8_t` are
-collectively called *narrow character types*. For narrow character
-types, each possible bit pattern of the object representation represents
-a distinct value.
 [*Note 5*: This requirement does not hold for other
 types. — *end note*]
 [*Note 6*: A bit-field of narrow character type whose width is larger
 than the width of that type has padding bits; see
-[[basic.types]]. — *end note*]
 Type `wchar_t` is a distinct type that has an *implementation-defined*
-signed or unsigned integer type as its underlying type. The values of
-type `wchar_t` can represent distinct codes for all members of the
-largest extended character set specified among the supported locales
-[[locale]].
 Type `char8_t` denotes a distinct type whose underlying type is
 `unsigned char`. Types `char16_t` and `char32_t` denote distinct types
 whose underlying types are `uint_least16_t` and `uint_least32_t`,
 respectively, in `<cstdint>`.
@@ -4099,58 +3967,140 @@ value representation, and alignment requirements as an
 `bool` are `true` and `false`.
 [*Note 7*: There are no `signed`, `unsigned`, `short`, or `long bool`
 types or values. — *end note*]
-Types `bool`, `char`, `wchar_t`, `char8_t`, `char16_t`, `char32_t`, and
-the signed and unsigned integer types are collectively called *integral
 types*. A synonym for integral type is *integer type*.
 [*Note 8*: Enumerations [[dcl.enum]] are not integral; however,
 unscoped enumerations can be promoted to integral types as specified in
 [[conv.prom]]. — *end note*]
-There are three *floating-point types*: `float`, `double`, and
-`long double`. The type `double` provides at least as much precision as
-`float`, and the type `long double` provides at least as much precision
-as `double`. The set of values of the type `float` is a subset of the
-set of values of the type `double`; the set of values of the type
-`double` is a subset of the set of values of the type `long double`. The
-value representation of floating-point types is
 *implementation-defined*.
-[*Note 9*: This document imposes no requirements on the accuracy of
-floating-point operations; see also  [[support.limits]]. — *end note*]
-Integral and floating-point types are collectively called *arithmetic*
-types. Specializations of the standard library template
-`std::numeric_limits` [[support.limits]] shall specify the maximum and
-minimum values of each arithmetic type for an implementation.
 A type cv `void` is an incomplete type that cannot be completed; such a
 type has an empty set of values. 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.type.conv]], [[expr.static.cast]],
-[[expr.cast]]). An expression of type cv `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
-cv `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*)`.
 The types described in this subclause are called *fundamental types*.
-[*Note 10*: Even if the implementation defines two or more fundamental
 types to have the same value representation, they are nevertheless
 different types. — *end note*]
 ### Compound types <a id="basic.compound">[[basic.compound]]</a>
 Compound types can be constructed in the following ways:
 - *arrays* of objects of a given type, [[dcl.array]];
@@ -4166,17 +4116,16 @@ Compound types can be constructed in the following ways:
   a set of types, enumerations and functions for manipulating these
   objects [[class.mfct]], and a set of restrictions on the access to
   these entities [[class.access]];
 - *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 class members*, [^23] which identify members
- of a given type within objects of a given class, [[dcl.mptr]].
- Pointers to data members and pointers to member functions are
- collectively called *pointer-to-member* types.
 These methods of constructing types can be applied recursively;
 restrictions are mentioned in  [[dcl.meaning]]. 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]]
@@ -4207,28 +4156,29 @@ allowed although there are restrictions on what can be done with them
 - the *null pointer value* for that type, or
 - an *invalid pointer value*.
 A value of a pointer type that is a pointer to or past the end of an
 object *represents the address* of the first byte in memory
-[[intro.memory]] occupied by the object [^24] or the first byte in
-memory after the end of the storage occupied by the object,
-respectively.
 [*Note 2*: A pointer past the end of an object [[expr.add]] is not
-considered to point to an unrelated object of the object’s type that
-might be located at that address. A pointer value becomes invalid when
-the storage it denotes reaches the end of its storage duration; see
-[[basic.stc]]. — *end note*]
-For purposes of pointer arithmetic [[expr.add]] and comparison (
-[[expr.rel]], [[expr.eq]]), a pointer past the end of the last element
-of an array `x` of n elements is considered to be equivalent to a
-pointer to a hypothetical array element n of `x` and an object of type
-`T` that is not an array element is considered to belong to an array
-with one element of type `T`. The value representation of pointer types
-is *implementation-defined*. Pointers to layout-compatible types shall
-have the same value representation and alignment requirements
 [[basic.align]].
 [*Note 3*: Pointers to over-aligned types [[basic.align]] have no
 special representation, but their range of valid values is restricted by
 the extended alignment requirement. — *end note*]
@@ -4237,13 +4187,12 @@ Two objects *a* and *b* are *pointer-interconvertible* if:
 - they are the same object, or
 - one is a union object and the other is a non-static data member of
   that object [[class.union]], or
 - one is a standard-layout class object and the other is the first
-  non-static data member of that object, or, if the object has no
- non-static data members, any base class subobject of that object
-  [[class.mem]], or
 - there exists an object *c* such that *a* and *c* are
   pointer-interconvertible, and *c* and *b* are
   pointer-interconvertible.
 If two objects are pointer-interconvertible, then they have the same
@@ -4252,48 +4201,53 @@ the other via a `reinterpret_cast` [[expr.reinterpret.cast]].
 [*Note 4*: An array object and its first element are not
 pointer-interconvertible, even though they have the same
 address. — *end note*]
 A pointer to cv `void` can be used to point to objects of unknown type.
 Such a pointer shall be able to hold any object pointer. An object of
-type cv `void*` shall have the same representation and alignment
-requirements as cv `char*`.
 ### CV-qualifiers <a id="basic.type.qualifier">[[basic.type.qualifier]]</a>
-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 type of an object
-[[intro.object]] includes the *cv-qualifier*s specified in the
-*decl-specifier-seq* [[dcl.spec]], *declarator* [[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 a const object.
 - A *volatile object* is an object of type `volatile T` or a subobject
   of a volatile object.
 - A *const volatile object* is an object of type `const volatile T`, a
   non-mutable subobject of a const volatile 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]].[^25]
 Except for array types, a compound type [[basic.compound]] is not
 cv-qualified by the cv-qualifiers (if any) of the types from which it is
 compounded.
 An array type whose elements are cv-qualified is also considered to have
 the same cv-qualifications as its elements.
-[*Note 1*: 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
 [[dcl.array]]. — *end note*]
 [*Example 1*:
@@ -4308,12 +4262,12 @@ 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.
 — *end example*]
-[*Note 2*: See  [[dcl.fct]] and  [[class.this]] regarding function
-types that have *cv-qualifier*s. — *end note*]
 There is a partial ordering on cv-qualifiers, so that a type can be said
 to be *more cv-qualified* than another. [[basic.type.qualifier.rel]]
 shows the relations that constitute this ordering.
@@ -4339,45 +4293,78 @@ no top-level cv-qualifiers. The type corresponding to the *type-id*
 `volatile int * const` has the top-level cv-qualifier `const`. For a
 class type `C`, the type corresponding to the *type-id*
 `void (C::* volatile)(int) const` has the top-level cv-qualifier
 `volatile`. — *end example*]
-### Integer conversion rank <a id="conv.rank">[[conv.rank]]</a>
 Every integer type has an *integer conversion rank* defined as follows:
 - No two signed integer types other than `char` and `signed
-  char` (if `char` is signed) shall have the same rank, even if they
- have the same representation.
-- The rank of a signed integer type shall be greater than the rank of
- any signed integer type with a smaller width.
-- The rank of `long long int` shall be greater than the rank of
- `long int`, which shall be greater than the rank of `int`, which shall
- be greater than the rank of `short int`, which shall be greater than
-  the rank of `signed char`.
-- The rank of any unsigned integer type shall equal the rank of the
   corresponding signed integer type.
-- The rank of any standard integer type shall be greater than the rank
- of any extended integer type with the same width.
-- The rank of `char` shall equal the rank of `signed char` and
   `unsigned char`.
-- The rank of `bool` shall be less than the rank of all other standard
- integer types.
-- The ranks of `char8_t`, `char16_t`, `char32_t`, and `wchar_t` shall
- equal the ranks of their underlying types [[basic.fundamental]].
 - The rank of any extended signed integer type relative to another
   extended signed integer type with the same width is
   *implementation-defined*, but still subject to the other rules for
   determining the integer conversion rank.
 - For all integer types `T1`, `T2`, and `T3`, if `T1` has greater rank
-  than `T2` and `T2` has greater rank than `T3`, then `T1` shall have
- greater rank than `T3`.
 [*Note 1*: The integer conversion rank is used in the definition of the
 integral promotions [[conv.prom]] and the usual arithmetic conversions
 [[expr.arith.conv]]. — *end note*]
 ## Program execution <a id="basic.exec">[[basic.exec]]</a>
 ### Sequential execution <a id="intro.execution">[[intro.execution]]</a>
 An instance of each object with automatic storage duration
@@ -4387,10 +4374,12 @@ the block and while the block is suspended (by a call of a function,
 suspension of a coroutine [[expr.await]], or receipt of a signal).
 A *constituent expression* is defined as follows:
 - The constituent expression of an expression is that expression.
 - The constituent expressions of a *braced-init-list* or of a (possibly
   parenthesized) *expression-list* are the constituent expressions of
   the elements of the respective list.
 - The constituent expressions of a *brace-or-equal-initializer* of the
   form `=` *initializer-clause* are the constituent expressions of the
@@ -4428,13 +4417,20 @@ or a subexpression of an immediate subexpression of E.
 [*Note 1*: Expressions appearing in the *compound-statement* of a
 *lambda-expression* are not subexpressions of the
 *lambda-expression*. — *end note*]
 A *full-expression* is
-- an unevaluated operand [[expr.prop]],
 - a *constant-expression* [[expr.const]],
 - an immediate invocation [[expr.const]],
 - an *init-declarator* [[dcl.decl]] or a *mem-initializer*
   [[class.base.init]], including the constituent expressions of the
   initializer,
@@ -4518,20 +4514,20 @@ overlap. — *end note*]
 Evaluations *A* and *B* are *indeterminately sequenced* when either *A*
 is sequenced before *B* or *B* is sequenced before *A*, but it is
 unspecified which.
 [*Note 4*: Indeterminately sequenced evaluations cannot overlap, but
-either could be executed first. — *end note*]
 An expression *X* is said to be sequenced before an expression *Y* if
 every value computation and every side effect associated with the
 expression *X* is sequenced before every value computation and every
 side effect associated with the expression *Y*.
 Every value computation and side effect associated with a
 full-expression is sequenced before every value computation and side
-effect associated with the next full-expression to be evaluated.[^26]
 Except where noted, evaluations of operands of individual operators and
 of subexpressions of individual expressions are unsequenced.
 [*Note 5*: In an expression that is evaluated more than once during the
@@ -4562,22 +4558,23 @@ void g(int i) {
 }
 ```
 — *end example*]
-When calling a function (whether or not the function is inline), every
-value computation and side effect associated with any argument
-expression, or with the postfix expression designating the called
-function, is sequenced before execution of every expression or statement
-in the body of the called function. For each function invocation *F*,
-for every evaluation *A* that occurs within *F* and every evaluation *B*
-that does not occur within *F* but is evaluated on the same thread and
-as part of the same signal handler (if any), either *A* is sequenced
-before *B* or *B* is sequenced before *A*.[^27]
-[*Note 7*: If *A* and *B* would not otherwise be sequenced then they
-are indeterminately sequenced. — *end note*]
 Several contexts in C++ cause evaluation of a function call, even though
 no corresponding function call syntax appears in the translation unit.
 [*Example 4*: Evaluation of a *new-expression* invokes one or more
@@ -4586,37 +4583,40 @@ example, invocation of a conversion function [[class.conv.fct]] can
 arise in contexts in which no function call syntax
 appears. — *end example*]
 The sequencing constraints on the execution of the called function (as
 described above) are features of the function calls as evaluated,
-whatever the syntax of the expression that calls the function might be.
 If a signal handler is executed as a result of a call to the
 `std::raise` function, then the execution of the handler is sequenced
 after the invocation of the `std::raise` function and before its return.
-[*Note 8*: When a signal is received for another reason, the execution
 of the signal handler is usually unsequenced with respect to the rest of
 the program. — *end note*]
 ### Multi-threaded executions and data races <a id="intro.multithread">[[intro.multithread]]</a>
 A *thread of execution* (also known as a *thread*) is a single flow of
 control within a program, including the initial invocation of a specific
 top-level function, and recursively including every function invocation
 subsequently executed by the thread.
 [*Note 1*: When one thread creates another, the initial call to the
 top-level function of the new thread is executed by the new thread, not
 by the creating thread. — *end note*]
 Every thread in a program can potentially access every object and
-function in a program.[^28] Under a hosted implementation, a C++ program
-can have more than one thread running concurrently. The execution of
-each thread proceeds as defined by the remainder of this document. The
-execution of the entire program consists of an execution of all of its
-threads.
 [*Note 2*: Usually the execution can be viewed as an interleaving of
 all its threads. However, some kinds of atomic operations, for example,
 allow executions inconsistent with a simple interleaving, as described
 below. — *end note*]
@@ -4633,12 +4633,12 @@ contains the signal handler invocation.
 The value of an object visible to a thread T at a particular point is
 the initial value of the object, a value assigned to the object by T, or
 a value assigned to the object by another thread, according to the rules
 below.
-[*Note 1*: In some cases, there may instead be undefined behavior. Much
-of this subclause is motivated by the desire to support atomic
 operations with explicit and detailed visibility constraints. However,
 it also implicitly supports a simpler view for more restricted
 programs. — *end note*]
 Two expression evaluations *conflict* if one of them modifies a memory
@@ -4671,11 +4671,11 @@ All modifications to a particular atomic object M occur in some
 particular total order, called the *modification order* of M.
 [*Note 3*: There is a separate order for each atomic object. There is
 no requirement that these can be combined into a single total order for
 all objects. In general this will be impossible since different threads
-may observe modifications to different objects in inconsistent
 orders. — *end note*]
 A *release sequence* headed by a release operation A on an atomic object
 M is a maximal contiguous sub-sequence of side effects in the
 modification order of M, where the first operation is A, and every
@@ -4884,12 +4884,12 @@ computation of an object being taken from the last side effect on that
 object in that interleaving. This is normally referred to as “sequential
 consistency”. However, this applies only to data-race-free programs, and
 data-race-free programs cannot observe most program transformations that
 do not change single-threaded program semantics. In fact, most
 single-threaded program transformations continue to be allowed, since
-any program that behaves differently as a result must perform an
-undefined operation. — *end note*]
 Two accesses to the same object of type `volatile std::sig_atomic_t` do
 not result in a data race if both occur in the same thread, even if one
 or more occurs in a signal handler. For each signal handler invocation,
 evaluations performed by the thread invoking a signal handler can be
@@ -4905,17 +4905,17 @@ potentially shared memory location that would not be modified by the
 abstract machine are generally precluded by this document, since such an
 assignment might overwrite another assignment by a different thread in
 cases in which an abstract machine execution would not have encountered
 a data race. This includes implementations of data member assignment
 that overwrite adjacent members in separate memory locations. Reordering
-of atomic loads in cases in which the atomics in question may alias is
-also generally precluded, since this may violate the coherence
 rules. — *end note*]
 [*Note 23*: Transformations that introduce a speculative read of a
-potentially shared memory location may not preserve the semantics of the
-C++ program as defined in this document, since they potentially
 introduce a data race. However, they are typically valid in the context
 of an optimizing compiler that targets a specific machine with
 well-defined semantics for data races. They would be invalid for a
 hypothetical machine that is not tolerant of races or provides hardware
 race detection. — *end note*]
@@ -4938,25 +4938,25 @@ Executions of atomic functions that are either defined to be lock-free
 [[atomics.flag]] or indicated as lock-free [[atomics.lockfree]] are
 *lock-free executions*.
 - If there is only one thread that is not blocked [[defns.block]] in a
   standard library function, a lock-free execution in that thread shall
-  complete. \[*Note 2*: Concurrently executing threads may prevent
   progress of a lock-free execution. For example, this situation can
   occur with load-locked store-conditional implementations. This
   property is sometimes termed obstruction-free. — *end note*]
 - When one or more lock-free executions run concurrently, at least one
   should complete. \[*Note 3*: It is difficult for some implementations
   to provide absolute guarantees to this effect, since repeated and
-  particularly inopportune interference from other threads may prevent
   forward progress, e.g., by repeatedly stealing a cache line for
   unrelated purposes between load-locked and store-conditional
-  instructions. Implementations should ensure that such effects cannot
- indefinitely delay progress under expected operating conditions, and
- that such anomalies can therefore safely be ignored by programmers.
-  Outside this document, this property is sometimes termed
-  lock-free. — *end note*]
 During the execution of a thread of execution, each of the following is
 termed an *execution step*:
 - termination of the thread of execution,
@@ -4968,11 +4968,11 @@ An invocation of a standard library function that blocks [[defns.block]]
 is considered to continuously execute execution steps while waiting for
 the condition that it blocks on to be satisfied.
 [*Example 1*: A library I/O function that blocks until the I/O
 operation is complete can be considered to continuously check whether
-the operation is complete. Each such check might consist of one or more
 execution steps, for example using observable behavior of the abstract
 machine. — *end example*]
 [*Note 4*: Because of this and the preceding requirement regarding what
 threads of execution have to perform eventually, it follows that no
@@ -4987,30 +4987,28 @@ concurrent threads that are not blocked in a standard library function
 For a thread of execution providing *concurrent forward progress
 guarantees*, the implementation ensures that the thread will eventually
 make progress for as long as it has not terminated.
 [*Note 5*: This is required regardless of whether or not other threads
-of executions (if any) have been or are making progress. To eventually
 fulfill this requirement means that this will happen in an unspecified
 but finite amount of time. — *end note*]
 It is *implementation-defined* whether the implementation-created thread
 of execution that executes `main` [[basic.start.main]] and the threads
 of execution created by `std::thread` [[thread.thread.class]] or
 `std::jthread` [[thread.jthread.class]] provide concurrent forward
-progress guarantees.
-[*Note 6*: General-purpose implementations should provide these
-guarantees. — *end note*]
 For a thread of execution providing *parallel forward progress
 guarantees*, the implementation is not required to ensure that the
 thread will eventually make progress if it has not yet executed any
 execution step; once this thread has executed a step, it provides
 concurrent forward progress guarantees.
-[*Note 7*: This does not specify a requirement for when to start this
 thread of execution, which will typically be specified by the entity
 that creates this thread of execution. For example, a thread of
 execution that provides concurrent forward progress guarantees and
 executes tasks from a set of tasks in an arbitrary order, one after the
 other, satisfies the requirements of parallel forward progress for these
@@ -5018,57 +5016,57 @@ tasks. — *end note*]
 For a thread of execution providing *weakly parallel forward progress
 guarantees*, the implementation does not ensure that the thread will
 eventually make progress.
-[*Note 8*: Threads of execution providing weakly parallel forward
 progress guarantees cannot be expected to make progress regardless of
 whether other threads make progress or not; however, blocking with
 forward progress guarantee delegation, as defined below, can be used to
 ensure that such threads of execution make progress
 eventually. — *end note*]
 Concurrent forward progress guarantees are stronger than parallel
 forward progress guarantees, which in turn are stronger than weakly
 parallel forward progress guarantees.
-[*Note 9*: For example, some kinds of synchronization between threads
-of execution may only make progress if the respective threads of
 execution provide parallel forward progress guarantees, but will fail to
 make progress under weakly parallel guarantees. — *end note*]
 When a thread of execution P is specified to *block with forward
 progress guarantee delegation* on the completion of a set S of threads
 of execution, then throughout the whole time of P being blocked on S,
 the implementation shall ensure that the forward progress guarantees
 provided by at least one thread of execution in S is at least as strong
 as P’s forward progress guarantees.
-[*Note 10*: It is unspecified which thread or threads of execution in S
 are chosen and for which number of execution steps. The strengthening is
 not permanent and not necessarily in place for the rest of the lifetime
 of the affected thread of execution. As long as P is blocked, the
 implementation has to eventually select and potentially strengthen a
 thread of execution in S. — *end note*]
 Once a thread of execution in S terminates, it is removed from S. Once S
 is empty, P is unblocked.
-[*Note 11*: A thread of execution B thus can temporarily provide an
 effectively stronger forward progress guarantee for a certain amount of
 time, due to a second thread of execution A being blocked on it with
 forward progress guarantee delegation. In turn, if B then blocks with
-forward progress guarantee delegation on C, this may also temporarily
 provide a stronger forward progress guarantee to C. — *end note*]
-[*Note 12*: If all threads of execution in S finish executing (e.g.,
 they terminate and do not use blocking synchronization incorrectly),
 then P’s execution of the operation that blocks with forward progress
 guarantee delegation will not result in P’s progress guarantee being
 effectively weakened. — *end note*]
-[*Note 13*: This does not remove any constraints regarding blocking
 synchronization for threads of execution providing parallel or weakly
 parallel forward progress guarantees because the implementation is not
 required to strengthen a particular thread of execution whose too-weak
 progress guarantee is preventing overall progress. — *end note*]
@@ -5078,28 +5076,26 @@ visible to all other threads in a finite period of time.
 ### Start and termination <a id="basic.start">[[basic.start]]</a>
 #### `main` function <a id="basic.start.main">[[basic.start.main]]</a>
-A program shall contain a global function called `main` attached to the
-global module. Executing a program starts a main thread of execution (
-[[intro.multithread]], [[thread.threads]]) in which the `main` function
-is invoked, and in which variables of static storage duration might be
-initialized [[basic.start.static]] and destroyed [[basic.start.term]].
-It is *implementation-defined* whether a program in a freestanding
-environment is required to define a `main` function.
 [*Note 1*: In a freestanding environment, startup and termination is
 *implementation-defined*; startup contains the execution of constructors
-for objects of namespace scope with static storage duration; termination
-contains the execution of destructors for objects with static storage
 duration. — *end note*]
-An implementation shall not predefine the `main` function. This function
-shall not be overloaded. Its type shall have C++ language linkage and 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
@@ -5112,33 +5108,37 @@ characters of null-terminated multibyte strings (NTMBSs)
 [[multibyte.strings]] and `argv[0]` shall be the pointer to the initial
 character of a NTMBS that 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.
-[*Note 2*: It is recommended that any further (optional) parameters be
-added after `argv`. — *end note*]
 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 function `main` shall not be
-a coroutine [[dcl.fct.def.coroutine]]. The `main` function shall not be
-declared with a *linkage-specification* [[dcl.link]]. A program that
-declares a variable `main` at global scope, or that declares a function
-`main` at global scope attached to a named module, or that declares the
-name `main` with C language linkage (in any namespace) is ill-formed.
-The name `main` is not otherwise reserved.
 [*Example 1*: Member functions, classes, and enumerations can be called
 `main`, as can entities in other namespaces. — *end example*]
 Terminating the program without leaving the current block (e.g., by
 calling the function `std::exit(int)` [[support.start.term]]) does not
 destroy any objects with automatic storage duration [[class.dtor]]. If
-`std::exit` is called to end a program during the destruction of an
-object with static or thread storage duration, the program has undefined
-behavior.
 A `return` statement [[stmt.return]] in `main` has the effect of leaving
 the main function (destroying any objects with automatic storage
 duration) and calling `std::exit` with the return value as the argument.
 If control flows off the end of the *compound-statement* of `main`, the
@@ -5156,16 +5156,16 @@ phases of initiation, initialization occurs as follows.
 with static or thread storage duration is constant-initialized
 [[expr.const]]. If constant initialization is not performed, a variable
 with static storage duration [[basic.stc.static]] or thread storage
 duration [[basic.stc.thread]] is zero-initialized [[dcl.init]].
 Together, zero-initialization and constant initialization are called
-*static initialization*; all other initialization is *dynamic
-initialization*. All static initialization strongly happens before
-[[intro.races]] any dynamic initialization.
-[*Note 1*: The dynamic initialization of non-local variables is
-described in  [[basic.start.dynamic]]; that of local static variables is
 described in  [[stmt.dcl]]. — *end note*]
 An implementation is permitted to perform the initialization of a
 variable with static or thread storage duration as a static
 initialization even if such initialization is not required to be done
@@ -5180,49 +5180,48 @@ statically, provided that
   statically were initialized dynamically.
 [*Note 2*:
 As a consequence, if the initialization of an object `obj1` refers to an
-object `obj2` of namespace scope potentially requiring dynamic
-initialization and defined later in the same translation unit, it is
-unspecified whether the value of `obj2` used will be the value of the
-fully initialized `obj2` (because `obj2` was statically initialized) or
-will be the value of `obj2` merely zero-initialized. For example,
 ``` cpp
 inline double fd() { return 1.0; }
 extern double d1;
 double d2 = d1;     // unspecified:
-                    // may be statically initialized to 0.0 or
                     // dynamically initialized to 0.0 if d1 is
                     // dynamically initialized, or 1.0 otherwise
-double d1 = fd();   // may be initialized statically or dynamically to 1.0
 ```
 — *end note*]
-#### Dynamic initialization of non-local variables <a id="basic.start.dynamic">[[basic.start.dynamic]]</a>
-Dynamic initialization of a non-local variable with static storage
 duration is unordered if the variable is an implicitly or explicitly
 instantiated specialization, is partially-ordered if the variable is an
 inline variable that is not an implicitly or explicitly instantiated
 specialization, and otherwise is ordered.
-[*Note 1*: An explicitly specialized non-inline static data member or
-variable template specialization has ordered
-initialization. — *end note*]
 A declaration `D` is *appearance-ordered* before a declaration `E` if
 - `D` appears in the same translation unit as `E`, or
 - the translation unit containing `E` has an interface dependency on the
   translation unit containing `D`,
 in either case prior to `E`.
-Dynamic initialization of non-local variables `V` and `W` with static
 storage duration are ordered as follows:
 - If `V` and `W` have ordered initialization and the definition of `V`
   is appearance-ordered before the definition of `W`, or if `V` has
   partially-ordered initialization, `W` does not have unordered
@@ -5244,25 +5243,26 @@ storage duration are ordered as follows:
   sequenced.
 [*Note 2*: This definition permits initialization of a sequence of
 ordered variables concurrently with another sequence. — *end note*]
-A *non-initialization odr-use* is an odr-use [[basic.def.odr]] not
-caused directly or indirectly by the initialization of a non-local
-static or thread storage duration variable.
 It is *implementation-defined* whether the dynamic initialization of a
-non-local non-inline variable with static storage duration is sequenced
 before the first statement of `main` or is deferred. If it is deferred,
 it strongly happens before any non-initialization odr-use of any
 non-inline function or non-inline variable defined in the same
-translation unit as the variable to be initialized. [^29] It is
-*implementation-defined* in which threads and at which points in the
-program such deferred dynamic initialization occurs.
-[*Note 3*: Such points should be chosen in a way that allows the
-programmer to avoid deadlocks. — *end note*]
 [*Example 1*:
 ``` cpp
 // - File 1 -
@@ -5299,27 +5299,27 @@ point after the first statement of `main`, `b` will be initialized prior
 to its use in `A::A`.
 — *end example*]
 It is *implementation-defined* whether the dynamic initialization of a
-non-local inline variable with static storage duration is sequenced
 before the first statement of `main` or is deferred. If it is deferred,
 it strongly happens before any non-initialization odr-use of that
 variable. It is *implementation-defined* in which threads and at which
 points in the program such deferred dynamic initialization occurs.
 It is *implementation-defined* whether the dynamic initialization of a
-non-local non-inline variable with thread storage duration is sequenced
 before the first statement of the initial function of a thread or is
 deferred. If it is deferred, the initialization associated with the
 entity for thread *t* is sequenced before the first non-initialization
 odr-use by *t* of any non-inline variable with thread storage duration
 defined in the same translation unit as the variable to be initialized.
 It is *implementation-defined* in which threads and at which points in
 the program such deferred dynamic initialization occurs.
-If the initialization of a non-local variable with static or thread
 storage duration exits via an exception, the function `std::terminate`
 is called [[except.terminate]].
 #### Termination <a id="basic.start.term">[[basic.start.term]]</a>
@@ -5346,23 +5346,25 @@ of the constructor or dynamic initialization of an object with thread
 storage duration is sequenced before that of another, the completion of
 the destructor of the second is sequenced before the initiation of the
 destructor of the first. If an object is initialized statically, the
 object is destroyed in the same order as if the object was dynamically
 initialized. For an object of array or class type, all subobjects of
-that object are destroyed before any block-scope object with static
-storage duration initialized during the construction of the subobjects
-is destroyed. If the destruction of an object with static or thread
-storage duration exits via an exception, the function `std::terminate`
-is called [[except.terminate]].
-If a function contains a block-scope object of static or thread storage
 duration that has been destroyed and the function is called during the
 destruction of an object with static or thread storage duration, the
 program has undefined behavior if the flow of control passes through the
-definition of the previously destroyed block-scope object. Likewise, the
-behavior is undefined if the block-scope object is used indirectly
-(i.e., through a pointer) after its destruction.
 If the completion of the initialization of an object with static storage
 duration strongly happens before a call to `std::atexit` (see
 `<cstdlib>`, [[support.start.term]]), the call to the function passed to
 `std::atexit` is sequenced before the call to the destructor for the
@@ -5379,11 +5381,11 @@ If there is a use of a standard library object or function not permitted
 within signal handlers [[support.runtime]] that does not happen before
 [[intro.multithread]] completion of destruction of objects with static
 storage duration and execution of `std::atexit` registered functions
 [[support.start.term]], the program has undefined behavior.
-[*Note 2*: If there is a use of an object with static storage duration
 that does not happen before the object’s destruction, the program has
 undefined behavior. Terminating every thread before a call to
 `std::exit` or the exit from `main` is sufficient, but not necessary, to
 satisfy these requirements. These requirements permit thread managers as
 static-storage-duration objects. — *end note*]
@@ -5391,49 +5393,50 @@ static-storage-duration objects. — *end note*]
 Calling the function `std::abort()` declared in `<cstdlib>` terminates
 the program without executing any destructors and without calling the
 functions passed to `std::atexit()` or `std::at_quick_exit()`.
 <!-- Link reference definitions -->
-[allocator.members]: utilities.md#allocator.members
-[allocator.traits.members]: utilities.md#allocator.traits.members
-[atomics]: atomics.md#atomics
-[atomics.flag]: atomics.md#atomics.flag
-[atomics.lockfree]: atomics.md#atomics.lockfree
-[atomics.order]: atomics.md#atomics.order
 [bad.alloc]: support.md#bad.alloc
 [basic]: #basic
 [basic.align]: #basic.align
 [basic.compound]: #basic.compound
 [basic.def]: #basic.def
 [basic.def.odr]: #basic.def.odr
 [basic.exec]: #basic.exec
 [basic.fundamental]: #basic.fundamental
 [basic.fundamental.width]: #basic.fundamental.width
-[basic.funscope]: #basic.funscope
 [basic.indet]: #basic.indet
 [basic.life]: #basic.life
 [basic.link]: #basic.link
 [basic.lookup]: #basic.lookup
 [basic.lookup.argdep]: #basic.lookup.argdep
-[basic.lookup.classref]: #basic.lookup.classref
 [basic.lookup.elab]: #basic.lookup.elab
 [basic.lookup.qual]: #basic.lookup.qual
 [basic.lookup.udir]: #basic.lookup.udir
 [basic.lookup.unqual]: #basic.lookup.unqual
 [basic.lval]: expr.md#basic.lval
 [basic.memobj]: #basic.memobj
 [basic.namespace]: dcl.md#basic.namespace
 [basic.pre]: #basic.pre
 [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.param]: #basic.scope.param
 [basic.scope.pdecl]: #basic.scope.pdecl
 [basic.scope.temp]: #basic.scope.temp
 [basic.start]: #basic.start
 [basic.start.dynamic]: #basic.start.dynamic
 [basic.start.main]: #basic.start.main
 [basic.start.static]: #basic.start.static
@@ -5441,22 +5444,25 @@ functions passed to `std::atexit()` or `std::at_quick_exit()`.
 [basic.stc]: #basic.stc
 [basic.stc.auto]: #basic.stc.auto
 [basic.stc.dynamic]: #basic.stc.dynamic
 [basic.stc.dynamic.allocation]: #basic.stc.dynamic.allocation
 [basic.stc.dynamic.deallocation]: #basic.stc.dynamic.deallocation
-[basic.stc.dynamic.safety]: #basic.stc.dynamic.safety
 [basic.stc.inherit]: #basic.stc.inherit
 [basic.stc.static]: #basic.stc.static
 [basic.stc.thread]: #basic.stc.thread
 [basic.type.qualifier]: #basic.type.qualifier
 [basic.type.qualifier.rel]: #basic.type.qualifier.rel
 [basic.types]: #basic.types
-[bit.cast]: numerics.md#bit.cast
-[c.malloc]: utilities.md#c.malloc
 [class]: class.md#class
 [class.abstract]: class.md#class.abstract
 [class.access]: class.md#class.access
 [class.base.init]: class.md#class.base.init
 [class.bit]: class.md#class.bit
 [class.cdtor]: class.md#class.cdtor
 [class.conv.fct]: class.md#class.conv.fct
 [class.copy.assign]: class.md#class.copy.assign
@@ -5465,26 +5471,24 @@ functions passed to `std::atexit()` or `std::at_quick_exit()`.
 [class.default.ctor]: class.md#class.default.ctor
 [class.derived]: class.md#class.derived
 [class.dtor]: class.md#class.dtor
 [class.free]: class.md#class.free
 [class.friend]: class.md#class.friend
-[class.local]: class.md#class.local
 [class.mem]: class.md#class.mem
-[class.member.lookup]: class.md#class.member.lookup
 [class.mfct]: class.md#class.mfct
-[class.mfct.non-static]: class.md#class.mfct.non-static
 [class.name]: class.md#class.name
-[class.nest]: class.md#class.nest
 [class.pre]: class.md#class.pre
 [class.prop]: class.md#class.prop
 [class.qual]: #class.qual
 [class.spaceship]: class.md#class.spaceship
 [class.static]: class.md#class.static
 [class.static.data]: class.md#class.static.data
 [class.temporary]: #class.temporary
-[class.this]: class.md#class.this
 [class.union]: class.md#class.union
 [class.virtual]: class.md#class.virtual
 [conv]: expr.md#conv
 [conv.array]: expr.md#conv.array
 [conv.func]: expr.md#conv.func
 [conv.integral]: expr.md#conv.integral
@@ -5512,11 +5516,10 @@ functions passed to `std::atexit()` or `std::at_quick_exit()`.
 [dcl.fct.default]: dcl.md#dcl.fct.default
 [dcl.init]: dcl.md#dcl.init
 [dcl.init.aggr]: dcl.md#dcl.init.aggr
 [dcl.init.list]: dcl.md#dcl.init.list
 [dcl.init.ref]: dcl.md#dcl.init.ref
-[dcl.inline]: dcl.md#dcl.inline
 [dcl.link]: dcl.md#dcl.link
 [dcl.meaning]: dcl.md#dcl.meaning
 [dcl.mptr]: dcl.md#dcl.mptr
 [dcl.name]: dcl.md#dcl.name
 [dcl.pre]: dcl.md#dcl.pre
@@ -5524,34 +5527,31 @@ functions passed to `std::atexit()` or `std::at_quick_exit()`.
 [dcl.ref]: dcl.md#dcl.ref
 [dcl.spec]: dcl.md#dcl.spec
 [dcl.spec.auto]: dcl.md#dcl.spec.auto
 [dcl.stc]: dcl.md#dcl.stc
 [dcl.struct.bind]: dcl.md#dcl.struct.bind
 [dcl.type.elab]: dcl.md#dcl.type.elab
 [dcl.typedef]: dcl.md#dcl.typedef
 [defns.block]: intro.md#defns.block
-[defns.signature]: intro.md#defns.signature
-[defns.signature.templ]: intro.md#defns.signature.templ
 [depr.local]: future.md#depr.local
 [depr.static.constexpr]: future.md#depr.static.constexpr
 [diff.cpp11.basic]: compatibility.md#diff.cpp11.basic
 [enum.udecl]: dcl.md#enum.udecl
 [except.handle]: except.md#except.handle
 [except.pre]: except.md#except.pre
 [except.spec]: except.md#except.spec
 [except.terminate]: except.md#except.terminate
 [except.throw]: except.md#except.throw
-[expr]: expr.md#expr
 [expr.add]: expr.md#expr.add
 [expr.alignof]: expr.md#expr.alignof
 [expr.arith.conv]: expr.md#expr.arith.conv
 [expr.ass]: expr.md#expr.ass
 [expr.await]: expr.md#expr.await
 [expr.call]: expr.md#expr.call
 [expr.cast]: expr.md#expr.cast
 [expr.comma]: expr.md#expr.comma
-[expr.compound]: expr.md#expr.compound
 [expr.cond]: expr.md#expr.cond
 [expr.const]: expr.md#expr.const
 [expr.const.cast]: expr.md#expr.const.cast
 [expr.context]: expr.md#expr.context
 [expr.delete]: expr.md#expr.delete
@@ -5561,12 +5561,12 @@ functions passed to `std::atexit()` or `std::at_quick_exit()`.
 [expr.log.or]: expr.md#expr.log.or
 [expr.mptr.oper]: expr.md#expr.mptr.oper
 [expr.new]: expr.md#expr.new
 [expr.pre]: expr.md#expr.pre
 [expr.prim.id]: expr.md#expr.prim.id
-[expr.prim.id.dtor]: expr.md#expr.prim.id.dtor
 [expr.prim.id.qual]: expr.md#expr.prim.id.qual
 [expr.prim.lambda]: expr.md#expr.prim.lambda
 [expr.prim.lambda.capture]: expr.md#expr.prim.lambda.capture
 [expr.prim.lambda.closure]: expr.md#expr.prim.lambda.closure
 [expr.prim.this]: expr.md#expr.prim.this
 [expr.prop]: expr.md#expr.prop
@@ -5582,184 +5582,175 @@ functions passed to `std::atexit()` or `std::at_quick_exit()`.
 [get.new.handler]: support.md#get.new.handler
 [headers]: library.md#headers
 [intro.execution]: #intro.execution
 [intro.memory]: #intro.memory
 [intro.multithread]: #intro.multithread
 [intro.object]: #intro.object
 [intro.progress]: #intro.progress
 [intro.races]: #intro.races
 [lex.charset]: lex.md#lex.charset
 [lex.name]: lex.md#lex.name
 [lex.separate]: lex.md#lex.separate
-[locale]: localization.md#locale
-[meta.trans.other]: utilities.md#meta.trans.other
 [module.context]: module.md#module.context
 [module.global.frag]: module.md#module.global.frag
-[module.import]: module.md#module.import
 [module.interface]: module.md#module.interface
 [module.reach]: module.md#module.reach
 [module.unit]: module.md#module.unit
 [multibyte.strings]: library.md#multibyte.strings
 [namespace.def]: dcl.md#namespace.def
-[namespace.memdef]: dcl.md#namespace.memdef
 [namespace.qual]: #namespace.qual
 [namespace.udecl]: dcl.md#namespace.udecl
 [namespace.udir]: dcl.md#namespace.udir
 [new.delete]: support.md#new.delete
 [new.delete.array]: support.md#new.delete.array
 [new.delete.placement]: support.md#new.delete.placement
 [new.delete.single]: support.md#new.delete.single
 [new.handler]: support.md#new.handler
 [over]: over.md#over
 [over.literal]: over.md#over.literal
 [over.match]: over.md#over.match
 [over.oper]: over.md#over.oper
 [over.over]: over.md#over.over
-[ptr.align]: utilities.md#ptr.align
 [ptr.launder]: support.md#ptr.launder
 [replacement.functions]: library.md#replacement.functions
 [special]: class.md#special
 [stmt.block]: stmt.md#stmt.block
 [stmt.dcl]: stmt.md#stmt.dcl
 [stmt.expr]: stmt.md#stmt.expr
-[stmt.goto]: stmt.md#stmt.goto
 [stmt.if]: stmt.md#stmt.if
-[stmt.label]: stmt.md#stmt.label
 [stmt.ranged]: stmt.md#stmt.ranged
 [stmt.return]: stmt.md#stmt.return
 [support.dynamic]: support.md#support.dynamic
-[support.limits]: support.md#support.limits
 [support.runtime]: support.md#support.runtime
 [support.start.term]: support.md#support.start.term
 [support.types]: support.md#support.types
 [temp.deduct.guide]: temp.md#temp.deduct.guide
 [temp.dep]: temp.md#temp.dep
 [temp.dep.candidate]: temp.md#temp.dep.candidate
 [temp.expl.spec]: temp.md#temp.expl.spec
 [temp.explicit]: temp.md#temp.explicit
 [temp.local]: temp.md#temp.local
 [temp.names]: temp.md#temp.names
-[temp.nondep]: temp.md#temp.nondep
 [temp.over]: temp.md#temp.over
 [temp.param]: temp.md#temp.param
 [temp.point]: temp.md#temp.point
 [temp.pre]: temp.md#temp.pre
 [temp.res]: temp.md#temp.res
 [temp.spec]: temp.md#temp.spec
 [temp.type]: temp.md#temp.type
 [thread]: thread.md#thread
 [thread.jthread.class]: thread.md#thread.jthread.class
 [thread.thread.class]: thread.md#thread.thread.class
 [thread.threads]: thread.md#thread.threads
-[util.dynamic.safety]: utilities.md#util.dynamic.safety
 [^1]: Appearing inside the brace-enclosed *declaration-seq* in a
     *linkage-specification* does not affect whether a declaration is a
     definition.
 [^2]: An implementation is not required to call allocation and
     deallocation functions from constructors or destructors; however,
     this is a permissible implementation technique.
-[^3]: This refers to unqualified names that occur, for instance, in a
- type or default argument in the *parameter-declaration-clause* or
-    used in the function body.
-[^4]: This refers to unqualified names following the class name; such a
-    name may be used in a *base-specifier* or in the
-    *member-specification* of the class definition.
-[^5]: 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]].
-[^6]: That is, an unqualified name that occurs, for instance, in a type
-    in the *parameter-declaration-clause* or in the
-    *noexcept-specifier*.
-[^7]: 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.
-[^8]: Lookups in which function names are ignored include names
     appearing in a *nested-name-specifier*, an
     *elaborated-type-specifier*, or a *base-specifier*.
-[^9]: The number of bits in a byte is reported by the macro `CHAR_BIT`
     in the header `<climits>`.
-[^10]: Under the “as-if” rule an implementation is allowed to store two
     objects at the same machine address or not store an object at all if
     the program cannot observe the difference [[intro.execution]].
-[^11]: For example, before the construction of a global object that is
- initialized via a user-provided constructor [[class.cdtor]].
-[^12]: 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.
-[^13]: Some implementations might define that copying an invalid pointer
     value causes a system-generated runtime fault.
-[^14]: 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.
-[^15]: The global `operator delete(void*, std::size_t)` precludes use of
     an allocation function `void operator new(std::size_t, std::size_t)`
-    as a placement allocation function ([[diff.cpp11.basic]]).
-[^16]: This subclause 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.
-[^17]: The same rules apply to initialization of an `initializer_list`
     object [[dcl.init.list]] with its underlying temporary array.
-[^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]: This is also known as two’s complement representation.
-[^23]: Static class members are objects or functions, and pointers to
     them are ordinary pointers to objects or functions.
-[^24]: For an object that is not within its lifetime, this is the first
     byte in memory that it will occupy or used to occupy.
-[^25]: 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.
-[^26]: As specified in  [[class.temporary]], after a full-expression is
     evaluated, a sequence of zero or more invocations of destructor
     functions for temporary objects takes place, usually in reverse
     order of the construction of each temporary object.
-[^27]: In other words, function executions do not interleave with each
     other.
-[^28]: An object with automatic or thread storage duration [[basic.stc]]
     is associated with one specific thread, and can be accessed by a
     different thread only indirectly through a pointer or reference
     [[basic.compound]].
-[^29]: A non-local variable with static storage duration having
     initialization with side effects is initialized in this case, even
-    if it is not itself odr-used ([[basic.def.odr]],
-    [[basic.stc.static]]).

 An *entity* is a value, object, reference, structured binding, function,
 enumerator, type, class member, bit-field, template, template
 specialization, namespace, or pack.
+A *name* is an *identifier* [[lex.name]], *operator-function-id*
+[[over.oper]], *literal-operator-id* [[over.literal]], or
+*conversion-function-id* [[class.conv.fct]].
+Every name is introduced by a *declaration*, which is a
+- *name-declaration*, *block-declaration*, or *member-declaration*
+  [[dcl.pre]], [[class.mem]],
+- *init-declarator* [[dcl.decl]],
+- *identifier* in a structured binding declaration [[dcl.struct.bind]],
+- *init-capture* [[expr.prim.lambda.capture]],
+- *condition* with a *declarator* [[stmt.pre]],
+- *member-declarator* [[class.mem]],
+- *using-declarator* [[namespace.udecl]],
+- *parameter-declaration* [[dcl.fct]],
+- *type-parameter* [[temp.param]],
+- *elaborated-type-specifier* that introduces a name [[dcl.type.elab]],
+- *class-specifier* [[class.pre]],
+- *enum-specifier* or *enumerator-definition* [[dcl.enum]],
+- *exception-declaration* [[except.pre]], or
+- implicit declaration of an injected-class-name [[class.pre]].
+[*Note 3*: The interpretation of a *for-range-declaration* produces one
+or more of the above [[stmt.ranged]]. — *end note*]
+An entity E is denoted by the name (if any) that is introduced by a
+declaration of E or by a *typedef-name* introduced by a declaration
+specifying E.
 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.
 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 equivalent
+  [[temp.over.link]] types, or
 - they are *literal-operator-id*s [[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
 [[basic.link]] of the name specified in each translation unit.
 ## Declarations and definitions <a id="basic.def">[[basic.def]]</a>
+A declaration [[dcl.dcl]] may (re)introduce one or more names and/or
+entities into a translation unit. If so, the declaration specifies the
+interpretation and semantic properties of these names. A declaration of
+an entity or *typedef-name* X is a redeclaration of X if another
+declaration of X is reachable from it [[module.reach]]. A declaration
+may also have effects including:
 - a static assertion [[dcl.pre]],
 - controlling template instantiation [[temp.explicit]],
 - guiding template argument deduction for constructors
   [[temp.deduct.guide]],
 - it declares a function without specifying the function’s body
   [[dcl.fct.def]],
 - it contains the `extern` specifier [[dcl.stc]] or a
   *linkage-specification*[^1] [[dcl.link]] and neither an *initializer*
   nor a *function-body*,
+- it declares a non-inline static data member in a class definition
+  [[class.mem]], [[class.static]],
 - it declares a static data member outside a class definition and the
   variable was defined within the class with the `constexpr` specifier
   (this usage is deprecated; see [[depr.static.constexpr]]),
+- it is an *elaborated-type-specifier* [[class.name]],
 - it is an *opaque-enum-declaration* [[dcl.enum]],
 - it is a *template-parameter* [[temp.param]],
 - it is a *parameter-declaration* [[dcl.fct]] in a function declarator
   that is not the *declarator* of a *function-definition*,
 - it is a `typedef` declaration [[dcl.typedef]],
 [*Note 2*: A class name can also be implicitly declared by an
 *elaborated-type-specifier* [[dcl.type.elab]]. — *end note*]
 In the definition of an object, the type of that object shall not be an
+incomplete type [[term.incomplete.type]], an abstract class type
+[[class.abstract]], or a (possibly multidimensional) array thereof.
 ## One-definition rule <a id="basic.def.odr">[[basic.def.odr]]</a>
+Each of the following is termed a *definable item*:
+- a class type [[class]],
+- an enumeration type [[dcl.enum]],
+- a function [[dcl.fct]],
+- a variable [[basic.pre]],
+- a templated entity [[temp.pre]],
+- a default argument for a parameter (for a function in a given scope)
+  [[dcl.fct.default]], or
+- a default template argument [[temp.param]].
 No translation unit shall contain more than one definition of any
+definable item.
 An expression or conversion is *potentially evaluated* unless it is an
+unevaluated operand [[expr.context]], a subexpression thereof, or a
 conversion in an initialization or conversion sequence in such a
 context. The set of *potential results* of an expression E is defined as
 follows:
 - If E is an *id-expression* [[expr.prim.id]], the set contains only E.
 — *end note*]
 A function is *named by* an expression or conversion as follows:
 - A function is named by an expression or conversion if it is the
+  selected member of an overload set
+  [[basic.lookup]], [[over.match]], [[over.over]] in an overload
+ resolution performed as part of forming that expression or conversion,
+ unless it is a pure virtual function and either the expression is not
+  an *id-expression* naming the function with an explicitly qualified
+ name or the expression forms a pointer to member [[expr.unary.op]].
+ \[*Note 2*: This covers taking the address of functions
+  [[conv.func]], [[expr.unary.op]], calls to named functions
+  [[expr.call]], operator overloading [[over]], user-defined conversions
+  [[class.conv.fct]], allocation functions for *new-expression*s
+  [[expr.new]], as well as non-default initialization [[dcl.init]]. A
+ constructor selected to copy or move an object of class type is
+ considered to be named by an expression or conversion even if the call
+  is actually elided by the implementation
   [[class.copy.elision]]. — *end note*]
 - A deallocation function for a class is named by a *new-expression* if
   it is the single matching deallocation function for the allocation
   function selected by overload resolution, as specified in
   [[expr.new]].
 - A deallocation function for a class is named by a *delete-expression*
   if it is the selected usual deallocation function as specified in
   [[expr.delete]] and  [[class.free]].
+A variable is named by an expression if the expression is an
+*id-expression* that denotes it. A variable `x` that is named by a
+potentially-evaluated expression E is *odr-used* by E unless
 - `x` is a reference that is usable in constant expressions
   [[expr.const]], or
 - `x` is a variable of non-reference type that is usable in constant
   expressions and has no mutable subobjects, and E is an element of the
   set of potential results of an expression of non-volatile-qualified
   non-class type to which the lvalue-to-rvalue conversion [[conv.lval]]
   is applied, or
 - `x` is a variable of non-reference type, and E is an element of the
+  set of potential results of a discarded-value expression
+ [[expr.context]] to which the lvalue-to-rvalue conversion is not
+  applied.
 A structured binding is odr-used if it appears as a
 potentially-evaluated expression.
 `*this` is odr-used if `this` 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 is
 odr-used if it is named by a potentially-evaluated expression or
 conversion. A non-placement allocation or deallocation function for a
 class is odr-used by the definition of a constructor of that class. A
 implicitly-defined copy-assignment or move-assignment function for
 another class as specified in  [[class.copy.assign]]. 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]].
+A local entity [[basic.pre]] is *odr-usable* in a scope
+[[basic.scope.scope]] if:
 - either the local entity is not `*this`, or an enclosing class or
   non-lambda function parameter scope exists and, if the innermost such
   scope is a function parameter scope, it corresponds to a non-static
   member function, and
+- for each intervening scope [[basic.scope.scope]] between the point at
+  which the entity is introduced and the scope (where `*this` is
+  considered to be introduced within the innermost enclosing class or
+  non-lambda function definition scope), either:
+  - the intervening scope is a block scope, or
+  - the intervening scope is the function parameter scope of a
+    *lambda-expression* that has a *simple-capture* naming the entity or
+    has a *capture-default*, and the block scope of the
+    *lambda-expression* is also an intervening scope.
+If a local entity is odr-used in a scope in which it is not odr-usable,
+the program is ill-formed.
 [*Example 2*:
 ``` cpp
 void f(int n) {
 }
 ```
 — *end example*]
+Every program shall contain at least one definition of every function or
+variable that is odr-used in that program outside of a discarded
+statement [[stmt.if]]; no diagnostic required. The definition can appear
+explicitly in the program, it can be found in the standard or a
+user-defined library, or (when appropriate) it is implicitly defined
 (see  [[class.default.ctor]], [[class.copy.ctor]], [[class.dtor]], and
 [[class.copy.assign]]).
 [*Example 3*:
 translation unit excluding its *private-module-fragment* (if any). A
 definition of an inline function or variable shall be reachable from the
 end of every definition domain in which it is odr-used outside of a
 discarded statement.
+A definition of a class shall be reachable in every context in which the
+class is used in a way that requires the class type to be complete.
 [*Example 4*:
 The following complete translation unit is well-formed, even though it
 never defines `X`:
 - `T` is used as the allocated type or array element type in a
   *new-expression* [[expr.new]], or
 - an lvalue-to-rvalue conversion is applied to a glvalue referring to an
   object of type `T` [[conv.lval]], or
 - an expression is converted (either implicitly or explicitly) to type
+  `T`
+  [[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 [[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`
 - an *exception-declaration* has type `T`, reference to `T`, or pointer
   to `T` [[except.handle]].
 — *end note*]
+For any definable item `D` with definitions in multiple translation
+units,
+- if `D` is a non-inline non-templated function or variable, or
+- if the definitions in different translation units do not satisfy the
+  following requirements,
+the program is ill-formed; a diagnostic is required only if the
+definable item is attached to a named module and a prior definition is
+reachable at the point where a later definition occurs. Given such an
+item, for all definitions of `D`, or, if `D` is an unnamed enumeration,
+for all definitions of `D` that are reachable at any given program
+point, the following requirements shall be satisfied.
 - Each such definition shall not be attached to a named module
   [[module.unit]].
 - Each such definition shall consist of the same sequence of tokens,
   where the definition of a closure type is considered to consist of the
 - In each such definition, except within the default arguments and
   default template arguments of `D`, corresponding *lambda-expression*s
   shall have the same closure type (see below).
 - In each such definition, corresponding entities shall have the same
   language linkage.
+- In each such definition, const objects with static or thread storage
+  duration shall be constant-initialized if the object is
+  constant-initialized in any such definition.
+- In each such definition, corresponding manifestly constant-evaluated
+  expressions that are not value-dependent shall have the same value
+  [[expr.const]], [[temp.dep.constexpr]].
 - In each such definition, the overloaded operators referred to, the
   implicit calls to conversion functions, constructors, operator new
   functions and operator delete functions, shall refer to the same
   function.
 - In each such definition, a default argument used by an (implicit or
   explicit) function call or a default template argument used by an
   (implicit or explicit) *template-id* or *simple-template-id* is
   treated as if its token sequence were present in the definition of
   `D`; that is, the default argument or default template argument is
   subject to the requirements described in this paragraph (recursively).
+- If `D` is a class with an implicitly-declared constructor
+  [[class.default.ctor]], [[class.copy.ctor]], it is as if the
   constructor was implicitly defined in every translation unit where it
   is odr-used, and the implicit definition in every translation unit
   shall call the same constructor for a subobject of `D`.
   \[*Example 5*:
   ``` cpp
   implicit definition in every translation unit shall call the same
   comparison operators for each subobject of `D`.
 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, and also to
+dependent names at the point of instantiation [[temp.dep]]. These
+requirements also apply to corresponding entities defined within each
+definition of `D` (including the closure types of *lambda-expression*s,
+but excluding entities defined within default arguments or default
+template arguments of either `D` or an entity not defined within `D`).
+For each such entity and for `D` itself, the behavior is as if there is
+a single entity with a single definition, including in the application
+of these requirements to other entities.
 [*Note 4*: The entity is still declared in multiple translation units,
 and [[basic.link]] still applies to these declarations. In particular,
 *lambda-expression*s [[expr.prim.lambda]] appearing in the type of `D`
+can result in the different declarations having distinct types, and
+*lambda-expression*s appearing in a default argument of `D` might still
 denote different types in different translation units. — *end note*]
 [*Example 6*:
 ``` cpp
 inline void f(bool cond, void (*p)()) {
   if (cond) f(false, []{});
 [[dcl.enum]], those unnamed enumeration types shall be the same; no
 diagnostic required.
 ## Scope <a id="basic.scope">[[basic.scope]]</a>
+### General <a id="basic.scope.scope">[[basic.scope.scope]]</a>
+The declarations in a program appear in a number of *scopes* that are in
+general discontiguous. The *global scope* contains the entire program;
+every other scope S is introduced by a declaration,
+*parameter-declaration-clause*, *statement*, or *handler* (as described
+in the following subclauses of [[basic.scope]]) appearing in another
+scope which thereby contains S. An *enclosing scope* at a program point
+is any scope that contains it; the smallest such scope is said to be the
+*immediate scope* at that point. A scope *intervenes* between a program
+point P and a scope S (that does not contain P) if it is or contains S
+but does not contain P.
+Unless otherwise specified:
+- The smallest scope that contains a scope S is the *parent scope* of S.
+- No two declarations (re)introduce the same entity.
+- A declaration *inhabits* the immediate scope at its locus
+  [[basic.scope.pdecl]].
+- A declaration’s *target scope* is the scope it inhabits.
+- Any names (re)introduced by a declaration are *bound* to it in its
+  target scope.
+An entity *belongs* to a scope S if S is the target scope of a
+declaration of the entity.
+[*Note 1*:
+Special cases include that:
+- Template parameter scopes are parents only to other template parameter
+  scopes [[basic.scope.temp]].
+- Corresponding declarations with appropriate linkage declare the same
+  entity [[basic.link]].
+- The declaration in a *template-declaration* inhabits the same scope as
+  the *template-declaration*.
+- Friend declarations and declarations of qualified names and template
+  specializations do not bind names [[dcl.meaning]]; those with
+  qualified names target a specified scope, and other friend
+  declarations and certain *elaborated-type-specifier*s
+  [[dcl.type.elab]] target a larger enclosing scope.
+- Block-scope extern declarations target a larger enclosing scope but
+  bind a name in their immediate scope.
+- The names of unscoped enumerators are bound in the two innermost
+  enclosing scopes [[dcl.enum]].
+- A class’s name is also bound in its own scope [[class.pre]].
+- The names of the members of an anonymous union are bound in the
+  union’s parent scope [[class.union.anon]].
+— *end note*]
+Two non-static member functions have *corresponding object parameters*
+if:
+- exactly one is an implicit object member function with no
+  *ref-qualifier* and the types of their object parameters [[dcl.fct]],
+  after removing top-level references, are the same, or
+- their object parameters have the same type.
+Two non-static member function templates have *corresponding object
+parameters* if:
+- exactly one is an implicit object member function with no
+  *ref-qualifier* and the types of their object parameters, after
+  removing any references, are equivalent, or
+- the types of their object parameters are equivalent.
+Two function templates have *corresponding signatures* if their
+*template-parameter-list*s have the same length, their corresponding
+*template-parameter*s are equivalent, they have equivalent
+non-object-parameter-type-lists and return types (if any), and, if both
+are non-static members, they have corresponding object parameters.
+Two declarations *correspond* if they (re)introduce the same name, both
+declare constructors, or both declare destructors, unless
+- either is a *using-declarator*, or
+- one declares a type (not a *typedef-name*) and the other declares a
+  variable, non-static data member other than of an anonymous union
+  [[class.union.anon]], enumerator, function, or function template, or
+- each declares a function or function template, except when
+  - both declare functions with the same
+    non-object-parameter-type-list,[^3] equivalent [[temp.over.link]]
+    trailing *requires-clause*s (if any, except as specified in
+    [[temp.friend]]), and, if both are non-static members, they have
+    corresponding object parameters, or
+  - both declare function templates with corresponding signatures and
+    equivalent *template-head*s and trailing *requires-clause*s (if
+    any).
+[*Note 2*:
+Declarations can correspond even if neither binds a name.
 [*Example 1*:
+``` cpp
+struct A {
+  friend void f();      // #1
+};
+struct B {
+  friend void f() {}    // corresponds to, and defines, #1
+};
+```
+— *end example*]
+— *end note*]
+[*Example 2*:
 ``` cpp
+typedef int Int;
+enum E : int { a };
+void f(int);                    // #1
+void f(Int) {}                  // defines #1
+void f(E) {}                    // OK, another overload
+struct X {
+  static void f();
+  void f() const;               // error: redeclaration
+  void g();
+  void g() const;               // OK
+  void g() &;                   // error: redeclaration
+  void h(this X&, int);
+  void h(int) &&;               // OK, another overload
+  void j(this const X&);
+  void j() const &;             // error: redeclaration
+  void k();
+  void k(this X&);              // error: redeclaration
+};
+```
+— *end example*]
+Two declarations *potentially conflict* if they correspond and cause
+their shared name to denote different entities [[basic.link]]. The
+program is ill-formed if, in any scope, a name is bound to two
+declarations that potentially conflict and one precedes the other
+[[basic.lookup]].
+[*Note 3*: Overload resolution can consider potentially conflicting
+declarations found in multiple scopes (e.g., via *using-directive*s or
+for operator functions), in which case it is often
+ambiguous. — *end note*]
+[*Example 3*:
+``` cpp
+void f() {
+  int x,y;
+  void x();             // error: different entity for x
+  int y;                // error: redefinition
+}
+enum { f };             // error: different entity for ::f
+namespace A {}
+namespace B = A;
+namespace B = A;        // OK, no effect
+namespace B = B;        // OK, no effect
+namespace A = B;        // OK, no effect
+namespace B {}          // error: different entity for B
+```
+— *end example*]
+A declaration is *nominable* in a class, class template, or namespace E
+at a point P if it precedes P, it does not inhabit a block scope, and
+its target scope is the scope associated with E or, if E is a namespace,
+any element of the inline namespace set of E [[namespace.def]].
+[*Example 4*:
+``` cpp
+namespace A {
+  void f() {void g();}
+  inline namespace B {
+    struct S {
+      friend void h();
+      static int i;
+    };
+  }
 }
 ```
+At the end of this example, the declarations of `f`, `B`, `S`, and `h`
+are nominable in `A`, but those of `g` and `i` are not.
 — *end example*]
+When instantiating a templated entity [[temp.pre]], any scope S
+introduced by any part of the template definition is considered to be
+introduced by the instantiated entity and to contain the instantiations
+of any declarations that inhabit S.
 ### Point of declaration <a id="basic.scope.pdecl">[[basic.scope.pdecl]]</a>
+The *locus* of a declaration [[basic.pre]] that is a declarator is
+immediately after the complete declarator [[dcl.decl]].
 [*Example 1*:
 ``` cpp
 unsigned char x = 12;
 — *end example*]
 [*Note 1*:
+A name from an outer scope remains visible up to the locus of the
+declaration that hides it.
 [*Example 2*:
 ``` cpp
 const int  i = 2;
 — *end example*]
 — *end note*]
+The locus of a *class-specifier* is immediately after the *identifier*
+or *simple-template-id* (if any) in its *class-head* [[class.pre]]. The
+locus of an *enum-specifier* is immediately after its *enum-head*; the
+locus of an *opaque-enum-declaration* is immediately after it
+[[dcl.enum]]. The locus of an *alias-declaration* is immediately after
+it.
+The locus of a *using-declarator* that does not name a constructor is
+immediately after the *using-declarator* [[namespace.udecl]].
+The locus of an *enumerator-definition* is immediately after it.
 [*Example 3*:
 ``` cpp
 const int x = 12;
 Here, the enumerator `x` is initialized with the value of the constant
 `x`, namely 12.
 — *end example*]
 [*Note 2*:
+After the declaration of a class member, the member name can be found in
+the scope of its class even if the class is an incomplete class.
+[*Example 4*:
 ``` cpp
 struct X {
   enum E { z = 16 };
   int b[X::z];          // OK
 };
 ```
+— *end example*]
 — *end note*]
+The locus of an *elaborated-type-specifier* that is a declaration
+[[dcl.type.elab]] is immediately after it.
+The locus of an injected-class-name declaration [[class.pre]] is
 immediately following the opening brace of the class definition.
+The locus of the implicit declaration of a function-local predefined
+variable [[dcl.fct.def.general]] is immediately before the
+*function-body* of its function’s definition.
+The locus of the declaration of a structured binding [[dcl.struct.bind]]
+is immediately after the *identifier-list* of the structured binding
 declaration.
+The locus of a *for-range-declaration* of a range-based `for` statement
 [[stmt.ranged]] is immediately after the *for-range-initializer*.
+The locus of a *template-parameter* is immediately after it.
+[*Example 5*:
 ``` cpp
 typedef unsigned char T;
 template<class T
+  = T               // lookup finds the typedef-name
   , T               // lookup finds the template parameter
     N = 0> struct A { };
 ```
 — *end example*]
+The locus of a *concept-definition* is immediately after its
+concept-name [[temp.concept]].
+[*Note 3*: The *constraint-expression* cannot use the
+*concept-name*. — *end note*]
+The locus of a *namespace-definition* with an *identifier* is
+immediately after the *identifier*.
+[*Note 4*: An identifier is invented for an
+*unnamed-namespace-definition* [[namespace.unnamed]]. — *end note*]
+[*Note 5*: Friend declarations can introduce functions or classes that
+belong to the nearest enclosing namespace or block scope, but they do
+not bind names anywhere [[class.friend]]. Function declarations at block
+scope and variable declarations with the `extern` specifier at block
+scope declare entities that belong to the nearest enclosing namespace,
+but they do not bind names in it. — *end note*]
 [*Note 6*: For point of instantiation of a template, see
 [[temp.point]]. — *end note*]
 ### Block scope <a id="basic.scope.block">[[basic.scope.block]]</a>
+Each
+- selection or iteration statement [[stmt.select]], [[stmt.iter]],
+- substatement of such a statement,
+- *handler* [[except.pre]], or
+- compound statement [[stmt.block]] that is not the *compound-statement*
+  of a *handler*
+introduces a *block scope* that includes that statement or *handler*.
+[*Note 1*: A substatement that is also a block has only one
+scope. — *end note*]
+A variable that belongs to a block scope is a *block variable*.
 [*Example 1*:
+``` cpp
+int i = 42;
+int a[10];
+for (int i = 0; i < 10; i++)
+  a[i] = i;
+int j = i;          // j = 42
+```
+— *end example*]
+If a declaration whose target scope is the block scope S of a
+- *compound-statement* of a *lambda-expression*, *function-body*, or
+  *function-try-block*,
+- substatement of a selection or iteration statement that is not itself
+  a selection or iteration statement, or
+- *handler* of a *function-try-block*
+potentially conflicts with a declaration whose target scope is the
+parent scope of S, the program is ill-formed.
+[*Example 2*:
 ``` cpp
 if (int x = f()) {
   int x;            // error: redeclaration of x
 }
 else {
 — *end example*]
 ### Function parameter scope <a id="basic.scope.param">[[basic.scope.param]]</a>
+A *parameter-declaration-clause* P introduces a
+*function parameter scope* that includes P.
+[*Note 1*: A function parameter cannot be used for its value within the
+*parameter-declaration-clause* [[dcl.fct.default]]. — *end note*]
+- If P is associated with a *declarator* and is preceded by a
+  (possibly-parenthesized) *noptr-declarator* of the form
+  *declarator-id* *attribute-specifier-seq*ₒₚₜ , its scope extends to
+  the end of the nearest enclosing *init-declarator*,
+  *member-declarator*, *declarator* of a *parameter-declaration* or a
+  *nodeclspec-function-declaration*, or *function-definition*, but does
+  not include the locus of the associated *declarator*. \[*Note 2*: In
+  this case, P declares the parameters of a function (or a function or
+  template parameter declared with function type). A member function’s
+  parameter scope is nested within its class’s scope. — *end note*]
+- If P is associated with a *lambda-declarator*, its scope extends to
+  the end of the *compound-statement* in the *lambda-expression*.
+- If P is associated with a *requirement-parameter-list*, its scope
+  extends to the end of the *requirement-body* of the
+  requires-expression.
+- If P is associated with a *deduction-guide*, its scope extends to the
+  end of the *deduction-guide*.
+### Lambda scope <a id="basic.scope.lambda">[[basic.scope.lambda]]</a>
+A *lambda-expression* `E` introduces a *lambda scope* that starts
+immediately after the *lambda-introducer* of `E` and extends to the end
+of the *compound-statement* of `E`.
 ### Namespace scope <a id="basic.scope.namespace">[[basic.scope.namespace]]</a>
+Any *namespace-definition* for a namespace N introduces a
+*namespace scope* that includes the *namespace-body* for every
+*namespace-definition* for N. For each non-friend redeclaration or
+specialization whose target scope is or is contained by the scope, the
+portion after the *declarator-id*, *class-head-name*, or
+*enum-head-name* is also included in the scope. The global scope is the
+namespace scope of the global namespace [[basic.namespace]].
 [*Example 1*:
 ``` cpp
+namespace Q {
+ namespace V { void f(); }
+ void V::f() {         // in the scope of V
+    void h();           // declares Q::V::h
   }
 }
 ```
 — *end example*]
 ### Class scope <a id="basic.scope.class">[[basic.scope.class]]</a>
+Any declaration of a class or class template C introduces a
+*class scope* that includes the *member-specification* of the
+*class-specifier* for C (if any). For each non-friend redeclaration or
+specialization whose target scope is or is contained by the scope, the
+portion after the *declarator-id*, *class-head-name*, or
+*enum-head-name* is also included in the scope.
+[*Note 1*:
+Lookup from a program point before the *class-specifier* of a class will
+find no bindings in the class scope.
 [*Example 1*:
 ``` cpp
+template<class D>
+struct B {
+  D::type x;            // #1
 };
+struct A { using type = int; };
+struct C : A, B<C> {};  // error at #1: C::type not found
 ```
 — *end example*]
+— *end note*]
 ### Enumeration scope <a id="basic.scope.enum">[[basic.scope.enum]]</a>
+Any declaration of an enumeration E introduces an *enumeration scope*
+that includes the *enumerator-list* of the *enum-specifier* for E (if
+any).
 ### Template parameter scope <a id="basic.scope.temp">[[basic.scope.temp]]</a>
+Each template *template-parameter* introduces a
+*template parameter scope* that includes the *template-head* of the
+*template-parameter*.
+Each *template-declaration* D introduces a template parameter scope that
+extends from the beginning of its *template-parameter-list* to the end
+of the *template-declaration*. Any declaration outside the
+*template-parameter-list* that would inhabit that scope instead inhabits
+the same scope as D. The parent scope of any scope S that is not a
+template parameter scope is the smallest scope that contains S and is
+not a template parameter scope.
+[*Note 1*: Therefore, only template parameters belong to a template
+parameter scope, and only template parameter scopes have a template
+parameter scope as a parent scope. — *end note*]
 ## Name lookup <a id="basic.lookup">[[basic.lookup]]</a>
+### General <a id="basic.lookup.general">[[basic.lookup.general]]</a>
 The name lookup rules apply uniformly to all names (including
 *typedef-name*s [[dcl.typedef]], *namespace-name*s [[basic.namespace]],
 and *class-name*s [[class.name]]) wherever the grammar allows such names
 in the context discussed by a particular rule. Name lookup associates
 the use of a name with a set of declarations [[basic.def]] of that name.
+Unless otherwise specified, the program is ill-formed if no declarations
+are found. If the declarations found by name lookup all denote functions
+or function templates, the declarations are said to form an *overload
+set*. Otherwise, if the declarations found by name lookup do not all
+denote the same entity, they are *ambiguous* and the program is
+ill-formed. Overload resolution [[over.match]], [[over.over]] takes
+place after name lookup has succeeded. The access rules [[class.access]]
+are considered only once name lookup and function overload resolution
+(if applicable) have succeeded. Only after name lookup, function
+overload resolution (if applicable) and access checking have succeeded
+are the semantic properties introduced by the declarations used in
+further processing.
+A program point P is said to follow any declaration in the same
+translation unit whose locus [[basic.scope.pdecl]] is before P.
+[*Note 1*: The declaration might appear in a scope that does not
+contain P. — *end note*]
+A declaration X *precedes* a program point P in a translation unit L if
+P follows X, X inhabits a class scope and is reachable from P, or else X
+appears in a translation unit D and
+- P follows a *module-import-declaration* or *module-declaration* that
+  imports D (directly or indirectly), and
+- X appears after the *module-declaration* in D (if any) and before the
+  *private-module-fragment* in D (if any), and
+- either X is exported or else D and L are part of the same module and X
+  does not inhabit a namespace with internal linkage or declare a name
+  with internal linkage. \[*Note 2*: Names declared by a
+  *using-declaration* have no linkage. — *end note*]
+[*Note 3*:
+A *module-import-declaration* imports both the named translation unit(s)
+and any modules named by exported *module-import-declaration*s within
+them, recursively.
+[*Example 1*:
+Translation unit #1
+``` cpp
+export module Q;
+export int sq(int i) { return i*i; }
+```
+Translation unit #2
+``` cpp
+export module R;
+export import Q;
+```
+Translation unit #3
+``` cpp
+import R;
+int main() { return sq(9); }    // OK, sq from module Q
+```
+— *end example*]
+— *end note*]
+A *single search* in a scope S for a name N from a program point P finds
+all declarations that precede P to which any name that is the same as N
+[[basic.pre]] is bound in S. If any such declaration is a
+*using-declarator* whose terminal name [[expr.prim.id.unqual]] is not
+dependent [[temp.dep.type]], it is replaced by the declarations named by
+the *using-declarator* [[namespace.udecl]].
+In certain contexts, only certain kinds of declarations are included.
+After any such restriction, any declarations of classes or enumerations
+are discarded if any other declarations are found.
+[*Note 4*: A type (but not a *typedef-name* or template) is therefore
+hidden by any other entity in its scope. — *end note*]
+However, if a lookup is *type-only*, only declarations of types and
+templates whose specializations are types are considered; furthermore,
+if declarations of a *typedef-name* and of the type to which it refers
+are found, the declaration of the *typedef-name* is discarded instead of
+the type declaration.
+### Member name lookup <a id="class.member.lookup">[[class.member.lookup]]</a>
+A *search* in a scope X for a name M from a program point P is a single
+search in X for M from P unless X is the scope of a class or class
+template T, in which case the following steps define the result of the
+search.
+[*Note 1*: The result differs only if M is a *conversion-function-id*
+or if the single search would find nothing. — *end note*]
+The *lookup set* for a name N in a class or class template C, called
+S(N,C), consists of two component sets: the *declaration set*, a set of
+members named N; and the *subobject set*, a set of subobjects where
+declarations of these members were found (possibly via
+*using-declaration*s). In the declaration set, type declarations
+(including injected-class-names) are replaced by the types they
+designate. S(N,C) is calculated as follows:
+The declaration set is the result of a single search in the scope of C
+for N from immediately after the *class-specifier* of C if P is in a
+complete-class context of C or from P otherwise. If the resulting
+declaration set is not empty, the subobject set contains C itself, and
+calculation is complete.
+Otherwise (i.e., C does not contain a declaration of N or the resulting
+declaration set is empty), S(N,C) is initially empty. Calculate the
+lookup set for N in each direct non-dependent [[temp.dep.type]] base
+class subobject Bᵢ, and merge each such lookup set S(N,Bᵢ) in turn into
+S(N,C).
+[*Note 2*: If C is incomplete, only base classes whose *base-specifier*
+appears before P are considered. If C is an instantiated class, its base
+classes are not dependent. — *end note*]
+The following steps define the result of merging lookup set S(N,Bᵢ) into
+the intermediate S(N,C):
+- If each of the subobject members of S(N,Bᵢ) is a base class subobject
+  of at least one of the subobject members of S(N,C), or if S(N,Bᵢ) is
+  empty, S(N,C) is unchanged and the merge is complete. Conversely, if
+  each of the subobject members of S(N,C) is a base class subobject of
+  at least one of the subobject members of S(N,Bᵢ), or if S(N,C) is
+  empty, the new S(N,C) is a copy of S(N,Bᵢ).
+- Otherwise, if the declaration sets of S(N,Bᵢ) and S(N,C) differ, the
+  merge is ambiguous: the new S(N,C) is a lookup set with an invalid
+  declaration set and the union of the subobject sets. In subsequent
+  merges, an invalid declaration set is considered different from any
+  other.
+- Otherwise, the new S(N,C) is a lookup set with the shared set of
+  declarations and the union of the subobject sets.
+The result of the search is the declaration set of S(M,T). If it is an
+invalid set, the program is ill-formed. If it differs from the result of
+a search in T for M in a complete-class context [[class.mem]] of T, the
+program is ill-formed, no diagnostic required.
+[*Example 1*:
+``` cpp
+struct A { int x; };                    // S(x,A) = { { A::x }, { A } }
+struct B { float x; };                  // S(x,B) = { { B::x }, { B } }
+struct C: public A, public B { };       // S(x,C) = { invalid, { A in C, B in C } }
+struct D: public virtual C { };         // S(x,D) = S(x,C)
+struct E: public virtual C { char x; }; // S(x,E) = { { E::x }, { E } }
+struct F: public D, public E { };       // S(x,F) = S(x,E)
+int main() {
+  F f;
+  f.x = 0;                              // OK, lookup finds E::x
+}
+```
+S(`x`,`F`) is unambiguous because the `A` and `B` base class subobjects
+of `D` are also base class subobjects of `E`, so S(`x`,`D`) is discarded
+in the first merge step.
+— *end example*]
+If M is a non-dependent *conversion-function-id*, conversion function
+templates that are members of T are considered. For each such template
+F, the lookup set S(t,T) is constructed, considering a function template
+declaration to have the name t only if it corresponds to a declaration
+of F [[basic.scope.scope]]. The members of the declaration set of each
+such lookup set, which shall not be an invalid set, are included in the
+result.
+[*Note 3*: Overload resolution will discard those that cannot convert
+to the type specified by M [[temp.over]]. — *end note*]
+[*Note 4*: A static member, a nested type or an enumerator defined in a
+base class `T` can unambiguously be found even if an object has more
+than one base class subobject of type `T`. Two base class subobjects
+share the non-static member subobjects of their common virtual base
+classes. — *end note*]
+[*Example 2*:
+``` cpp
+struct V {
+  int v;
+};
+struct A {
+  int a;
+  static int s;
+  enum { e };
+};
+struct B : A, virtual V { };
+struct C : A, virtual V { };
+struct D : B, C { };
+void f(D* pd) {
+  pd->v++;          // OK, only one v (virtual)
+  pd->s++;          // OK, only one s (static)
+  int i = pd->e;    // OK, only one e (enumerator)
+  pd->a++;          // error: ambiguous: two a{s} in D
+}
+```
+— *end example*]
+[*Note 5*:  When virtual base classes are used, a hidden declaration
+can be reached along a path through the subobject lattice that does not
+pass through the hiding declaration. This is not an ambiguity. The
+identical use with non-virtual base classes is an ambiguity; in that
+case there is no unique instance of the name that hides all the
+others. — *end note*]
+[*Example 3*:
+``` cpp
+struct V { int f();  int x; };
+struct W { int g();  int y; };
+struct B : virtual V, W {
+  int f();  int x;
+  int g();  int y;
+};
+struct C : virtual V, W { };
+struct D : B, C { void glorp(); };
+```
+<a id="fig:class.lookup"></a>
+![Name lookup \[fig:class.lookup\]](images/figname.svg)
+As illustrated in Figure [[fig:class.lookup]], the names declared in
+`V` and the left-hand instance of `W` are hidden by those in `B`, but
+the names declared in the right-hand instance of `W` are not hidden at
+all.
+``` cpp
+void D::glorp() {
+  x++;              // OK, B::x hides V::x
+  f();              // OK, B::f() hides V::f()
+  y++;              // error: B::y and C's W::y
+  g();              // error: B::g() and C's W::g()
+}
+```
+— *end example*]
+An explicit or implicit conversion from a pointer to or an expression
+designating an object of a derived class to a pointer or reference to
+one of its base classes shall unambiguously refer to a unique object
+representing the base class.
+[*Example 4*:
+``` cpp
+struct V { };
+struct A { };
+struct B : A, virtual V { };
+struct C : A, virtual V { };
+struct D : B, C { };
+void g() {
+  D d;
+  B* pb = &d;
+  A* pa = &d;       // error: ambiguous: C's A or B's A?
+  V* pv = &d;       // OK, only one V subobject
+}
+```
+— *end example*]
+[*Note 6*: Even if the result of name lookup is unambiguous, use of a
+name found in multiple subobjects might still be ambiguous
+[[conv.mem]], [[expr.ref]], [[class.access.base]]. — *end note*]
+[*Example 5*:
+``` cpp
+struct B1 {
+  void f();
+  static void f(int);
+  int i;
+};
+struct B2 {
+  void f(double);
+};
+struct I1: B1 { };
+struct I2: B1 { };
+struct D: I1, I2, B2 {
+  using B1::f;
+  using B2::f;
+  void g() {
+    f();                        // Ambiguous conversion of this
+    f(0);                       // Unambiguous (static)
+    f(0.0);                     // Unambiguous (only one B2)
+    int B1::* mpB1 = &D::i;     // Unambiguous
+    int D::* mpD = &D::i;       // Ambiguous conversion
+  }
+};
+```
+— *end example*]
 ### Unqualified name lookup <a id="basic.lookup.unqual">[[basic.lookup.unqual]]</a>
+A *using-directive* is *active* in a scope S at a program point P if it
+precedes P and inhabits either S or the scope of a namespace nominated
+by a *using-directive* that is active in S at P.
+An *unqualified search* in a scope S from a program point P includes the
+results of searches from P in
+- S, and
+- for any scope U that contains P and is or is contained by S, each
+ namespace contained by S that is nominated by a *using-directive* that
+  is active in U at P.
+If no declarations are found, the results of the unqualified search are
+the results of an unqualified search in the parent scope of S, if any,
+from P.
+[*Note 1*: When a class scope is searched, the scopes of its base
+classes are also searched [[class.member.lookup]]. If it inherits from a
+single base, it is as if the scope of the base immediately contains the
+scope of the derived class. Template parameter scopes that are
+associated with one scope in the chain of parents are also considered
+[[temp.local]]. — *end note*]
+*Unqualified name lookup* from a program point performs an unqualified
+search in its immediate scope.
+An *unqualified name* is a name that does not immediately follow a
+*nested-name-specifier* or the `.` or `->` in a class member access
+expression [[expr.ref]], possibly after a `template` keyword or `~`.
+Unless otherwise specified, such a name undergoes unqualified name
+lookup from the point where it appears.
+An unqualified name that is a component name [[expr.prim.id.unqual]] of
+a *type-specifier* or *ptr-operator* of a *conversion-type-id* is looked
+up in the same fashion as the *conversion-function-id* in which it
+appears. If that lookup finds nothing, it undergoes unqualified name
+lookup; in each case, only names that denote types or templates whose
+specializations are types are considered.
+[*Example 1*:
+``` cpp
+struct T1 { struct U { int i; }; };
+struct T2 { };
+struct U1 {};
+struct U2 {};
+struct B {
+  using T = T1;
+  using U = U1;
+  operator U1 T1::*();
+  operator U1 T2::*();
+  operator U2 T1::*();
+  operator U2 T2::*();
+};
+template<class X, class T>
+int g() {
+  using U = U2;
+  X().operator U T::*();                // #1, searches for T in the scope of X first
+  X().operator U decltype(T())::*();    // #2
+  return 0;
+}
+int x = g<B, T2>();                     // #1 calls B::operator U1 T1::*
+                                        // #2 calls B::operator U1 T2::*
+```
+— *end example*]
+In a friend declaration *declarator* whose *declarator-id* is a
+*qualified-id* whose lookup context [[basic.lookup.qual]] is a class or
+namespace S, lookup for an unqualified name that appears after the
+*declarator-id* performs a search in the scope associated with S. If
+that lookup finds nothing, it undergoes unqualified name lookup.
+[*Example 2*:
+``` cpp
+using I = int;
+using D = double;
+namespace A {
+  inline namespace N {using C = char; }
+  using F = float;
+  void f(I);
+  void f(D);
+  void f(C);
+  void f(F);
+}
+struct X0 {using F = float; };
+struct W {
+  using D = void;
+  struct X : X0 {
+    void g(I);
+    void g(::D);
+    void g(F);
+  };
+};
+namespace B {
+  typedef short I, F;
+  class Y {
+    friend void A::f(I);        // error: no void A::f(short)
+    friend void A::f(D);        // OK
+    friend void A::f(C);        // error: A::N::C not found
+    friend void A::f(F);        // OK
+    friend void W::X::g(I);     // error: no void X::g(short)
+    friend void W::X::g(D);     // OK
+    friend void W::X::g(F);     // OK
+  };
+}
+```
+— *end example*]
+### 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*, and unqualified lookup [[basic.lookup.unqual]] for the
+name in the *unqualified-id* does not find any
+- declaration of a class member, or
+- function declaration inhabiting a block scope, or
+- declaration not of a function or function template
+then lookup for the name also includes the result of
+*argument-dependent lookup* in a set of associated namespaces that
+depends on the types of the arguments (and for template template
+arguments, the namespace of the template argument), as specified below.
+[*Example 1*:
+``` cpp
+namespace N {
+  struct S { };
+  void f(S);
+}
+void g() {
+  N::S s;
+  f(s);             // OK, calls N::f
+  (f)(s);           // error: N::f not considered; parentheses prevent argument-dependent lookup
+}
+```
+— *end example*]
 [*Note 1*:
 For purposes of determining (during parsing) whether an expression is a
 *postfix-expression* for a function call, the usual name lookup rules
   template <class T> int f(T);
   template <class T> int g(T);
   template <class T> int h(T);
 }
+int x = f<N::A>(N::A());        // OK, lookup of f finds nothing, f treated as template name
+int y = g<N::A>(N::A());        // OK, lookup of g finds a function, g treated as template name
 int z = h<N::A>(N::A());        // error: h< does not begin a template-id
 ```
+The rules have no effect on the syntactic interpretation of an
+expression. For example,
 ``` cpp
 typedef int f;
 namespace N {
   struct A {
     }
   };
 }
 ```
+Because the expression is not a function call, argument-dependent name
+lookup does not apply and the friend function `f` is not found.
 — *end note*]
 For each argument type `T` in the function call, there is a set of zero
+or more *associated entities* to be considered. The set of entities is
+determined entirely by the types of the function arguments (and any
+template template arguments). Any *typedef-name*s and
+*using-declaration*s used to specify the types do not contribute to this
+set. The set of entities is determined in the following way:
+- If `T` is a fundamental type, its associated set of entities is empty.
 - If `T` is a class type (including unions), its associated entities
   are: the class itself; the class of which it is a member, if any; and
+  its direct and indirect base classes. Furthermore, if `T` is a class
+ template specialization, its associated entities also include: the
+ entities associated with the types of the template arguments provided
+ for template type parameters; the templates used as template template
+ arguments; and the classes of which any member templates used as
+  template template arguments are members. \[*Note 2*: Non-type template
+ arguments do not contribute to the set of associated
+ entities. — *end note*]
+- If `T` is an enumeration type, its associated entities are `T` and, if
+ it is a class member, the member’s class.
+- If `T` is a pointer to `U` or an array of `U`, its associated entities
+  are those associated with `U`.
+- If `T` is a function type, its associated entities are those
+ associated with the function parameter types and those associated with
+  the return type.
 - If `T` is a pointer to a member function of a class `X`, its
+  associated entities are those associated with the function parameter
+  types and return type, together with those associated with `X`.
 - If `T` is a pointer to a data member of class `X`, its associated
+  entities are those associated with the member type together with those
+  associated with `X`.
+In addition, if the argument is an overload set or the address of such a
+set, its associated entities are the union of those associated with each
+of the members of the set, i.e., the entities associated with its
+parameter types and return type. Additionally, if the aforementioned
+overload set is named with a *template-id*, its associated entities also
+include its template *template-argument*s and those associated with its
+type *template-argument*s.
+The *associated namespaces* for a call are the innermost enclosing
+non-inline namespaces for its associated entities as well as every
+element of the inline namespace set [[namespace.def]] of those
+namespaces. Argument-dependent lookup finds all declarations of
+functions and function templates that
+- are found by a search of any associated namespace, or
+- are declared as a friend [[class.friend]] of any class with a
+ reachable definition in the set of associated entities, or
+- are exported, are attached to a named module `M` [[module.interface]],
+  do not appear in the translation unit containing the point of the
+  lookup, and have the same innermost enclosing non-inline namespace
+  scope as a declaration of an associated entity attached to `M`
+  [[basic.link]].
+If the lookup is for a dependent name
+[[temp.dep]], [[temp.dep.candidate]], the above lookup is also performed
+from each point in the instantiation context [[module.context]] of the
+lookup, additionally ignoring any declaration that appears in another
+translation unit, is attached to the global module, and is either
+discarded [[module.global.frag]] or has internal linkage.
 [*Example 2*:
 Translation unit #1
 ``` cpp
 export module M;
 namespace R {
 }
 ```
 — *end example*]
+[*Note 3*: The associated namespace can include namespaces already
+considered by ordinary unqualified lookup. — *end note*]
+[*Example 3*:
+``` cpp
+namespace NS {
+  class T { };
+  void f(T);
+  void g(T, int);
+}
+NS::T parm;
+void g(NS::T, float);
+int main() {
+  f(parm);                      // OK, calls NS::f
+  extern void g(NS::T, float);
+  g(parm, 1);                   // OK, calls g(NS::T, float)
+}
+```
+— *end example*]
 ### Qualified name lookup <a id="basic.lookup.qual">[[basic.lookup.qual]]</a>
+#### General <a id="basic.lookup.qual.general">[[basic.lookup.qual.general]]</a>
+Lookup of an *identifier* followed by a `::` scope resolution operator
+considers only namespaces, types, and templates whose specializations
+are types. If a name, *template-id*, or *decltype-specifier* is followed
+by a `::`, it shall designate a namespace, class, enumeration, or
+dependent type, and the `::` is never interpreted as a complete
+*nested-name-specifier*.
 [*Example 1*:
 ``` cpp
 class A {
 int main() {
   int A;
   A::n = 42;            // OK
   A b;                  // error: A does not name a type
 }
+template<int> struct B : A {};
+namespace N {
+  template<int> void B();
+  int f() {
+    return B<0>::n;     // error: N::B<0> is not a type
+  }
+}
 ```
 — *end example*]
+A member-qualified name is the (unique) component name
+[[expr.prim.id.unqual]], if any, of
+- an *unqualified-id* or
+- a *nested-name-specifier* of the form *type-name* `::` or
+ *namespace-name* `::`
+in the *id-expression* of a class member access expression [[expr.ref]].
+A *qualified name* is
+- a member-qualified name or
+- the terminal name of
+  - a *qualified-id*,
+  - a *using-declarator*,
+  - a *typename-specifier*,
+  - a *qualified-namespace-specifier*, or
+  - a *nested-name-specifier*, *elaborated-type-specifier*, or
+    *class-or-decltype* that has a *nested-name-specifier*
+    [[expr.prim.id.qual]].
+The *lookup context* of a member-qualified name is the type of its
+associated object expression (considered dependent if the object
+expression is type-dependent). The lookup context of any other qualified
+name is the type, template, or namespace nominated by the preceding
+*nested-name-specifier*.
+[*Note 1*: When parsing a class member access, the name following the
+`->` or `.` is a qualified name even though it is not yet known of which
+kind. — *end note*]
 [*Example 2*:
+In
 ``` cpp
+  N::C::m.Base::f()
 ```
+`Base` is a member-qualified name; the other qualified names are `C`,
+`m`, and `f`.
 — *end example*]
+*Qualified name lookup* in a class, namespace, or enumeration performs a
+search of the scope associated with it [[class.member.lookup]] except as
+specified below. Unless otherwise specified, a qualified name undergoes
+qualified name lookup in its lookup context from the point where it
+appears unless the lookup context either is dependent and is not the
+current instantiation [[temp.dep.type]] or is not a class or class
+template. If nothing is found by qualified lookup for a member-qualified
+name that is the terminal name [[expr.prim.id.unqual]] of a
+*nested-name-specifier* and is not dependent, it undergoes unqualified
+lookup.
+[*Note 2*: During lookup for a template specialization, no names are
+dependent. — *end note*]
 [*Example 3*:
+``` cpp
+int f();
+struct A {
+  int B, C;
+  template<int> using D = void;
+  using T = void;
+  void f();
+};
+using B = A;
+template<int> using C = A;
+template<int> using D = A;
+template<int> using X = A;
+template<class T>
+void g(T *p) {                  // as instantiated for g<A>:
+  p->X<0>::f();                 // error: A::X not found in ((p->X) < 0) > ::f()
+  p->template X<0>::f();        // OK, ::X found in definition context
+  p->B::f();                    // OK, non-type A::B ignored
+  p->template C<0>::f();        // error: A::C is not a template
+  p->template D<0>::f();        // error: A::D<0> is not a class type
+  p->T::f();                    // error: A::T is not a class type
+}
+template void g(A*);
+```
+— *end example*]
+If a qualified name Q follows a `~`:
+- If Q is a member-qualified name, it undergoes unqualified lookup as
+  well as qualified lookup.
+- Otherwise, its *nested-name-specifier* N shall nominate a type. If N
+  has another *nested-name-specifier* S, Q is looked up as if its lookup
+  context were that nominated by S.
+- Otherwise, if the terminal name of N is a member-qualified name M, Q
+  is looked up as if `\~`Q appeared in place of M (as above).
+- Otherwise, Q undergoes unqualified lookup.
+- Each lookup for Q considers only types (if Q is not followed by a `<`)
+  and templates whose specializations are types. If it finds nothing or
+  is ambiguous, it is discarded.
+- The *type-name* that is or contains Q shall refer to its (original)
+  lookup context (ignoring cv-qualification) under the interpretation
+  established by at least one (successful) lookup performed.
+[*Example 4*:
 ``` cpp
 struct C {
   typedef int I;
 };
 typedef int I1, I2;
 extern int* p;
 extern int* q;
+void f() {
   p->C::I::~I();        // I is looked up in the scope of C
+ q->I1::~I2(); // I2 is found by unqualified lookup
+}
 struct A {
   ~A();
 };
 typedef A AB;
 int main() {
 }
 ```
 — *end example*]
 #### Class members <a id="class.qual">[[class.qual]]</a>
+In a lookup for a qualified name N whose lookup context is a class C in
+which function names are not ignored,[^4]
+- if the search finds the injected-class-name of `C` [[class.pre]], or
+- if N is dependent and is the terminal name of a *using-declarator*
+  [[namespace.udecl]] that names a constructor,
+N is instead considered to name the constructor of class `C`. Such a
+constructor name shall be used only in the *declarator-id* of a (friend)
+declaration of a constructor or in a *using-declaration*.
 [*Example 1*:
 ``` cpp
 struct A { A(); };
 struct A::A a2;     // object of type A
 ```
 — *end example*]
 #### Namespace members <a id="namespace.qual">[[namespace.qual]]</a>
+Qualified name lookup in a namespace N additionally searches every
+element of the inline namespace set of N [[namespace.def]]. If nothing
+is found, the results of the lookup are the results of qualified name
+lookup in each namespace nominated by a *using-directive* that precedes
+the point of the lookup and inhabits N or an element of N’s inline
+namespace set.
+[*Note 1*: If a *using-directive* refers to a namespace that has
+already been considered, it does not affect the result. — *end note*]
 [*Example 1*:
 ``` cpp
 int x;
 }
 ```
 — *end example*]
+[*Note 2*:
 The same declaration found more than once is not an ambiguity (because
 it is still a unique declaration).
 [*Example 2*:
   using namespace C;
 }
 void f()
 {
+  BC::a++;          // OK, S is { `A::a`, `A::a` }
 }
 namespace D {
   using A::a;
 }
   using namespace D;
 }
 void g()
 {
+  BD::a++;          // OK, S is { `A::a`, `A::a` }
 }
 ```
 — *end example*]
   using namespace A;
 }
 void f()
 {
+  A::a++;           // OK, a declared directly in A, S is { `A::a` }
+  B::a++;           // OK, both A and B searched (once), S is { `A::a` }
+  A::b++;           // OK, both A and B searched (once), S is { `B::b` }
+  B::b++;           // OK, b declared directly in B, S is { `B::b` }
 }
 ```
 — *end example*]
+[*Note 3*: Class and enumeration declarations are not discarded because
+of other declarations found in other searches. — *end note*]
 [*Example 4*:
 ``` cpp
 namespace A {
 }
 ```
 — *end example*]
 ### Elaborated type specifiers <a id="basic.lookup.elab">[[basic.lookup.elab]]</a>
+If the *class-key* or `enum` keyword in an *elaborated-type-specifier*
+is followed by an *identifier* that is not followed by `::`, lookup for
+the *identifier* is type-only [[basic.lookup.general]].
+[*Note 1*: In general, the recognition of an
+*elaborated-type-specifier* depends on the following tokens. If the
+*identifier* is followed by `::`, see
+[[basic.lookup.qual]]. — *end note*]
+If the terminal name of the *elaborated-type-specifier* is a qualified
+name, lookup for it is type-only. If the name lookup does not find a
+previously declared *type-name*, the *elaborated-type-specifier* is
+ill-formed.
 [*Example 1*:
 ``` cpp
 struct Node {
+  struct Node* Next;            // OK, refers to injected-class-name Node
+  struct Data* Data;            // OK, declares type Data at global scope and member Data
 };
 struct Data {
+  struct Node* Node;            // OK, refers to Node at global scope
   friend struct ::Glob;         // error: Glob is not declared, cannot introduce a qualified type[dcl.type.elab]
+  friend struct Glob;           // OK, refers to (as yet) undeclared Glob at global scope.
   ...
 };
 struct Base {
+  struct Data;                  // OK, declares nested Data
+  struct ::Data*     thatData;  // OK, refers to ::Data
+  struct Base::Data* thisData;  // OK, refers to nested Data
+  friend class ::Data;          // OK, global Data is a friend
+  friend class Data;            // OK, nested Data is a friend
   struct Data { ... };    // Defines nested Data
 };
+struct Data;                    // OK, redeclares Data at global scope
 struct ::Data;                  // error: cannot introduce a qualified type[dcl.type.elab]
 struct Base::Data;              // error: cannot introduce a qualified type[dcl.type.elab]
 struct Base::Datum;             // error: Datum undefined
+struct Base::Data* pBase;       // OK, refers to nested Data
 ```
 — *end example*]
 ### Using-directives and namespace aliases <a id="basic.lookup.udir">[[basic.lookup.udir]]</a>
 translation-unit:
     declaration-seqₒₚₜ
     global-module-fragmentₒₚₜ module-declaration declaration-seqₒₚₜ private-module-fragmentₒₚₜ
 ```
+A name is said to have *linkage* when it can denote the same object,
 reference, function, type, template, namespace or value as a name
 introduced by a declaration in another scope:
 - When a name has *external linkage*, the entity it denotes can be
   referred to by names from scopes of other translation units or from
 - When a name has *internal linkage*, the entity it denotes can be
   referred to by names from other scopes in the same translation unit.
 - When a name has *no linkage*, the entity it denotes cannot be referred
   to by names from other scopes.
+The name of an entity that belongs to a namespace scope
+[[basic.scope.namespace]] has internal linkage if it is the name of
 - a variable, variable template, function, or function template that is
   explicitly declared `static`; or
 - a non-template variable of non-volatile const-qualified type, unless
+  - it is declared in the purview of a module interface unit (outside
+    the *private-module-fragment*, if any) or module partition, or
   - it is explicitly declared `extern`, or
+  - it is inline, or
   - it was previously declared and the prior declaration did not have
     internal linkage; or
 - a data member of an anonymous union.
 [*Note 1*: An instantiated variable template that has const-qualified
 type can have external or module linkage, even if not declared
 `extern`. — *end note*]
 An unnamed namespace or a namespace declared directly or indirectly
 within an unnamed namespace has internal linkage. All other namespaces
+have external linkage. The name of an entity that belongs to a namespace
+scope that has not been given internal linkage above and that is the
+name of
 - a variable; or
 - a function; or
 - a named class [[class.pre]], or an unnamed class defined in a typedef
   declaration in which the class has the typedef name for linkage
 - otherwise, if the declaration of the name is attached to a named
   module [[module.unit]] and is not exported [[module.interface]], the
   name has module linkage;
 - otherwise, the name has external linkage.
+In addition, a member function, a static data member, a named class or
+enumeration that inhabits a class scope, or an unnamed class or
+enumeration defined in a typedef declaration that inhabits a class scope
+such that the class or enumeration has the typedef name for linkage
+purposes [[dcl.typedef]], has the same linkage, if any, as the name of
+the class of which it is a member.
 [*Example 1*:
 ``` cpp
 static void f();
 extern "C" void h();
 static int i = 0;               // #1
+void q() {
   extern void f();              // internal linkage
+  extern void g();              // ::g, external linkage
   extern void h();              // C language linkage
   int i;                        // #2: i has no linkage
   {
     extern void f();            // internal linkage
+    extern int i;               // #3: internal linkage
   }
 }
 ```
+Even though the declaration at line \#2 hides the declaration at line
+\#1, the declaration at line \#3 still redeclares \#1 and receives
+internal linkage.
 — *end example*]
 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.
+Two declarations of entities declare the same entity if, considering
+declarations of unnamed types to introduce their names for linkage
+purposes, if any [[dcl.typedef]], [[dcl.enum]], they correspond
+[[basic.scope.scope]], have the same target scope that is not a function
+or template parameter scope, and either
+- they appear in the same translation unit, or
+- they both declare names with module linkage and are attached to the
+  same module, or
+- they both declare names with external linkage.
+[*Note 2*: There are other circumstances in which declarations declare
+the same entity
+[[dcl.link]], [[temp.type]], [[temp.spec.partial]]. — *end note*]
+If a declaration H that declares a name with internal linkage precedes a
+declaration D in another translation unit U and would declare the same
+entity as D if it appeared in U, the program is ill-formed.
+[*Note 3*: Such an H can appear only in a header unit. — *end note*]
+If two declarations of an entity are attached to different modules, the
+program is ill-formed; no diagnostic is required if neither is reachable
+from the other.
+[*Example 2*:
 \`"decls.h"\`
 ``` cpp
 int f();            // #1, attached to the global module
 ``` cpp
 module;
 #include "decls.h"
 export module M;
+export using ::f;   // OK, does not declare an entity, exports #1
 int g();            // error: matches #2, but attached to M
 export int h();     // #3
 export int k();     // #4
 ```
 As a consequence of these rules, all declarations of an entity are
 attached to the same module; the entity is said to be *attached* to that
 module.
+For any two declarations of an entity E:
+- If one declares E to be a variable or function, the other shall
+  declare E as one of the same type.
+- If one declares E to be an enumerator, the other shall do so.
+- If one declares E to be a namespace, the other shall do so.
+- If one declares E to be a type, the other shall declare E to be a type
+  of the same kind [[dcl.type.elab]].
+- If one declares E to be a class template, the other shall do so with
+  the same kind and an equivalent *template-head* [[temp.over.link]].
+  \[*Note 4*: The declarations can supply different default template
+  arguments. — *end note*]
+- If one declares E to be a function template or a (partial
+  specialization of a) variable template, the other shall declare E to
+  be one with an equivalent *template-head* and type.
+- If one declares E to be an alias template, the other shall declare E
+  to be one with an equivalent *template-head* and *defining-type-id*.
+- If one declares E to be a concept, the other shall do so.
+Types are compared after all adjustments of types (during which typedefs
+[[dcl.typedef]] are replaced by their definitions); declarations for an
+array object can specify array types that differ by the presence or
+absence of a major array bound [[dcl.array]]. No diagnostic is required
+if neither declaration is reachable from the other.
+[*Example 3*:
+``` cpp
+int f(int x, int x);    // error: different entities for x
+void g();               // #1
+void g(int);            // OK, different entity from #1
+int g();                // error: same entity as #1 with different type
+void h();               // #2
+namespace h {}          // error: same entity as #2, but not a function
+```
+— *end example*]
+[*Note 5*: Linkage to non-C++ declarations can be achieved using a
 *linkage-specification* [[dcl.link]]. — *end note*]
 A declaration D *names* an entity E if
 - D contains a *lambda-expression* whose closure type is E,
 - E is not a function or function template and D contains an
   *id-expression*, *type-specifier*, *nested-name-specifier*,
   *template-name*, or *concept-name* denoting E, or
 - E is a function or function template and D contains an expression that
   names E [[basic.def.odr]] or an *id-expression* that refers to a set
+  of overloads that contains E. \[*Note 6*: Non-dependent names in an
   instantiated declaration do not refer to a set of overloads
+  [[temp.res]]. — *end note*]
 A declaration is an *exposure* if it either names a TU-local entity
 (defined below), ignoring
 - the *function-body* for a non-inline function or function template
 - the *initializer* for a variable or variable template (but not the
   variable’s type),
 - friend declarations in a class definition, and
 - any reference to a non-volatile const object or reference with
   internal or no linkage initialized with a constant expression that is
+  not an odr-use [[term.odr.use]],
 or defines a constexpr variable initialized to a TU-local value (defined
 below).
+[*Note 7*: An inline function template can be an exposure even though
+certain explicit specializations of it would be usable in other
+translation units. — *end note*]
 An entity is *TU-local* if it is
 - a type, function, variable, or template that
   - has a name with internal linkage, or
   *defining-type-specifier* that is used to declare only TU-local
   entities,
 - a specialization of a TU-local template,
 - a specialization of a template with any TU-local template argument, or
 - a specialization of a template whose (possibly instantiated)
+  declaration is an exposure. \[*Note 8*: A specialization can be
+ produced by implicit or explicit instantiation. — *end note*]
 A value or object is *TU-local* if either
 - it is, or is a pointer to, a TU-local function or the object
+  associated with a TU-local variable, or
 - it is an object of class or array type and any of its subobjects or
   any of the objects or functions to which its non-static data members
   of reference type refer is TU-local and is usable in constant
   expressions.
   void adl(A);
   static void adl(int);
 }
 void adl(double);
+inline void h(auto x) { adl(x); }   // OK, but certain specializations are exposures
 ```
 Translation unit #2
 ``` cpp
 ## Memory and objects <a id="basic.memobj">[[basic.memobj]]</a>
 ### Memory model <a id="intro.memory">[[intro.memory]]</a>
 The fundamental storage unit in the C++ memory model is the *byte*. A
+byte is at least large enough to contain the ordinary literal encoding
+of any element of the basic literal character set [[lex.charset]] and
+the eight-bit code units of the Unicode[^5]
+UTF-8 encoding form and is composed of a contiguous sequence of
+bits,[^6]
+the number of which is *implementation-defined*. The least significant
+bit is called the *low-order bit*; the most significant bit is called
+the *high-order bit*. The memory available to a C++ program consists of
+one or more sequences of contiguous bytes. Every byte has a unique
+address.
 [*Note 1*: The representation of types is described in
+[[basic.types.general]]. — *end note*]
+A *memory location* is either an object of scalar type that is not a
+bit-field or a maximal sequence of adjacent bit-fields all having
+nonzero width.
 [*Note 2*: Various features of the language, such as references and
 virtual functions, might involve additional memory locations that are
 not accessible to programs but are managed by the
 implementation. — *end note*]
   int b:5,
   c:11,
   :0,
   d:8;
   struct {int ee:8;} e;
+};
 ```
 contains four separate memory locations: The member `a` and bit-fields
 `d` and `e.ee` are each separate memory locations, and can be modified
 concurrently without interfering with each other. The bit-fields `b` and
 The constructs in a C++ program create, destroy, refer to, access, and
 manipulate objects. An *object* is created by a definition
 [[basic.def]], by a *new-expression* [[expr.new]], by an operation that
 implicitly creates objects (see below), when implicitly changing the
 active member of a union [[class.union]], or when a temporary object is
+created [[conv.rval]], [[class.temporary]]. An object occupies a region
+of storage in its period of construction [[class.cdtor]], throughout its
+lifetime [[basic.life]], and in its period of destruction
 [[class.cdtor]].
 [*Note 1*: A function is not an object, regardless of whether or not it
 occupies storage in the way that objects do. — *end note*]
 The properties of an object are determined when the object is created.
 An object can have a name [[basic.pre]]. An object has a storage
 duration [[basic.stc]] which influences its lifetime [[basic.life]]. An
+object has a type [[basic.types]].
+[*Note 2*: Some objects are polymorphic [[class.virtual]]; the
+implementation generates information associated with each such object
+that makes it possible to determine that object’s type during program
+execution. — *end note*]
 Objects can contain other objects, called *subobjects*. A subobject can
 be a *member subobject* [[class.mem]], a *base class subobject*
 [[class.derived]], or an array element. An object that is not a
 subobject of any other object is called a *complete object*. If an
 “array of N `std::byte`” [[cstddef.syn]], that array *provides storage*
 for the created object if:
 - the lifetime of *e* has begun and not ended, and
 - the storage for the new object fits entirely within *e*, and
+- there is no array object that satisfies these constraints nested
+  within *e*.
+[*Note 3*: If that portion of the array previously provided storage for
 another object, the lifetime of that object ends because its storage was
 reused [[basic.life]]. — *end note*]
 [*Example 1*:
 - If `x` is a complete object, then the complete object of `x` is
   itself.
 - Otherwise, the complete object of `x` is the complete object of the
   (unique) object that contains `x`.
+If a complete object, a member subobject, or an array element is of
+class type, its type is considered the *most derived class*, to
 distinguish it from the class type of any base class subobject; an
 object of a most derived class type or of a non-class type is called a
 *most derived object*.
 A *potentially-overlapping subobject* is either:
 - is not a potentially-overlapping subobject, or
 - is not of class type, or
 - is of a class type with virtual member functions or virtual base
   classes, or
+- has subobjects of nonzero size or unnamed bit-fields of nonzero
+  length.
 Otherwise, if the object is a base class subobject of a standard-layout
 class type with no non-static data members, it has zero size. Otherwise,
 the circumstances under which the object has zero size are
 *implementation-defined*. Unless it is a bit-field [[class.bit]], an
 object with nonzero size shall occupy one or more bytes of storage,
 including every byte that is occupied in full or in part by any of its
 subobjects. An object of trivially copyable or standard-layout type
+[[basic.types.general]] shall occupy contiguous bytes of storage.
 Unless an object is a bit-field or a subobject of zero size, the address
 of that object is the address of the first byte it occupies. Two objects
 with overlapping lifetimes that are not bit-fields may have the same
 address if one is nested within the other, or if at least one is a
 subobject of zero size and they are of different types; otherwise, they
+have distinct addresses and occupy disjoint bytes of storage.[^7]
 [*Example 2*:
 ``` cpp
 static const char test1 = 'x';
 Some operations are described as *implicitly creating objects* within a
 specified region of storage. For each operation that is specified as
 implicitly creating objects, that operation implicitly creates and
 starts the lifetime of zero or more objects of implicit-lifetime types
+[[basic.types.general]] in its specified region of storage if doing so
+would result in the program having defined behavior. If no such set of
+objects would give the program defined behavior, the behavior of the
+program is undefined. If multiple such sets of objects would give the
+program defined behavior, it is unspecified which such set of objects is
 created.
+[*Note 4*: Such operations do not start the lifetimes of subobjects of
 such objects that are not themselves of implicit-lifetime
 types. — *end note*]
 Further, after implicitly creating objects within a specified region of
 storage, some operations are described as producing a pointer to a
 }
 ```
 — *end example*]
+An operation that begins the lifetime of an array of `unsigned char` or
+`std::byte` implicitly creates objects within the region of storage
+occupied by the array.
+[*Note 5*: The array object provides storage for these
 objects. — *end note*]
 Any implicit or explicit invocation of a function named `operator new`
 or `operator new[]` implicitly creates objects in the returned region of
 storage and returns a pointer to a suitable created object.
+[*Note 6*: Some functions in the C++ standard library implicitly create
+objects
+[[obj.lifetime]], [[allocator.traits.members]], [[c.malloc]], [[cstring.syn]], [[bit.cast]]. — *end note*]
 ### Lifetime <a id="basic.life">[[basic.life]]</a>
 The *lifetime* of an object or reference is a runtime property of the
 object or reference. A variable is said to have *vacuous initialization*
 if it is default-initialized and, if it is of class type or a (possibly
+multidimensional) array thereof, that class type has a trivial default
 constructor. The lifetime of an object of type `T` begins when:
 - storage with the proper alignment and size for type `T` is obtained,
   and
 - its initialization (if any) is complete (including vacuous
   initialization) [[dcl.init]],
 except that if the object is a union member or subobject thereof, its
 lifetime only begins if that union member is the initialized member in
+the union [[dcl.init.aggr]], [[class.base.init]], or as described in
+[[class.union]], [[class.copy.ctor]], and [[class.copy.assign]], and
+except as described in [[allocator.members]]. The lifetime of an object
+*o* of type `T` ends when:
 - if `T` is a non-class type, the object is destroyed, or
 - if `T` is a class type, the destructor call starts, or
 - the storage which the object occupies is released, or is reused by an
   object that is not nested within *o* [[intro.object]].
 The properties ascribed to objects and references throughout this
 document apply for a given object or reference only during its lifetime.
 [*Note 2*: In particular, before the lifetime of an object starts and
 after its lifetime ends there are significant restrictions on the use of
+the object, as described below, in  [[class.base.init]], and in
 [[class.cdtor]]. Also, the behavior of an object under construction and
+destruction can differ from the behavior of an object whose lifetime has
+started and not ended. [[class.base.init]] and  [[class.cdtor]] describe
+the behavior of an object during its periods of construction and
+destruction. — *end note*]
+A program may end the lifetime of an object of class type without
+invoking the destructor, by reusing or releasing the storage as
+described above.
+[*Note 3*: A *delete-expression* [[expr.delete]] invokes the destructor
+prior to releasing the storage. — *end note*]
+In this case, the destructor is not implicitly invoked.
+[*Note 4*: The correct behavior of a program often depends on the
+destructor being invoked for each object of class type. — *end note*]
 Before the lifetime of an object has started but after the storage which
+the object will occupy has been allocated[^8]
+or, after the lifetime of an object has ended and before the storage
+which the object occupied is reused or released, any pointer that
+represents the address of 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.allocation]],
+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 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`
 void g() {
   void* p = std::malloc(sizeof(D1) + sizeof(D2));
   B* pb = new (p) D1;
   pb->mutate();
+  *pb;              // OK, pb points to valid memory
+  void* q = pb;     // OK, pb points to valid memory
   pb->f();          // undefined behavior: lifetime of *pb has ended
 }
 ```
 — *end example*]
 - the storage that o₂ occupies exactly overlays the storage that o₁
   occupied, and
 - o₁ and o₂ are of the same type (ignoring the top-level cv-qualifiers),
   and
+- o₁ is not a const, complete object, and
 - neither o₁ nor o₂ is a potentially-overlapping subobject
   [[intro.object]], and
 - either o₁ and o₂ are both complete objects, or o₁ and o₂ are direct
   subobjects of objects p₁ and p₂, respectively, and p₁ is transparently
   replaceable by p₂.
 c1.f();                         // well-defined; c1 refers to a new object of type C
 ```
 — *end example*]
+[*Note 5*: If these conditions are not met, a pointer to the new object
 can be obtained from a pointer that represents the address of its
 storage by calling `std::launder` [[ptr.launder]]. — *end note*]
 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,[^9]
+and another object of the original type does not occupy that same
+storage location when the implicit destructor call takes place, the
+behavior of the program is undefined. This is true even if the block is
+exited with an exception.
 [*Example 3*:
 ``` cpp
 class T { };
 }                               // undefined behavior at block exit
 ```
 — *end example*]
+Creating a new object within the storage that a const, complete object
 with static, thread, or automatic storage duration occupies, or within
 the storage that such a const object used to occupy before its lifetime
 ended, results in undefined behavior.
 [*Example 4*:
 — *end example*]
 In this subclause, “before” and “after” refer to the “happens before”
 relation [[intro.multithread]].
+[*Note 6*: Therefore, undefined behavior results if an object that is
 being constructed in one thread is referenced from another thread
 without adequate synchronization. — *end note*]
 ### Indeterminate values <a id="basic.indet">[[basic.indet]]</a>
   [[basic.fundamental]] or `std::byte` type [[cstddef.syn]] is produced
   by the evaluation of:
   - the second or third operand of a conditional expression
     [[expr.cond]],
   - the right operand of a comma expression [[expr.comma]],
+  - the operand of a cast or conversion
+    [[conv.integral]], [[expr.type.conv]], [[expr.static.cast]], [[expr.cast]]
+ to an unsigned ordinary character type or `std::byte` type
     [[cstddef.syn]], or
   - a discarded-value expression [[expr.context]],
   then the result of the operation is an indeterminate value.
 - If an indeterminate value of unsigned ordinary character type or
 — *end example*]
 ### Storage duration <a id="basic.stc">[[basic.stc]]</a>
+#### General <a id="basic.stc.general">[[basic.stc.general]]</a>
 The *storage duration* is the property of an object that defines the
 minimum potential lifetime of the storage containing the object. The
 storage duration is determined by the construct used to create the
 object and is one of the following:
 values of all pointers representing the address of any part of that
 region of storage become invalid pointer values [[basic.compound]].
 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.[^10]
 #### Static storage duration <a id="basic.stc.static">[[basic.stc.static]]</a>
+All variables which
+- do not have thread storage duration and
+- belong to a namespace scope [[basic.scope.namespace]] or are first
+  declared with the `static` or `extern` keywords [[dcl.stc]]
+have *static storage duration*. The storage for these entities lasts for
+the duration of the program
+[[basic.start.static]], [[basic.start.term]].
 If a variable with static storage duration has initialization or a
 destructor with side effects, it shall not be eliminated even if it
 appears to be unused, except that a class object or its copy/move may be
 eliminated as specified in  [[class.copy.elision]].
+[*Note 1*:  The keyword `static` can be used to declare a block
+variable [[basic.scope.block]] with static storage duration;
+[[stmt.dcl]] and [[basic.start.term]] describe the initialization and
+destruction of such variables. The keyword `static` applied to a class
+data member in a class definition gives the data member static storage
+duration [[class.static.data]]. — *end note*]
 #### Thread storage duration <a id="basic.stc.thread">[[basic.stc.thread]]</a>
 All variables declared with the `thread_local` keyword have
 *thread storage duration*. The storage for these entities lasts for the
 [[stmt.dcl]] and, if constructed, is destroyed on thread exit
 [[basic.start.term]]. — *end note*]
 #### Automatic storage duration <a id="basic.stc.auto">[[basic.stc.auto]]</a>
+Variables that belong to a block or parameter scope and are not
+explicitly declared `static`, `thread_local`, or `extern` have
+*automatic storage duration*. The storage for these entities lasts until
+the block in which they are created exits.
 [*Note 1*: These variables are initialized and destroyed as described
 in  [[stmt.dcl]]. — *end note*]
 If a variable with automatic storage duration has initialization or a
 it appears to be unused, except that a class object or its copy/move may
 be eliminated as specified in  [[class.copy.elision]].
 #### Dynamic storage duration <a id="basic.stc.dynamic">[[basic.stc.dynamic]]</a>
+##### General <a id="basic.stc.dynamic.general">[[basic.stc.dynamic.general]]</a>
 Objects can be created dynamically during program execution
 [[intro.execution]], using *new-expression*s [[expr.new]], and destroyed
 using *delete-expression*s [[expr.delete]]. A C++ implementation
 provides access to, and management of, dynamic storage via the global
+*allocation functions* `operator new` and `operator new[]` and the
+global *deallocation functions* `operator delete` and
+`operator delete[]`.
 [*Note 1*: The non-allocating forms described in
 [[new.delete.placement]] do not perform allocation or
 deallocation. — *end note*]
 The library provides default definitions for the global allocation and
 deallocation functions. Some global allocation and deallocation
+functions are replaceable [[new.delete]]; these are attached to the
+global module [[module.unit]]. A C++ program shall provide at most one
+definition of a replaceable allocation or deallocation function. Any
+such function definition replaces the default version provided in the
+library [[replacement.functions]]. The following allocation and
+deallocation functions [[support.dynamic]] are implicitly declared in
+global scope in each translation unit of a program.
 ``` cpp
 [[nodiscard]] void* operator new(std::size_t);
 [[nodiscard]] void* operator new(std::size_t, std::align_val_t);
 void operator delete[](void*, std::size_t) noexcept;
 void operator delete[](void*, std::align_val_t) noexcept;
 void operator delete[](void*, std::size_t, std::align_val_t) noexcept;
 ```
+These implicit declarations introduce only the function names
+`operator new`, `operator new[]`, `operator delete`, and
+`operator delete[]`.
 [*Note 2*: The implicit declarations do not introduce the names `std`,
 `std::size_t`, `std::align_val_t`, or any other names that the library
 uses to declare these names. Thus, a *new-expression*,
 *delete-expression*, or function call that refers to one of these
+functions without importing or including the header `<new>` or importing
+a C++ library module [[std.modules]] is well-formed. However, referring
+to `std` or `std::size_t` or `std::align_val_t` is ill-formed unless a
+standard library declaration
+[[cstddef.syn]], [[new.syn]], [[std.modules]] of that name precedes
+[[basic.lookup.general]] the use of that name. — *end note*]
 Allocation and/or deallocation functions may also be declared and
 defined for any class [[class.free]].
 If the behavior of an allocation or deallocation function does not
 [[basic.stc.dynamic.allocation]] and
 [[basic.stc.dynamic.deallocation]], the behavior is undefined.
 ##### Allocation functions <a id="basic.stc.dynamic.allocation">[[basic.stc.dynamic.allocation]]</a>
+An allocation function that is not a class member function shall belong
+to the global scope and not have a name with internal linkage. The
+return type shall be `void*`. The first parameter shall have type
+`std::size_t` [[support.types]]. The first parameter shall not have an
+associated default argument [[dcl.fct.default]]. The value of the first
+parameter is interpreted as the requested size of the allocation. An
+allocation function can be a function template. Such a template shall
+declare its return type and first parameter as specified above (that is,
+template parameter types shall not be used in the return type and first
+parameter type). Allocation function templates shall have two or more
+parameters.
 An allocation function attempts to allocate the requested amount of
 storage. If it is successful, it returns the address of the start of a
 block of storage whose length in bytes is at least as large as the
 requested size. The order, contiguity, and initial value of storage
 subsequently passed to a replaceable deallocation function. Furthermore,
 for the library allocation functions in  [[new.delete.single]] and
 [[new.delete.array]], `p0` represents the address of a block of storage
 disjoint from the storage for any other object accessible to the caller.
 The effect of indirecting through a pointer returned from a request for
+zero size is undefined.[^11]
 For an allocation function other than a reserved placement allocation
 function [[new.delete.placement]], the pointer returned on a successful
 call shall represent the address of storage that is aligned as follows:
 [[expr.typeid]], or for an exception object
 [[except.throw]]. — *end note*]
 ##### Deallocation functions <a id="basic.stc.dynamic.deallocation">[[basic.stc.dynamic.deallocation]]</a>
+A deallocation function that is not a class member function shall belong
+to the global scope and not have a name with internal linkage.
 A deallocation function is a *destroying operator delete* if it has at
 least two parameters and its second parameter is of type
 `std::destroying_delete_t`. A destroying operator delete shall be a
 class member function named `operator delete`.
 parameter shall be `void*`. A deallocation function may have more than
 one parameter. A *usual deallocation function* is a deallocation
 function whose parameters after the first are
 - optionally, a parameter of type `std::destroying_delete_t`, then
+- optionally, a parameter of type `std::size_t`,[^12] then
 - optionally, a parameter of type `std::align_val_t`.
 A destroying operator delete shall be a usual deallocation function. A
 deallocation function may be an instance of a function template. Neither
 the first parameter nor the return type shall depend on a template
 If the argument given to a deallocation function in the standard library
 is a pointer that is not the null pointer value [[basic.compound]], the
 deallocation function shall deallocate the storage referenced by the
 pointer, ending the duration of the region of storage.
 #### Duration of subobjects <a id="basic.stc.inherit">[[basic.stc.inherit]]</a>
 The storage duration of subobjects and reference members is that of
 their complete object [[intro.object]].
 ### Alignment <a id="basic.align">[[basic.align]]</a>
+Object types have *alignment requirements*
+[[basic.fundamental]], [[basic.compound]] which place restrictions on
+the addresses at which an object of that type may be allocated. An
+*alignment* is an *implementation-defined* integer value representing
+the number of bytes between successive addresses at which a given object
+can be allocated. An object type imposes an alignment requirement on
+every object of that type; stricter alignment can be requested using the
+alignment specifier [[dcl.align]].
 A *fundamental alignment* is represented by an alignment less than or
 equal to the greatest alignment supported by the implementation in all
 contexts, which is equal to `alignof(std::max_align_t)`
+[[support.types]]. The alignment required for a type may be different
 when it is used as the type of a complete object and when it is used as
 the type of a subobject.
 [*Example 1*:
 - Two alignments are different when their numeric values are not equal.
 - When an alignment is larger than another it represents a stricter
   alignment.
 [*Note 3*: The runtime pointer alignment function [[ptr.align]] can be
+used to obtain an aligned pointer within a buffer; an
+*alignment-specifier* [[dcl.align]] can be used to align storage
+explicitly. — *end note*]
 If a request for a specific extended alignment in a specific context is
 not supported by an implementation, the program is ill-formed.
 ### Temporary objects <a id="class.temporary">[[class.temporary]]</a>
 Temporary objects are created
 - when a prvalue is converted to an xvalue [[conv.rval]],
 - when needed by the implementation to pass or return an object of
+  trivially copyable type (see below), and
 - when throwing an exception [[except.throw]]. \[*Note 1*: The lifetime
   of exception objects is described in  [[except.throw]]. — *end note*]
 Even when the creation of the temporary object is unevaluated
+[[expr.context]], all the semantic restrictions shall be respected as if
 the temporary object had been created and later destroyed.
 [*Note 2*: This includes accessibility [[class.access]] and whether it
 is deleted, for the constructor selected and for the destructor.
 However, in the special case of the operand of a *decltype-specifier*
+[[dcl.type.decltype]], no temporary is introduced, so the foregoing does
+not apply to such a prvalue. — *end note*]
 The materialization of a temporary object is generally delayed as long
 as possible in order to avoid creating unnecessary temporary objects.
 [*Note 3*:
 Temporary objects are materialized:
+- when binding a reference to a prvalue
+  [[dcl.init.ref]], [[expr.type.conv]], [[expr.dynamic.cast]], [[expr.static.cast]], [[expr.const.cast]], [[expr.cast]],
+- when performing member access on a class prvalue
+ [[expr.ref]], [[expr.mptr.oper]],
 - when performing an array-to-pointer conversion or subscripting on an
+  array prvalue [[conv.array]], [[expr.sub]],
 - when initializing an object of type `std::initializer_list<T>` from a
   *braced-init-list* [[dcl.init.list]],
+- for certain unevaluated operands [[expr.typeid]], [[expr.sizeof]], and
 - when a prvalue that has type other than cv `void` appears as a
+  discarded-value expression [[expr.context]].
 — *end note*]
 [*Example 1*:
 [*Note 4*: This latitude is granted to allow objects of class type to
 be passed to or returned from functions in registers. — *end note*]
 When an implementation introduces a temporary object of a class that has
+a non-trivial constructor [[class.default.ctor]], [[class.copy.ctor]],
+it shall ensure that a constructor is called for the temporary object.
+Similarly, the destructor shall be called for a temporary with a
+non-trivial destructor [[class.dtor]]. Temporary objects are destroyed
+as the last step in evaluating the full-expression [[intro.execution]]
+that (lexically) contains the point where they were created. This is
+true even if that evaluation ends in throwing an exception. The value
+computations and side effects of destroying a temporary object are
+associated only with the full-expression, not with any specific
+subexpression.
+There are four contexts in which temporaries are destroyed at a
 different point than the end of the full-expression. The first context
 is when a default constructor is called to initialize an element of an
 array with no corresponding initializer [[dcl.init]]. The second context
 is when a copy constructor is called to copy an element of an array
+while the entire array is copied
+[[expr.prim.lambda.capture]], [[class.copy.ctor]]. In either case, if
+the constructor has one or more default arguments, the destruction of
+every temporary created in a default argument is sequenced before the
+construction of the next array element, if any.
+The third context is when a reference binds to a temporary object.[^13]
+The temporary object to which the reference is bound or the temporary
+object that is the complete object of a subobject to which the reference
+is bound persists for the lifetime of the reference if the glvalue to
+which the reference is bound was obtained through one of the following:
 - a temporary materialization conversion [[conv.rval]],
 - `(` *expression* `)`, where *expression* is one of these expressions,
 - subscripting [[expr.sub]] of an array operand, where that operand is
   one of these expressions,
 — *end example*]
 [*Note 5*:
+An explicit type conversion [[expr.type.conv]], [[expr.cast]] is
 interpreted as a sequence of elementary casts, covered above.
 [*Example 3*:
 ``` cpp
   `return` statement [[stmt.return]] is not extended; the temporary is
   destroyed at the end of the full-expression in the `return` statement.
 - A temporary bound to a reference in a *new-initializer* [[expr.new]]
   persists until the completion of the full-expression containing the
   *new-initializer*.
+  \[*Note 7*: This might introduce a dangling reference. — *end note*]
   \[*Example 5*:
   ``` cpp
   struct S { int mi; const std::pair<int,int>& mp; };
   S a { 1, {2,3} };
   S* p = new S{ 1, {2,3} };       // creates dangling reference
   ```
   — *end example*]
+The fourth context is when a temporary object other than a function
+parameter object is created in the *for-range-initializer* of a
+range-based `for` statement. If such a temporary object would otherwise
+be destroyed at the end of the *for-range-initializer* full-expression,
+the object persists for the lifetime of the reference initialized by the
+*for-range-initializer*.
+The destruction of a temporary whose lifetime is not extended beyond the
+full-expression in which it was created is sequenced before the
+destruction of every temporary which is constructed earlier in the same
+full-expression. If the lifetime of two or more temporaries with
+lifetimes extending beyond the full-expressions in which they were
+created ends at the same point, these temporaries are destroyed at that
+point in the reverse order of the completion of their construction. In
+addition, the destruction of such temporaries shall take into account
+the ordering of destruction of objects with static, thread, or automatic
+storage duration
+[[basic.stc.static]], [[basic.stc.thread]], [[basic.stc.auto]]; that is,
+if `obj1` is an object with the same storage duration as the temporary
+and created before the temporary is created the temporary shall be
+destroyed before `obj1` is destroyed; if `obj2` is an object with the
+same storage duration as the temporary and created after the temporary
+is created the temporary shall be destroyed after `obj2` is destroyed.
 [*Example 6*:
 ``` cpp
 struct S {
 — *end example*]
 ## Types <a id="basic.types">[[basic.types]]</a>
+### General <a id="basic.types.general">[[basic.types.general]]</a>
 [*Note 1*:  [[basic.types]] and the subclauses thereof impose
 requirements on implementations regarding the representation of types.
 There are two kinds of types: fundamental types and compound types.
 Types describe objects [[intro.object]], references [[dcl.ref]], or
 functions [[dcl.fct]]. — *end note*]
 For any object (other than a potentially-overlapping 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`, `unsigned char`, or
+`std::byte` [[cstddef.syn]].[^14]
+If the content of that array is copied back into the object, the object
+shall subsequently hold its original value.
 [*Example 1*:
 ``` cpp
 constexpr std::size_t N = sizeof(T);
 std::memcpy(&obj, buf, N);      // at this point, each subobject of obj of scalar type holds its original value
 ```
 — *end example*]
+For two distinct objects `obj1` and `obj2` of trivially copyable type
+`T`, where neither `obj1` nor `obj2` is a potentially-overlapping
+subobject, if the underlying bytes [[intro.memory]] making up `obj1` are
+copied into `obj2`,[^15]
+`obj2` shall subsequently hold the same value as `obj1`.
 [*Example 2*:
 ``` cpp
 T* t1p;
 `T` is the set of bits that participate in representing a value of type
 `T`. Bits in the object representation that are not part of the value
 representation are *padding bits*. 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.[^16]
 A class that has been declared but not defined, an enumeration type in
 certain contexts [[dcl.enum]], or an array of unknown bound or of
+incomplete element type, is an *incompletely-defined object type*.[^17]
 Incompletely-defined object types and cv `void` are *incomplete types*
+[[basic.fundamental]].
+[*Note 2*: Objects cannot be defined to have an incomplete type
+[[basic.def]]. — *end note*]
+A class type (such as “`class X`”) can 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 can 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 can be an array of unknown bound
 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.
+[*Note 3*: The type of a pointer or reference to array of unknown bound
+permanently points to or refers to an incomplete type. An array of
+unknown bound named by a `typedef` declaration permanently refers to an
+incomplete type. In either case, the array type cannot be
+completed. — *end note*]
 [*Example 3*:
 ``` cpp
 class X;                        // X is an incomplete type
 UNKA** arrpp;
 void foo() {
   xp++;                         // error: X is incomplete
   arrp++;                       // error: incomplete type
+  arrpp++;                      // OK, sizeof UNKA* is known
 }
 struct X { int i; };            // now X is a complete type
 int  arr[10];                   // now the type of arr is complete
 X x;
 void bar() {
   xp = &x;                      // OK; type is ``pointer to X''
+  arrp = &arr;                  // OK; qualification conversion[conv.qual]
+  xp++;                         // OK, X is complete
   arrp++;                       // error: UNKA can't be completed
 }
 ```
 — *end example*]
+[*Note 4*: The rules for declarations and expressions describe in which
 contexts incomplete types are prohibited. — *end note*]
 An *object type* is a (possibly cv-qualified) type that is not a
 function type, not a reference type, and not cv `void`.
 - a reference type; or
 - an array of literal type; or
 - a possibly cv-qualified class type [[class]] that has all of the
   following properties:
   - it has a constexpr destructor [[dcl.constexpr]],
+  - all of its non-static non-variant data members and base classes are
+ of non-volatile literal types, and
+  - it
+ - is a closure type [[expr.prim.lambda.closure]],
+ - is an aggregate union type that has either no variant members or
+ at least one variant member of non-volatile literal type,
+ - is a non-union aggregate type for which each of its anonymous
+ union members satisfies the above requirements for an aggregate
+      union type, or
+    - has at least one constexpr constructor or constructor template
+      (possibly inherited [[namespace.udecl]] from a base class) that is
+      not a copy or move constructor.
+[*Note 5*: A literal type is one for which it might be possible to
 create an object within a constant expression. It is not a guarantee
 that it is possible to create such an object, nor is it a guarantee that
 any object of that type will be usable in a constant
 expression. — *end note*]
+Two types *cv1* `T1` and *cv2* `T2` are *layout-compatible types* if
 `T1` and `T2` are the same type, layout-compatible enumerations
 [[dcl.enum]], or layout-compatible standard-layout class types
 [[class.mem]].
 ### Fundamental types <a id="basic.fundamental">[[basic.fundamental]]</a>
 An unsigned integer type has the same object representation, value
 representation, and alignment requirements [[basic.align]] as the
 corresponding signed integer type. For each value x of a signed integer
 type, the value of the corresponding unsigned integer type congruent to
 x modulo 2ᴺ has the same value of corresponding bits in its value
+representation.[^18]
 [*Example 1*: The value -1 of a signed integer type has the same
 representation as the largest value of the corresponding unsigned
 type. — *end example*]
 **Table: Minimum width** <a id="basic.fundamental.width">[basic.fundamental.width]</a>
 | Type            | Minimum width $N$ |
+| --------------- | ----------------- |
 | `signed char`   | 8                 |
+| `short int` | 16                |
 | `int`           | 16                |
+| `long int` | 32                |
+| `long long int` | 64                |
 The width of each signed integer type shall not be less than the values
 specified in [[basic.fundamental.width]]. The value representation of a
 signed or unsigned integer type comprises N bits, where N is the
 respective width. Each set of values for any padding bits
+[[basic.types.general]] in the object representation are alternative
 representations of the value specified by the value representation.
 [*Note 3*: Padding bits have unspecified value, but cannot cause traps.
 In contrast, see ISO C 6.2.6.2. — *end note*]
 representable values as the underlying type. Further, each value has the
 same representation in both types.
 Type `char` is a distinct type that has an *implementation-defined*
 choice of “`signed char`” or “`unsigned char`” as its underlying type.
+The three types `char`, `signed char`, and `unsigned char` are
+collectively called *ordinary character types*. The ordinary character
+types and `char8_t` are collectively called *narrow character types*.
+For narrow character types, each possible bit pattern of the object
+representation represents a distinct value.
 [*Note 5*: This requirement does not hold for other
 types. — *end note*]
 [*Note 6*: A bit-field of narrow character type whose width is larger
 than the width of that type has padding bits; see
+[[basic.types.general]]. — *end note*]
 Type `wchar_t` is a distinct type that has an *implementation-defined*
+signed or unsigned integer type as its underlying type.
 Type `char8_t` denotes a distinct type whose underlying type is
 `unsigned char`. Types `char16_t` and `char32_t` denote distinct types
 whose underlying types are `uint_least16_t` and `uint_least32_t`,
 respectively, in `<cstdint>`.
 `bool` are `true` and `false`.
 [*Note 7*: There are no `signed`, `unsigned`, `short`, or `long bool`
 types or values. — *end note*]
+The types `char`, `wchar_t`, `char8_t`, `char16_t`, and `char32_t` are
+collectively called *character types*. The character types, `bool`, the
+signed and unsigned integer types, and cv-qualified versions
+[[basic.type.qualifier]] thereof, are collectively termed *integral
 types*. A synonym for integral type is *integer type*.
 [*Note 8*: Enumerations [[dcl.enum]] are not integral; however,
 unscoped enumerations can be promoted to integral types as specified in
 [[conv.prom]]. — *end note*]
+The three distinct types `float`, `double`, and `long double` can
+represent floating-point numbers. The type `double` provides at least as
+much precision as `float`, and the type `long double` provides at least
+as much precision as `double`. The set of values of the type `float` is
+a subset of the set of values of the type `double`; the set of values of
+the type `double` is a subset of the set of values of the type
+`long double`. The types `float`, `double`, and `long double`, and
+cv-qualified versions [[basic.type.qualifier]] thereof, are collectively
+termed *standard floating-point types*. An implementation may also
+provide additional types that represent floating-point values and define
+them (and cv-qualified versions thereof) to be *extended floating-point
+types*. The standard and extended floating-point types are collectively
+termed *floating-point types*.
+[*Note 9*: Any additional implementation-specific types representing
+floating-point values that are not defined by the implementation to be
+extended floating-point types are not considered to be floating-point
+types, and this document imposes no requirements on them or their
+interactions with floating-point types. — *end note*]
+Except as specified in [[basic.extended.fp]], the object and value
+representations and accuracy of operations of floating-point types are
 *implementation-defined*.
+Integral and floating-point types are collectively termed *arithmetic
+types*.
+[*Note 10*: Properties of the arithmetic types, such as their minimum
+and maximum representable value, can be queried using the facilities in
+the standard library headers `<limits>`, `<climits>`, and
+`<cfloat>`. — *end note*]
 A type cv `void` is an incomplete type that cannot be completed; such a
 type has an empty set of values. 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.type.conv]], [[expr.static.cast]], [[expr.cast]]. An expression
+of type cv `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 cv `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*)`.
 The types described in this subclause are called *fundamental types*.
+[*Note 11*: Even if the implementation defines two or more fundamental
 types to have the same value representation, they are nevertheless
 different types. — *end note*]
+### Optional extended floating-point types <a id="basic.extended.fp">[[basic.extended.fp]]</a>
+If the implementation supports an extended floating-point type
+[[basic.fundamental]] whose properties are specified by the ISO/IEC/IEEE
+60559 floating-point interchange format binary16, then the
+*typedef-name* `std::float16_t` is defined in the header `<stdfloat>`
+and names such a type, the macro `__STDCPP_FLOAT16_T__` is defined
+[[cpp.predefined]], and the floating-point literal suffixes `f16` and
+`F16` are supported [[lex.fcon]].
+If the implementation supports an extended floating-point type whose
+properties are specified by the ISO/IEC/IEEE 60559 floating-point
+interchange format binary32, then the *typedef-name* `std::float32_t` is
+defined in the header `<stdfloat>` and names such a type, the macro
+`__STDCPP_FLOAT32_T__` is defined, and the floating-point literal
+suffixes `f32` and `F32` are supported.
+If the implementation supports an extended floating-point type whose
+properties are specified by the ISO/IEC/IEEE 60559 floating-point
+interchange format binary64, then the *typedef-name* `std::float64_t` is
+defined in the header `<stdfloat>` and names such a type, the macro
+`__STDCPP_FLOAT64_T__` is defined, and the floating-point literal
+suffixes `f64` and `F64` are supported.
+If the implementation supports an extended floating-point type whose
+properties are specified by the ISO/IEC/IEEE 60559 floating-point
+interchange format binary128, then the *typedef-name* `std::float128_t`
+is defined in the header `<stdfloat>` and names such a type, the macro
+`__STDCPP_FLOAT128_T__` is defined, and the floating-point literal
+suffixes `f128` and `F128` are supported.
+If the implementation supports an extended floating-point type with the
+properties, as specified by ISO/IEC/IEEE 60559, of radix (b) of 2,
+storage width in bits (k) of 16, precision in bits (p) of 8, maximum
+exponent (emax) of 127, and exponent field width in bits (w) of 8, then
+the *typedef-name* `std::bfloat16_t` is defined in the header
+`<stdfloat>` and names such a type, the macro `__STDCPP_BFLOAT16_T__` is
+defined, and the floating-point literal suffixes `bf16` and `BF16` are
+supported.
+[*Note 1*: A summary of the parameters for each type is given in
+[[basic.extended.fp]]. The precision p includes the implicit 1 bit at
+the beginning of the mantissa, so the storage used for the mantissa is
+p-1 bits. ISO/IEC/IEEE 60559 does not assign a name for a type having
+the parameters specified for `std::bfloat16_t`. — *end note*]
+**Table: Properties of named extended floating-point types** <a id="basic.extended.fp">[basic.extended.fp]</a>
+| Parameter                         | `float16_t` | `float32_t` | `float64_t` | `float128_t` | `bfloat16_t` |
+| --------------------------------- | ----------- | ----------- | ----------- | ------------ | ------------ |
+| ISO/IEC/IEEE 60559 name           | binary16    | binary32    | binary64    | binary128    |              |
+| $k$, storage width in bits        | 16          | 32          | 64          | 128          | 16           |
+| $p$, precision in bits            | 11          | 24          | 53          | 113          | 8            |
+| $emax$, maximum exponent          | 15          | 127         | 1023        | 16383        | 127          |
+| $w$, exponent field width in bits | 5           | 8           | 11          | 15           | 8            |
+*Recommended practice:* Any names that the implementation provides for
+the extended floating-point types described in this subsection that are
+in addition to the names defined in the `<stdfloat>` header should be
+chosen to increase compatibility and interoperability with the
+interchange types `_Float16`, `_Float32`, `_Float64`, and `_Float128`
+defined in ISO/IEC TS 18661-3 and with future versions of the C
+standard.
 ### Compound types <a id="basic.compound">[[basic.compound]]</a>
 Compound types can be constructed in the following ways:
 - *arrays* of objects of a given type, [[dcl.array]];
   a set of types, enumerations and functions for manipulating these
   objects [[class.mfct]], and a set of restrictions on the access to
   these entities [[class.access]];
 - *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,
   [[dcl.enum]];
+- *pointers to non-static class members*,[^19] which identify members of
+  a given type within objects of a given class, [[dcl.mptr]]. Pointers
+  to data members and pointers to member functions are collectively
+  called *pointer-to-member* types.
 These methods of constructing types can be applied recursively;
 restrictions are mentioned in  [[dcl.meaning]]. 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]]
 - the *null pointer value* for that type, or
 - an *invalid pointer value*.
 A value of a pointer type that is a pointer to or past the end of an
 object *represents the address* of the first byte in memory
+[[intro.memory]] occupied by the object[^20]
+or the first byte in memory after the end of the storage occupied by the
+object, respectively.
 [*Note 2*: A pointer past the end of an object [[expr.add]] is not
+considered to point to an unrelated object of the object’s type, even if
+the unrelated object is located at that address. A pointer value becomes
+invalid when the storage it denotes reaches the end of its storage
+duration; see [[basic.stc]]. — *end note*]
+For purposes of pointer arithmetic [[expr.add]] and comparison
+[[expr.rel]], [[expr.eq]], a pointer past the end of the last element of
+an array `x` of n elements is considered to be equivalent to a pointer
+to a hypothetical array element n of `x` and an object of type `T` that
+is not an array element is considered to belong to an array with one
+element of type `T`. The value representation of pointer types is
+*implementation-defined*. Pointers to layout-compatible types shall have
+the same value representation and alignment requirements
 [[basic.align]].
 [*Note 3*: Pointers to over-aligned types [[basic.align]] have no
 special representation, but their range of valid values is restricted by
 the extended alignment requirement. — *end note*]
 - they are the same object, or
 - one is a union object and the other is a non-static data member of
   that object [[class.union]], or
 - one is a standard-layout class object and the other is the first
+  non-static data member of that object or any base class subobject of
+ that object [[class.mem]], or
 - there exists an object *c* such that *a* and *c* are
   pointer-interconvertible, and *c* and *b* are
   pointer-interconvertible.
 If two objects are pointer-interconvertible, then they have the same
 [*Note 4*: An array object and its first element are not
 pointer-interconvertible, even though they have the same
 address. — *end note*]
+A byte of storage *b* is *reachable through* a pointer value that points
+to an object *x* if there is an object *y*, pointer-interconvertible
+with *x*, such that *b* is within the storage occupied by *y*, or the
+immediately-enclosing array object if *y* is an array element.
 A pointer to cv `void` can be used to point to objects of unknown type.
 Such a pointer shall be able to hold any object pointer. An object of
+type “pointer to cv `void`” shall have the same representation and
+alignment requirements as an object of type “pointer to cv `char`”.
 ### CV-qualifiers <a id="basic.type.qualifier">[[basic.type.qualifier]]</a>
+Each type other than a function or reference type is part of a group of
+four distinct, but related, types: a *cv-unqualified* version, a
+*const-qualified* version, a *volatile-qualified* version, and a
+*const-volatile-qualified* version. The types in each such group shall
+have the same representation and alignment requirements
+[[basic.align]].[^21]
+A function or reference type is always cv-unqualified.
 - A *const object* is an object of type `const T` or a non-mutable
   subobject of a const object.
 - A *volatile object* is an object of type `volatile T` or a subobject
   of a volatile object.
 - A *const volatile object* is an object of type `const volatile T`, a
   non-mutable subobject of a const volatile object, a const subobject of
   a volatile object, or a non-mutable volatile subobject of a const
   object.
+[*Note 1*: The type of an object [[intro.object]] includes the
+*cv-qualifier*s specified in the *decl-specifier-seq* [[dcl.spec]],
+*declarator* [[dcl.decl]], *type-id* [[dcl.name]], or *new-type-id*
+[[expr.new]] when the object is created. — *end note*]
 Except for array types, a compound type [[basic.compound]] is not
 cv-qualified by the cv-qualifiers (if any) of the types from which it is
 compounded.
 An array type whose elements are cv-qualified is also considered to have
 the same cv-qualifications as its elements.
+[*Note 2*: 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
 [[dcl.array]]. — *end note*]
 [*Example 1*:
 The type of both `arr1` and `arr2` is “array of 5 `const char`”, and the
 array type is considered to be const-qualified.
 — *end example*]
+[*Note 3*: See  [[dcl.fct]] and  [[over.match.funcs]] regarding
+function types that have *cv-qualifier*s. — *end note*]
 There is a partial ordering on cv-qualifiers, so that a type can be said
 to be *more cv-qualified* than another. [[basic.type.qualifier.rel]]
 shows the relations that constitute this ordering.
 `volatile int * const` has the top-level cv-qualifier `const`. For a
 class type `C`, the type corresponding to the *type-id*
 `void (C::* volatile)(int) const` has the top-level cv-qualifier
 `volatile`. — *end example*]
+### Conversion ranks <a id="conv.rank">[[conv.rank]]</a>
 Every integer type has an *integer conversion rank* defined as follows:
 - No two signed integer types other than `char` and `signed
+  char` (if `char` is signed) have the same rank, even if they have the
+  same representation.
+- The rank of a signed integer type is greater than the rank of any
+  signed integer type with a smaller width.
+- The rank of `long long int` is greater than the rank of `long int`,
+  which is greater than the rank of `int`, which is greater than the
+  rank of `short int`, which is greater than the rank of `signed char`.
+- The rank of any unsigned integer type equals the rank of the
   corresponding signed integer type.
+- The rank of any standard integer type is greater than the rank of any
+  extended integer type with the same width.
+- The rank of `char` equals the rank of `signed char` and
   `unsigned char`.
+- The rank of `bool` is less than the rank of all standard integer
+  types.
+- The ranks of `char8_t`, `char16_t`, `char32_t`, and `wchar_t` equal
+  the ranks of their underlying types [[basic.fundamental]].
 - The rank of any extended signed integer type relative to another
   extended signed integer type with the same width is
   *implementation-defined*, but still subject to the other rules for
   determining the integer conversion rank.
 - For all integer types `T1`, `T2`, and `T3`, if `T1` has greater rank
+  than `T2` and `T2` has greater rank than `T3`, then `T1` has greater
+  rank than `T3`.
 [*Note 1*: The integer conversion rank is used in the definition of the
 integral promotions [[conv.prom]] and the usual arithmetic conversions
 [[expr.arith.conv]]. — *end note*]
+Every floating-point type has a *floating-point conversion rank* defined
+as follows:
+- The rank of a floating point type `T` is greater than the rank of any
+  floating-point type whose set of values is a proper subset of the set
+  of values of `T`.
+- The rank of `long double` is greater than the rank of `double`, which
+  is greater than the rank of `float`.
+- Two extended floating-point types with the same set of values have
+  equal ranks.
+- An extended floating-point type with the same set of values as exactly
+  one cv-unqualified standard floating-point type has a rank equal to
+  the rank of that standard floating-point type.
+- An extended floating-point type with the same set of values as more
+  than one cv-unqualified standard floating-point type has a rank equal
+  to the rank of `double`.
+[*Note 2*: The conversion ranks of floating-point types `T1` and `T2`
+are unordered if the set of values of `T1` is neither a subset nor a
+superset of the set of values of `T2`. This can happen when one type has
+both a larger range and a lower precision than the other. — *end note*]
+Floating-point types that have equal floating-point conversion ranks are
+ordered by floating-point conversion subrank. The subrank forms a total
+order among types with equal ranks. The types `std::float16_t`,
+`std::float32_t`, `std::float64_t`, and `std::float128_t`
+[[stdfloat.syn]] have a greater conversion subrank than any standard
+floating-point type with equal conversion rank. Otherwise, the
+conversion subrank order is *implementation-defined*.
+[*Note 3*: The floating-point conversion rank and subrank are used in
+the definition of the usual arithmetic conversions
+[[expr.arith.conv]]. — *end note*]
 ## Program execution <a id="basic.exec">[[basic.exec]]</a>
 ### Sequential execution <a id="intro.execution">[[intro.execution]]</a>
 An instance of each object with automatic storage duration
 suspension of a coroutine [[expr.await]], or receipt of a signal).
 A *constituent expression* is defined as follows:
 - The constituent expression of an expression is that expression.
+- The constituent expression of a conversion is the corresponding
+  implicit function call, if any, or the converted expression otherwise.
 - The constituent expressions of a *braced-init-list* or of a (possibly
   parenthesized) *expression-list* are the constituent expressions of
   the elements of the respective list.
 - The constituent expressions of a *brace-or-equal-initializer* of the
   form `=` *initializer-clause* are the constituent expressions of the
 [*Note 1*: Expressions appearing in the *compound-statement* of a
 *lambda-expression* are not subexpressions of the
 *lambda-expression*. — *end note*]
+The *potentially-evaluated subexpressions* of an expression, conversion,
+or *initializer* E are
+- the constituent expressions of E and
+- the subexpressions thereof that are not subexpressions of a nested
+  unevaluated operand [[term.unevaluated.operand]].
 A *full-expression* is
+- an unevaluated operand [[expr.context]],
 - a *constant-expression* [[expr.const]],
 - an immediate invocation [[expr.const]],
 - an *init-declarator* [[dcl.decl]] or a *mem-initializer*
   [[class.base.init]], including the constituent expressions of the
   initializer,
 Evaluations *A* and *B* are *indeterminately sequenced* when either *A*
 is sequenced before *B* or *B* is sequenced before *A*, but it is
 unspecified which.
 [*Note 4*: Indeterminately sequenced evaluations cannot overlap, but
+either can be executed first. — *end note*]
 An expression *X* is said to be sequenced before an expression *Y* if
 every value computation and every side effect associated with the
 expression *X* is sequenced before every value computation and every
 side effect associated with the expression *Y*.
 Every value computation and side effect associated with a
 full-expression is sequenced before every value computation and side
+effect associated with the next full-expression to be evaluated.[^22]
 Except where noted, evaluations of operands of individual operators and
 of subexpressions of individual expressions are unsequenced.
 [*Note 5*: In an expression that is evaluated more than once during the
 }
 ```
 — *end example*]
+When invoking a function (whether or not the function is inline), every
+argument expression and the postfix expression designating the called
+function are sequenced before every expression or statement in the body
+of the called function. For each function invocation or evaluation of an
+*await-expression* *F*, each evaluation that does not occur within *F*
+but is evaluated on the same thread and as part of the same signal
+handler (if any) is either sequenced before all evaluations that occur
+within *F* or sequenced after all evaluations that occur within
+*F*;[^23]
+if *F* invokes or resumes a coroutine [[expr.await]], only evaluations
+subsequent to the previous suspension (if any) and prior to the next
+suspension (if any) are considered to occur within *F*.
 Several contexts in C++ cause evaluation of a function call, even though
 no corresponding function call syntax appears in the translation unit.
 [*Example 4*: Evaluation of a *new-expression* invokes one or more
 arise in contexts in which no function call syntax
 appears. — *end example*]
 The sequencing constraints on the execution of the called function (as
 described above) are features of the function calls as evaluated,
+regardless of the syntax of the expression that calls the function.
 If a signal handler is executed as a result of a call to the
 `std::raise` function, then the execution of the handler is sequenced
 after the invocation of the `std::raise` function and before its return.
+[*Note 7*: When a signal is received for another reason, the execution
 of the signal handler is usually unsequenced with respect to the rest of
 the program. — *end note*]
 ### Multi-threaded executions and data races <a id="intro.multithread">[[intro.multithread]]</a>
+#### General <a id="intro.multithread.general">[[intro.multithread.general]]</a>
 A *thread of execution* (also known as a *thread*) is a single flow of
 control within a program, including the initial invocation of a specific
 top-level function, and recursively including every function invocation
 subsequently executed by the thread.
 [*Note 1*: When one thread creates another, the initial call to the
 top-level function of the new thread is executed by the new thread, not
 by the creating thread. — *end note*]
 Every thread in a program can potentially access every object and
+function in a program.[^24]
+Under a hosted implementation, a C++ program can have more than one
+thread running concurrently. The execution of each thread proceeds as
+defined by the remainder of this document. The execution of the entire
+program consists of an execution of all of its threads.
 [*Note 2*: Usually the execution can be viewed as an interleaving of
 all its threads. However, some kinds of atomic operations, for example,
 allow executions inconsistent with a simple interleaving, as described
 below. — *end note*]
 The value of an object visible to a thread T at a particular point is
 the initial value of the object, a value assigned to the object by T, or
 a value assigned to the object by another thread, according to the rules
 below.
+[*Note 1*: In some cases, there might instead be undefined behavior.
+Much of this subclause is motivated by the desire to support atomic
 operations with explicit and detailed visibility constraints. However,
 it also implicitly supports a simpler view for more restricted
 programs. — *end note*]
 Two expression evaluations *conflict* if one of them modifies a memory
 particular total order, called the *modification order* of M.
 [*Note 3*: There is a separate order for each atomic object. There is
 no requirement that these can be combined into a single total order for
 all objects. In general this will be impossible since different threads
+can observe modifications to different objects in inconsistent
 orders. — *end note*]
 A *release sequence* headed by a release operation A on an atomic object
 M is a maximal contiguous sub-sequence of side effects in the
 modification order of M, where the first operation is A, and every
 object in that interleaving. This is normally referred to as “sequential
 consistency”. However, this applies only to data-race-free programs, and
 data-race-free programs cannot observe most program transformations that
 do not change single-threaded program semantics. In fact, most
 single-threaded program transformations continue to be allowed, since
+any program that behaves differently as a result has undefined
+behavior. — *end note*]
 Two accesses to the same object of type `volatile std::sig_atomic_t` do
 not result in a data race if both occur in the same thread, even if one
 or more occurs in a signal handler. For each signal handler invocation,
 evaluations performed by the thread invoking a signal handler can be
 abstract machine are generally precluded by this document, since such an
 assignment might overwrite another assignment by a different thread in
 cases in which an abstract machine execution would not have encountered
 a data race. This includes implementations of data member assignment
 that overwrite adjacent members in separate memory locations. Reordering
+of atomic loads in cases in which the atomics in question might alias is
+also generally precluded, since this could violate the coherence
 rules. — *end note*]
 [*Note 23*: Transformations that introduce a speculative read of a
+potentially shared memory location might not preserve the semantics of
+the C++ program as defined in this document, since they potentially
 introduce a data race. However, they are typically valid in the context
 of an optimizing compiler that targets a specific machine with
 well-defined semantics for data races. They would be invalid for a
 hypothetical machine that is not tolerant of races or provides hardware
 race detection. — *end note*]
 [[atomics.flag]] or indicated as lock-free [[atomics.lockfree]] are
 *lock-free executions*.
 - If there is only one thread that is not blocked [[defns.block]] in a
   standard library function, a lock-free execution in that thread shall
+  complete. \[*Note 2*: Concurrently executing threads might prevent
   progress of a lock-free execution. For example, this situation can
   occur with load-locked store-conditional implementations. This
   property is sometimes termed obstruction-free. — *end note*]
 - When one or more lock-free executions run concurrently, at least one
   should complete. \[*Note 3*: It is difficult for some implementations
   to provide absolute guarantees to this effect, since repeated and
+  particularly inopportune interference from other threads could prevent
   forward progress, e.g., by repeatedly stealing a cache line for
   unrelated purposes between load-locked and store-conditional
+  instructions. For implementations that follow this recommendation and
+ ensure that such effects cannot indefinitely delay progress under
+ expected operating conditions, such anomalies can therefore safely be
+ ignored by programmers. Outside this document, this property is
+ sometimes termed lock-free. — *end note*]
 During the execution of a thread of execution, each of the following is
 termed an *execution step*:
 - termination of the thread of execution,
 is considered to continuously execute execution steps while waiting for
 the condition that it blocks on to be satisfied.
 [*Example 1*: A library I/O function that blocks until the I/O
 operation is complete can be considered to continuously check whether
+the operation is complete. Each such check consists of one or more
 execution steps, for example using observable behavior of the abstract
 machine. — *end example*]
 [*Note 4*: Because of this and the preceding requirement regarding what
 threads of execution have to perform eventually, it follows that no
 For a thread of execution providing *concurrent forward progress
 guarantees*, the implementation ensures that the thread will eventually
 make progress for as long as it has not terminated.
 [*Note 5*: This is required regardless of whether or not other threads
+of execution (if any) have been or are making progress. To eventually
 fulfill this requirement means that this will happen in an unspecified
 but finite amount of time. — *end note*]
 It is *implementation-defined* whether the implementation-created thread
 of execution that executes `main` [[basic.start.main]] and the threads
 of execution created by `std::thread` [[thread.thread.class]] or
 `std::jthread` [[thread.jthread.class]] provide concurrent forward
+progress guarantees. General-purpose implementations should provide
+these guarantees.
 For a thread of execution providing *parallel forward progress
 guarantees*, the implementation is not required to ensure that the
 thread will eventually make progress if it has not yet executed any
 execution step; once this thread has executed a step, it provides
 concurrent forward progress guarantees.
+[*Note 6*: This does not specify a requirement for when to start this
 thread of execution, which will typically be specified by the entity
 that creates this thread of execution. For example, a thread of
 execution that provides concurrent forward progress guarantees and
 executes tasks from a set of tasks in an arbitrary order, one after the
 other, satisfies the requirements of parallel forward progress for these
 For a thread of execution providing *weakly parallel forward progress
 guarantees*, the implementation does not ensure that the thread will
 eventually make progress.
+[*Note 7*: Threads of execution providing weakly parallel forward
 progress guarantees cannot be expected to make progress regardless of
 whether other threads make progress or not; however, blocking with
 forward progress guarantee delegation, as defined below, can be used to
 ensure that such threads of execution make progress
 eventually. — *end note*]
 Concurrent forward progress guarantees are stronger than parallel
 forward progress guarantees, which in turn are stronger than weakly
 parallel forward progress guarantees.
+[*Note 8*: For example, some kinds of synchronization between threads
+of execution might only make progress if the respective threads of
 execution provide parallel forward progress guarantees, but will fail to
 make progress under weakly parallel guarantees. — *end note*]
 When a thread of execution P is specified to *block with forward
 progress guarantee delegation* on the completion of a set S of threads
 of execution, then throughout the whole time of P being blocked on S,
 the implementation shall ensure that the forward progress guarantees
 provided by at least one thread of execution in S is at least as strong
 as P’s forward progress guarantees.
+[*Note 9*: It is unspecified which thread or threads of execution in S
 are chosen and for which number of execution steps. The strengthening is
 not permanent and not necessarily in place for the rest of the lifetime
 of the affected thread of execution. As long as P is blocked, the
 implementation has to eventually select and potentially strengthen a
 thread of execution in S. — *end note*]
 Once a thread of execution in S terminates, it is removed from S. Once S
 is empty, P is unblocked.
+[*Note 10*: A thread of execution B thus can temporarily provide an
 effectively stronger forward progress guarantee for a certain amount of
 time, due to a second thread of execution A being blocked on it with
 forward progress guarantee delegation. In turn, if B then blocks with
+forward progress guarantee delegation on C, this can also temporarily
 provide a stronger forward progress guarantee to C. — *end note*]
+[*Note 11*: If all threads of execution in S finish executing (e.g.,
 they terminate and do not use blocking synchronization incorrectly),
 then P’s execution of the operation that blocks with forward progress
 guarantee delegation will not result in P’s progress guarantee being
 effectively weakened. — *end note*]
+[*Note 12*: This does not remove any constraints regarding blocking
 synchronization for threads of execution providing parallel or weakly
 parallel forward progress guarantees because the implementation is not
 required to strengthen a particular thread of execution whose too-weak
 progress guarantee is preventing overall progress. — *end note*]
 ### Start and termination <a id="basic.start">[[basic.start]]</a>
 #### `main` function <a id="basic.start.main">[[basic.start.main]]</a>
+A program shall contain exactly one function called `main` that belongs
+to the global scope. Executing a program starts a main thread of
+execution [[intro.multithread]], [[thread.threads]] in which the `main`
+function is invoked. It is *implementation-defined* whether a program in
+a freestanding environment is required to define a `main` function.
 [*Note 1*: In a freestanding environment, startup and termination is
 *implementation-defined*; startup contains the execution of constructors
+for non-local objects with static storage duration; termination contains
+the execution of destructors for objects with static storage
 duration. — *end note*]
+An implementation shall not predefine the `main` function. Its type
+shall have C++ language linkage and 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
 [[multibyte.strings]] and `argv[0]` shall be the pointer to the initial
 character of a NTMBS that 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.
+*Recommended practice:* Any further (optional) parameters should 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`, `constexpr`, or `consteval` is ill-formed. The function `main`
+shall not be a coroutine [[dcl.fct.def.coroutine]]. The `main` function
+shall not be declared with a *linkage-specification* [[dcl.link]]. A
+program that declares
+- a variable `main` that belongs to the global scope, or
+- a function `main` that belongs to the global scope and is attached to
+  a named module, or
+- a function template `main` that belongs to the global scope, or
+- an entity named `main` with C language linkage (in any namespace)
+is ill-formed. The name `main` is not otherwise reserved.
 [*Example 1*: Member functions, classes, and enumerations can be called
 `main`, as can entities in other namespaces. — *end example*]
 Terminating the program without leaving the current block (e.g., by
 calling the function `std::exit(int)` [[support.start.term]]) does not
 destroy any objects with automatic storage duration [[class.dtor]]. If
+`std::exit` is invoked during the destruction of an object with static
+or thread storage duration, the program has undefined behavior.
 A `return` statement [[stmt.return]] in `main` has the effect of leaving
 the main function (destroying any objects with automatic storage
 duration) and calling `std::exit` with the return value as the argument.
 If control flows off the end of the *compound-statement* of `main`, the
 with static or thread storage duration is constant-initialized
 [[expr.const]]. If constant initialization is not performed, a variable
 with static storage duration [[basic.stc.static]] or thread storage
 duration [[basic.stc.thread]] is zero-initialized [[dcl.init]].
 Together, zero-initialization and constant initialization are called
+*static initialization*; all other initialization is
+*dynamic initialization*. All static initialization strongly happens
+before [[intro.races]] any dynamic initialization.
+[*Note 1*: The dynamic initialization of non-block variables is
+described in  [[basic.start.dynamic]]; that of static block variables is
 described in  [[stmt.dcl]]. — *end note*]
 An implementation is permitted to perform the initialization of a
 variable with static or thread storage duration as a static
 initialization even if such initialization is not required to be done
   statically were initialized dynamically.
 [*Note 2*:
 As a consequence, if the initialization of an object `obj1` refers to an
+object `obj2` potentially requiring dynamic initialization and defined
+later in the same translation unit, it is unspecified whether the value
+of `obj2` used will be the value of the fully initialized `obj2`
+(because `obj2` was statically initialized) or will be the value of
+`obj2` merely zero-initialized. For example,
 ``` cpp
 inline double fd() { return 1.0; }
 extern double d1;
 double d2 = d1;     // unspecified:
+                    // either statically initialized to 0.0 or
                     // dynamically initialized to 0.0 if d1 is
                     // dynamically initialized, or 1.0 otherwise
+double d1 = fd();   // either initialized statically or dynamically to 1.0
 ```
 — *end note*]
+#### Dynamic initialization of non-block variables <a id="basic.start.dynamic">[[basic.start.dynamic]]</a>
+Dynamic initialization of a non-block variable with static storage
 duration is unordered if the variable is an implicitly or explicitly
 instantiated specialization, is partially-ordered if the variable is an
 inline variable that is not an implicitly or explicitly instantiated
 specialization, and otherwise is ordered.
+[*Note 1*: A non-inline explicit specialization of a templated variable
+has ordered initialization. — *end note*]
 A declaration `D` is *appearance-ordered* before a declaration `E` if
 - `D` appears in the same translation unit as `E`, or
 - the translation unit containing `E` has an interface dependency on the
   translation unit containing `D`,
 in either case prior to `E`.
+Dynamic initialization of non-block variables `V` and `W` with static
 storage duration are ordered as follows:
 - If `V` and `W` have ordered initialization and the definition of `V`
   is appearance-ordered before the definition of `W`, or if `V` has
   partially-ordered initialization, `W` does not have unordered
   sequenced.
 [*Note 2*: This definition permits initialization of a sequence of
 ordered variables concurrently with another sequence. — *end note*]
+A *non-initialization odr-use* is an odr-use [[term.odr.use]] not caused
+directly or indirectly by the initialization of a non-block static or
+thread storage duration variable.
 It is *implementation-defined* whether the dynamic initialization of a
+non-block non-inline variable with static storage duration is sequenced
 before the first statement of `main` or is deferred. If it is deferred,
 it strongly happens before any non-initialization odr-use of any
 non-inline function or non-inline variable defined in the same
+translation unit as the variable to be initialized.[^25]
+It is *implementation-defined* in which threads and at which points in
+the program such deferred dynamic initialization occurs.
+*Recommended practice:* An implementation should choose such points in a
+way that allows the programmer to avoid deadlocks.
 [*Example 1*:
 ``` cpp
 // - File 1 -
 to its use in `A::A`.
 — *end example*]
 It is *implementation-defined* whether the dynamic initialization of a
+non-block inline variable with static storage duration is sequenced
 before the first statement of `main` or is deferred. If it is deferred,
 it strongly happens before any non-initialization odr-use of that
 variable. It is *implementation-defined* in which threads and at which
 points in the program such deferred dynamic initialization occurs.
 It is *implementation-defined* whether the dynamic initialization of a
+non-block non-inline variable with thread storage duration is sequenced
 before the first statement of the initial function of a thread or is
 deferred. If it is deferred, the initialization associated with the
 entity for thread *t* is sequenced before the first non-initialization
 odr-use by *t* of any non-inline variable with thread storage duration
 defined in the same translation unit as the variable to be initialized.
 It is *implementation-defined* in which threads and at which points in
 the program such deferred dynamic initialization occurs.
+If the initialization of a non-block variable with static or thread
 storage duration exits via an exception, the function `std::terminate`
 is called [[except.terminate]].
 #### Termination <a id="basic.start.term">[[basic.start.term]]</a>
 storage duration is sequenced before that of another, the completion of
 the destructor of the second is sequenced before the initiation of the
 destructor of the first. If an object is initialized statically, the
 object is destroyed in the same order as if the object was dynamically
 initialized. For an object of array or class type, all subobjects of
+that object are destroyed before any block variable with static storage
+duration initialized during the construction of the subobjects is
+destroyed. If the destruction of an object with static or thread storage
+duration exits via an exception, the function `std::terminate` is called
+[[except.terminate]].
+If a function contains a block variable of static or thread storage
 duration that has been destroyed and the function is called during the
 destruction of an object with static or thread storage duration, the
 program has undefined behavior if the flow of control passes through the
+definition of the previously destroyed block variable.
+[*Note 2*: Likewise, the behavior is undefined if the block variable is
+used indirectly (e.g., through a pointer) after its
+destruction. — *end note*]
 If the completion of the initialization of an object with static storage
 duration strongly happens before a call to `std::atexit` (see
 `<cstdlib>`, [[support.start.term]]), the call to the function passed to
 `std::atexit` is sequenced before the call to the destructor for the
 within signal handlers [[support.runtime]] that does not happen before
 [[intro.multithread]] completion of destruction of objects with static
 storage duration and execution of `std::atexit` registered functions
 [[support.start.term]], the program has undefined behavior.
+[*Note 3*: If there is a use of an object with static storage duration
 that does not happen before the object’s destruction, the program has
 undefined behavior. Terminating every thread before a call to
 `std::exit` or the exit from `main` is sufficient, but not necessary, to
 satisfy these requirements. These requirements permit thread managers as
 static-storage-duration objects. — *end note*]
 Calling the function `std::abort()` declared in `<cstdlib>` terminates
 the program without executing any destructors and without calling the
 functions passed to `std::atexit()` or `std::at_quick_exit()`.
 <!-- Link reference definitions -->
+[allocator.members]: mem.md#allocator.members
+[allocator.traits.members]: mem.md#allocator.traits.members
+[atomics]: thread.md#atomics
+[atomics.flag]: thread.md#atomics.flag
+[atomics.lockfree]: thread.md#atomics.lockfree
+[atomics.order]: thread.md#atomics.order
 [bad.alloc]: support.md#bad.alloc
 [basic]: #basic
 [basic.align]: #basic.align
 [basic.compound]: #basic.compound
 [basic.def]: #basic.def
 [basic.def.odr]: #basic.def.odr
 [basic.exec]: #basic.exec
+[basic.extended.fp]: #basic.extended.fp
 [basic.fundamental]: #basic.fundamental
 [basic.fundamental.width]: #basic.fundamental.width
 [basic.indet]: #basic.indet
 [basic.life]: #basic.life
 [basic.link]: #basic.link
 [basic.lookup]: #basic.lookup
 [basic.lookup.argdep]: #basic.lookup.argdep
 [basic.lookup.elab]: #basic.lookup.elab
+[basic.lookup.general]: #basic.lookup.general
 [basic.lookup.qual]: #basic.lookup.qual
+[basic.lookup.qual.general]: #basic.lookup.qual.general
 [basic.lookup.udir]: #basic.lookup.udir
 [basic.lookup.unqual]: #basic.lookup.unqual
 [basic.lval]: expr.md#basic.lval
 [basic.memobj]: #basic.memobj
 [basic.namespace]: dcl.md#basic.namespace
 [basic.pre]: #basic.pre
 [basic.scope]: #basic.scope
 [basic.scope.block]: #basic.scope.block
 [basic.scope.class]: #basic.scope.class
 [basic.scope.enum]: #basic.scope.enum
+[basic.scope.lambda]: #basic.scope.lambda
 [basic.scope.namespace]: #basic.scope.namespace
 [basic.scope.param]: #basic.scope.param
 [basic.scope.pdecl]: #basic.scope.pdecl
+[basic.scope.scope]: #basic.scope.scope
 [basic.scope.temp]: #basic.scope.temp
 [basic.start]: #basic.start
 [basic.start.dynamic]: #basic.start.dynamic
 [basic.start.main]: #basic.start.main
 [basic.start.static]: #basic.start.static
 [basic.stc]: #basic.stc
 [basic.stc.auto]: #basic.stc.auto
 [basic.stc.dynamic]: #basic.stc.dynamic
 [basic.stc.dynamic.allocation]: #basic.stc.dynamic.allocation
 [basic.stc.dynamic.deallocation]: #basic.stc.dynamic.deallocation
+[basic.stc.dynamic.general]: #basic.stc.dynamic.general
+[basic.stc.general]: #basic.stc.general
 [basic.stc.inherit]: #basic.stc.inherit
 [basic.stc.static]: #basic.stc.static
 [basic.stc.thread]: #basic.stc.thread
 [basic.type.qualifier]: #basic.type.qualifier
 [basic.type.qualifier.rel]: #basic.type.qualifier.rel
 [basic.types]: #basic.types
+[basic.types.general]: #basic.types.general
+[bit.cast]: utilities.md#bit.cast
+[c.malloc]: mem.md#c.malloc
 [class]: class.md#class
 [class.abstract]: class.md#class.abstract
 [class.access]: class.md#class.access
+[class.access.base]: class.md#class.access.base
 [class.base.init]: class.md#class.base.init
 [class.bit]: class.md#class.bit
 [class.cdtor]: class.md#class.cdtor
 [class.conv.fct]: class.md#class.conv.fct
 [class.copy.assign]: class.md#class.copy.assign
 [class.default.ctor]: class.md#class.default.ctor
 [class.derived]: class.md#class.derived
 [class.dtor]: class.md#class.dtor
 [class.free]: class.md#class.free
 [class.friend]: class.md#class.friend
 [class.mem]: class.md#class.mem
+[class.member.lookup]: #class.member.lookup
 [class.mfct]: class.md#class.mfct
+[class.mfct.non.static]: class.md#class.mfct.non.static
 [class.name]: class.md#class.name
 [class.pre]: class.md#class.pre
 [class.prop]: class.md#class.prop
 [class.qual]: #class.qual
 [class.spaceship]: class.md#class.spaceship
 [class.static]: class.md#class.static
 [class.static.data]: class.md#class.static.data
 [class.temporary]: #class.temporary
 [class.union]: class.md#class.union
+[class.union.anon]: class.md#class.union.anon
 [class.virtual]: class.md#class.virtual
 [conv]: expr.md#conv
 [conv.array]: expr.md#conv.array
 [conv.func]: expr.md#conv.func
 [conv.integral]: expr.md#conv.integral
 [dcl.fct.default]: dcl.md#dcl.fct.default
 [dcl.init]: dcl.md#dcl.init
 [dcl.init.aggr]: dcl.md#dcl.init.aggr
 [dcl.init.list]: dcl.md#dcl.init.list
 [dcl.init.ref]: dcl.md#dcl.init.ref
 [dcl.link]: dcl.md#dcl.link
 [dcl.meaning]: dcl.md#dcl.meaning
 [dcl.mptr]: dcl.md#dcl.mptr
 [dcl.name]: dcl.md#dcl.name
 [dcl.pre]: dcl.md#dcl.pre
 [dcl.ref]: dcl.md#dcl.ref
 [dcl.spec]: dcl.md#dcl.spec
 [dcl.spec.auto]: dcl.md#dcl.spec.auto
 [dcl.stc]: dcl.md#dcl.stc
 [dcl.struct.bind]: dcl.md#dcl.struct.bind
+[dcl.type.decltype]: dcl.md#dcl.type.decltype
 [dcl.type.elab]: dcl.md#dcl.type.elab
 [dcl.typedef]: dcl.md#dcl.typedef
 [defns.block]: intro.md#defns.block
 [depr.local]: future.md#depr.local
 [depr.static.constexpr]: future.md#depr.static.constexpr
 [diff.cpp11.basic]: compatibility.md#diff.cpp11.basic
 [enum.udecl]: dcl.md#enum.udecl
 [except.handle]: except.md#except.handle
 [except.pre]: except.md#except.pre
 [except.spec]: except.md#except.spec
 [except.terminate]: except.md#except.terminate
 [except.throw]: except.md#except.throw
 [expr.add]: expr.md#expr.add
 [expr.alignof]: expr.md#expr.alignof
 [expr.arith.conv]: expr.md#expr.arith.conv
 [expr.ass]: expr.md#expr.ass
 [expr.await]: expr.md#expr.await
 [expr.call]: expr.md#expr.call
 [expr.cast]: expr.md#expr.cast
 [expr.comma]: expr.md#expr.comma
 [expr.cond]: expr.md#expr.cond
 [expr.const]: expr.md#expr.const
 [expr.const.cast]: expr.md#expr.const.cast
 [expr.context]: expr.md#expr.context
 [expr.delete]: expr.md#expr.delete
 [expr.log.or]: expr.md#expr.log.or
 [expr.mptr.oper]: expr.md#expr.mptr.oper
 [expr.new]: expr.md#expr.new
 [expr.pre]: expr.md#expr.pre
 [expr.prim.id]: expr.md#expr.prim.id
 [expr.prim.id.qual]: expr.md#expr.prim.id.qual
+[expr.prim.id.unqual]: expr.md#expr.prim.id.unqual
 [expr.prim.lambda]: expr.md#expr.prim.lambda
 [expr.prim.lambda.capture]: expr.md#expr.prim.lambda.capture
 [expr.prim.lambda.closure]: expr.md#expr.prim.lambda.closure
 [expr.prim.this]: expr.md#expr.prim.this
 [expr.prop]: expr.md#expr.prop
 [get.new.handler]: support.md#get.new.handler
 [headers]: library.md#headers
 [intro.execution]: #intro.execution
 [intro.memory]: #intro.memory
 [intro.multithread]: #intro.multithread
+[intro.multithread.general]: #intro.multithread.general
 [intro.object]: #intro.object
 [intro.progress]: #intro.progress
 [intro.races]: #intro.races
 [lex.charset]: lex.md#lex.charset
+[lex.fcon]: lex.md#lex.fcon
 [lex.name]: lex.md#lex.name
 [lex.separate]: lex.md#lex.separate
 [module.context]: module.md#module.context
 [module.global.frag]: module.md#module.global.frag
 [module.interface]: module.md#module.interface
 [module.reach]: module.md#module.reach
 [module.unit]: module.md#module.unit
 [multibyte.strings]: library.md#multibyte.strings
 [namespace.def]: dcl.md#namespace.def
 [namespace.qual]: #namespace.qual
 [namespace.udecl]: dcl.md#namespace.udecl
 [namespace.udir]: dcl.md#namespace.udir
+[namespace.unnamed]: dcl.md#namespace.unnamed
 [new.delete]: support.md#new.delete
 [new.delete.array]: support.md#new.delete.array
 [new.delete.placement]: support.md#new.delete.placement
 [new.delete.single]: support.md#new.delete.single
 [new.handler]: support.md#new.handler
+[new.syn]: support.md#new.syn
+[obj.lifetime]: mem.md#obj.lifetime
 [over]: over.md#over
 [over.literal]: over.md#over.literal
 [over.match]: over.md#over.match
+[over.match.funcs]: over.md#over.match.funcs
 [over.oper]: over.md#over.oper
 [over.over]: over.md#over.over
+[ptr.align]: mem.md#ptr.align
 [ptr.launder]: support.md#ptr.launder
 [replacement.functions]: library.md#replacement.functions
 [special]: class.md#special
+[std.modules]: library.md#std.modules
+[stdfloat.syn]: support.md#stdfloat.syn
 [stmt.block]: stmt.md#stmt.block
 [stmt.dcl]: stmt.md#stmt.dcl
 [stmt.expr]: stmt.md#stmt.expr
 [stmt.if]: stmt.md#stmt.if
+[stmt.iter]: stmt.md#stmt.iter
+[stmt.pre]: stmt.md#stmt.pre
 [stmt.ranged]: stmt.md#stmt.ranged
 [stmt.return]: stmt.md#stmt.return
+[stmt.select]: stmt.md#stmt.select
 [support.dynamic]: support.md#support.dynamic
 [support.runtime]: support.md#support.runtime
 [support.start.term]: support.md#support.start.term
 [support.types]: support.md#support.types
+[temp.concept]: temp.md#temp.concept
 [temp.deduct.guide]: temp.md#temp.deduct.guide
 [temp.dep]: temp.md#temp.dep
 [temp.dep.candidate]: temp.md#temp.dep.candidate
+[temp.dep.constexpr]: temp.md#temp.dep.constexpr
+[temp.dep.type]: temp.md#temp.dep.type
 [temp.expl.spec]: temp.md#temp.expl.spec
 [temp.explicit]: temp.md#temp.explicit
+[temp.friend]: temp.md#temp.friend
 [temp.local]: temp.md#temp.local
 [temp.names]: temp.md#temp.names
 [temp.over]: temp.md#temp.over
+[temp.over.link]: temp.md#temp.over.link
 [temp.param]: temp.md#temp.param
 [temp.point]: temp.md#temp.point
 [temp.pre]: temp.md#temp.pre
 [temp.res]: temp.md#temp.res
 [temp.spec]: temp.md#temp.spec
+[temp.spec.partial]: temp.md#temp.spec.partial
 [temp.type]: temp.md#temp.type
+[term.incomplete.type]: #term.incomplete.type
+[term.odr.use]: #term.odr.use
+[term.unevaluated.operand]: expr.md#term.unevaluated.operand
 [thread]: thread.md#thread
 [thread.jthread.class]: thread.md#thread.jthread.class
 [thread.thread.class]: thread.md#thread.thread.class
 [thread.threads]: thread.md#thread.threads
 [^1]: Appearing inside the brace-enclosed *declaration-seq* in a
     *linkage-specification* does not affect whether a declaration is a
     definition.
 [^2]: An implementation is not required to call allocation and
     deallocation functions from constructors or destructors; however,
     this is a permissible implementation technique.
+[^3]: An implicit object parameter [[over.match.funcs]] is not part of
+    the parameter-type-list.
+[^4]: Lookups in which function names are ignored include names
     appearing in a *nested-name-specifier*, an
     *elaborated-type-specifier*, or a *base-specifier*.
+[^5]: Unicode® is a registered trademark of Unicode, Inc. This
+    information is given for the convenience of users of this document
+    and does not constitute an endorsement by ISO or IEC of this
+    product.
+[^6]: The number of bits in a byte is reported by the macro `CHAR_BIT`
     in the header `<climits>`.
+[^7]: Under the “as-if” rule an implementation is allowed to store two
     objects at the same machine address or not store an object at all if
     the program cannot observe the difference [[intro.execution]].
+[^8]: For example, before the dynamic initialization of an object with
+ static storage duration [[basic.start.dynamic]].
+[^9]: 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.
+[^10]: Some implementations might define that copying an invalid pointer
     value causes a system-generated runtime fault.
+[^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]: The global `operator delete(void*, std::size_t)` precludes use of
     an allocation function `void operator new(std::size_t, std::size_t)`
+    as a placement allocation function [[diff.cpp11.basic]].
+[^13]: The same rules apply to initialization of an `initializer_list`
     object [[dcl.init.list]] with its underlying temporary array.
+[^14]: By using, for example, the library functions [[headers]]
     `std::memcpy` or `std::memmove`.
+[^15]: By using, for example, the library functions [[headers]]
     `std::memcpy` or `std::memmove`.
+[^16]: The intent is that the memory model of C++ is compatible with
     that of ISO/IEC 9899 Programming Language C.
+[^17]: The size and layout of an instance of an incompletely-defined
     object type is unknown.
+[^18]: This is also known as two’s complement representation.
+[^19]: Static class members are objects or functions, and pointers to
     them are ordinary pointers to objects or functions.
+[^20]: For an object that is not within its lifetime, this is the first
     byte in memory that it will occupy or used to occupy.
+[^21]: 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.
+[^22]: As specified in  [[class.temporary]], after a full-expression is
     evaluated, a sequence of zero or more invocations of destructor
     functions for temporary objects takes place, usually in reverse
     order of the construction of each temporary object.
+[^23]: In other words, function executions do not interleave with each
     other.
+[^24]: An object with automatic or thread storage duration [[basic.stc]]
     is associated with one specific thread, and can be accessed by a
     different thread only indirectly through a pointer or reference
     [[basic.compound]].
+[^25]: A non-block variable with static storage duration having
     initialization with side effects is initialized in this case, even
+    if it is not itself odr-used [[term.odr.use]], [[basic.stc.static]].

Diff to HTML by rtfpessoa