[basic] - C++23 → Trunk

Files changed (1) hide show

tmp/tmpre5ha1pc/{from.md → to.md} +1567 -784

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

@@ -13,88 +13,105 @@ compound types from these. — *end note*]
 [*Note 2*: This Clause does not cover concepts that affect only a
 single part of the language. Such concepts are discussed in the relevant
 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 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.
 A *local entity* is a variable with automatic storage duration
 [[basic.stc.auto]], a structured binding [[dcl.struct.bind]] whose
-corresponding variable is such an entity, or the `*this` object
-[[expr.prim.this]].
-Some names denote types or templates. In general, whenever a name is
-encountered it is necessary to determine whether that name denotes one
-of these entities before continuing to parse the program that contains
-it. The process that determines this is called *name lookup*
-[[basic.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 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]],
 - use of attributes [[dcl.attr]], and
 - nothing (in the case of an *empty-declaration*).
-Each entity declared by a *declaration* is also *defined* by that
 declaration unless:
 - it declares a function without specifying the function’s body
   [[dcl.fct.def]],
 - it contains the `extern` specifier [[dcl.stc]] or a
@@ -102,28 +119,31 @@ declaration unless:
   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]],
 - it is an *alias-declaration* [[dcl.typedef]],
 - it is a *using-declaration* [[namespace.udecl]],
 - it is a *deduction-guide* [[temp.deduct.guide]],
 - it is a *static_assert-declaration* [[dcl.pre]],
 - it is an *attribute-declaration* [[dcl.pre]],
 - it is an *empty-declaration* [[dcl.pre]],
 - it is a *using-directive* [[namespace.udir]],
 - it is a *using-enum-declaration* [[enum.udecl]],
 - it is a *template-declaration* [[temp.pre]] whose *template-head* is
   not followed by either a *concept-definition* or a *declaration* that
-  defines a function, a class, a variable, or a static data member.
 - it is an explicit instantiation declaration [[temp.explicit]], or
 - it is an explicit specialization [[temp.expl.spec]] whose
   *declaration* is not a definition.
 A declaration is said to be a *definition* of each entity that it
@@ -144,11 +164,10 @@ struct X {                      // defines X
   X(): x(0) { }                 // defines a constructor of X
 };
 int X::y = 1;                   // defines X::y
 enum { up, down };              // defines up and down
 namespace N { int d; }          // defines N and N::d
-namespace N1 = N;               // defines N1
 X anX;                          // defines anX
 ```
 whereas these are just declarations:
@@ -156,17 +175,18 @@ whereas these are just declarations:
 extern int a;                   // declares a
 extern const int c;             // declares c
 int f(int);                     // declares f
 struct S;                       // declares S
 typedef int Int;                // declares Int
 extern X anotherX;              // declares anotherX
 using N::d;                     // declares d
 ```
 — *end example*]
-[*Note 1*:  In some circumstances, C++ implementations implicitly
 define the default constructor [[class.default.ctor]], copy constructor,
 move constructor [[class.copy.ctor]], copy assignment operator, move
 assignment operator [[class.copy.assign]], or destructor [[class.dtor]]
 member functions. — *end note*]
@@ -205,11 +225,11 @@ struct C {
 };
 ```
 — *end example*]
-[*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.
@@ -234,11 +254,12 @@ 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.
 - If E is a subscripting operation [[expr.sub]] with an array operand,
   the set contains the potential results of that operand.
 - If E is a class member access expression [[expr.ref]] of the form E₁
   `.` `template`ₒₚₜ  E₂ naming a non-static data member, the set
   contains the potential results of E₁.
@@ -255,24 +276,26 @@ follows:
   potential results of the right operand.
 - Otherwise, the set is empty.
 [*Note 1*:
-This set is a (possibly-empty) set of *id-expression*s, each of which is
-either E or a subexpression of E.
 [*Example 1*:
 In the following example, the set of potential results of the
 initializer of `n` contains the first `S::x` subexpression, but not the
-second `S::x` subexpression.
 ``` cpp
 struct S { static const int x = 0; };
 const int &f(const int &r);
 int n = b ? (1, S::x)           // S::x is not odr-used here
           : f(S::x);            // S::x is odr-used here, so a definition is required
 ```
 — *end example*]
 — *end note*]
@@ -281,13 +304,13 @@ 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
@@ -302,31 +325,64 @@ A function is *named by* an expression or conversion as follows:
 - 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
@@ -334,36 +390,40 @@ non-placement deallocation function for a class is odr-used by the
 definition of the destructor of that class, or by being selected by the
 lookup at the point of definition of a virtual destructor
 [[class.dtor]].[^2]
 An assignment operator function in a class is odr-used by an
-implicitly-defined copy-assignment or move-assignment function for
 another class as specified in  [[class.copy.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) {
   [] { n = 1; };                // error: n is not odr-usable due to intervening lambda-expression
   struct A {
@@ -376,19 +436,41 @@ 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*:
 ``` cpp
 auto f() {
   struct A {};
   return A{};
@@ -411,11 +493,11 @@ 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`:
 ``` cpp
@@ -427,11 +509,11 @@ X* x2;                          // use X in pointer formation
 — *end example*]
 [*Note 3*:
 The rules for declarations and expressions describe in which contexts
-complete class types are required. A class type `T` must be complete if:
 - an object of type `T` is defined [[basic.def]], or
 - a non-static class data member of type `T` is declared [[class.mem]],
   or
 - `T` is used as the allocated type or array element type in a
@@ -451,20 +533,27 @@ complete class types are required. A class type `T` must be complete if:
 - the `typeid` operator [[expr.typeid]] or the `sizeof` operator
   [[expr.sizeof]] is applied to an operand of type `T`, or
 - a function with a return type or argument type of type `T` is defined
   [[basic.def]] or called [[expr.call]], or
 - a class with a base class of type `T` is defined [[class.derived]], or
-- an lvalue of type `T` is assigned to [[expr.ass]], or
 - the type `T` is the subject of an `alignof` expression
   [[expr.alignof]], or
 - 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,
@@ -479,24 +568,25 @@ point, the following requirements shall be satisfied.
   [[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
   sequence of tokens of the corresponding *lambda-expression*.
 - In each such definition, corresponding names, looked up according to
-  [[basic.lookup]], shall refer to the same entity, after overload
   resolution [[over.match]] and after matching of partial template
- specialization [[temp.over]], except that a name can refer to
   - a non-volatile const object with internal or no linkage if the
     object
     - has the same literal type in all definitions of `D`,
     - is initialized with a constant expression [[expr.const]],
     - is not odr-used in any definition of `D`, and
     - has the same value in all definitions of `D`,
     or
   - a reference with internal or no linkage initialized with a constant
-    expression such that the reference refers to the same entity in all
-    definitions of `D`.
 - 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.
@@ -510,20 +600,26 @@ point, the following requirements shall be satisfied.
   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
   // translation unit 1:
   struct X {
     X(int, int);
     X(int, int, int);
@@ -551,31 +647,31 @@ point, the following requirements shall be satisfied.
 - If `D` is a class with a defaulted three-way comparison operator
   function [[class.spaceship]], it is as if the operator was implicitly
   defined in every translation unit where it is odr-used, and the
   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, []{});
 }
@@ -612,17 +708,17 @@ diagnostic required.
 ### 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.
@@ -630,12 +726,13 @@ Unless otherwise specified:
   [[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:
@@ -643,35 +740,36 @@ Special cases include that:
   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.
@@ -684,22 +782,26 @@ 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.
@@ -743,17 +845,34 @@ struct X {
 };
 ```
 — *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*:
@@ -769,10 +888,22 @@ 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
@@ -895,11 +1026,13 @@ variable [[dcl.fct.def.general]] is immediately before the
 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*:
@@ -911,12 +1044,15 @@ template<class T
     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
@@ -937,11 +1073,12 @@ but they do not bind names in it. — *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*
@@ -964,11 +1101,12 @@ for (int i = 0; i < 10; 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
@@ -1010,11 +1148,11 @@ A *parameter-declaration-clause* P introduces a
   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>
@@ -1081,13 +1219,13 @@ 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
@@ -1097,19 +1235,35 @@ 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
@@ -1182,18 +1336,18 @@ 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
@@ -1535,11 +1689,11 @@ name in the *unqualified-id* does not find any
 - 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
@@ -1601,26 +1755,34 @@ 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
@@ -1636,12 +1798,12 @@ set. The set of entities is determined in the following way:
 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
@@ -1710,11 +1872,11 @@ void test() {
 }
 ```
 — *end example*]
-[*Note 3*: The associated namespace can include namespaces already
 considered by ordinary unqualified lookup. — *end note*]
 [*Example 3*:
 ``` cpp
@@ -1738,14 +1900,15 @@ int main() {
 #### 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 {
@@ -1782,13 +1945,13 @@ A *qualified name* is
 - 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
@@ -2151,37 +2314,88 @@ struct Base::Data* pBase;       // OK, refers to nested Data
 In a *using-directive* or *namespace-alias-definition*, during the
 lookup for a *namespace-name* or for a name in a *nested-name-specifier*
 only namespace names are considered.
 ## Program and linkage <a id="basic.link">[[basic.link]]</a>
-A *program* consists of one or more translation units [[lex.separate]]
 linked together. A translation unit consists of a sequence of
 declarations.
 ``` bnf
 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
-  other scopes of the same translation unit.
-- When a name has *module linkage*, the entity it denotes can be
-  referred to by names from other scopes of the same module unit
-  [[module.unit]] or from scopes of other module units of that same
-  module.
-- 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
@@ -2193,18 +2407,18 @@ The name of an entity that belongs to a namespace scope
   - 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
@@ -2217,12 +2431,21 @@ name of
   purposes [[dcl.enum]]; or
 - a template
 has its linkage determined as follows:
-- if the enclosing namespace has internal linkage, the name has internal
- 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.
@@ -2263,26 +2486,29 @@ 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.
@@ -2329,11 +2555,11 @@ For any two declarations of an entity E:
 - 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
@@ -2357,22 +2583,27 @@ 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
@@ -2389,38 +2620,46 @@ A declaration is an *exposure* if it either names a TU-local entity
   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
   - does not have a name with linkage and is declared, or introduced by
     a *lambda-expression*, within the definition of a TU-local entity,
 - a type with no name that is defined outside a *class-specifier*,
   function body, or *initializer* or is introduced by a
   *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.
 If a (possibly instantiated) declaration of, or a deduction guide for, a
 non-TU-local entity in a module interface unit (outside the
 *private-module-fragment*, if any) or module partition [[module.unit]]
 is an exposure, the program is ill-formed. Such a declaration in any
@@ -2463,10 +2702,20 @@ namespace N {
   static void adl(int);
 }
 void adl(double);
 inline void h(auto x) { adl(x); }   // OK, but certain specializations are exposures
 ```
 Translation unit #2
 ``` cpp
@@ -2489,27 +2738,23 @@ void other() {
 ### 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*]
@@ -2580,21 +2825,21 @@ 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
 object is created in storage associated with a member subobject or array
 element *e* (which may or may not be within its lifetime), the created
-object is a subobject of *e*’s containing object if:
 - the lifetime of *e*’s containing object has begun and not ended, and
 - the storage for the new object exactly overlays the storage location
   associated with *e*, and
 - the new object is of the same type as *e* (ignoring cv-qualification).
 If a complete object is created [[expr.new]] in storage associated with
 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 array object that satisfies these constraints nested
   within *e*.
@@ -2604,10 +2849,12 @@ another object, the lifetime of that object ends because its storage was
 reused [[basic.life]]. — *end note*]
 [*Example 1*:
 ``` cpp
 template<typename ...T>
 struct AlignedUnion {
   alignas(T...) unsigned char data[max(sizeof(T)...)];
 };
 int f() {
@@ -2618,20 +2865,20 @@ int f() {
   return *c + *d;                       // OK
 }
 struct A { unsigned char a[32]; };
 struct B { unsigned char b[16]; };
-A a;
 B *b = new (a.a + 8) B;                 // a.a provides storage for *b
 int *p = new (b->b + 4) int;            // b->b provides storage for *p
                                         // a.a does not provide storage for *p (directly),
                                         // but *p is nested within a (see below)
 ```
 — *end example*]
-An object *a* is *nested within* another object *b* if:
 - *a* is a subobject of *b*, or
 - *b* provides storage for *a*, or
 - there exists an object *c* where *a* is nested within *c*, and *c* is
   nested within *b*.
@@ -2672,23 +2919,45 @@ the circumstances under which the object has zero size are
 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';
 static const char test2 = 'x';
 const bool b = &test1 != &test2;        // always true
 ```
 — *end example*]
 The address of a non-bit-field subobject of zero size is the address of
@@ -2697,16 +2966,16 @@ 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.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*]
@@ -2739,32 +3008,123 @@ X *make_x() {
 }
 ```
 — *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]],
@@ -2779,10 +3139,29 @@ except as described in [[allocator.members]]. The lifetime of an object
 - 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 lifetime of a reference begins when its initialization is complete.
 The lifetime of a reference ends as if it were a scalar object requiring
 storage.
 [*Note 1*:  [[class.base.init]] describes the lifetime of base and
@@ -2811,22 +3190,22 @@ 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
@@ -2836,11 +3215,11 @@ The program has undefined behavior if:
   cv `void`, or to pointer to cv `void` and subsequently to pointer to
   cv `char`, cv `unsigned char`, or cv `std::byte` [[cstddef.syn]], or
 - the pointer is used as the operand of a `dynamic_cast`
   [[expr.dynamic.cast]].
-[*Example 1*:
 ``` cpp
 #include <cstdlib>
 struct B {
@@ -2869,36 +3248,32 @@ void g() {
 ```
 — *end example*]
 Similarly, before the lifetime of an object has started but after the
-storage which the object will occupy has been allocated or, after the
 lifetime of an object has ended and before the storage which the object
 occupied is reused or released, any glvalue that refers to the original
 object may be used but only in limited ways. For an object under
 construction or destruction, see  [[class.cdtor]]. Otherwise, such a
 glvalue refers to allocated storage [[basic.stc.dynamic.allocation]],
 and using the properties of the glvalue that do not depend on its value
-is well-defined. The program has undefined behavior if:
 - the glvalue is used to access the object, or
 - the glvalue is used to call a non-static member function of the
   object, or
 - the glvalue is bound to a reference to a virtual base class
   [[dcl.init.ref]], or
 - the glvalue is used as the operand of a `dynamic_cast`
   [[expr.dynamic.cast]] or as the operand of `typeid`.
-If, after the lifetime of an object has ended and before the storage
-which the object occupied is reused or released, a new object is created
-at the storage location which the original object occupied, a pointer
-that pointed to the original object, a reference that referred to the
-original object, or the name of the original object will automatically
-refer to the new object and, once the lifetime of the new object has
-started, can be used to manipulate the new object, if the original
-object is transparently replaceable (see below) by the new object. An
-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
@@ -2907,11 +3282,20 @@ object o₁ is *transparently replaceable* by an object o₂ if:
   [[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₂.
-[*Example 2*:
 ``` cpp
 struct C {
   int i;
   void f();
@@ -2933,25 +3317,25 @@ c1 = c2;                        // well-defined
 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 { };
 struct B {
   ~B();
@@ -2968,11 +3352,11 @@ void h() {
 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*:
 ``` cpp
 struct B {
   B();
   ~B();
@@ -2986,67 +3370,114 @@ void h() {
 }
 ```
 — *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>
 When storage for an object with automatic or dynamic storage duration is
-obtained, the object has an *indeterminate value*, and if no
-initialization is performed for the object, that object retains an
-indeterminate value until that value is replaced [[expr.ass]].
-[*Note 1*: Objects with static or thread storage duration are
 zero-initialized, see  [[basic.start.static]]. — *end note*]
-If an indeterminate value is produced by an evaluation, the behavior is
-undefined except in the following cases:
-- If an indeterminate value of unsigned ordinary character type
-  [[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
-  `std::byte` type is produced by the evaluation of the right operand of
- a simple assignment operator [[expr.ass]] whose first operand is an
- lvalue of unsigned ordinary character type or `std::byte` type, an
- indeterminate value replaces the value of the object referred to by
- the left operand.
-- If an indeterminate value of unsigned ordinary character type is
- produced by the evaluation of the initialization expression when
-  initializing an object of unsigned ordinary character type, that
- object is initialized to an indeterminate value.
 - If an indeterminate value of unsigned ordinary character type or
   `std::byte` type is produced by the evaluation of the initialization
   expression when initializing an object of `std::byte` type, that
-  object is initialized to an indeterminate value.
 [*Example 1*:
 ``` cpp
 int f(bool b) {
-  unsigned char c;
-  unsigned char d = c; // OK, d has an indeterminate value
   int e = d;                    // undefined behavior
   return b ? d : 0;             // undefined behavior if b is true
 }
 ```
 — *end example*]
 ### Storage duration <a id="basic.stc">[[basic.stc]]</a>
@@ -3061,24 +3492,24 @@ object and is one of the following:
 - static storage duration
 - thread storage duration
 - automatic storage duration
 - dynamic storage duration
 Static, thread, and automatic storage durations are associated with
-objects introduced by declarations [[basic.def]] and implicitly created
-by the implementation [[class.temporary]]. The dynamic storage duration
-is associated with objects created by a *new-expression* [[expr.new]].
 The storage duration categories apply to references as well.
-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.[^10]
 #### Static storage duration <a id="basic.stc.static">[[basic.stc.static]]</a>
 All variables which
@@ -3115,18 +3546,22 @@ 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>
-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
 destructor with side effects, an implementation shall not destroy it
 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]].
@@ -3147,29 +3582,25 @@ global *deallocation functions* `operator delete` and
 [[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*) 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;
-[[nodiscard]] void* operator new[](std::size_t);
-[[nodiscard]] void* operator new[](std::size_t, std::align_val_t);
 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;
@@ -3224,11 +3655,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.[^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:
@@ -3243,12 +3674,12 @@ call shall represent the address of storage that is aligned as follows:
 An allocation function that fails to allocate storage can invoke the
 currently installed new-handler function [[new.handler]], if any.
 [*Note 3*:  A program-supplied allocation function can obtain the
-address of the currently installed `new_handler` using the
-`std::get_new_handler` function [[get.new.handler]]. — *end note*]
 An allocation function that has a non-throwing exception specification
 [[except.spec]] indicates failure by returning a null pointer value. Any
 other allocation function never returns a null pointer value and
 indicates failure only by throwing an exception [[except.throw]] of a
@@ -3263,11 +3694,13 @@ calls to the functions in the C++ standard library.
 [*Note 4*: In particular, a global allocation function is not called to
 allocate storage for objects with static storage duration
 [[basic.stc.static]], for objects or references with thread storage
 duration [[basic.stc.thread]], for objects of type `std::type_info`
-[[expr.typeid]], or for an exception object
 [[except.throw]]. — *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
@@ -3287,11 +3720,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`,[^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
@@ -3308,129 +3741,41 @@ 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.
-#### 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*:
-``` cpp
-struct B { long double d; };
-struct D : virtual B { char c; };
-```
-When `D` is the type of a complete object, it will have a subobject of
-type `B`, so it must be aligned appropriately for a `long double`. If
-`D` appears as a subobject of another object that also has `B` as a
-virtual base class, the `B` subobject might be part of a different
-subobject, reducing the alignment requirements on the `D` subobject.
-— *end example*]
-The result of the `alignof` operator reflects the alignment requirement
-of the type in the complete-object case.
-An *extended alignment* is represented by an alignment greater than
-`alignof(std::max_align_t)`. It is *implementation-defined* whether any
-extended alignments are supported and the contexts in which they are
-supported [[dcl.align]]. A type having an extended alignment requirement
-is an *over-aligned type*.
-[*Note 1*: Every over-aligned type is or contains a class type to which
-extended alignment applies (possibly through a non-static data
-member). — *end note*]
-A *new-extended alignment* is represented by an alignment greater than
-`__STDCPP_DEFAULT_NEW_ALIGNMENT__` [[cpp.predefined]].
-Alignments are represented as values of the type `std::size_t`. Valid
-alignments include only those values returned by an `alignof` expression
-for the fundamental types plus an additional *implementation-defined*
-set of values, which may be empty. Every alignment value shall be a
-non-negative integral power of two.
-Alignments have an order from *weaker* to *stronger* or *stricter*
-alignments. Stricter alignments have larger alignment values. An address
-that satisfies an alignment requirement also satisfies any weaker valid
-alignment requirement.
-The alignment requirement of a complete type can be queried using an
-`alignof` expression [[expr.alignof]]. Furthermore, the narrow character
-types [[basic.fundamental]] shall have the weakest alignment
-requirement.
-[*Note 2*: This enables the ordinary character types to be used as the
-underlying type for an aligned memory area [[dcl.align]]. — *end note*]
-Comparing alignments is meaningful and provides the obvious results:
-- Two alignments are equal when their numeric values are equal.
-- Two alignments are different when their numeric values are not equal.
-- 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
@@ -3478,49 +3823,56 @@ result is constructed directly in `c`. On the other hand, the expression
 materialized so that the reference parameter of `X::operator=(const X&)`
 can bind to it.
 — *end example*]
-When an object of class type `X` is passed to or returned from a
-function, if `X` has at least one eligible copy or move constructor
-[[special]], each such constructor is trivial, and the destructor of `X`
-is either trivial or deleted, implementations are permitted to create a
-temporary object to hold the function parameter or result object. The
-temporary object is constructed from the function argument or return
-value, respectively, and the function’s parameter or return object is
-initialized as if by using the eligible trivial constructor to copy the
-temporary (even if that constructor is inaccessible or would not be
-selected by overload resolution to perform a copy or move of the
-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 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:
@@ -3562,11 +3914,11 @@ int&& c = cond ? id<int[3]>{1, 2, 3}[i] : static_cast<int&&>(0);
                                             // exactly one of the two temporaries is lifetime-extended
 ```
 — *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*:
@@ -3577,11 +3929,11 @@ const int& x = (const int&)1;   // temporary for value 1 has same lifetime as x
 — *end example*]
 — *end note*]
-[*Note 6*:
 If a temporary object has a reference member initialized by another
 temporary object, lifetime extension applies recursively to such a
 member’s initializer.
@@ -3605,43 +3957,52 @@ The exceptions to this lifetime rule are:
   containing the call.
 - A temporary object bound to a reference element of an aggregate of
   class type initialized from a parenthesized *expression-list*
   [[dcl.init]] persists until the completion of the full-expression
   containing the *expression-list*.
-- The lifetime of a temporary bound to the returned value in a function
-  `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
@@ -3693,11 +4054,11 @@ 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*:
@@ -3713,11 +4074,11 @@ std::memcpy(&obj, buf, N);      // at this point, each subobject of obj of scala
 — *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*:
@@ -3730,23 +4091,31 @@ std::memcpy(t1p, t2p, sizeof(T));
     // the same value as the corresponding subobject in *t2p
 ```
 — *end example*]
-The *object representation* of an object of type `T` is the sequence of
-*N* `unsigned char` objects taken up by the object of type `T`, where
-*N* equals `sizeof(T)`. The *value representation* of an object of type
-`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
@@ -3804,34 +4173,36 @@ 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`.
 Arithmetic types [[basic.fundamental]], enumeration types, pointer
-types, pointer-to-member types [[basic.compound]], `std::nullptr_t`, and
-cv-qualified [[basic.type.qualifier]] versions of these types are
-collectively called *scalar types*. Scalar types, trivially copyable
-class types [[class.prop]], arrays of such types, and cv-qualified
-versions of these types are collectively called *trivially copyable
-types*. Scalar types, trivial class types [[class.prop]], arrays of such
-types and cv-qualified versions of these types are collectively called
-*trivial types*. Scalar types, standard-layout class types
-[[class.prop]], arrays of such types and cv-qualified versions of these
-types are collectively called *standard-layout types*. Scalar types,
-implicit-lifetime class types [[class.prop]], array types, and
-cv-qualified versions of these types are collectively called
-*implicit-lifetime types*.
 A type is a *literal type* if it is:
 - cv `void`; or
 - a scalar type; or
 - 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,
@@ -3851,20 +4222,30 @@ 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>
 There are five *standard signed integer types*: “`signed char`”,
 “`short int`”, “`int`”, “`long int`”, and “`long long int`”. In this
 list, each type provides at least as much storage as those preceding it
 in the list. There may also be *implementation-defined* *extended signed
 integer types*. The standard and extended signed integer types are
 collectively called *signed integer types*. The range of representable
-values for a signed integer type is -2ᴺ⁻¹ to 2ᴺ⁻¹-1 (inclusive), where
-*N* is called the *width* of the type.
 [*Note 1*: Plain `int`s are intended to have the natural width
 suggested by the architecture of the execution environment; the other
 signed integer types are provided to meet special needs. — *end note*]
@@ -3886,11 +4267,11 @@ 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.[^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*]
@@ -3903,22 +4284,22 @@ type. — *end example*]
 | `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*]
 [*Note 4*: The signed and unsigned integer types satisfy the
-constraints given in ISO C 5.2.4.2.1. — *end note*]
 Except as specified above, the width of a signed or unsigned integer
 type is *implementation-defined*.
 Each value x of an unsigned integer type with width N has a unique
@@ -3956,12 +4337,12 @@ than the width of that type has padding bits; see
 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>`.
 Type `bool` is a distinct type that has the same object representation,
 value representation, and alignment requirements as an
 *implementation-defined* unsigned integer type. The values of type
 `bool` are `true` and `false`.
@@ -4001,128 +4382,233 @@ 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]];
 - *functions*, which have parameters of given types and return `void` or
- references or objects of a given type, [[dcl.fct]];
 - *pointers* to cv `void` or objects or functions (including static
   members of classes) of a given type, [[dcl.ptr]];
 - *references* to objects or functions of a given type, [[dcl.ref]].
   There are two types of references:
   - lvalue reference
   - rvalue reference
-- *classes* containing a sequence of objects of various types [[class]],
-  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;
@@ -4146,46 +4632,59 @@ to as a “pointer to `T`”.
 “pointer to `X`”. — *end example*]
 Except for pointers to static members, text referring to “pointers” does
 not apply to pointers to members. Pointers to incomplete types are
 allowed although there are restrictions on what can be done with them
-[[basic.align]]. Every value of pointer type is one of the following:
 - a *pointer to* an object or function (the pointer is said to *point*
   to the object or function), or
 - a *pointer past the end of* an object [[expr.add]], or
 - 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*]
-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
@@ -4197,11 +4696,11 @@ Two objects *a* and *b* are *pointer-interconvertible* if:
 If two objects are pointer-interconvertible, then they have the same
 address, and it is possible to obtain a pointer to one from a pointer to
 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 byte of storage *b* is *reachable through* a pointer value that points
 to an object *x* if there is an object *y*, pointer-interconvertible
@@ -4218,11 +4717,11 @@ alignment requirements as an object of type “pointer to cv `char`”.
 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.
@@ -4330,11 +4829,11 @@ 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
@@ -4342,11 +4841,19 @@ as follows:
 - 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*]
@@ -4429,16 +4936,18 @@ or *initializer* E are
 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,
 - an invocation of a destructor generated at the end of the lifetime of
   an object other than a temporary object [[class.temporary]] whose
-  lifetime has not been extended, or
 - an expression that is not a subexpression of another expression and
   that is not otherwise part of a full-expression.
 If a language construct is defined to produce an implicit call of a
 function, a use of the language construct is considered to be an
@@ -4465,11 +4974,11 @@ S s1(1);                        // full-expression comprises call of S::S(int)
 void f() {
   S s2 = 2;                     // full-expression comprises call of S::S(int)
   if (S(3).v())                 // full-expression includes lvalue-to-rvalue and int to bool conversions,
                                 // performed before temporary is deleted at end of full-expression
   { }
-  bool b = noexcept(S()); // exception specification of destructor of S considered for noexcept
   // full-expression is destruction of s2 at end of block
 }
 struct B {
   B(S = S(0));
@@ -4486,19 +4995,20 @@ full-expression. For example, subexpressions involved in evaluating
 default arguments [[dcl.fct.default]] are considered to be created in
 the expression that calls the function, not the expression that defines
 the default argument. — *end note*]
 Reading an object designated by a `volatile` glvalue [[basic.lval]],
-modifying an object, calling a library I/O function, or calling a
-function that does any of those operations are all *side effects*, which
-are changes in the state of the execution environment. *Evaluation* of
-an expression (or a subexpression) in general includes both value
 computations (including determining the identity of an object for
 glvalue evaluation and fetching a value previously assigned to an object
 for prvalue evaluation) and initiation of side effects. When a call to a
 library I/O function returns or an access through a volatile glvalue is
-evaluated the side effect is considered complete, even though some
 external actions implied by the call (such as the I/O itself) or by the
 `volatile` access may not have completed yet.
 *Sequenced before* is an asymmetric, transitive, pair-wise relation
 between evaluations executed by a single thread [[intro.multithread]],
@@ -4523,29 +5033,43 @@ 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
 execution of a program, unsequenced and indeterminately sequenced
 evaluations of its subexpressions need not be performed consistently in
 different evaluations. — *end note*]
 The value computations of the operands of an operator are sequenced
-before the value computation of the result of the operator. If a side
-effect on a memory location [[intro.memory]] is unsequenced relative to
-either another side effect on the same memory location or a value
-computation using the value of any object in the same memory location,
-and they are not potentially concurrent [[intro.multithread]], the
-behavior is undefined.
-[*Note 6*: The next subclause imposes similar, but more complex
 restrictions on potentially concurrent computations. — *end note*]
 [*Example 3*:
 ``` cpp
@@ -4553,24 +5077,35 @@ void g(int i) {
   i = 7, i++, i++;              // i becomes 9
   i = i++ + 1;                  // the value of i is incremented
   i = i++ + i;                  // undefined behavior
   i = i + 1;                    // the value of i is incremented
 }
 ```
 — *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*.
@@ -4589,14 +5124,19 @@ 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
@@ -4606,12 +5146,12 @@ 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.
@@ -4639,27 +5179,37 @@ below.
 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
-location [[intro.memory]] and the other one reads or modifies the same
-memory location.
 The library defines a number of atomic operations [[atomics]] and
 operations on mutexes [[thread]] that are specially identified as
 synchronization operations. These operations play a special role in
 making assignments in one thread visible to another. A synchronization
-operation on one or more memory locations is either a consume operation,
-an acquire operation, a release operation, or both an acquire and
-release operation. A synchronization operation without an associated
-memory location is a fence and can be either an acquire fence, a release
-fence, or both an acquire and release fence. In addition, there are
-relaxed atomic operations, which are not synchronization operations, and
-atomic read-modify-write operations, which have special characteristics.
-[*Note 2*: For example, a call that acquires a mutex will perform an
 acquire operation on the locations comprising the mutex.
 Correspondingly, a call that releases the same mutex will perform a
 release operation on those same locations. Informally, performing a
 release operation on A forces prior side effects on other memory
 locations to become visible to other threads that later perform a
@@ -4668,11 +5218,11 @@ not synchronization operations even though, like synchronization
 operations, they cannot contribute to data races. — *end note*]
 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
 can observe modifications to different objects in inconsistent
 orders. — *end note*]
@@ -4684,181 +5234,107 @@ subsequent operation is an atomic read-modify-write operation.
 Certain library calls *synchronize with* other library calls performed
 by another thread. For example, an atomic store-release synchronizes
 with a load-acquire that takes its value from the store
 [[atomics.order]].
-[*Note 4*: Except in the specified cases, reading a later value does
 not necessarily ensure visibility as described below. Such a requirement
 would sometimes interfere with efficient implementation. — *end note*]
-[*Note 5*: The specifications of the synchronization operations define
 when one reads the value written by another. For atomic objects, the
 definition is clear. All operations on a given mutex occur in a single
 total order. Each mutex acquisition “reads the value written” by the
 last mutex release. — *end note*]
-An evaluation A *carries a dependency* to an evaluation B if
-- the value of A is used as an operand of B, unless:
-  - B is an invocation of any specialization of `std::kill_dependency`
-    [[atomics.order]], or
-  - A is the left operand of a built-in logical (`&&`, see
-    [[expr.log.and]]) or logical (`||`, see  [[expr.log.or]]) operator,
-    or
-  - A is the left operand of a conditional (`?:`, see  [[expr.cond]])
-    operator, or
-  - A is the left operand of the built-in comma (`,`) operator
-    [[expr.comma]];
-  or
-- A writes a scalar object or bit-field M, B reads the value written by
-  A from M, and A is sequenced before B, or
-- for some evaluation X, A carries a dependency to X, and X carries a
-  dependency to B.
-[*Note 6*: “Carries a dependency to” is a subset of “is sequenced
-before”, and is similarly strictly intra-thread. — *end note*]
-An evaluation A is *dependency-ordered before* an evaluation B if
-- A performs a release operation on an atomic object M, and, in another
-  thread, B performs a consume operation on M and reads the value
-  written by A, or
-- for some evaluation X, A is dependency-ordered before X and X carries
-  a dependency to B.
-[*Note 7*: The relation “is dependency-ordered before” is analogous to
-“synchronizes with”, but uses release/consume in place of
-release/acquire. — *end note*]
-An evaluation A *inter-thread happens before* an evaluation B if
-- A synchronizes with B, or
-- A is dependency-ordered before B, or
-- for some evaluation X
-  - A synchronizes with X and X is sequenced before B, or
-  - A is sequenced before X and X inter-thread happens before B, or
-  - A inter-thread happens before X and X inter-thread happens before B.
-[*Note 8*: The “inter-thread happens before” relation describes
-arbitrary concatenations of “sequenced before”, “synchronizes with” and
-“dependency-ordered before” relationships, with two exceptions. The
-first exception is that a concatenation is not permitted to end with
-“dependency-ordered before” followed by “sequenced before”. The reason
-for this limitation is that a consume operation participating in a
-“dependency-ordered before” relationship provides ordering only with
-respect to operations to which this consume operation actually carries a
-dependency. The reason that this limitation applies only to the end of
-such a concatenation is that any subsequent release operation will
-provide the required ordering for a prior consume operation. The second
-exception is that a concatenation is not permitted to consist entirely
-of “sequenced before”. The reasons for this limitation are (1) to permit
-“inter-thread happens before” to be transitively closed and (2) the
-“happens before” relation, defined below, provides for relationships
-consisting entirely of “sequenced before”. — *end note*]
 An evaluation A *happens before* an evaluation B (or, equivalently, B
-*happens after* A) if:
-- A is sequenced before B, or
-- A inter-thread happens before B.
-The implementation shall ensure that no program execution demonstrates a
-cycle in the “happens before” relation.
-[*Note 9*: This cycle would otherwise be possible only through the use
-of consume operations. — *end note*]
-An evaluation A *simply happens before* an evaluation B if either
 - A is sequenced before B, or
 - A synchronizes with B, or
-- A simply happens before X and X simply happens before B.
-[*Note 10*: In the absence of consume operations, the happens before
-and simply happens before relations are identical. — *end note*]
 An evaluation A *strongly happens before* an evaluation D if, either
 - A is sequenced before D, or
 - A synchronizes with D, and both A and D are sequentially consistent
   atomic operations [[atomics.order]], or
 - there are evaluations B and C such that A is sequenced before B, B
- simply happens before C, and C is sequenced before D, or
 - there is an evaluation B such that A strongly happens before B, and B
   strongly happens before D.
-[*Note 11*: Informally, if A strongly happens before B, then A appears
-to be evaluated before B in all contexts. Strongly happens before
-excludes consume operations. — *end note*]
 A *visible side effect* A on a scalar object or bit-field M with respect
 to a value computation B of M satisfies the conditions:
 - A happens before B and
 - there is no other side effect X to M such that A happens before X and
   X happens before B.
 The value of a non-atomic scalar object or bit-field M, as determined by
-evaluation B, shall be the value stored by the visible side effect A.
-[*Note 12*: If there is ambiguity about which side effect to a
 non-atomic object or bit-field is visible, then the behavior is either
 unspecified or undefined. — *end note*]
-[*Note 13*: This states that operations on ordinary objects are not
 visibly reordered. This is not actually detectable without data races,
-but it is necessary to ensure that data races, as defined below, and
-with suitable restrictions on the use of atomics, correspond to data
-races in a simple interleaved (sequentially consistent)
-execution. — *end note*]
-The value of an atomic object M, as determined by evaluation B, shall be
-the value stored by some side effect A that modifies M, where B does not
-happen before A.
-[*Note 14*: The set of such side effects is also restricted by the rest
 of the rules described here, and in particular, by the coherence
 requirements below. — *end note*]
 If an operation A that modifies an atomic object M happens before an
-operation B that modifies M, then A shall be earlier than B in the
 modification order of M.
-[*Note 15*: This requirement is known as write-write
 coherence. — *end note*]
 If a value computation A of an atomic object M happens before a value
 computation B of M, and A takes its value from a side effect X on M,
-then the value computed by B shall either be the value stored by X or
-the value stored by a side effect Y on M, where Y follows X in the
 modification order of M.
-[*Note 16*: This requirement is known as read-read
 coherence. — *end note*]
 If a value computation A of an atomic object M happens before an
-operation B that modifies M, then A shall take its value from a side
-effect X on M, where X precedes B in the modification order of M.
-[*Note 17*: This requirement is known as read-write
 coherence. — *end note*]
 If a side effect X on an atomic object M happens before a value
-computation B of M, then the evaluation B shall take its value from X or
-from a side effect Y that follows X in the modification order of M.
-[*Note 18*: This requirement is known as write-read
 coherence. — *end note*]
-[*Note 19*: The four preceding coherence requirements effectively
 disallow compiler reordering of atomic operations to a single object,
 even if both operations are relaxed loads. This effectively makes the
 cache coherence guarantee provided by most hardware available to C++
 atomic operations. — *end note*]
-[*Note 20*: The value observed by a load of an atomic depends on the
 “happens before” relation, which depends on the values observed by loads
 of atomics. The intended reading is that there must exist an association
 of atomic loads with modifications they observe that, together with
 suitably chosen modification orders and the “happens before” relation
 derived as described above, satisfy the resulting constraints as imposed
@@ -4874,67 +5350,71 @@ The execution of a program contains a *data race* if it contains two
 potentially concurrent conflicting actions, at least one of which is not
 atomic, and neither happens before the other, except for the special
 case for signal handlers described below. Any such data race results in
 undefined behavior.
-[*Note 21*: It can be shown that programs that correctly use mutexes
 and `memory_order::seq_cst` operations to prevent all data races and use
 no other synchronization operations behave as if the operations executed
 by their constituent threads were simply interleaved, with each value
 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 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
-divided into two groups A and B, such that no evaluations in B happen
-before evaluations in A, and the evaluations of such
-`volatile std::sig_atomic_t` objects take values as though all
-evaluations in A happened before the execution of the signal handler and
-the execution of the signal handler happened before all evaluations in
-B.
-[*Note 22*: Compiler transformations that introduce assignments to a
 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 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*]
 #### Forward progress <a id="intro.progress">[[intro.progress]]</a>
 The implementation may assume that any thread will eventually do one of
 the following:
 - terminate,
 - make a call to a library I/O function,
-- perform an access through a volatile glvalue, or
-- perform a synchronization operation or an atomic operation.
 [*Note 1*: This is intended to allow compiler transformations such as
-removal of empty loops, even when termination cannot be
-proven. — *end note*]
 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*.
@@ -4958,13 +5438,14 @@ Executions of atomic functions that are either defined to be lock-free
 During the execution of a thread of execution, each of the following is
 termed an *execution step*:
 - termination of the thread of execution,
-- performing an access through a volatile glvalue, or
-- completion of a call to a library I/O function, a synchronization
-  operation, or an atomic operation.
 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.
@@ -4986,12 +5467,12 @@ 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 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
@@ -5104,24 +5585,24 @@ function parameter is called `argv`, where `argc` shall be the number of
 arguments passed to the program from the environment in which the
 program is run. If `argc` is nonzero these arguments shall be supplied
 in `argv[0]` through `argv[argc - 1]` as pointers to the initial
 characters of null-terminated multibyte strings (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.
 *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
@@ -5137,29 +5618,29 @@ 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
-effect is equivalent to a `return` with operand `0` (see also
-[[except.handle]]).
 #### Static initialization <a id="basic.start.static">[[basic.start.static]]</a>
 Variables with static storage duration are initialized as a consequence
 of program initiation. Variables with thread storage duration are
 initialized as a consequence of thread execution. Within each of these
 phases of initiation, initialization occurs as follows.
-*Constant initialization* is performed if a variable or temporary object
-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
@@ -5252,11 +5733,11 @@ 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
@@ -5392,21 +5873,298 @@ 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
@@ -5423,21 +6181,24 @@ functions passed to `std::atexit()` or `std::at_quick_exit()`.
 [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.start.term]: #basic.start.term
@@ -5446,11 +6207,10 @@ functions passed to `std::atexit()` or `std::at_quick_exit()`.
 [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
@@ -5468,17 +6228,17 @@ functions passed to `std::atexit()` or `std::at_quick_exit()`.
 [class.copy.assign]: class.md#class.copy.assign
 [class.copy.ctor]: class.md#class.copy.ctor
 [class.copy.elision]: class.md#class.copy.elision
 [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
@@ -5494,34 +6254,42 @@ functions passed to `std::atexit()` or `std::at_quick_exit()`.
 [conv.integral]: expr.md#conv.integral
 [conv.lval]: expr.md#conv.lval
 [conv.mem]: expr.md#conv.mem
 [conv.prom]: expr.md#conv.prom
 [conv.ptr]: expr.md#conv.ptr
 [conv.rank]: #conv.rank
 [conv.rval]: expr.md#conv.rval
 [cpp.predefined]: cpp.md#cpp.predefined
 [cstddef.syn]: support.md#cstddef.syn
 [cstring.syn]: strings.md#cstring.syn
 [dcl.align]: dcl.md#dcl.align
 [dcl.array]: dcl.md#dcl.array
 [dcl.attr]: dcl.md#dcl.attr
 [dcl.attr.nouniqueaddr]: dcl.md#dcl.attr.nouniqueaddr
 [dcl.constexpr]: dcl.md#dcl.constexpr
-[dcl.dcl]: dcl.md#dcl.dcl
 [dcl.decl]: dcl.md#dcl.decl
 [dcl.enum]: dcl.md#dcl.enum
 [dcl.fct]: dcl.md#dcl.fct
 [dcl.fct.def]: dcl.md#dcl.fct.def
 [dcl.fct.def.coroutine]: dcl.md#dcl.fct.def.coroutine
 [dcl.fct.def.general]: dcl.md#dcl.fct.def.general
 [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.ptr]: dcl.md#dcl.ptr
 [dcl.ref]: dcl.md#dcl.ref
@@ -5530,10 +6298,11 @@ functions passed to `std::atexit()` or `std::at_quick_exit()`.
 [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
@@ -5543,11 +6312,11 @@ functions passed to `std::atexit()` or `std::at_quick_exit()`.
 [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
@@ -5555,57 +6324,67 @@ functions passed to `std::atexit()` or `std::at_quick_exit()`.
 [expr.const.cast]: expr.md#expr.const.cast
 [expr.context]: expr.md#expr.context
 [expr.delete]: expr.md#expr.delete
 [expr.dynamic.cast]: expr.md#expr.dynamic.cast
 [expr.eq]: expr.md#expr.eq
-[expr.log.and]: expr.md#expr.log.and
-[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
 [expr.ref]: expr.md#expr.ref
 [expr.reinterpret.cast]: expr.md#expr.reinterpret.cast
 [expr.rel]: expr.md#expr.rel
 [expr.sizeof]: expr.md#expr.sizeof
 [expr.static.cast]: expr.md#expr.static.cast
 [expr.sub]: expr.md#expr.sub
 [expr.type.conv]: expr.md#expr.type.conv
 [expr.typeid]: expr.md#expr.typeid
 [expr.unary.op]: expr.md#expr.unary.op
 [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
@@ -5616,32 +6395,37 @@ functions passed to `std::atexit()` or `std::at_quick_exit()`.
 [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
@@ -5652,17 +6436,21 @@ functions passed to `std::atexit()` or `std::at_quick_exit()`.
 [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.
@@ -5676,81 +6464,76 @@ functions passed to `std::atexit()` or `std::at_quick_exit()`.
 [^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]].

 [*Note 2*: This Clause does not cover concepts that affect only a
 single part of the language. Such concepts are discussed in the relevant
 Clauses. — *end note*]
+A *name* is an *identifier* [[lex.name]], *conversion-function-id*
+[[class.conv.fct]], *operator-function-id* [[over.oper]], or
+*literal-operator-id* [[over.literal]].
+Two names are *the same* if
+- they are *identifier*s composed of the same character sequence, or
+- they are *conversion-function-id*s formed with equivalent
+  [[temp.over.link]] types, or
+- they are *operator-function-id*s formed with the same operator, or
+- they are *literal-operator-id*s formed with the same literal suffix
+  identifier.
 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]],
+- *identifier* in a *result-name-introducer* in a postcondition
+  assertion [[dcl.contract.res]],
 - *init-capture* [[expr.prim.lambda.capture]],
 - *condition* with a *declarator* [[stmt.pre]],
 - *member-declarator* [[class.mem]],
 - *using-declarator* [[namespace.udecl]],
+- *parameter-declaration* [[dcl.fct]], [[temp.param]],
 - *type-parameter* [[temp.param]],
+- *type-tt-parameter* [[temp.param]],
+- *variable-tt-parameter* [[temp.param]],
+- *concept-tt-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 term declaration is not a synonym for the grammar
+non-terminal *declaration* [[dcl.pre]]. — *end note*]
+[*Note 4*: The interpretation of a *for-range-declaration* produces one
 or more of the above [[stmt.ranged]]. — *end note*]
+[*Note 5*: Some names denote types or templates. In general, whenever a
+name is encountered it is necessary to look it up [[basic.lookup]] to
+determine whether that name denotes one of these entities before
+continuing to parse the program that contains it. — *end note*]
+A *variable* is introduced by the declaration of
+- a reference other than a non-static data member or
+- an object.
+An *entity* is a variable, structured binding, result binding, function,
+enumerator, type, type alias, non-static data member, bit-field,
+template, namespace, namespace alias, template parameter, function
+parameter, or *init-capture*. The *underlying entity* of an entity is
+that entity unless otherwise specified. A name *denotes* the underlying
+entity of the entity declared by each declaration that introduces the
+name.
+[*Note 6*: Type aliases and namespace aliases have underlying entities
+that are distinct from themselves. — *end note*]
 A *local entity* is a variable with automatic storage duration
 [[basic.stc.auto]], a structured binding [[dcl.struct.bind]] whose
+corresponding variable is such an entity, a result binding
+[[dcl.contract.res]], or the `*this` object [[expr.prim.this]].
 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 [[basic.pre]] 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 X is a redeclaration of X if another declaration of X is
+reachable from it [[module.reach]]; otherwise, it is a
+*first declaration*.
+[*Note 1*:
+A declaration can also have effects including:
 - a static assertion [[dcl.pre]],
 - controlling template instantiation [[temp.explicit]],
 - guiding template argument deduction for constructors
   [[temp.deduct.guide]],
 - use of attributes [[dcl.attr]], and
 - nothing (in the case of an *empty-declaration*).
+— *end note*]
+Each entity declared by a declaration is also *defined* by that
 declaration unless:
 - it declares a function without specifying the function’s body
   [[dcl.fct.def]],
 - it contains the `extern` specifier [[dcl.stc]] or a
   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
+ [[class.static.data]] (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]],
 - it is an *alias-declaration* [[dcl.typedef]],
+- it is a *namespace-alias-definition* [[namespace.alias]],
 - it is a *using-declaration* [[namespace.udecl]],
 - it is a *deduction-guide* [[temp.deduct.guide]],
 - it is a *static_assert-declaration* [[dcl.pre]],
+- it is a *consteval-block-declaration*,
 - it is an *attribute-declaration* [[dcl.pre]],
 - it is an *empty-declaration* [[dcl.pre]],
 - it is a *using-directive* [[namespace.udir]],
 - it is a *using-enum-declaration* [[enum.udecl]],
 - it is a *template-declaration* [[temp.pre]] whose *template-head* is
   not followed by either a *concept-definition* or a *declaration* that
+  defines a function, a class, a variable, or a static data member,
 - it is an explicit instantiation declaration [[temp.explicit]], or
 - it is an explicit specialization [[temp.expl.spec]] whose
   *declaration* is not a definition.
 A declaration is said to be a *definition* of each entity that it
   X(): x(0) { }                 // defines a constructor of X
 };
 int X::y = 1;                   // defines X::y
 enum { up, down };              // defines up and down
 namespace N { int d; }          // defines N and N::d
 X anX;                          // defines anX
 ```
 whereas these are just declarations:
 extern int a;                   // declares a
 extern const int c;             // declares c
 int f(int);                     // declares f
 struct S;                       // declares S
 typedef int Int;                // declares Int
+namespace N1 = N;               // declares N1
 extern X anotherX;              // declares anotherX
 using N::d;                     // declares d
 ```
 — *end example*]
+[*Note 2*:  In some circumstances, C++ implementations implicitly
 define the default constructor [[class.default.ctor]], copy constructor,
 move constructor [[class.copy.ctor]], copy assignment operator, move
 assignment operator [[class.copy.assign]], or destructor [[class.dtor]]
 member functions. — *end note*]
 };
 ```
 — *end example*]
+[*Note 3*: 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.
 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]] or a *splice-expression*
+  [[expr.prim.splice]], the set contains only E.
 - If E is a subscripting operation [[expr.sub]] with an array operand,
   the set contains the potential results of that operand.
 - If E is a class member access expression [[expr.ref]] of the form E₁
   `.` `template`ₒₚₜ  E₂ naming a non-static data member, the set
   contains the potential results of E₁.
   potential results of the right operand.
 - Otherwise, the set is empty.
 [*Note 1*:
+This set is a (possibly-empty) set of *id-expression*s and
+*splice-expression*s, each of which is either E or a subexpression of E.
 [*Example 1*:
 In the following example, the set of potential results of the
 initializer of `n` contains the first `S::x` subexpression, but not the
+second `S::x` subexpression. The set of potential results of the
+initializer of `o` contains the subexpression `[:^^ S::x:]`.
 ``` cpp
 struct S { static const int x = 0; };
 const int &f(const int &r);
 int n = b ? (1, S::x)           // S::x is not odr-used here
           : f(S::x);            // S::x is odr-used here, so a definition is required
+int o = [:^^S::x:];
 ```
 — *end example*]
 — *end note*]
 - 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,
+ and either it is not a pure virtual function or the expression is an
+  *id-expression* naming the function with an explicitly qualified name
+ that does not form 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
 - 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* or *splice-expression* [[expr.prim.splice]] that
+designates it. A variable `x` that is named by a potentially-evaluated
+expression N that appears at a point P is *odr-used* by N unless
+- `x` is a reference that is usable in constant expressions at P
+  [[expr.const]] or
+- N is an element of the set of potential results of an expression E,
+ where
+ - E is a discarded-value expression [[expr.context]] to which the
+ lvalue-to-rvalue conversion is not applied or
+ - `x` is a non-volatile object that is usable in constant expressions
+    at P and has no mutable subobjects and
+    - E is a class member access expression [[expr.ref]] naming a
+      non-static data member of reference type and whose object
+      expression has non-volatile-qualified type or
+    - the lvalue-to-rvalue conversion [[conv.lval]] is applied to E and
+      E has non-volatile-qualified non-class type
+[*Example 2*:
+``` cpp
+int f(int);
+int g(int&);
+struct A {
+  int x;
+};
+struct B {
+  int& r;
+};
+int h(bool cond) {
+  constexpr A a = {1};
+  constexpr const volatile A& r = a;    // odr-uses a
+  int _ = f(cond ? a.x : r.x);          // does not odr-use a or r
+  int x, y;
+  constexpr B b1 = {x}, b2 = {y};       // odr-uses x and y
+  int _ = g(cond ? b1.r : b2.r);        // does not odr-use b1 or b2
+  int _ = ((cond ? x : y), 0);          // does not odr-use x or y
+  return [] {
+    return b1.r;                        // error: b1 is odr-used here because the object
+                                        // referred to by b1.r is not constexpr-referenceable here
+  }();
+}
+```
+— *end example*]
+A structured binding is named by an expression if that expression is
+either an *id-expression* or a *splice-expression* that designates that
+structured binding. A structured binding is odr-used if it is named by a
 potentially-evaluated expression.
 `*this` is odr-used if `this` appears as a potentially-evaluated
+expression (including as the result of any implicit transformation to a
+class member access expression [[expr.prim.id.general]]).
 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
 definition of the destructor of that class, or by being selected by the
 lookup at the point of definition of a virtual destructor
 [[class.dtor]].[^2]
 An assignment operator function in a class is odr-used by an
+implicitly-defined copy assignment or move assignment function for
 another class as specified in  [[class.copy.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,
+  - the intervening scope is a contract-assertion scope
+    [[basic.scope.contract]],
   - the intervening scope is the function parameter scope of a
+    *lambda-expression* or *requires-expression*, or
+  - the intervening scope is the lambda 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 3*:
 ``` cpp
 void f(int n) {
   [] { n = 1; };                // error: n is not odr-usable due to intervening lambda-expression
   struct A {
 }
 ```
 — *end example*]
+[*Example 4*:
+``` cpp
+void g() {
+  constexpr int x = 1;
+  auto lambda = [] <typename T, int = ((T)x, 0)> {};    // OK
+  lambda.operator()<int, 1>();          // OK, does not consider x at all
+  lambda.operator()<int>();             // OK, does not odr-use x
+  lambda.operator()<const int&>();      // error: odr-uses x from a context where x is not odr-usable
+}
+void h() {
+  constexpr int x = 1;
+  auto lambda = [] <typename T> { (T)x; };      // OK
+  lambda.operator()<int>();             // OK, does not odr-use x
+  lambda.operator()<void>();            // OK, does not odr-use x
+  lambda.operator()<const int&>();      // error: odr-uses x from a context where x is not odr-usable
+}
+```
+— *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 5*:
 ``` cpp
 auto f() {
   struct A {};
   return 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 6*:
 The following complete translation unit is well-formed, even though it
 never defines `X`:
 ``` cpp
 — *end example*]
 [*Note 3*:
 The rules for declarations and expressions describe in which contexts
+complete class types are required. A class type `T` must be complete if
 - an object of type `T` is defined [[basic.def]], or
 - a non-static class data member of type `T` is declared [[class.mem]],
   or
 - `T` is used as the allocated type or array element type in a
 - the `typeid` operator [[expr.typeid]] or the `sizeof` operator
   [[expr.sizeof]] is applied to an operand of type `T`, or
 - a function with a return type or argument type of type `T` is defined
   [[basic.def]] or called [[expr.call]], or
 - a class with a base class of type `T` is defined [[class.derived]], or
+- an lvalue of type `T` is assigned to [[expr.assign]], or
 - the type `T` is the subject of an `alignof` expression
   [[expr.alignof]], or
 - an *exception-declaration* has type `T`, reference to `T`, or pointer
   to `T` [[except.handle]].
 — *end note*]
+If a definable item `D` is defined in a translation unit by an injected
+declaration X [[expr.const]] and another translation unit contains a
+definition of `D`, that definition shall be an injected declaration
+having the same characteristic sequence as X; a diagnostic is required
+only if `D` is attached to a named module and a prior definition is
+reachable at the point where a later definition occurs.
+For any other 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,
   [[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
   sequence of tokens of the corresponding *lambda-expression*.
 - In each such definition, corresponding names, looked up according to
+  [[basic.lookup]], shall denote the same entity, after overload
   resolution [[over.match]] and after matching of partial template
+ specializations [[temp.spec.partial.match]], except that a name can
+  refer to
   - a non-volatile const object with internal or no linkage if the
     object
     - has the same literal type in all definitions of `D`,
     - is initialized with a constant expression [[expr.const]],
     - is not odr-used in any definition of `D`, and
     - has the same value in all definitions of `D`,
     or
   - a reference with internal or no linkage initialized with a constant
+    expression such that the reference refers to the same object or
+ function in all definitions of `D`.
 - 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.
   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*, *simple-template-id*, or
+ *splice-specialization-specifier* 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).
+- In each such definition, corresponding *reflect-expression*s
+  [[expr.reflect]] compute equivalent values [[expr.eq]].
+For the purposes of the preceding requirements:
 - 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 7*:
   ``` cpp
   // translation unit 1:
   struct X {
     X(int, int);
     X(int, int, int);
 - If `D` is a class with a defaulted three-way comparison operator
   function [[class.spaceship]], it is as if the operator was implicitly
   defined in every translation unit where it is odr-used, and the
   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,
+  the requirements 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 8*:
 ``` cpp
 inline void f(bool cond, void (*p)()) {
   if (cond) f(false, []{});
 }
 ### 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*, *handler*, or contract
+assertion (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.
   [[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.
+The *host scope* of a declaration is the inhabited scope if that scope
+is a block scope and the target scope otherwise. 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:
   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 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 or function declarations target a larger enclosing
+ scope but bind a name in their immediate scope
+  [[dcl.meaning.general]].
 - 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 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 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 type alias) 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 and they do not declare
+  corresponding overloads.
+Two function or function template declarations declare *corresponding
+overloads* if
 - 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.
 };
 ```
 — *end example*]
+A declaration is *name-independent* if its name is `_`
+(U+005f (low line)) and it declares
+- a variable with automatic storage duration,
+- a structured binding with no *storage-class-specifier* and not
+  inhabiting a namespace scope,
+- a result binding [[dcl.contract.res]],
+- the variable introduced by an *init-capture*, or
+- a non-static data member of other than an anonymous union.
+*Recommended practice:* Implementations should not emit a warning that a
+name-independent declaration is used or unused.
 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 A and B that potentially conflict and A precedes B
+[[basic.lookup]], unless B is name-independent.
+[*Note 3*: An *id-expression* that names a unique name-independent
+declaration is usable until an additional declaration of the same name
+is introduced in the same scope [[basic.lookup.general]]. — *end note*]
+[*Note 4*: 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*:
 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
+void g() {
+  int _;
+  _ = 0;                // OK
+  int _;                // OK, name-independent declaration
+  _ = 0;                // error: two non-function declarations in the lookup set
+}
+void h () {
+  int _;                // #1
+  _ ++;                 // OK
+  static int _;         // error: conflicts with #1 because static variables are not name-independent
+}
 ```
 — *end example*]
 A declaration is *nominable* in a class, class template, or namespace E
 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 *for-range-declaration* of an *expansion-statement*
+[[stmt.expand]] is immediately after the *expansion-initializer*.
 The locus of a *template-parameter* is immediately after it.
 [*Example 5*:
     N = 0> struct A { };
 ```
 — *end example*]
+The locus of a *result-name-introducer* [[dcl.contract.res]] is
+immediately after it.
 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
 ### Block scope <a id="basic.scope.block">[[basic.scope.block]]</a>
 Each
+- selection, iteration, or expansion statement
+  [[stmt.select]], [[stmt.iter]], [[stmt.expand]],
 - substatement of such a statement,
 - *handler* [[except.pre]], or
 - compound statement [[stmt.block]] that is not the *compound-statement*
   of a *handler*
 int j = i;          // j = 42
 ```
 — *end example*]
+If a declaration that is not a name-independent declaration and that
+binds a name in 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
   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>
 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 *type-tt-parameter*, *variable-tt-parameter*, and
+*concept-tt-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
 [*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*]
+### Contract-assertion scope <a id="basic.scope.contract">[[basic.scope.contract]]</a>
+Each contract assertion [[basic.contract]] C introduces a
+*contract-assertion scope* that includes C.
+If a *result-name-introducer* [[dcl.contract.res]] that is not
+name-independent [[basic.scope.scope]] and whose enclosing postcondition
+assertion is associated with a function `F` potentially conflicts with a
+declaration whose target scope is
+- the function parameter scope of `F` or
+- if associated with a *lambda-declarator*, the nearest enclosing lambda
+  scope of the precondition assertion [[expr.prim.lambda]],
+the program is ill-formed.
 ## Name lookup <a id="basic.lookup">[[basic.lookup]]</a>
 ### General <a id="basic.lookup.general">[[basic.lookup.general]]</a>
+*Name lookup* associates the use of a name with a set of declarations
+[[basic.def]] of that name. 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.
 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
 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 type alias 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 type alias and of its underlying entity are found,
+the declaration of the type alias 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
 - 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 type template template
 arguments, the namespace of the template argument), as specified below.
 [*Example 1*:
 ``` cpp
 — *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 type
 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 `std::meta::info` [[meta.syn]], its associated set of
+  entities is the singleton containing the enumeration type
+  `std::meta::operators` [[meta.reflection.operators]]. \[*Note 2*: The
+  `std::meta::info` type is a type alias, so an explicit rule is needed
+  to associate calls whose arguments are reflections with the namespace
+  `std::meta`. — *end note*]
+- If `T` is any other 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,
+ if it is a complete type, 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 type template template arguments; and the classes of
+ which any member templates used as type template template arguments
+ are members. \[*Note 3*: Constant template arguments, variable
+ template template arguments, and concept 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
 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 arguments and those associated with its
+type template arguments.
 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
 }
 ```
 — *end example*]
+[*Note 4*: The associated namespace can include namespaces already
 considered by ordinary unqualified lookup. — *end note*]
 [*Example 3*:
 ``` cpp
 #### 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*, *splice-scope-specifier*, or
+*computed-type-specifier* is followed by a `::`, it shall either be a
+dependent *splice-scope-specifier* [[temp.dep.splice]] or 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 {
 - the terminal name of
   - a *qualified-id*,
   - a *using-declarator*,
   - a *typename-specifier*,
   - a *qualified-namespace-specifier*, or
+  - a *nested-name-specifier*, *reflection-name*,
+    *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
 In a *using-directive* or *namespace-alias-definition*, during the
 lookup for a *namespace-name* or for a name in a *nested-name-specifier*
 only namespace names are considered.
+## Splice specifiers <a id="basic.splice">[[basic.splice]]</a>
+``` bnf
+splice-specifier:
+  '[:' constant-expression ':]'
+```
+``` bnf
+splice-specialization-specifier:
+  splice-specifier '<' template-argument-listₒₚₜ '>'
+```
+The *constant-expression* of a *splice-specifier* shall be a converted
+constant expression of type `std::meta::info` [[expr.const]]. A
+*splice-specifier* whose converted *constant-expression* represents a
+construct X is said to *designate* either
+- the underlying entity of X if X is an entity [[basic.pre]], or
+- X otherwise.
+[*Note 1*: A *splice-specifier* is dependent if the converted
+*constant-expression* is value-dependent
+[[temp.dep.splice]]. — *end note*]
+A non-dependent *splice-specifier* of a
+*splice-specialization-specifier* shall designate a template.
+[*Note 2*:
+A `<` following a *splice-specifier* is interpreted as the delimiter of
+a *template-argument-list* when the *splice-specifier* is preceded by
+the keyword `template` or the keyword `typename`, or when it appears in
+a type-only context [[temp.names]].
+[*Example 1*:
+``` cpp
+constexpr int v = 1;
+template<int V> struct TCls {
+  static constexpr int s = V + 1;
+};
+using alias = [:^^TCls:]<([:^^v:])>;
+  // OK, a splice-specialization-specifier with a parenthesized splice-expression as a template argument
+static_assert(alias::s == 2);
+auto o1 = [:^^TCls:]<([:^^v:])>();              // error: < means less than
+auto o2 = typename [:^^TCls:]<([:^^v:])>();     // OK, o2 is an object of type TCls<1>
+consteval int bad_splice(std::meta::info v) {
+  return [:v:];                                 // error: v is not constant
+}
+```
+— *end example*]
+— *end note*]
 ## Program and linkage <a id="basic.link">[[basic.link]]</a>
+A *program* consists of one or more translation units [[lex.phases]]
 linked together. A translation unit consists of a sequence of
 declarations.
 ``` bnf
 translation-unit:
     declaration-seqₒₚₜ
     global-module-fragmentₒₚₜ module-declaration declaration-seqₒₚₜ private-module-fragmentₒₚₜ
 ```
+A name has *external linkage*, *module linkage*, *internal linkage*, or
+*no linkage*, as determined by the rules below.
+[*Note 1*: All declarations of an entity with a name with internal
+linkage appear in the same translation unit. All declarations of an
+entity with module linkage are attached to the same
+module. — *end note*]
 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
   - 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 2*: 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
   purposes [[dcl.enum]]; or
 - a template
 has its linkage determined as follows:
+- if the entity is a function or function template first declared in a
+ friend declaration and that declaration is a definition and the
+  enclosing class is defined within an *export-declaration*, the name
+  has the same linkage, if any, as the name of the enclosing class
+  [[class.friend]];
+- otherwise, if the entity is a function or function template declared
+  in a friend declaration and a corresponding non-friend declaration is
+  reachable, the name has the linkage determined from that prior
+  declaration,
+- otherwise, if the enclosing namespace has internal linkage, the name
+  has internal 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.
 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, neither is a name-independent declaration,
+and either
 - they appear in the same translation unit, or
+- they both declare type aliases or namespace aliases that have the same
+  underlying entity, or
 - they both declare names with module linkage and are attached to the
   same module, or
 - they both declare names with external linkage.
+[*Note 3*: 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 4*: 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.
 - 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 5*: 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
 namespace h {}          // error: same entity as #2, but not a function
 ```
 — *end example*]
+[*Note 6*: 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,
+- D contains a *reflect-expression* or a *splice-specifier* that,
+  respectively, represents or designates E,
+- D is an injected declaration [[expr.const]] whose characteristic
+  sequence contains a reflection that represents a data member
+  description (T, N, A, W, NUA) [[class.mem.general]] for which T 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 7*: 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
   not an odr-use [[term.odr.use]],
 or defines a constexpr variable initialized to a TU-local value (defined
 below).
+[*Note 8*: 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, type alias, namespace, namespace alias, function, variable, or
+  template that
   - has a name with internal linkage, or
   - does not have a name with linkage and is declared, or introduced by
     a *lambda-expression*, within the definition of a TU-local entity,
 - a type with no name that is defined outside a *class-specifier*,
   function body, or *initializer* or is introduced by a
   *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 9*: A specialization can be
   produced by implicit or explicit instantiation. — *end note*]
 A value or object is *TU-local* if either
+- it is of TU-local type,
 - 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, or
+- it is a reflection value [[basic.fundamental]] that represents
+  - an entity, value, or object that is TU-local,
+  - a direct base class relationship (D, B) [[class.derived.general]]
+    for which either D or B is TU-local, or
+  - a data member description (T, N, A, W, NUA) [[class.mem.general]]
+    for which T is TU-local.
 If a (possibly instantiated) declaration of, or a deduction guide for, a
 non-TU-local entity in a module interface unit (outside the
 *private-module-fragment*, if any) or module partition [[module.unit]]
 is an exposure, the program is ill-formed. Such a declaration in any
   static void adl(int);
 }
 void adl(double);
 inline void h(auto x) { adl(x); }   // OK, but certain specializations are exposures
+constexpr std::meta::info r1 = ^^g<0>;  // OK
+namespace N2 {
+  static constexpr std::meta::info r2 = ^^g<1>;     // OK, r2 is TU-local
+}
+constexpr std::meta::info r3 = ^^f;                 // error: r3 is an exposure of f
+constexpr auto ctx = std::meta::access_context::current();
+constexpr std::meta::info r4 =
+  std::meta::members_of(^^N2, ctx)[0];              // error: r4 is an exposure of N2::r2
 ```
 Translation unit #2
 ``` cpp
 ### 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 UTF-8 encoding form and is
+composed of a contiguous sequence of bits,[^5]
+the number of which is *implementation-defined*. 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 the storage occupied by the object representation
+of 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*]
 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
 object is created in storage associated with a member subobject or array
 element *e* (which may or may not be within its lifetime), the created
+object is a subobject of *e*’s containing object if
 - the lifetime of *e*’s containing object has begun and not ended, and
 - the storage for the new object exactly overlays the storage location
   associated with *e*, and
 - the new object is of the same type as *e* (ignoring cv-qualification).
 If a complete object is created [[expr.new]] in storage associated with
 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 array object that satisfies these constraints nested
   within *e*.
 reused [[basic.life]]. — *end note*]
 [*Example 1*:
 ``` cpp
+// assumes that sizeof(int) is equal to 4
 template<typename ...T>
 struct AlignedUnion {
   alignas(T...) unsigned char data[max(sizeof(T)...)];
 };
 int f() {
   return *c + *d;                       // OK
 }
 struct A { unsigned char a[32]; };
 struct B { unsigned char b[16]; };
+alignas(int) A a;
 B *b = new (a.a + 8) B;                 // a.a provides storage for *b
 int *p = new (b->b + 4) int;            // b->b provides storage for *p
                                         // a.a does not provide storage for *p (directly),
                                         // but *p is nested within a (see below)
 ```
 — *end example*]
+An object *a* is *nested within* another object *b* if
 - *a* is a subobject of *b*, or
 - *b* provides storage for *a*, or
 - there exists an object *c* where *a* is nested within *c*, and *c* is
   nested within *b*.
 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.
+An object is a *potentially non-unique object* if it is
+- a string literal object [[lex.string]],
+- the backing array of an initializer list [[dcl.init.ref]], or
+- the object introduced by a call to `std::meta::reflect_constant_array`
+  or `std::meta::reflect_constant_string` [[meta.define.static]], or
+- a subobject thereof.
 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,
+- at least one is a subobject of zero size and they are not of similar
+  types [[conv.qual]], or
+- they are both potentially non-unique objects;
+otherwise, they have distinct addresses and occupy disjoint bytes of
+storage.[^6]
 [*Example 2*:
 ``` cpp
 static const char test1 = 'x';
 static const char test2 = 'x';
 const bool b = &test1 != &test2;        // always true
+static const char (&r) [] = "x";
+static const char *s = "x";
+static std::initializer_list<char> il = { 'x' };
+const bool b2 = r != il.begin();        // unspecified result
+const bool b3 = r != s;                 // unspecified result
+const bool b4 = il.begin() != &test1;   // always true
+const bool b5 = r != &test1;            // always true
 ```
 — *end example*]
 The address of a non-bit-field subobject of zero size is the address of
 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
+[[term.implicit.lifetime.type]] 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*]
 }
 ```
 — *end example*]
+Except during constant evaluation, 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*]
+Except during constant evaluation, 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]], [[c.malloc]], [[mem.res.public]], [[bit.cast]], [[cstring.syn]]. — *end note*]
+### 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]]. Attempting to create an object
+[[intro.object]] in storage that does not meet the alignment
+requirements of the object’s type is undefined behavior.
+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*:
+``` cpp
+struct B { long double d; };
+struct D : virtual B { char c; };
+```
+When `D` is the type of a complete object, it will have a subobject of
+type `B`, so it must be aligned appropriately for a `long double`. If
+`D` appears as a subobject of another object that also has `B` as a
+virtual base class, the `B` subobject might be part of a different
+subobject, reducing the alignment requirements on the `D` subobject.
+— *end example*]
+The result of the `alignof` operator reflects the alignment requirement
+of the type in the complete-object case.
+An *extended alignment* is represented by an alignment greater than
+`alignof(std::max_align_t)`. It is *implementation-defined* whether any
+extended alignments are supported and the contexts in which they are
+supported [[dcl.align]]. A type having an extended alignment requirement
+is an *over-aligned type*.
+[*Note 1*: Every over-aligned type is or contains a class type to which
+extended alignment applies (possibly through a non-static data
+member). — *end note*]
+A *new-extended alignment* is represented by an alignment greater than
+`__STDCPP_DEFAULT_NEW_ALIGNMENT__` [[cpp.predefined]].
+Alignments are represented as values of the type `std::size_t`. Valid
+alignments include only those values returned by an `alignof` expression
+for the fundamental types plus an additional *implementation-defined*
+set of values, which may be empty. Every alignment value shall be a
+non-negative integral power of two.
+Alignments have an order from *weaker* to *stronger* or *stricter*
+alignments. Stricter alignments have larger alignment values. An address
+that satisfies an alignment requirement also satisfies any weaker valid
+alignment requirement.
+The alignment requirement of a complete type can be queried using an
+`alignof` expression [[expr.alignof]]. Furthermore, the narrow character
+types [[basic.fundamental]] shall have the weakest alignment
+requirement.
+[*Note 2*: This enables the ordinary character types to be used as the
+underlying type for an aligned memory area [[dcl.align]]. — *end note*]
+Comparing alignments is meaningful and provides the obvious results:
+- Two alignments are equal when their numeric values are equal.
+- Two alignments are different when their numeric values are not equal.
+- 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.
 ### Lifetime <a id="basic.life">[[basic.life]]</a>
+In this subclause, “before” and “after” refer to the “happens before”
+relation [[intro.multithread]].
 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, no other initialization is performed, and,
+if it is of class type or a (possibly multidimensional) array thereof, a
+trivial constructor of that class type is selected for the
+default-initialization. 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]],
 - 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]].
+When evaluating a *new-expression*, storage is considered reused after
+it is returned from the allocation function, but before the evaluation
+of the *new-initializer* [[expr.new]].
+[*Example 1*:
+``` cpp
+struct S {
+  int m;
+};
+void f() {
+  S x{1};
+  new(&x) S(x.m);   // undefined behavior
+}
+```
+— *end example*]
 The lifetime of a reference begins when its initialization is complete.
 The lifetime of a reference ends as if it were a scalar object requiring
 storage.
 [*Note 1*:  [[class.base.init]] describes the lifetime of base and
 [*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[^7]
+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
   cv `void`, or to pointer to cv `void` and subsequently to pointer to
   cv `char`, cv `unsigned char`, or cv `std::byte` [[cstddef.syn]], or
 - the pointer is used as the operand of a `dynamic_cast`
   [[expr.dynamic.cast]].
+[*Example 2*:
 ``` cpp
 #include <cstdlib>
 struct B {
 ```
 — *end example*]
 Similarly, before the lifetime of an object has started but after the
+storage which the object will occupy has been allocated or after the
 lifetime of an object has ended and before the storage which the object
 occupied is reused or released, any glvalue that refers to the original
 object may be used but only in limited ways. For an object under
 construction or destruction, see  [[class.cdtor]]. Otherwise, such a
 glvalue refers to allocated storage [[basic.stc.dynamic.allocation]],
 and using the properties of the glvalue that do not depend on its value
+is well-defined. The program has undefined behavior if
 - the glvalue is used to access the object, or
 - the glvalue is used to call a non-static member function of the
   object, or
 - the glvalue is bound to a reference to a virtual base class
   [[dcl.init.ref]], or
 - the glvalue is used as the operand of a `dynamic_cast`
   [[expr.dynamic.cast]] or as the operand of `typeid`.
+[*Note 5*: Therefore, undefined behavior results if an object that is
+being constructed in one thread is referenced from another thread
+without adequate synchronization. — *end note*]
+An 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
   [[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₂.
+After the lifetime of an object has ended and before the storage which
+the object occupied is reused or released, if a new object is created at
+the storage location which the original object occupied and the original
+object was transparently replaceable by the new object, a pointer that
+pointed to the original object, a reference that referred to the
+original object, or the name of the original object will automatically
+refer to the new object and, once the lifetime of the new object has
+started, can be used to manipulate the new object.
+[*Example 3*:
 ``` cpp
 struct C {
   int i;
   void f();
 c1.f();                         // well-defined; c1 refers to a new object of type C
 ```
 — *end example*]
+[*Note 6*: 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,[^8]
 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 4*:
 ``` cpp
 class T { };
 struct B {
   ~B();
 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 5*:
 ``` cpp
 struct B {
   B();
   ~B();
 }
 ```
 — *end example*]
+### Indeterminate and erroneous values <a id="basic.indet">[[basic.indet]]</a>
 When storage for an object with automatic or dynamic storage duration is
+obtained, the bytes comprising the storage for the object have the
+following initial value:
+- If the object has dynamic storage duration, or is the object
+  associated with a variable or function parameter whose first
+  declaration is marked with the `[[indeterminate]]` attribute
+  [[dcl.attr.indet]], the bytes have *indeterminate values*;
+- otherwise, the bytes have *erroneous values*, where each value is
+  determined by the implementation independently of the state of the
+  program.
+If no initialization is performed for an object (including subobjects),
+such a byte retains its initial value until that value is replaced
+[[dcl.init.general]], [[expr.assign]]. If any bit in the value
+representation has an indeterminate value, the object has an
+indeterminate value; otherwise, if any bit in the value representation
+has an erroneous value, the object has an erroneous value.
+[*Note 1*: Lvalue-to-rvalue conversion has undefined behavior if the
+erroneous value of an object is not valid for its type
+[[conv.lval]]. — *end note*]
+[*Note 2*: Objects with static or thread storage duration are
 zero-initialized, see  [[basic.start.static]]. — *end note*]
+Except in the following cases, if an indeterminate value is produced by
+an evaluation, the behavior is undefined, and if an erroneous value is
+produced by an evaluation, the behavior is erroneous and the result of
+the evaluation is the value so produced but is not erroneous:
+- If an indeterminate or erroneous value of unsigned ordinary character
+ type [[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 or that
+  erroneous value, respectively.
+- If an indeterminate or erroneous value of unsigned ordinary character
+ type or `std::byte` type is produced by the evaluation of the right
+ operand of a simple assignment operator [[expr.assign]] whose first
+ operand is an lvalue of unsigned ordinary character type or
+ `std::byte` type, an indeterminate value or that erroneous value,
+  respectively, replaces the value of the object referred to by the left
+ operand.
+- If an indeterminate or erroneous value of unsigned ordinary character
+ type is produced by the evaluation of the initialization expression
+  when initializing an object of unsigned ordinary character type, that
+  object is initialized to an indeterminate value or that erroneous
+  value, respectively.
 - If an indeterminate value of unsigned ordinary character type or
   `std::byte` type is produced by the evaluation of the initialization
   expression when initializing an object of `std::byte` type, that
+  object is initialized to an indeterminate value or that erroneous
+  value, respectively.
+Converting an indeterminate or erroneous value of unsigned ordinary
+character type or `std::byte` type produces an indeterminate or
+erroneous value, respectively. In the latter case, the result of the
+conversion is the value of the converted operand.
 [*Example 1*:
 ``` cpp
 int f(bool b) {
+  unsigned char *c = new unsigned char;
+  unsigned char d = *c; // OK, d has an indeterminate value
   int e = d;                    // undefined behavior
   return b ? d : 0;             // undefined behavior if b is true
 }
+int g(bool b) {
+  unsigned char c;
+  unsigned char d = c;          // no erroneous behavior, but d has an erroneous value
+  assert(c == d);               // holds, both integral promotions have erroneous behavior
+  int e = d;                    // erroneous behavior
+  return b ? d : 0;             // erroneous behavior if b is true
+}
+void h() {
+  int d1, d2;
+  int e1 = d1;                  // erroneous behavior
+  int e2 = d1;                  // erroneous behavior
+  assert(e1 == e2);             // holds
+  assert(e1 == d1);             // holds, erroneous behavior
+  assert(e2 == d1);             // holds, erroneous behavior
+  std::memcpy(&d2, &d1, sizeof(int));   // no erroneous behavior, but d2 has an erroneous value
+  assert(e1 == d2);             // holds, erroneous behavior
+  assert(e2 == d2);             // holds, erroneous behavior
+}
 ```
 — *end example*]
 ### Storage duration <a id="basic.stc">[[basic.stc]]</a>
 - static storage duration
 - thread storage duration
 - automatic storage duration
 - dynamic storage duration
+[*Note 1*: After the duration of a region of storage has ended, the use
+of pointers to that region of storage is limited
+[[basic.compound]]. — *end note*]
 Static, thread, and automatic storage durations are associated with
+objects introduced by declarations [[basic.def]] and with temporary
+objects [[class.temporary]]. The dynamic storage duration is associated
+with objects created by a *new-expression* [[expr.new]] or with
+implicitly created objects [[intro.object]].
 The storage duration categories apply to references as well.
+The storage duration of subobjects and reference members is that of
+their complete object [[intro.object]].
 #### Static storage duration <a id="basic.stc.static">[[basic.stc.static]]</a>
 All variables which
 [[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 scope and are not explicitly declared
+`static`, `thread_local`, or `extern` have *automatic storage duration*.
+The storage for such variables 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*]
+Variables that belong to a parameter scope also have automatic storage
+duration. The storage for a function parameter lasts until immediately
+after its destruction [[expr.call]].
 If a variable with automatic storage duration has initialization or a
 destructor with side effects, an implementation shall not destroy it
 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]].
 [[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 [[term.replaceable.function]]. The following
+allocation and deallocation functions [[support.dynamic]] are implicitly
+declared in global scope in each translation unit of a program.
 ``` cpp
+void* operator new(std::size_t);
+void* operator new(std::size_t, std::align_val_t);
 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;
+void* operator new[](std::size_t);
+void* operator new[](std::size_t, std::align_val_t);
 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;
 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.[^9]
 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:
 An allocation function that fails to allocate storage can invoke the
 currently installed new-handler function [[new.handler]], if any.
 [*Note 3*:  A program-supplied allocation function can obtain the
+currently installed `new_handler` using the `std::get_new_handler`
+function [[get.new.handler]]. — *end note*]
 An allocation function that has a non-throwing exception specification
 [[except.spec]] indicates failure by returning a null pointer value. Any
 other allocation function never returns a null pointer value and
 indicates failure only by throwing an exception [[except.throw]] of a
 [*Note 4*: In particular, a global allocation function is not called to
 allocate storage for objects with static storage duration
 [[basic.stc.static]], for objects or references with thread storage
 duration [[basic.stc.thread]], for objects of type `std::type_info`
+[[expr.typeid]], for an object of type
+`std::contracts::contract_violation` when a contract violation occurs
+[[basic.contract.eval]], 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
 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`,[^10] 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.
 ### Temporary objects <a id="class.temporary">[[class.temporary]]</a>
+A *temporary object* is an object created
+- when a prvalue is converted to an xvalue [[conv.rval]] and
 - when needed by the implementation to pass or return an object of
+ suitable type (see below).
 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 1*: 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 2*:
 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 certain member accesses on a class prvalue
   [[expr.ref]], [[expr.mptr.oper]],
+- when invoking an implicit object member function on a class prvalue
+  [[expr.call]],
 - 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
 materialized so that the reference parameter of `X::operator=(const X&)`
 can bind to it.
 — *end example*]
+When an object of type `X` is passed to or returned from a
+potentially-evaluated function call, if `X` is
+- a scalar type or
+- a class type that has at least one eligible copy or move constructor
+  [[special]], where each such constructor is trivial, and the
+  destructor of `X` is either trivial or deleted,
+implementations are permitted to create temporary objects to hold the
+function parameter or result object, as follows:
+- The first such temporary object is constructed from the function
+  argument or return value, respectively.
+- Each successive temporary object is initialized from the previous one
+  as if by direct-initialization if `X` is a scalar type, otherwise by
+  using an eligible trivial constructor.
+- The function parameter or return object is initialized from the final
+  temporary as if by direct-initialization if `X` is a scalar type,
+  otherwise by using an eligible trivial constructor.
+(In all cases, the eligible constructor is used even if that constructor
+is inaccessible or would not be selected by overload resolution to
+perform a copy or move of the object).
+[*Note 3*: This latitude is granted to allow objects to be passed to or
+returned from functions in registers. — *end note*]
+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.
+Temporary objects are destroyed at a different point than the end of the
+full-expression in the following contexts: 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.[^11]
 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:
                                             // exactly one of the two temporaries is lifetime-extended
 ```
 — *end example*]
+[*Note 4*:
 An explicit type conversion [[expr.type.conv]], [[expr.cast]] is
 interpreted as a sequence of elementary casts, covered above.
 [*Example 3*:
 — *end example*]
 — *end note*]
+[*Note 5*:
 If a temporary object has a reference member initialized by another
 temporary object, lifetime extension applies recursively to such a
 member’s initializer.
   containing the call.
 - A temporary object bound to a reference element of an aggregate of
   class type initialized from a parenthesized *expression-list*
   [[dcl.init]] persists until the completion of the full-expression
   containing the *expression-list*.
 - 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 6*: 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 is created in the
+*for-range-initializer* of either a range-based `for` statement or an
+enumerating expansion statement [[stmt.expand]]. 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 fifth context is when a temporary object is created in the
+*expansion-initializer* of an iterating or destructuring expansion
+statement. If such a temporary object would otherwise be destroyed at
+the end of that *expansion-initializer*, the object persists for the
+lifetime of the reference initialized by the *expansion-initializer*, if
+any.
+The sixth context is when a temporary object is created in a structured
+binding declaration [[dcl.struct.bind]]. Any temporary objects
+introduced by the *initializer*s for the variables with unique names are
+destroyed at the end of the structured binding declaration.
+Let `x` and `y` each be either a temporary object whose lifetime is not
+extended, or a function parameter. If the lifetimes of `x` and `y` end
+at the end of the same full-expression, and `x` is initialized before
+`y`, then the destruction of `y` is sequenced before that of `x`. 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
 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]].[^12]
 If the content of that array is copied back into the object, the object
 shall subsequently hold its original value.
 [*Example 1*:
 — *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`,[^13]
 `obj2` shall subsequently hold the same value as `obj1`.
 [*Example 2*:
     // the same value as the corresponding subobject in *t2p
 ```
 — *end example*]
+The *object representation* of a complete object type `T` is the
+sequence of *N* `unsigned char` objects taken up by a non-bit-field
+complete object of type `T`, where *N* equals `sizeof(T)`. The *value
+representation* of a type `T` is the set of bits in the object
+representation of `T` that participate in representing a value of type
+`T`. The object and value representation of a non-bit-field complete
+object of type `T` are the bytes and bits, respectively, of the object
+corresponding to the object and value representation of its type. The
+object representation of a bit-field object is the sequence of *N* bits
+taken up by the object, where *N* is the width of the bit-field
+[[class.bit]]. The value representation of a bit-field object is the set
+of bits in the object representation that participate in representing
+its value. Bits in the object representation of a type or object 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.[^14]
 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*.[^15]
 Incompletely-defined object types and cv `void` are *incomplete types*
 [[basic.fundamental]].
 [*Note 2*: Objects cannot be defined to have an incomplete type
 An *object type* is a (possibly cv-qualified) type that is not a
 function type, not a reference type, and not cv `void`.
 Arithmetic types [[basic.fundamental]], enumeration types, pointer
+types, pointer-to-member types [[basic.compound]], `std::meta::{}info`,
+`std::nullptr_t`, and cv-qualified [[basic.type.qualifier]] versions of
+these types are collectively called *scalar types*. Scalar types,
+trivially copyable class types [[class.prop]], arrays of such types, and
+cv-qualified versions of these types are collectively called *trivially
+copyable types*. Scalar types, trivially relocatable class types
+[[class.prop]], arrays of such types, and cv-qualified versions of these
+types are collectively called *trivially relocatable types*.
+Cv-unqualified scalar types, replaceable class types [[class.prop]], and
+arrays of such types are collectively called *replaceable types*. Scalar
+types, standard-layout class types [[class.prop]], arrays of such types,
+and cv-qualified versions of these types are collectively called
+*standard-layout types*. Scalar types, implicit-lifetime class types
+[[class.prop]], array types, and cv-qualified versions of these types
+are collectively called *implicit-lifetime types*.
 A type is a *literal type* if it is:
 - cv `void`; or
 - a scalar type; or
 - 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-variant non-static 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,
 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]].
+A type is *consteval-only* if it is either `std::meta::info` or a type
+compounded from a consteval-only type [[basic.compound]]. Every object
+of consteval-only type shall be
+- the object associated with a constexpr variable or a subobject
+  thereof,
+- a template parameter object [[temp.param]] or a subobject thereof, or
+- an object whose lifetime begins and ends during the evaluation of a
+  core constant expression.
 ### Fundamental types <a id="basic.fundamental">[[basic.fundamental]]</a>
 There are five *standard signed integer types*: “`signed char`”,
 “`short int`”, “`int`”, “`long int`”, and “`long long int`”. In this
 list, each type provides at least as much storage as those preceding it
 in the list. There may also be *implementation-defined* *extended signed
 integer types*. The standard and extended signed integer types are
 collectively called *signed integer types*. The range of representable
+values for a signed integer type is -2ᴺ⁻¹ to 2ᴺ⁻¹-1 (inclusive), where N
+is called the *width* of the type.
 [*Note 1*: Plain `int`s are intended to have the natural width
 suggested by the architecture of the execution environment; the other
 signed integer types are provided to meet special needs. — *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.[^16]
 [*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*]
 | `int`           | 16                |
 | `long int`      | 32                |
 | `long long int` | 64                |
+The width of each standard 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/IEC 9899:2018 (C) 6.2.6.2. — *end note*]
 [*Note 4*: The signed and unsigned integer types satisfy the
+constraints given in ISO/IEC 9899:2018 (C) 5.3.5.3.2. — *end note*]
 Except as specified above, the width of a signed or unsigned integer
 type is *implementation-defined*.
 Each value x of an unsigned integer type with width N has a unique
 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 `std::uint_least16_t` and
+`std::uint_least32_t`, respectively, in `<cstdint>`.
 Type `bool` is a distinct type that has the same object representation,
 value representation, and alignment requirements as an
 *implementation-defined* unsigned integer type. The values of type
 `bool` are `true` and `false`.
 Except as specified in [[basic.extended.fp]], the object and value
 representations and accuracy of operations of floating-point types are
 *implementation-defined*.
+The minimum range of representable values for a floating-point type is
+the most negative finite floating-point number representable in that
+type through the most positive finite floating-point number
+representable in that type. In addition, if negative infinity is
+representable in a type, the range of that type is extended to all
+negative real numbers; likewise, if positive infinity is representable
+in a type, the range of that type is extended to all positive real
+numbers.
+[*Note 10*: Since negative and positive infinity are representable in
+ISO/IEC 60559 formats, all real numbers lie within the range of
+representable values of a floating-point type adhering to ISO/IEC
+60559. — *end note*]
 Integral and floating-point types are collectively termed *arithmetic
 types*.
+[*Note 11*: 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. An expression of type cv `void`
+shall be used only as
+- an expression statement [[stmt.expr]],
+- the expression in a `return` statement [[stmt.return]] for a function
+  with the return type cv `void`,
+- an operand of a comma expression [[expr.comma]],
+- the second or third operand of `?:` [[expr.cond]],
+- the operand of a `typeid` expression [[expr.typeid]],
+- the operand of a `noexcept` operator [[expr.unary.noexcept]],
+- the operand of a `decltype` specifier [[dcl.type.decltype]], or
+- the operand of an explicit conversion to type cv `void`
+ [[expr.type.conv]], [[expr.static.cast]], [[expr.cast]].
+The types denoted by cv `std::nullptr_t` are distinct types. A prvalue
+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*)`.
+A value of type `std::meta::info` is called a *reflection*. There exists
+a unique *null reflection*; every other reflection is a representation
+of
+- a value of scalar type [[temp.param]],
+- an object with static storage duration [[basic.stc]],
+- a variable [[basic.pre]],
+- a structured binding [[dcl.struct.bind]],
+- a function [[dcl.fct]],
+- a function parameter,
+- an enumerator [[dcl.enum]],
+- an annotation [[dcl.attr.grammar]],
+- a type alias [[dcl.typedef]],
+- a type [[basic.types]],
+- a class member [[class.mem]],
+- an unnamed bit-field [[class.bit]],
+- a class template [[temp.pre]],
+- a function template,
+- a variable template,
+- an alias template [[temp.alias]],
+- a concept [[temp.concept]],
+- a namespace alias [[namespace.alias]],
+- a namespace [[basic.namespace.general]],
+- a direct base class relationship [[class.derived.general]], or
+- a data member description [[class.mem.general]].
+A reflection is said to *represent* the corresponding construct.
+[*Note 12*: A reflection of a value can be produced by library
+functions such as `std::meta::constant_of` and
+`std::meta::reflect_constant`. — *end note*]
+[*Example 2*:
+``` cpp
+int arr[] = {1, 2, 3};
+auto [a1, a2, a3] = arr;
+[[=1]] void fn(int n);
+enum Enum { A };
+using Alias = int;
+struct B {};
+struct S : B {
+  int mem;
+  int : 0;
+};
+template<auto> struct TCls {};
+template<auto> void TFn();
+template<auto> int TVar;
+template<auto N> using TAlias = TCls<N>;
+template<auto> concept Concept = requires { true; };
+namespace NS {};
+namespace NSAlias = NS;
+constexpr auto ctx = std::meta::access_context::current();
+constexpr auto r1 = std::meta::reflect_constant(42);        // represents int value of 42
+constexpr auto r2 = std::meta::reflect_object(arr[1]);      // represents int object
+constexpr auto r3 = ^^arr;                                  // represents a variable
+constexpr auto r4 = ^^a3;                                   // represents a structured binding
+constexpr auto r5 = ^^fn;                                   // represents a function
+constexpr auto r6 = std::meta::parameters_of(^^fn)[0];      // represents a function parameter
+constexpr auto r7 = ^^Enum::A;                              // represents an enumerator
+constexpr auto r8 = std::meta::annotations_of(^^fn)[0];     // represents an annotation
+constexpr auto r9 = ^^Alias;                                // represents a type alias
+constexpr auto r10 = ^^S;                                   // represents a type
+constexpr auto r11 = ^^S::mem;                              // represents a class member
+constexpr auto r12 = std::meta::members_of(^^S, ctx)[1];    // represents an unnamed bit-field
+constexpr auto r13 = ^^TCls;                                // represents a class template
+constexpr auto r14 = ^^TFn;                                 // represents a function template
+constexpr auto r15 = ^^TVar;                                // represents a variable template
+constexpr auto r16 = ^^TAlias;                              // represents an alias template
+constexpr auto r17 = ^^Concept;                             // represents a concept
+constexpr auto r18 = ^^NSAlias;                             // represents a namespace alias
+constexpr auto r19 = ^^NS;                                  // represents a namespace
+constexpr auto r20 = std::meta::bases_of(^^S, ctx)[0];      // represents a direct base class relationship
+constexpr auto r21 =
+  std::meta::data_member_spec(^^int, {.name="member"});     // represents a data member description
+```
+— *end example*]
+*Recommended practice:* Implementations should not represent other
+constructs specified in this document, such as *using-declarator*s,
+partial template specializations, attributes, placeholder types,
+statements, or expressions, as values of type `std::meta::info`.
+[*Note 13*: Future revisions of this document can specify semantics for
+reflections representing any such constructs. — *end note*]
 The types described in this subclause are called *fundamental types*.
+[*Note 14*: 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
 60559 floating-point interchange format binary16, then the
+*typedef-name* `std::float16_t` is declared 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 60559 floating-point interchange
+format binary32, then the *typedef-name* `std::float32_t` is declared 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 60559 floating-point interchange
+format binary64, then the *typedef-name* `std::float64_t` is declared 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 60559 floating-point interchange
+format binary128, then the *typedef-name* `std::float128_t` is declared
+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 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 declared 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 significand, so the storage used for the
+significand is p-1 bits. ISO/IEC 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 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 declared 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 \IsoCUndated.
 ### 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]];
 - *functions*, which have parameters of given types and return `void` or
+ a result of a given type, [[dcl.fct]];
 - *pointers* to cv `void` or objects or functions (including static
   members of classes) of a given type, [[dcl.ptr]];
 - *references* to objects or functions of a given type, [[dcl.ref]].
   There are two types of references:
   - lvalue reference
   - rvalue reference
+- *classes* containing a sequence of class members
+ [[class]], [[class.mem]], 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*,[^17] 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;
 “pointer to `X`”. — *end example*]
 Except for pointers to static members, text referring to “pointers” does
 not apply to pointers to members. Pointers to incomplete types are
 allowed although there are restrictions on what can be done with them
+[[basic.types.general]]. Every value of pointer type is one of the
+following:
 - a *pointer to* an object or function (the pointer is said to *point*
   to the object or function), or
 - a *pointer past the end of* an object [[expr.add]], or
 - 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[^18]
 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. — *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*]
+A pointer value P is *valid in the context of* an evaluation E if P is a
+pointer to function or a null pointer value, or if it is a pointer to or
+past the end of an object O and E happens before the end of the duration
+of the region of storage for O. If a pointer value P is used in an
+evaluation E and P is not valid in the context of E, then the behavior
+is undefined if E is an indirection [[expr.unary.op]] or an invocation
+of a deallocation function [[basic.stc.dynamic.deallocation]], and
+*implementation-defined* otherwise.[^19]
+[*Note 4*: P can be valid in the context of E even if it points to a
+type unrelated to that of O or if O is not within its lifetime, although
+further restrictions apply to such pointer values
+[[basic.life]], [[basic.lval]], [[expr.add]]. — *end note*]
+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
 If two objects are pointer-interconvertible, then they have the same
 address, and it is possible to obtain a pointer to one from a pointer to
 the other via a `reinterpret_cast` [[expr.reinterpret.cast]].
+[*Note 5*: 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
 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]].[^20]
 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.
 [[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
 - 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`.\begin{tailnote}
+  The treatment of \texttt{std::float64_t} differs from
+  that of the analogous \texttt{\_Float64} in C,
+  for example on platforms where all of
+  \texttt{\texttt{long} \texttt{double}},
+  \texttt{double}, and
+  \texttt{std::float64_t}
+  have the same set of values (see ISO/IEC 9899:2018 (C)H.4.3).
+  \end{tailnote}
 [*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*]
 A *full-expression* is
 - an unevaluated operand [[expr.context]],
 - a *constant-expression* [[expr.const]],
 - an immediate invocation [[expr.const]],
+- an *init-declarator* [[dcl.decl]] (including such introduced by a
+  structured binding [[dcl.struct.bind]]) or a *mem-initializer*
   [[class.base.init]], including the constituent expressions of the
   initializer,
 - an invocation of a destructor generated at the end of the lifetime of
   an object other than a temporary object [[class.temporary]] whose
+  lifetime has not been extended,
+- the predicate of a contract assertion [[basic.contract]], or
 - an expression that is not a subexpression of another expression and
   that is not otherwise part of a full-expression.
 If a language construct is defined to produce an implicit call of a
 function, a use of the language construct is considered to be an
 void f() {
   S s2 = 2;                     // full-expression comprises call of S::S(int)
   if (S(3).v())                 // full-expression includes lvalue-to-rvalue and int to bool conversions,
                                 // performed before temporary is deleted at end of full-expression
   { }
+  bool b = noexcept(S(4)); // exception specification of destructor of S considered for noexcept
   // full-expression is destruction of s2 at end of block
 }
 struct B {
   B(S = S(0));
 default arguments [[dcl.fct.default]] are considered to be created in
 the expression that calls the function, not the expression that defines
 the default argument. — *end note*]
 Reading an object designated by a `volatile` glvalue [[basic.lval]],
+modifying an object, producing an injected declaration [[expr.const]],
+calling a library I/O function, or calling a function that does any of
+those operations are all *side effects*, which are changes in the state
+of the execution or translation environment. *Evaluation* of an
+expression (or a subexpression) in general includes both value
 computations (including determining the identity of an object for
 glvalue evaluation and fetching a value previously assigned to an object
 for prvalue evaluation) and initiation of side effects. When a call to a
 library I/O function returns or an access through a volatile glvalue is
+evaluated, the side effect is considered complete, even though some
 external actions implied by the call (such as the I/O itself) or by the
 `volatile` access may not have completed yet.
 *Sequenced before* is an asymmetric, transitive, pair-wise relation
 between evaluations executed by a single thread [[intro.multithread]],
 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.[^21]
 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
 execution of a program, unsequenced and indeterminately sequenced
 evaluations of its subexpressions need not be performed consistently in
 different evaluations. — *end note*]
 The value computations of the operands of an operator are sequenced
+before the value computation of the result of the operator. The behavior
+is undefined if
+- a side effect on a memory location [[intro.memory]] or
+- starting or ending the lifetime of an object in a memory location
+is unsequenced relative to
+- another side effect on the same memory location,
+- starting or ending the lifetime of an object occupying storage that
+  overlaps with the memory location, or
+- a value computation using the value of any object in the same memory
+  location,
+and the two evaluations are not potentially concurrent
+[[intro.multithread]].
+[*Note 6*: Starting the lifetime of an object in a memory location can
+end the lifetime of objects in other memory locations
+[[basic.life]]. — *end note*]
+[*Note 7*: The next subclause imposes similar, but more complex
 restrictions on potentially concurrent computations. — *end note*]
 [*Example 3*:
 ``` cpp
   i = 7, i++, i++;              // i becomes 9
   i = i++ + 1;                  // the value of i is incremented
   i = i++ + i;                  // undefined behavior
   i = i + 1;                    // the value of i is incremented
+  union U { int x, y; } u;
+  (u.x = 1, 0) + (u.y = 2, 0);  // undefined behavior
 }
 ```
 — *end example*]
+When invoking a function *f* (whether or not the function is inline),
+every argument expression and the postfix expression designating *f* are
+sequenced before every precondition assertion of *f*
+[[dcl.contract.func]], which in turn are sequenced before every
+expression or statement in the body of *f*, which in turn are sequenced
+before every postcondition assertion of *f*.
+For each
+- function invocation,
+- evaluation of an *await-expression* [[expr.await]], or
+- evaluation of a *throw-expression* [[expr.throw]]
+*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*;[^22]
 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*.
 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*]
+During the evaluation of an expression as a core constant expression
+[[expr.const]], evaluations of operands of individual operators and of
+subexpressions of individual expressions that are otherwise either
+unsequenced or indeterminately sequenced are evaluated in lexical order.
 ### 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
 [*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 use every object and function
+in a program.[^23]
 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.
 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 [[defns.access]] a memory location [[intro.memory]] or
+- starts or ends the lifetime of an object in a memory location
+and the other one
+- reads or modifies the same memory location or
+- starts or ends the lifetime of an object occupying storage that
+  overlaps with the memory location.
+[*Note 2*: A modification can still conflict even if it does not alter
+the value of any bits. — *end note*]
 The library defines a number of atomic operations [[atomics]] and
 operations on mutexes [[thread]] that are specially identified as
 synchronization operations. These operations play a special role in
 making assignments in one thread visible to another. A synchronization
+operation on one or more memory locations is either an acquire
+operation, a release operation, or both an acquire and release
+operation. A synchronization operation without an associated memory
+location is a fence and can be either an acquire fence, a release fence,
+or both an acquire and release fence. In addition, there are relaxed
+atomic operations, which are not synchronization operations, and atomic
+read-modify-write operations, which have special characteristics.
+[*Note 3*: For example, a call that acquires a mutex will perform an
 acquire operation on the locations comprising the mutex.
 Correspondingly, a call that releases the same mutex will perform a
 release operation on those same locations. Informally, performing a
 release operation on A forces prior side effects on other memory
 locations to become visible to other threads that later perform a
 operations, they cannot contribute to data races. — *end note*]
 All modifications to a particular atomic object M occur in some
 particular total order, called the *modification order* of M.
+[*Note 4*: 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*]
 Certain library calls *synchronize with* other library calls performed
 by another thread. For example, an atomic store-release synchronizes
 with a load-acquire that takes its value from the store
 [[atomics.order]].
+[*Note 5*: Except in the specified cases, reading a later value does
 not necessarily ensure visibility as described below. Such a requirement
 would sometimes interfere with efficient implementation. — *end note*]
+[*Note 6*: The specifications of the synchronization operations define
 when one reads the value written by another. For atomic objects, the
 definition is clear. All operations on a given mutex occur in a single
 total order. Each mutex acquisition “reads the value written” by the
 last mutex release. — *end note*]
 An evaluation A *happens before* an evaluation B (or, equivalently, B
+happens after A) if either
 - A is sequenced before B, or
 - A synchronizes with B, or
+- A happens before X and X happens before B.
+[*Note 7*: An evaluation does not happen before itself. — *end note*]
 An evaluation A *strongly happens before* an evaluation D if, either
 - A is sequenced before D, or
 - A synchronizes with D, and both A and D are sequentially consistent
   atomic operations [[atomics.order]], or
 - there are evaluations B and C such that A is sequenced before B, B
+  happens before C, and C is sequenced before D, or
 - there is an evaluation B such that A strongly happens before B, and B
   strongly happens before D.
+[*Note 8*: Informally, if A strongly happens before B, then A appears
+to be evaluated before B in all contexts. — *end note*]
 A *visible side effect* A on a scalar object or bit-field M with respect
 to a value computation B of M satisfies the conditions:
 - A happens before B and
 - there is no other side effect X to M such that A happens before X and
   X happens before B.
 The value of a non-atomic scalar object or bit-field M, as determined by
+evaluation B, is the value stored by the visible side effect A.
+[*Note 9*: If there is ambiguity about which side effect to a
 non-atomic object or bit-field is visible, then the behavior is either
 unspecified or undefined. — *end note*]
+[*Note 10*: This states that operations on ordinary objects are not
 visibly reordered. This is not actually detectable without data races,
+but is needed to ensure that data races, as defined below, and with
+suitable restrictions on the use of atomics, correspond to data races in
+a simple interleaved (sequentially consistent) execution. — *end note*]
+The value of an atomic object M, as determined by evaluation B, is the
+value stored by some unspecified side effect A that modifies M, where B
+does not happen before A.
+[*Note 11*: The set of such side effects is also restricted by the rest
 of the rules described here, and in particular, by the coherence
 requirements below. — *end note*]
 If an operation A that modifies an atomic object M happens before an
+operation B that modifies M, then A is earlier than B in the
 modification order of M.
+[*Note 12*: This requirement is known as write-write
 coherence. — *end note*]
 If a value computation A of an atomic object M happens before a value
 computation B of M, and A takes its value from a side effect X on M,
+then the value computed by B is either the value stored by X or the
+value stored by a side effect Y on M, where Y follows X in the
 modification order of M.
+[*Note 13*: This requirement is known as read-read
 coherence. — *end note*]
 If a value computation A of an atomic object M happens before an
+operation B that modifies M, then A takes its value from a side effect X
+on M, where X precedes B in the modification order of M.
+[*Note 14*: This requirement is known as read-write
 coherence. — *end note*]
 If a side effect X on an atomic object M happens before a value
+computation B of M, then the evaluation B takes its value from X or from
+a side effect Y that follows X in the modification order of M.
+[*Note 15*: This requirement is known as write-read
 coherence. — *end note*]
+[*Note 16*: The four preceding coherence requirements effectively
 disallow compiler reordering of atomic operations to a single object,
 even if both operations are relaxed loads. This effectively makes the
 cache coherence guarantee provided by most hardware available to C++
 atomic operations. — *end note*]
+[*Note 17*: The value observed by a load of an atomic depends on the
 “happens before” relation, which depends on the values observed by loads
 of atomics. The intended reading is that there must exist an association
 of atomic loads with modifications they observe that, together with
 suitably chosen modification orders and the “happens before” relation
 derived as described above, satisfy the resulting constraints as imposed
 potentially concurrent conflicting actions, at least one of which is not
 atomic, and neither happens before the other, except for the special
 case for signal handlers described below. Any such data race results in
 undefined behavior.
+[*Note 18*: It can be shown that programs that correctly use mutexes
 and `memory_order::seq_cst` operations to prevent all data races and use
 no other synchronization operations behave as if the operations executed
 by their constituent threads were simply interleaved, with each value
 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 remain possible, since any
+program that behaves differently as a result has undefined
 behavior. — *end note*]
+Two accesses to the same non-bit-field 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 divided into two groups A and B, such
+that no evaluations in B happen before evaluations in A, and the
+evaluations of such `volatile std::sig_atomic_t` objects take values as
+though all evaluations in A happened before the execution of the signal
+handler and the execution of the signal handler happened before all
+evaluations in B.
+[*Note 19*: Compiler transformations that introduce assignments to a
 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 might alias is
 also generally precluded, since this could violate the coherence
 rules. — *end note*]
+[*Note 20*: It is possible that transformations that introduce a
+speculative read of a potentially shared memory location do 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*]
 #### Forward progress <a id="intro.progress">[[intro.progress]]</a>
 The implementation may assume that any thread will eventually do one of
 the following:
 - terminate,
+- invoke the function `std::this_thread::yield` [[thread.thread.this]],
 - make a call to a library I/O function,
+- perform an access through a volatile glvalue,
+- perform an atomic or synchronization operation other than an atomic
+  modify-write operation [[atomics.order]], or
+- continue execution of a trivial infinite loop [[stmt.iter.general]].
 [*Note 1*: This is intended to allow compiler transformations such as
+removal, merging, and reordering of empty loops, even when termination
+cannot be proven. An affordance is made for trivial infinite loops,
+which cannot be removed nor reordered. — *end note*]
 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*.
 During the execution of a thread of execution, each of the following is
 termed an *execution step*:
 - termination of the thread of execution,
+- performing an access through a volatile glvalue,
+- completion of a call to a library I/O function, or
+- completion of an atomic or synchronization operation other than an
+  atomic modify-write operation [[atomics.order]].
 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.
 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 applies 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
 arguments passed to the program from the environment in which the
 program is run. If `argc` is nonzero these arguments shall be supplied
 in `argv[0]` through `argv[argc - 1]` as pointers to the initial
 characters of null-terminated multibyte strings (NTMBSs)
 [[multibyte.strings]] and `argv[0]` shall be the pointer to the initial
+character of an 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 named by an expression. 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]] other
+than `"C++"`. 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
 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 evaluating any postcondition assertions of `main`) and
+calling `std::exit` with the return value as the argument. If control
+flows off the end of the *compound-statement* of `main`, the effect is
+equivalent to a `return` with operand `0` (see also [[except.handle]]).
 #### Static initialization <a id="basic.start.static">[[basic.start.static]]</a>
 Variables with static storage duration are initialized as a consequence
 of program initiation. Variables with thread storage duration are
 initialized as a consequence of thread execution. Within each of these
 phases of initiation, initialization occurs as follows.
+*Constant initialization* is performed if a variable 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
 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.[^24]
 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
 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()`.
+## Contract assertions <a id="basic.contract">[[basic.contract]]</a>
+### General <a id="basic.contract.general">[[basic.contract.general]]</a>
+*Contract assertions* allow the programmer to specify properties of the
+state of the program that are expected to hold at certain points during
+execution. Contract assertions are introduced by
+*precondition-specifier*s, *postcondition-specifier*s
+[[dcl.contract.func]], and *assertion-statement*s
+[[stmt.contract.assert]].
+Each contract assertion has a *contract-assertion predicate*, which is
+an expression of type `bool`.
+[*Note 1*: The value of the predicate is used to identify program
+states that are expected. — *end note*]
+An invocation of the macro `va_start` [[cstdarg.syn]] shall not be a
+subexpression of the predicate of a contract assertion, no diagnostic
+required.
+[*Note 2*: Within the predicate of a contract assertion,
+*id-expression*s referring to variables declared outside the contract
+assertion are `const` [[expr.prim.id.unqual]], `this` is a pointer to
+`const` [[expr.prim.this]], and the result object can be named if a
+*result-name-introducer* [[dcl.contract.res]] has been
+specified. — *end note*]
+### Evaluation <a id="basic.contract.eval">[[basic.contract.eval]]</a>
+An evaluation of a contract assertion uses one of the following four
+*evaluation semantics*: *ignore*, *observe*, *enforce*, or
+*quick-enforce*. Observe, enforce, and quick-enforce are *checking
+semantics*; enforce and quick-enforce are *terminating semantics*.
+It is *implementation-defined* which evaluation semantic is used for any
+given evaluation of a contract assertion.
+[*Note 1*: The range and flexibility of available choices of evaluation
+semantics depends on the implementation and need not allow all four
+evaluation semantics as possibilities. The evaluation semantics can
+differ for different evaluations of the same contract assertion,
+including evaluations during constant evaluation. — *end note*]
+*Recommended practice:* An implementation should provide the option to
+translate a program such that all evaluations of contract assertions use
+the ignore semantic as well as the option to translate a program such
+that all evaluations of contract assertions use the enforce semantic. By
+default, evaluations of contract assertions should use the enforce
+semantic.
+The evaluation of a contract assertion using the ignore semantic has no
+effect.
+[*Note 2*: The predicate is potentially evaluated [[basic.def.odr]],
+but not evaluated. — *end note*]
+The evaluation A of a contract assertion using a checking semantic
+determines the value of the predicate. It is unspecified whether the
+predicate is evaluated. Let B be the value that would result from
+evaluating the predicate.
+[*Note 3*:
+To determine whether a predicate would evaluate to `true` or `false`, an
+alternative evaluation that produces the same value as the predicate but
+has no side effects can occur.
+[*Example 1*:
+``` cpp
+struct S {
+  mutable int g = 5;
+} s;
+void f()
+  pre(( s.g++, false ));    // #1
+void g()
+{
+  f();  // Increment of s.g might not occur, even if #1 uses a checking semantic.
+}
+```
+— *end example*]
+— *end note*]
+There is an observable checkpoint [[intro.abstract]] C that happens
+before A such that any other operation O that happens before A also
+happens before C.
+A *contract violation* occurs when
+- B is `false`,
+- the evaluation of the predicate exits via an exception, or
+- the evaluation of the predicate is performed in a context that is
+  manifestly constant-evaluated [[expr.const]] and the predicate is not
+  a core constant expression.
+[*Note 4*: If B is `true`, no contract violation occurs and control
+flow continues normally after the point of evaluation of the contract
+assertion. The evaluation of the predicate can fail to produce a value
+without causing a contract violation, for example, by calling `longjmp`
+[[csetjmp.syn]] or terminating the program. — *end note*]
+If a contract violation occurs in a context that is manifestly
+constant-evaluated [[expr.const]], and the evaluation semantic is a
+terminating semantic, the program is ill-formed.
+[*Note 5*: A diagnostic is produced if the evaluation semantic is
+observe [[intro.compliance]]. — *end note*]
+[*Note 6*:
+Different evaluation semantics chosen for the same contract assertion in
+different translation units can result in violations of the
+one-definition rule [[basic.def.odr]] when a contract assertion has side
+effects that alter the value produced by a constant expression.
+[*Example 2*:
+``` cpp
+constexpr int f(int i)
+{
+  contract_assert((++const_cast<int&>(i), true));
+  return i;
+}
+inline void g()
+{
+  int a[f(1)];  // size dependent on the evaluation semantic of contract_assert above
+}
+```
+— *end example*]
+— *end note*]
+When the program is *contract-terminated*, it is
+*implementation-defined* (depending on context) whether
+- `std::terminate` is called,
+- `std::abort` is called, or
+- execution is terminated. \[*Note 7*: No further execution steps occur
+  [[intro.progress]]. — *end note*]
+[*Note 8*: Performing the actions of `std::terminate` or `std::abort`
+without actually making a library call is a conforming implementation of
+contract-termination [[intro.abstract]]. — *end note*]
+If a contract violation occurs in a context that is not manifestly
+constant-evaluated and the evaluation semantic is quick-enforce, the
+program is contract-terminated.
+If a contract violation occurs in a context that is not manifestly
+constant-evaluated and the evaluation semantic is enforce or observe,
+the contract-violation handler [[basic.contract.handler]] is invoked
+with an lvalue referring to an object `v` of type
+`const std::contracts::contract_violation`
+[[support.contract.violation]] containing information about the contract
+violation. Storage for `v` is allocated in an unspecified manner except
+as noted in [[basic.stc.dynamic.allocation]]. The lifetime of `v`
+persists for the duration of the invocation of the contract-violation
+handler.
+If the contract violation occurred because the evaluation of the
+predicate exited via an exception, the contract-violation handler is
+invoked from within an active implicit handler for that exception
+[[except.handle]]. If the contract-violation handler returns normally
+and the evaluation semantic is observe, that implicit handler is no
+longer considered active.
+[*Note 9*: The exception can be inspected or rethrown within the
+contract-violation handler. — *end note*]
+If the contract-violation handler returns normally and the evaluation
+semantic is enforce, the program is contract-terminated; if violation
+occurred as the result of an uncaught exception from the evaluation of
+the predicate, the implicit handler remains active when contract
+termination occurs.
+[*Note 10*: If the contract-violation handler returns normally and the
+evaluation semantic is observe, control flow continues normally after
+the point of evaluation of the contract assertion. — *end note*]
+There is an observable checkpoint [[intro.abstract]] C that happens
+after the contract-violation handler returns normally such that any
+other operation O that happens after the contract-violation handler
+returns also happens after C.
+[*Note 11*: The terminating semantics terminate the program if
+execution would otherwise continue normally past a contract violation:
+the enforce semantic provides the opportunity to log information about
+the contract violation before terminating the program or to throw an
+exception to avoid termination, and the quick-enforce semantic is
+intended to terminate the program as soon as possible as well as to
+minimize the impact of contract checks on the generated code size.
+Conversely, the observe semantic provides the opportunity to log
+information about the contract violation without having to terminate the
+program. — *end note*]
+If a contract-violation handler invoked from the evaluation of a
+function contract assertion [[dcl.contract.func]] exits via an
+exception, the behavior is as if the function body exits via that same
+exception.
+[*Note 12*: A *function-try-block* [[except.pre]] is the function body
+when present and thus does not have an opportunity to catch the
+exception. If the function has a non-throwing exception specification,
+the function `std::terminate` is invoked
+[[except.terminate]]. — *end note*]
+[*Note 13*: If a contract-violation handler invoked from an
+*assertion-statement* [[stmt.contract.assert]] exits via an exception,
+the search for a handler continues from the execution of that
+statement. — *end note*]
+To *evaluate in sequence* a list R of contract assertions:
+- Construct a list of contract assertions S such that
+  - all elements of R are in S,
+  - each element of R may be repeated an *implementation-defined* number
+    of times within S, and
+  - if a contract assertion A precedes another contract assertion B in
+    R, then the first occurrence of A precedes the first occurrence of B
+    in S.
+- Evaluate each element of S such that, if a contract assertion A
+  precedes a contract assertion B in S, then the evaluation of A is
+  sequenced before the evaluation of B.
+[*Example 3*:
+``` cpp
+void f(int i)
+{
+  contract_assert(i > 0);   // #1
+  contract_assert(i < 10);  // #2
+    // valid sequence of evaluations: #1 #2
+    // valid sequence of evaluations: #1 #1 #2 #2
+    // valid sequence of evaluations: #1 #2 #1 #2
+    // valid sequence of evaluations: #1 #2 #2 #1
+    // invalid sequence of evaluations: #2 #1
+}
+```
+— *end example*]
+*Recommended practice:* An implementation should provide an option to
+perform a specified number of repeated evaluations for contract
+assertions. By default, no repeated evaluations should be performed.
+### Contract-violation handler <a id="basic.contract.handler">[[basic.contract.handler]]</a>
+The *contract-violation handler* of a program is a function named
+`::handle_contract_violation`. The contract-violation handler shall have
+a single parameter of type “lvalue reference to `const`
+`std::contracts::contract_violation`” and shall return `void`. The
+contract-violation handler may have a non-throwing exception
+specification. The implementation shall provide a definition of the
+contract-violation handler, called the
+*default contract-violation handler*.
+[*Note 1*: No declaration for the default contract-violation handler is
+provided by any standard library header. — *end note*]
+*Recommended practice:* The default contract-violation handler should
+produce diagnostic output that suitably formats the most relevant
+contents of the `std::contracts::contract_violation` object,
+rate-limited for potentially repeated violations of observed contract
+assertions, and then return normally.
+It is *implementation-defined* whether the contract-violation handler is
+replaceable [[term.replaceable.function]]. If the contract-violation
+handler is not replaceable, a declaration of a replacement function for
+the contract-violation handler is ill-formed, no diagnostic required.
 <!-- Link reference definitions -->
 [allocator.members]: mem.md#allocator.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.contract]: #basic.contract
+[basic.contract.eval]: #basic.contract.eval
+[basic.contract.general]: #basic.contract.general
+[basic.contract.handler]: #basic.contract.handler
 [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.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.namespace.general]: dcl.md#basic.namespace.general
 [basic.pre]: #basic.pre
 [basic.scope]: #basic.scope
 [basic.scope.block]: #basic.scope.block
 [basic.scope.class]: #basic.scope.class
+[basic.scope.contract]: #basic.scope.contract
 [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.splice]: #basic.splice
 [basic.start]: #basic.start
 [basic.start.dynamic]: #basic.start.dynamic
 [basic.start.main]: #basic.start.main
 [basic.start.static]: #basic.start.static
 [basic.start.term]: #basic.start.term
 [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.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
 [class.copy.assign]: class.md#class.copy.assign
 [class.copy.ctor]: class.md#class.copy.ctor
 [class.copy.elision]: class.md#class.copy.elision
 [class.default.ctor]: class.md#class.default.ctor
 [class.derived]: class.md#class.derived
+[class.derived.general]: class.md#class.derived.general
 [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.mem.general]: class.md#class.mem.general
 [class.member.lookup]: #class.member.lookup
 [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
 [conv.integral]: expr.md#conv.integral
 [conv.lval]: expr.md#conv.lval
 [conv.mem]: expr.md#conv.mem
 [conv.prom]: expr.md#conv.prom
 [conv.ptr]: expr.md#conv.ptr
+[conv.qual]: expr.md#conv.qual
 [conv.rank]: #conv.rank
 [conv.rval]: expr.md#conv.rval
 [cpp.predefined]: cpp.md#cpp.predefined
+[csetjmp.syn]: support.md#csetjmp.syn
+[cstdarg.syn]: support.md#cstdarg.syn
 [cstddef.syn]: support.md#cstddef.syn
 [cstring.syn]: strings.md#cstring.syn
 [dcl.align]: dcl.md#dcl.align
 [dcl.array]: dcl.md#dcl.array
 [dcl.attr]: dcl.md#dcl.attr
+[dcl.attr.grammar]: dcl.md#dcl.attr.grammar
+[dcl.attr.indet]: dcl.md#dcl.attr.indet
 [dcl.attr.nouniqueaddr]: dcl.md#dcl.attr.nouniqueaddr
 [dcl.constexpr]: dcl.md#dcl.constexpr
+[dcl.contract.func]: dcl.md#dcl.contract.func
+[dcl.contract.res]: dcl.md#dcl.contract.res
 [dcl.decl]: dcl.md#dcl.decl
 [dcl.enum]: dcl.md#dcl.enum
 [dcl.fct]: dcl.md#dcl.fct
 [dcl.fct.def]: dcl.md#dcl.fct.def
 [dcl.fct.def.coroutine]: dcl.md#dcl.fct.def.coroutine
 [dcl.fct.def.general]: dcl.md#dcl.fct.def.general
 [dcl.fct.default]: dcl.md#dcl.fct.default
 [dcl.init]: dcl.md#dcl.init
 [dcl.init.aggr]: dcl.md#dcl.init.aggr
+[dcl.init.general]: dcl.md#dcl.init.general
 [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.meaning.general]: dcl.md#dcl.meaning.general
 [dcl.mptr]: dcl.md#dcl.mptr
 [dcl.name]: dcl.md#dcl.name
 [dcl.pre]: dcl.md#dcl.pre
 [dcl.ptr]: dcl.md#dcl.ptr
 [dcl.ref]: dcl.md#dcl.ref
 [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.access]: intro.md#defns.access
 [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.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.assign]: expr.md#expr.assign
 [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.cast]: expr.md#expr.const.cast
 [expr.context]: expr.md#expr.context
 [expr.delete]: expr.md#expr.delete
 [expr.dynamic.cast]: expr.md#expr.dynamic.cast
 [expr.eq]: expr.md#expr.eq
 [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.general]: expr.md#expr.prim.id.general
 [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.splice]: expr.md#expr.prim.splice
 [expr.prim.this]: expr.md#expr.prim.this
 [expr.prop]: expr.md#expr.prop
 [expr.ref]: expr.md#expr.ref
+[expr.reflect]: expr.md#expr.reflect
 [expr.reinterpret.cast]: expr.md#expr.reinterpret.cast
 [expr.rel]: expr.md#expr.rel
 [expr.sizeof]: expr.md#expr.sizeof
 [expr.static.cast]: expr.md#expr.static.cast
 [expr.sub]: expr.md#expr.sub
+[expr.throw]: expr.md#expr.throw
 [expr.type.conv]: expr.md#expr.type.conv
 [expr.typeid]: expr.md#expr.typeid
+[expr.unary.noexcept]: expr.md#expr.unary.noexcept
 [expr.unary.op]: expr.md#expr.unary.op
 [get.new.handler]: support.md#get.new.handler
 [headers]: library.md#headers
+[intro.abstract]: intro.md#intro.abstract
+[intro.compliance]: intro.md#intro.compliance
 [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.phases]: lex.md#lex.phases
+[lex.string]: lex.md#lex.string
+[mem.res.public]: mem.md#mem.res.public
+[meta.define.static]: meta.md#meta.define.static
+[meta.reflection.operators]: meta.md#meta.reflection.operators
+[meta.syn]: meta.md#meta.syn
 [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.alias]: dcl.md#namespace.alias
 [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.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
 [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
 [special]: class.md#special
 [std.modules]: library.md#std.modules
 [stdfloat.syn]: support.md#stdfloat.syn
 [stmt.block]: stmt.md#stmt.block
+[stmt.contract.assert]: stmt.md#stmt.contract.assert
 [stmt.dcl]: stmt.md#stmt.dcl
+[stmt.expand]: stmt.md#stmt.expand
 [stmt.expr]: stmt.md#stmt.expr
 [stmt.if]: stmt.md#stmt.if
 [stmt.iter]: stmt.md#stmt.iter
+[stmt.iter.general]: stmt.md#stmt.iter.general
 [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.contract.violation]: support.md#support.contract.violation
 [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.alias]: temp.md#temp.alias
 [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.splice]: temp.md#temp.dep.splice
 [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.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.spec.partial.match]: temp.md#temp.spec.partial.match
 [temp.type]: temp.md#temp.type
+[term.implicit.lifetime.type]: #term.implicit.lifetime.type
 [term.incomplete.type]: #term.incomplete.type
 [term.odr.use]: #term.odr.use
+[term.replaceable.function]: dcl.md#term.replaceable.function
 [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.thread.this]: thread.md#thread.thread.this
 [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.
 [^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]: The number of bits in a byte is reported by the macro `CHAR_BIT`
     in the header `<climits>`.
+[^6]: 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]].
+[^7]: For example, before the dynamic initialization of an object with
     static storage duration [[basic.start.dynamic]].
+[^8]: 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.
+[^9]: 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.
+[^10]: 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]].
+[^11]: The same rules apply to initialization of an `initializer_list`
     object [[dcl.init.list]] with its underlying temporary array.
+[^12]: By using, for example, the library functions [[headers]]
     `std::memcpy` or `std::memmove`.
+[^13]: By using, for example, the library functions [[headers]]
     `std::memcpy` or `std::memmove`.
+[^14]: The intent is that the memory model of C++ is compatible with
+    that of the C programming language.
+[^15]: The size and layout of an instance of an incompletely-defined
     object type is unknown.
+[^16]: This is also known as two’s complement representation.
+[^17]: Static class members are objects or functions, and pointers to
     them are ordinary pointers to objects or functions.
+[^18]: For an object that is not within its lifetime, this is the first
     byte in memory that it will occupy or used to occupy.
+[^19]: Some implementations might define that copying such a pointer
+    value causes a system-generated runtime fault.
+[^20]: 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.
+[^21]: 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.
+[^22]: In other words, function executions do not interleave with each
     other.
+[^23]: 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]].
+[^24]: 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