[dcl.dcl] - C++14 → C++17

Files changed (1) hide show

tmp/tmpqij0xu72/{from.md → to.md} +1520 -770

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

@@ -10,12 +10,14 @@ declaration-seq:
 ```
 ``` bnf
 declaration:
     block-declaration
     function-definition
     template-declaration
     explicit-instantiation
     explicit-specialization
     linkage-specification
     namespace-definition
     empty-declaration
@@ -32,23 +34,30 @@ block-declaration:
     static_assert-declaration
     alias-declaration
     opaque-enum-declaration
 ```
 ``` bnf
 alias-declaration:
-    'using' identifier attribute-specifier-seqₒₚₜ '=' type-id ';'
 ```
 ``` bnf
 simple-declaration:
-    decl-specifier-seqₒₚₜ init-declarator-listₒₚₜ ';'
-    attribute-specifier-seq decl-specifier-seqₒₚₜ init-declarator-list ';'
 ```
 ``` bnf
 static_assert-declaration:
   'static_assert' '(' constant-expression ',' string-literal ')' ';'
 ```
 ``` bnf
 empty-declaration:
@@ -58,38 +67,43 @@ empty-declaration:
 ``` bnf
 attribute-declaration:
     attribute-specifier-seq ';'
 ```
-*asm-definition*s are described in  [[dcl.asm]], and
 *linkage-specification*s are described in  [[dcl.link]].
 *Function-definition*s are described in  [[dcl.fct.def]] and
-*template-declaration*s are described in Clause  [[temp]].
-*Namespace-definition*s are described in  [[namespace.def]],
 *using-declaration*s are described in  [[namespace.udecl]] and
-*using-directive*s are described in  [[namespace.udir]].
-The *simple-declaration*
 ``` bnf
 attribute-specifier-seqₒₚₜ decl-specifier-seqₒₚₜ init-declarator-listₒₚₜ ';'
 ```
 is divided into three parts. Attributes are described in  [[dcl.attr]].
 *decl-specifier*s, the principal components of a *decl-specifier-seq*,
 are described in  [[dcl.spec]]. *declarator*s, the components of an
 *init-declarator-list*, are described in Clause  [[dcl.decl]]. The
-*attribute-specifier-seq* in a *simple-declaration* appertains to each
-of the entities declared by the *declarator*s of the
-*init-declarator-list*. In the declaration for an entity, attributes
-appertaining to that entity may appear at the start of the declaration
-and after the *declarator-id* for that declaration.
 ``` cpp
 [[noreturn]] void f [[noreturn]] ();    // OK
 ```
 Except where otherwise specified, the meaning of an
 *attribute-declaration* is *implementation-defined*.
 A declaration occurs in a scope ([[basic.scope]]); the scope rules are
 summarized in  [[basic.lookup]]. A declaration that declares a function
@@ -111,34 +125,50 @@ omitted only when declaring a class (Clause  [[class]]) or enumeration (
 names being declared by the declaration (as *class-name*s, *enum-name*s,
 or *enumerator*s, depending on the syntax). In such cases, the
 *decl-specifier-seq* shall introduce one or more names into the program,
 or shall redeclare a name introduced by a previous declaration.
 ``` cpp
 enum { };           // ill-formed
 typedef class { };  // ill-formed
 ```
-In a *static_assert-declaration* the *constant-expression* shall be a
-constant expression ([[expr.const]]) that can be contextually converted
-to `bool` (Clause  [[conv]]). If the value of the expression when so
-converted is `true`, the declaration has no effect. Otherwise, the
-program is ill-formed, and the resulting diagnostic message (
-[[intro.compliance]]) shall include the text of the *string-literal*,
 except that characters not in the basic source character set (
 [[lex.charset]]) are not required to appear in the diagnostic message.
 ``` cpp
-static_assert(sizeof(long) >= 8, "64-bit code generation required for this library.");
 ```
 An *empty-declaration* has no effect.
 Each *init-declarator* in the *init-declarator-list* contains exactly
 one *declarator-id*, which is the name declared by that
 *init-declarator* and hence one of the names declared by the
-declaration. The *type-specifiers* ([[dcl.type]]) in the
 *decl-specifier-seq* and the recursive *declarator* structure of the
 *init-declarator* describe a type ([[dcl.meaning]]), which is then
 associated with the name being declared by the *init-declarator*.
 If the *decl-specifier-seq* contains the `typedef` specifier, the
@@ -155,25 +185,31 @@ declaration are added to a function declaration to make a
 definition unless it contains the `extern` specifier and has no
 initializer ([[basic.def]]). A definition causes the appropriate amount
 of storage to be reserved and any appropriate initialization (
 [[dcl.init]]) to be done.
-Only in function declarations for constructors, destructors, and type
-conversions can the *decl-specifier-seq* be omitted.[^1]
 ## Specifiers <a id="dcl.spec">[[dcl.spec]]</a>
 The specifiers that can be used in a declaration are
 ``` bnf
 decl-specifier:
     storage-class-specifier
-    type-specifier
     function-specifier
     'friend'
     'typedef'
     'constexpr'
 ```
 ``` bnf
 decl-specifier-seq:
     decl-specifier attribute-specifier-seqₒₚₜ
@@ -184,15 +220,20 @@ The optional *attribute-specifier-seq* in a *decl-specifier-seq*
 appertains to the type determined by the preceding *decl-specifier*s (
 [[dcl.meaning]]). The *attribute-specifier-seq* affects the type only
 for the declaration it appears in, not other declarations involving the
 same type.
 If a *type-name* is encountered while parsing a *decl-specifier-seq*, it
 is interpreted as part of the *decl-specifier-seq* if and only if there
-is no previous *type-specifier* other than a *cv-qualifier* in the
-*decl-specifier-seq*. The sequence shall be self-consistent as described
-below.
 ``` cpp
 typedef char* Pc;
 static Pc;                      // error: name missing
 ```
@@ -207,26 +248,35 @@ For another example,
 ``` cpp
 void f(const Pc);               // void f(char* const) (not const char*)
 void g(const int Pc);           // void g(const int)
 ```
 Since `signed`, `unsigned`, `long`, and `short` by default imply `int`,
 a *type-name* appearing after one of those specifiers is treated as the
 name being (re)declared.
 ``` cpp
 void h(unsigned Pc);            // void h(unsigned int)
 void k(unsigned int Pc);        // void k(unsigned int)
 ```
 ### Storage class specifiers <a id="dcl.stc">[[dcl.stc]]</a>
 The storage class specifiers are
 ``` bnf
 storage-class-specifier:
-    'register'
     'static'
     'thread_local'
     'extern'
     'mutable'
 ```
@@ -235,70 +285,68 @@ At most one *storage-class-specifier* shall appear in a given
 *decl-specifier-seq*, except that `thread_local` may appear with
 `static` or `extern`. If `thread_local` appears in any declaration of a
 variable it shall be present in all declarations of that entity. If a
 *storage-class-specifier* appears in a *decl-specifier-seq*, there can
 be no `typedef` specifier in the same *decl-specifier-seq* and the
-*init-declarator-list* of the declaration shall not be empty (except for
-an anonymous union declared in a named namespace or in the global
-namespace, which shall be declared `static` ([[class.union]])). The
-*storage-class-specifier* applies to the name declared by each
-*init-declarator* in the list and not to any names declared by other
-specifiers. A *storage-class-specifier* shall not be specified in an
-explicit specialization ([[temp.expl.spec]]) or an explicit
-instantiation ([[temp.explicit]]) directive.
-The `register` specifier shall be applied only to names of variables
-declared in a block ([[stmt.block]]) or to function parameters (
-[[dcl.fct.def]]). It specifies that the named variable has automatic
-storage duration ([[basic.stc.auto]]). A variable declared without a
-*storage-class-specifier* at block scope or declared as a function
-parameter has automatic storage duration by default.
-A `register` specifier is a hint to the implementation that the variable
-so declared will be heavily used. The hint can be ignored and in most
-implementations it will be ignored if the address of the variable is
-taken. This use is deprecated (see  [[depr.register]]).
 The `thread_local` specifier indicates that the named entity has thread
 storage duration ([[basic.stc.thread]]). It shall be applied only to
 the names of variables of namespace or block scope and to the names of
 static data members. When `thread_local` is applied to a variable of
 block scope the *storage-class-specifier* `static` is implied if no
 other *storage-class-specifier* appears in the *decl-specifier-seq*.
 The `static` specifier can be applied only to names of variables and
-functions and to anonymous unions ([[class.union]]). There can be no
-`static` function declarations within a block, nor any `static` function
-parameters. A `static` specifier used in the declaration of a variable
-declares the variable to have static storage duration (
 [[basic.stc.static]]), unless accompanied by the `thread_local`
 specifier, which declares the variable to have thread storage duration (
 [[basic.stc.thread]]). A `static` specifier can be used in declarations
 of class members;  [[class.static]] describes its effect. For the
 linkage of a name declared with a `static` specifier, see
 [[basic.link]].
 The `extern` specifier can be applied only to the names of variables and
 functions. The `extern` specifier cannot be used in the declaration of
 class members or function parameters. For the linkage of a name declared
-with an `extern` specifier, see  [[basic.link]]. The `extern` keyword
-can also be used in s and s, but it is not a in such contexts.
 The linkages implied by successive declarations for a given entity shall
 agree. That is, within a given scope, each declaration declaring the
 same variable name or the same overloading of a function name shall
 imply the same linkage. Each function in a given set of overloaded
 functions can have a different linkage, however.
 ``` cpp
 static char* f();               // f() has internal linkage
 char* f()                       // f() still has internal linkage
-  { /* ... */ }
 char* g();                      // g() has external linkage
 static char* g()                // error: inconsistent linkage
-  { /* ... */ }
 void h();
 inline void h();                // external linkage
 inline void l();
@@ -321,14 +369,18 @@ static int c;                   // error: inconsistent linkage
 extern int d;                   // d has external linkage
 static int d;                   // error: inconsistent linkage
 ```
 The name of a declared but undefined class can be used in an `extern`
 declaration. Such a declaration can only be used in ways that do not
 require a complete class type.
 ``` cpp
 struct S;
 extern S a;
 extern S f();
 extern void g(S);
@@ -337,21 +389,27 @@ void h() {
   g(a);                         // error: S is incomplete
   f();                          // error: S is incomplete
 }
 ```
-The `mutable` specifier can be applied only to names of class data
-members ([[class.mem]]) and cannot be applied to names declared `const`
-or `static`, and cannot be applied to reference members.
 ``` cpp
 class X {
   mutable const int* p;         // OK
   mutable int* const q;         // ill-formed
 };
 ```
 The `mutable` specifier on a class data member nullifies a `const`
 specifier applied to the containing class object and permits
 modification of the mutable class member even though the rest of the
 object is `const` ([[dcl.type.cv]]).
@@ -359,48 +417,14 @@ object is `const` ([[dcl.type.cv]]).
 can be used only in function declarations.
 ``` bnf
 function-specifier:
-    'inline'
     'virtual'
     'explicit'
 ```
-A function declaration ([[dcl.fct]],  [[class.mfct]], [[class.friend]])
-with an `inline` specifier declares an *inline function*. The inline
-specifier indicates to the implementation that inline substitution of
-the function body at the point of call is to be preferred to the usual
-function call mechanism. An implementation is not required to perform
-this inline substitution at the point of call; however, even if this
-inline substitution is omitted, the other rules for inline functions
-defined by  [[dcl.fct.spec]] shall still be respected.
-A function defined within a class definition is an inline function. The
-`inline` specifier shall not appear on a block scope function
-declaration.[^2] If the `inline` specifier is used in a friend
-declaration, that declaration shall be a definition or the function
-shall have previously been declared inline.
-An inline function shall be defined in every translation unit in which
-it is odr-used and shall have exactly the same definition in every
-case ([[basic.def.odr]]). A call to the inline function may be
-encountered before its definition appears in the translation unit. If
-the definition of a function appears in a translation unit before its
-first declaration as inline, the program is ill-formed. If a function
-with external linkage is declared inline in one translation unit, it
-shall be declared inline in all translation units in which it appears;
-no diagnostic is required. An `inline` function with external linkage
-shall have the same address in all translation units. A `static` local
-variable in an `extern` `inline` function always refers to the same
-object. A string literal in the body of an `extern` `inline` function is
-the same object in different translation units. A string literal
-appearing in a default argument is not in the body of an inline function
-merely because the expression is used in a function call from that
-inline function. A type defined within the body of an `extern inline`
-function is the same type in every translation unit.
 The `virtual` specifier shall be used only in the initial declaration of
 a non-static class member function; see  [[class.virtual]].
 The `explicit` specifier shall be used only in the declaration of a
 constructor or conversion function within its class definition; see
@@ -410,14 +434,16 @@ constructor or conversion function within its class definition; see
 Declarations containing the *decl-specifier* `typedef` declare
 identifiers that can be used later for naming fundamental (
 [[basic.fundamental]]) or compound ([[basic.compound]]) types. The
 `typedef` specifier shall not be combined in a *decl-specifier-seq* with
-any other kind of specifier except a *type-specifier,* and it shall not
-be used in the *decl-specifier-seq* of a *parameter-declaration* (
-[[dcl.fct]]) nor in the *decl-specifier-seq* of a
-*function-definition* ([[dcl.fct.def]]).
 ``` bnf
 typedef-name:
     identifier
 ```
@@ -426,11 +452,15 @@ A name declared with the `typedef` specifier becomes a *typedef-name*.
 Within the scope of its declaration, a *typedef-name* is syntactically
 equivalent to a keyword and names the type associated with the
 identifier in the way described in Clause  [[dcl.decl]]. A
 *typedef-name* is thus a synonym for another type. A *typedef-name* does
 not introduce a new type the way a class declaration ([[class.name]])
-or enum declaration does. after
 ``` cpp
 typedef int MILES, *KLICKSP;
 ```
@@ -440,88 +470,121 @@ the constructions
 MILES distance;
 extern KLICKSP metricp;
 ```
 are all correct declarations; the type of `distance` is `int` and that
-of `metricp` is “pointer to `int`.”
 A *typedef-name* can also be introduced by an *alias-declaration*. The
 *identifier* following the `using` keyword becomes a *typedef-name* and
 the optional *attribute-specifier-seq* following the *identifier*
-appertains to that *typedef-name*. It has the same semantics as if it
-were introduced by the `typedef` specifier. In particular, it does not
-define a new type and it shall not appear in the *type-id*.
 ``` cpp
 using handler_t = void (*)(int);
 extern handler_t ignore;
 extern void (*ignore)(int);         // redeclare ignore
 using cell = pair<void*, cell*>;    // ill-formed
 ```
 In a given non-class scope, a `typedef` specifier can be used to
 redefine the name of any type declared in that scope to refer to the
 type to which it already refers.
 ``` cpp
-typedef struct s { /* ... */ } s;
 typedef int I;
 typedef int I;
 typedef I I;
 ```
 In a given class scope, a `typedef` specifier can be used to redefine
 any *class-name* declared in that scope that is not also a
 *typedef-name* to refer to the type to which it already refers.
 ``` cpp
 struct S {
   typedef struct A { } A;       // OK
   typedef struct B B;           // OK
   typedef A A;                  // error
 };
 ```
 If a `typedef` specifier is used to redefine in a given scope an entity
 that can be referenced using an *elaborated-type-specifier*, the entity
 can continue to be referenced by an *elaborated-type-specifier* or as an
 enumeration or class name in an enumeration or class definition
 respectively.
 ``` cpp
 struct S;
 typedef struct S S;
 int main() {
   struct S* p;                  // OK
 }
 struct S { };                   // OK
 ```
 In a given scope, a `typedef` specifier shall not be used to redefine
 the name of any type declared in that scope to refer to a different
 type.
 ``` cpp
-class complex { /* ... */ };
 typedef int complex;            // error: redefinition
 ```
 Similarly, in a given scope, a class or enumeration shall not be
 declared with the same name as a *typedef-name* that is declared in that
 scope and refers to a type other than the class or enumeration itself.
 ``` cpp
 typedef int complex;
-class complex { /* ... */ }; // error: redefinition
 ```
-A *typedef-name* that names a class type, or a cv-qualified version
-thereof, is also a *class-name* ([[class.name]]). If a *typedef-name*
-is used to identify the subject of an *elaborated-type-specifier* (
-[[dcl.type.elab]]), a class definition (Clause  [[class]]), a
-constructor declaration ([[class.ctor]]), or a destructor declaration (
-[[class.dtor]]), the program is ill-formed.
 ``` cpp
 struct S {
   S();
   ~S();
@@ -531,35 +594,47 @@ typedef struct S T;
 S a = T();                      // OK
 struct T * p;                   // error
 ```
 If the typedef declaration defines an unnamed class (or enum), the first
 *typedef-name* declared by the declaration to be that class type (or
 enum type) is used to denote the class type (or enum type) for linkage
 purposes only ([[basic.link]]).
 ``` cpp
 typedef struct { } *ps, S;      // S is the class name for linkage purposes
 ```
 ### The `friend` specifier <a id="dcl.friend">[[dcl.friend]]</a>
 The `friend` specifier is used to specify access to class members; see
 [[class.friend]].
 ### The `constexpr` specifier <a id="dcl.constexpr">[[dcl.constexpr]]</a>
 The `constexpr` specifier shall be applied only to the definition of a
-variable or variable template, the declaration of a function or function
-template, or the declaration of a static data member of a literal type (
-[[basic.types]]). If any declaration of a function, function template,
-or variable template has a `constexpr` specifier, then all its
-declarations shall contain the `constexpr` specifier. An explicit
-specialization can differ from the template declaration with respect to
-the `constexpr` specifier. Function parameters cannot be declared
-`constexpr`.
 ``` cpp
 constexpr void square(int &x);  // OK: declaration
 constexpr int bufsz = 1024;     // OK: definition
 constexpr struct pixel {        // error: pixel is a type
@@ -581,31 +656,34 @@ int next(constexpr int x) {     // error: not for parameters
      return x + 1;
 }
 extern constexpr int memsz;     // error: not a definition
 ```
 A `constexpr` specifier used in the declaration of a function that is
 not a constructor declares that function to be a *constexpr function*.
 Similarly, a `constexpr` specifier used in a constructor declaration
-declares that constructor to be a *constexpr constructor*. `constexpr`
-functions and `constexpr` constructors are implicitly `inline` (
-[[dcl.fct.spec]]).
-The definition of a `constexpr` function shall satisfy the following
-constraints:
 - it shall not be virtual ([[class.virtual]]);
 - its return type shall be a literal type;
 - each of its parameter types shall be a literal type;
 - its *function-body* shall be `= delete`, `= default`, or a
   *compound-statement* that does not contain
   - an *asm-definition*,
   - a `goto` statement,
   - a *try-block*, or
   - a definition of a variable of non-literal type or of static or
     thread storage duration or for which no initialization is performed.
 ``` cpp
 constexpr int square(int x)
   { return x * x; }             // OK
 constexpr long long_max()
   { return 2147483647; }        // OK
@@ -629,51 +707,60 @@ constexpr int g(int x, int n) { // OK
   while (--n > 0) r *= x;
   return r;
 }
 ```
-The definition of a `constexpr` constructor shall satisfy the following
-constraints:
 - the class shall not have any virtual base classes;
 - each of the parameter types shall be a literal type;
-- its *function-body* shall not be a *function-try-block*;
 In addition, either its *function-body* shall be `= delete`, or it shall
-satisfy the following constraints:
 - either its *function-body* shall be `= default`, or the
   *compound-statement* of its *function-body* shall satisfy the
- constraints for a *function-body* of a `constexpr` function;
-- every non-variant non-static data member and base class sub-object
   shall be initialized ([[class.base.init]]);
 - if the class is a union having variant members ([[class.union]]),
   exactly one of them shall be initialized;
 - if the class is a union-like class, but is not a union, for each of
   its anonymous union members having variant members, exactly one of
   them shall be initialized;
 - for a non-delegating constructor, every constructor selected to
-  initialize non-static data members and base class sub-objects shall be
-  a `constexpr` constructor;
 - for a delegating constructor, the target constructor shall be a
- `constexpr` constructor.
 ``` cpp
 struct Length {
   constexpr explicit Length(int i = 0) : val(i) { }
 private:
   int val;
 };
 ```
-For a non-template, non-defaulted `constexpr` function or a
-non-template, non-defaulted, non-inheriting `constexpr` constructor, if
-no argument values exist such that an invocation of the function or
-constructor could be an evaluated subexpression of a core constant
-expression ([[expr.const]]), the program is ill-formed; no diagnostic
 required.
 ``` cpp
 constexpr int f(bool b)
   { return b ? throw 0 : 0; }           // OK
 constexpr int f() { return f(true); }   // ill-formed, no diagnostic required
@@ -688,66 +775,113 @@ struct D : B {
   constexpr D() : B(global) { }         // ill-formed, no diagnostic required
                                         // lvalue-to-rvalue conversion on non-constant global
 };
 ```
-If the instantiated template specialization of a `constexpr` function
 template or member function of a class template would fail to satisfy
-the requirements for a `constexpr` function or `constexpr` constructor,
-that specialization is still a `constexpr` function or `constexpr`
-constructor, even though a call to such a function cannot appear in a
-constant expression. If no specialization of the template would satisfy
-the requirements for a `constexpr` function or `constexpr` constructor
-when considered as a non-template function or constructor, the template
-is ill-formed; no diagnostic required.
-A call to a `constexpr` function produces the same result as a call to
-an equivalent non-`constexpr` function in all respects except that a
-call to a `constexpr` function can appear in a constant expression.
-The `constexpr` specifier has no effect on the type of a `constexpr`
-function or a `constexpr` constructor.
 ``` cpp
 constexpr int bar(int x, int y)         // OK
     { return x + y + x*y; }
 // ...
 int bar(int x, int y)                   // error: redefinition of bar
     { return x * 2 + 3 * y; }
 ```
 A `constexpr` specifier used in an object declaration declares the
 object as `const`. Such an object shall have literal type and shall be
-initialized. If it is initialized by a constructor call, that call shall
-be a constant expression ([[expr.const]]). Otherwise, or if a
-`constexpr` specifier is used in a reference declaration, every
-full-expression that appears in its initializer shall be a constant
-expression. Each implicit conversion used in converting the initializer
-expressions and each constructor call used for the initialization is
-part of such a full-expression.
 ``` cpp
 struct pixel {
   int x, y;
 };
 constexpr pixel ur = { 1294, 1024 };    // OK
 constexpr pixel origin;                 // error: initializer missing
 ```
 ### Type specifiers <a id="dcl.type">[[dcl.type]]</a>
 The type-specifiers are
 ``` bnf
 type-specifier:
-    trailing-type-specifier
-    class-specifier
-    enum-specifier
-```
-``` bnf
-trailing-type-specifier:
   simple-type-specifier
   elaborated-type-specifier
   typename-specifier
   cv-qualifier
 ```
@@ -757,74 +891,91 @@ type-specifier-seq:
     type-specifier attribute-specifier-seqₒₚₜ
     type-specifier type-specifier-seq
 ```
 ``` bnf
-trailing-type-specifier-seq:
-  trailing-type-specifier attribute-specifier-seqₒₚₜ
-  trailing-type-specifier trailing-type-specifier-seq
 ```
 The optional *attribute-specifier-seq* in a *type-specifier-seq* or a
-*trailing-type-specifier-seq* appertains to the type denoted by the
-preceding *type-specifier*s ([[dcl.meaning]]). The
-*attribute-specifier-seq* affects the type only for the declaration it
-appears in, not other declarations involving the same type.
-As a general rule, at most one *type-specifier* is allowed in the
-complete *decl-specifier-seq* of a *declaration* or in a
-*type-specifier-seq* or *trailing-type-specifier-seq*. The only
-exceptions to this rule are the following:
 - `const` can be combined with any type specifier except itself.
 - `volatile` can be combined with any type specifier except itself.
 - `signed` or `unsigned` can be combined with `char`, `long`, `short`,
   or `int`.
 - `short` or `long` can be combined with `int`.
 - `long` can be combined with `double`.
 - `long` can be combined with `long`.
 Except in a declaration of a constructor, destructor, or conversion
-function, at least one *type-specifier* that is not a *cv-qualifier*
-shall appear in a complete *type-specifier-seq* or a complete
-*decl-specifier-seq*.[^3] A *type-specifier-seq* shall not define a
-class or enumeration unless it appears in the *type-id* of an
-*alias-declaration* ([[dcl.typedef]]) that is not the *declaration* of
-a *template-declaration*.
-*enum-specifier*s, *class-specifier*s, and *typename-specifier*s are
-discussed in [[dcl.enum]], Clause  [[class]], and [[temp.res]],
-respectively. The remaining *type-specifier*s are discussed in the rest
-of this section.
-#### The *cv-qualifiers* <a id="dcl.type.cv">[[dcl.type.cv]]</a>
-There are two *cv-qualifiers*, `const` and `volatile`. Each
 *cv-qualifier* shall appear at most once in a *cv-qualifier-seq*. If a
 *cv-qualifier* appears in a *decl-specifier-seq*, the
-*init-declarator-list* of the declaration shall not be empty.
-[[basic.type.qualifier]] and [[dcl.fct]] describe how cv-qualifiers
-affect object and function types. Redundant cv-qualifications are
-ignored. For example, these could be introduced by typedefs.
-Declaring a variable `const` can affect its linkage ([[dcl.stc]]) and
-its usability in constant expressions ([[expr.const]]). As described
-in  [[dcl.init]], the definition of an object or subobject of
-const-qualified type must specify an initializer or be subject to
-default-initialization.
 A pointer or reference to a cv-qualified type need not actually point or
 refer to a cv-qualified object, but it is treated as if it does; a
 const-qualified access path cannot be used to modify an object even if
 the object referenced is a non-const object and can be modified through
-some other access path. Cv-qualifiers are supported by the type system
-so that they cannot be subverted without casting ([[expr.const.cast]]).
 Except that any class member declared `mutable` ([[dcl.stc]]) can be
 modified, any attempt to modify a `const` object during its lifetime (
 [[basic.life]]) results in undefined behavior.
 ``` cpp
 const int ci = 3;                       // cv-qualified (initialized as required)
 ci = 4;                                 // ill-formed: attempt to modify const
 int i = 2;                              // not cv-qualified
@@ -839,11 +990,11 @@ ip = const_cast<int*>(cip);     // cast needed to convert const int* to int*
 const int* ciq = new const int (3);     // initialized as required
 int* iq = const_cast<int*>(ciq);        // cast required
 *iq = 4;                                // undefined: modifies a const object
 ```
-For another example
 ``` cpp
 struct X {
   mutable int i;
   int j;
@@ -859,31 +1010,35 @@ y.x.j++;                        // ill-formed: const-qualified member modified
 Y* p = const_cast<Y*>(&y);              // cast away const-ness of y
 p->x.i = 99;                            // well-formed: mutable member can be modified
 p->x.j = 99;                            // undefined: modifies a const member
 ```
-What constitutes an access to an object that has volatile-qualified type
-is implementation-defined. If an attempt is made to refer to an object
-defined with a volatile-qualified type through the use of a glvalue with
-a non-volatile-qualified type, the program behavior is undefined.
-`volatile` is a hint to the implementation to avoid aggressive
-optimization involving the object because the value of the object might
-be changed by means undetectable by an implementation. Furthermore, for
-some implementations, `volatile` might indicate that special hardware
-instructions are required to access the object. See  [[intro.execution]]
-for detailed semantics. In general, the semantics of `volatile` are
-intended to be the same in C++as they are in C.
 #### Simple type specifiers <a id="dcl.type.simple">[[dcl.type.simple]]</a>
 The simple type specifiers are
 ``` bnf
 simple-type-specifier:
     nested-name-specifierₒₚₜ type-name
     nested-name-specifier 'template' simple-template-id
     'char'
     'char16_t'
     'char32_t'
     'wchar_t'
     'bool'
@@ -911,23 +1066,28 @@ type-name:
 decltype-specifier:
   'decltype' '(' expression ')'
   'decltype' '(' 'auto' ')'
 ```
-The `auto` specifier is a placeholder for a type to be deduced (
-[[dcl.spec.auto]]). The other *simple-type-specifier*s specify either a
 previously-declared type, a type determined from an expression, or one
 of the fundamental types ([[basic.fundamental]]). Table
 [[tab:simple.type.specifiers]] summarizes the valid combinations of
 *simple-type-specifier*s and the types they specify.
 **Table: *simple-type-specifier*{s} and the types they specify** <a id="tab:simple.type.specifiers">[tab:simple.type.specifiers]</a>
-| | |
 | ---------------------- | -------------------------------------- |
 | *type-name*            | the type named                         |
 | *simple-template-id*   | the type as defined in~ [[temp.names]] |
 | char                   | ``char''                               |
 | unsigned char          | ``unsigned char''                      |
 | signed char            | ``signed char''                        |
 | char16_t               | ``char16_t''                           |
 | char32_t               | ``char32_t''                           |
@@ -959,90 +1119,109 @@ of the fundamental types ([[basic.fundamental]]). Table
 | float                  | ``float''                              |
 | double                 | ``double''                             |
 | long double            | ``long double''                        |
 | void                   | ``void''                               |
 | auto                   | placeholder for a type to be deduced   |
 | decltype(*expression*) | the type as defined below              |
-When multiple *simple-type-specifiers* are allowed, they can be freely
-intermixed with other *decl-specifiers* in any order. It is
-implementation-defined whether objects of `char` type are represented as
-signed or unsigned quantities. The `signed` specifier forces `char`
-objects to be signed; it is redundant in other contexts.
 For an expression `e`, the type denoted by `decltype(e)` is defined as
 follows:
-- if `e` is an unparenthesized *id-expression* or an unparenthesized
- class member access ([[expr.ref]]), `decltype(e)` is the type of the
- entity named by `e`. If there is no such entity, or if `e` names a set
-  of overloaded functions, the program is ill-formed;
 - otherwise, if `e` is an xvalue, `decltype(e)` is `T&&`, where `T` is
   the type of `e`;
 - otherwise, if `e` is an lvalue, `decltype(e)` is `T&`, where `T` is
   the type of `e`;
 - otherwise, `decltype(e)` is the type of `e`.
 The operand of the `decltype` specifier is an unevaluated operand
 (Clause  [[expr]]).
 ``` cpp
 const int&& foo();
 int i;
 struct A { double x; };
 const A* a = new A();
-decltype(foo()) x1 = 0; // type is const int&&
 decltype(i) x2;                 // type is int
 decltype(a->x) x3;              // type is double
 decltype((a->x)) x4 = x3;       // type is const double&
 ```
-The rules for determining types involving `decltype(auto)` are specified
-in  [[dcl.spec.auto]].
-in the case where the operand of a *decltype-specifier* is a function
-call and the return type of the function is a class type, a special
-rule ([[expr.call]]) ensures that the return type is not required to be
-complete (as it would be if the call appeared in a sub-expression or
-outside of a *decltype-specifier*). In this context, the common purpose
-of writing the expression is merely to refer to its type. In that sense,
-a *decltype-specifier* is analogous to a use of a *typedef-name*, so the
-usual reasons for requiring a complete type do not apply. In particular,
-it is not necessary to allocate storage for a temporary object or to
-enforce the semantic constraints associated with invoking the type’s
-destructor.
 ``` cpp
 template<class T> struct A { ~A() = delete; };
 template<class T> auto h()
   -> A<T>;
 template<class T> auto i(T)     // identity
   -> T;
 template<class T> auto f(T)     // #1
-  -> decltype(i(h<T>()));       // forces completion of A<T> and implicitly uses
-                                // A<T>::~A() for the temporary introduced by the
-                                // use of h(). (A temporary is not introduced
-                                // as a result of the use of i().)
 template<class T> auto f(T)     // #2
   -> void;
 auto g() -> void {
-  f(42);                        // OK: calls #2. (#1 is not a viable candidate: type
-                                // deduction fails~([temp.deduct]) because A<int>::~{A()}
-                                // is implicitly used in its decltype-specifier)
 }
 template<class T> auto q(T)
-  -> decltype((h<T>()));        // does not force completion of A<T>; A<T>::~A() is
-                                // not implicitly used within the context of this decltype-specifier
 void r() {
-  q(42);                        // Error: deduction against q succeeds, so overload resolution
-                                // selects the specialization ``q(T) -> decltype((h<T>())) [with T=int]''.
                                 // The return type is A<int>, so a temporary is introduced and its
                                 // destructor is used, so the program is ill-formed.
 }
 ```
 #### Elaborated type specifiers <a id="dcl.type.elab">[[dcl.type.elab]]</a>
 ``` bnf
 elaborated-type-specifier:
     class-key attribute-specifier-seqₒₚₜ nested-name-specifierₒₚₜ identifier
@@ -1076,20 +1255,26 @@ class whenever it is named.
 resolves to a *class-name* or *enum-name*, the
 *elaborated-type-specifier* introduces it into the declaration the same
 way a *simple-type-specifier* introduces its *type-name*. If the
 *identifier* resolves to a *typedef-name* or the *simple-template-id*
 resolves to an alias template specialization, the
-*elaborated-type-specifier* is ill-formed. This implies that, within a
-class template with a template *type-parameter* `T`, the declaration
 ``` cpp
 friend class T;
 ```
 is ill-formed. However, the similar declaration `friend T;` is allowed (
 [[class.friend]]).
 The *class-key* or `enum` keyword present in the
 *elaborated-type-specifier* shall agree in kind with the declaration to
 which the name in the *elaborated-type-specifier* refers. This rule also
 applies to the form of *elaborated-type-specifier* that declares a
 *class-name* or `friend` class since it can be construed as referring to
@@ -1098,164 +1283,130 @@ the `enum` keyword shall be used to refer to an enumeration (
 [[dcl.enum]]), the `union` *class-key* shall be used to refer to a union
 (Clause  [[class]]), and either the `class` or `struct` *class-key*
 shall be used to refer to a class (Clause  [[class]]) declared using the
 `class` or `struct` *class-key*.
 ``` cpp
 enum class E { a, b };
 enum E x = E::a;                // OK
 ```
-#### `auto` specifier <a id="dcl.spec.auto">[[dcl.spec.auto]]</a>
-The `auto` and `decltype(auto)` *type-specifier*s designate a
-placeholder type that will be replaced later, either by deduction from
-an initializer or by explicit specification with a
-*trailing-return-type*. The `auto` *type-specifier* is also used to
-signify that a lambda is a generic lambda.
 The placeholder type can appear with a function declarator in the
 *decl-specifier-seq*, *type-specifier-seq*, *conversion-function-id*, or
 *trailing-return-type*, in any context where such a declarator is valid.
 If the function declarator includes a *trailing-return-type* (
-[[dcl.fct]]), that specifies the declared return type of the function.
-If the declared return type of the function contains a placeholder type,
-the return type of the function is deduced from `return` statements in
-the body of the function, if any.
 If the `auto` *type-specifier* appears as one of the *decl-specifier*s
 in the *decl-specifier-seq* of a *parameter-declaration* of a
 *lambda-expression*, the lambda is a *generic lambda* (
-[[expr.prim.lambda]]).
 ``` cpp
 auto glambda = [](int i, auto a) { return i; };     // OK: a generic lambda
 ```
 The type of a variable declared using `auto` or `decltype(auto)` is
-deduced from its initializer. This use is allowed when declaring
-variables in a block ([[stmt.block]]), in namespace scope (
-[[basic.scope.namespace]]), and in a  ([[stmt.for]]). `auto` or
-`decltype(auto)` shall appear as one of the *decl-specifier*s in the
-*decl-specifier-seq* and the *decl-specifier-seq* shall be followed by
-one or more *init-declarator*s, each of which shall have a non-empty
 *initializer*. In an *initializer* of the form
 ``` cpp
 ( expression-list )
 ```
 the *expression-list* shall be a single *assignment-expression*.
 ``` cpp
 auto x = 5;                     // OK: x has type int
 const auto *v = &x, u = 6;      // OK: v has type const int*, u has type const int
 static auto y = 0.0;            // OK: y has type double
 auto int r;                     // error: auto is not a storage-class-specifier
 auto f() -> int;                // OK: f returns int
 auto g() { return 0.0; }        // OK: g returns double
 auto h();                       // OK: h's return type will be deduced when it is defined
 ```
-A placeholder type can also be used in declaring a variable in the of a
-selection statement ([[stmt.select]]) or an iteration statement (
-[[stmt.iter]]), in the in the or of a  ([[expr.new]]), in a
-*for-range-declaration*, and in declaring a static data member with a
-*brace-or-equal-initializer* that appears within the of a class
-definition ([[class.static.data]]).
 A program that uses `auto` or `decltype(auto)` in a context not
 explicitly allowed in this section is ill-formed.
-When a variable declared using a placeholder type is initialized, or a
-`return` statement occurs in a function declared with a return type that
-contains a placeholder type, the deduced return type or variable type is
-determined from the type of its initializer. In the case of a `return`
-with no operand, the initializer is considered to be `void()`. Let `T`
-be the declared type of the variable or return type of the function. If
-the placeholder is the `auto` *type-specifier*, the deduced type is
-determined using the rules for template argument deduction. If the
-deduction is for a `return` statement and the initializer is a
-*braced-init-list* ([[dcl.init.list]]), the program is ill-formed.
-Otherwise, obtain `P` from `T` by replacing the occurrences of `auto`
-with either a new invented type template parameter `U` or, if the
-initializer is a *braced-init-list*, with `std::initializer_list<U>`.
-Deduce a value for `U` using the rules of template argument deduction
-from a function call ([[temp.deduct.call]]), where `P` is a function
-template parameter type and the initializer is the corresponding
-argument. If the deduction fails, the declaration is ill-formed.
-Otherwise, the type deduced for the variable or return type is obtained
-by substituting the deduced `U` into `P`.
-``` cpp
-auto x1 = { 1, 2 };         // decltype(x1) is std::initializer_list<int>
-auto x2 = { 1, 2.0 };       // error: cannot deduce element type
-```
-``` cpp
-const auto &i = expr;
-```
-The type of `i` is the deduced type of the parameter `u` in the call
-`f(expr)` of the following invented function template:
-``` cpp
-template <class U> void f(const U& u);
-```
-If the placeholder is the `decltype(auto)` *type-specifier*, the
-declared type of the variable or return type of the function shall be
-the placeholder alone. The type deduced for the variable or return type
-is determined as described in  [[dcl.type.simple]], as though the
-initializer had been the operand of the `decltype`.
-``` cpp
-int i;
-int&& f();
-auto           x3a = i;        // decltype(x3a) is int
-decltype(auto) x3d = i;        // decltype(x3d) is int
-auto           x4a = (i);      // decltype(x4a) is int
-decltype(auto) x4d = (i);      // decltype(x4d) is int&
-auto           x5a = f();      // decltype(x5a) is int
-decltype(auto) x5d = f();      // decltype(x5d) is int&&
-auto           x6a = { 1, 2 }; // decltype(x6a) is std::initializer_list<int>
-decltype(auto) x6d = { 1, 2 }; // error, { 1, 2 } is not an expression
-auto          *x7a = &i;       // decltype(x7a) is int*
-decltype(auto)*x7d = &i;       // error, declared type is not plain decltype(auto)
-```
 If the *init-declarator-list* contains more than one *init-declarator*,
 they shall all form declarations of variables. The type of each declared
-variable is determined as described above, and if the type that replaces
-the placeholder type is not the same in each deduction, the program is
-ill-formed.
 ``` cpp
 auto x = 5, *y = &x;            // OK: auto is int
 auto a = 5, b = { 1, 2 };       // error: different types for auto
 ```
 If a function with a declared return type that contains a placeholder
-type has multiple `return` statements, the return type is deduced for
-each `return` statement. If the type deduced is not the same in each
-deduction, the program is ill-formed.
 If a function with a declared return type that uses a placeholder type
-has no `return` statements, the return type is deduced as though from a
-`return` statement with no operand at the closing brace of the function
-body.
 ``` cpp
 auto  f() { }                   // OK, return type is void
 auto* g() { }                   // error, cannot deduce auto* from void()
 ```
 If the type of an entity with an undeduced placeholder type is needed to
 determine the type of an expression, the program is ill-formed. Once a
-`return` statement has been seen in a function, however, the return type
-deduced from that statement can be used in the rest of the function,
-including in other `return` statements.
 ``` cpp
 auto n = n;                     // error, n's type is unknown
 auto f();
 void g() { &f; }                // error, f's return type is unknown
@@ -1265,30 +1416,41 @@ auto sum(int i) {
   else
     return sum(i-1)+i;          // OK, sum's return type has been deduced
 }
 ```
 Return type deduction for a function template with a placeholder in its
 declared type occurs when the definition is instantiated even if the
 function body contains a `return` statement with a non-type-dependent
-operand. Therefore, any use of a specialization of the function template
-will cause an implicit instantiation. Any errors that arise from this
-instantiation are not in the immediate context of the function type and
-can result in the program being ill-formed.
 ``` cpp
 template <class T> auto f(T t) { return t; }    // return type deduced at instantiation time
 typedef decltype(f(1)) fint_t;                  // instantiates f<int> to deduce return type
 template<class T> auto f(T* t) { return *t; }
 void g() { int (*p)(int*) = &f; }               // instantiates both fs to determine return types,
                                                 // chooses second
 ```
 Redeclarations or specializations of a function or function template
 with a declared return type that uses a placeholder type shall also use
 that placeholder, not a deduced type.
 ``` cpp
 auto f();
 auto f() { return 42; }                         // return type is int
 auto f();                                       // OK
 int f();                                        // error, cannot be overloaded with auto f()
@@ -1309,29 +1471,164 @@ template <typename T> struct A {
   friend T frf(T);
 };
 auto frf(int i) { return i; }                   // not a friend of A<int>
 ```
 A function declared with a return type that uses a placeholder type
 shall not be `virtual` ([[class.virtual]]).
 An explicit instantiation declaration ([[temp.explicit]]) does not
 cause the instantiation of an entity declared using a placeholder type,
 but it also does not prevent that entity from being instantiated as
 needed to determine its type.
 ``` cpp
 template <typename T> auto f(T t) { return t; }
 extern template auto f(int);    // does not instantiate f<int>
 int (*p)(int) = f;              // instantiates f<int> to determine its return type, but an explicit
                                 // instantiation definition is still required somewhere in the program
 ```
 ## Enumeration declarations <a id="dcl.enum">[[dcl.enum]]</a>
 An enumeration is a distinct type ([[basic.compound]]) with named
-constants. Its name becomes an *enum-name*, within its scope.
 ``` bnf
 enum-name:
     identifier
 ```
@@ -1342,18 +1639,21 @@ enum-specifier:
     enum-head '{' enumerator-list ', }'
 ```
 ``` bnf
 enum-head:
-    enum-key attribute-specifier-seqₒₚₜ identifierₒₚₜ enum-baseₒₚₜ
-    enum-key attribute-specifier-seqₒₚₜ nested-name-specifier identifier
-  enum-baseₒₚₜ
 ```
 ``` bnf
 opaque-enum-declaration:
-    enum-key attribute-specifier-seqₒₚₜ identifier enum-baseₒₚₜ ';'
 ```
 ``` bnf
 enum-key:
     'enum'
@@ -1378,61 +1678,85 @@ enumerator-definition:
     enumerator '=' constant-expression
 ```
 ``` bnf
 enumerator:
-    identifier
 ```
 The optional *attribute-specifier-seq* in the *enum-head* and the
 *opaque-enum-declaration* appertains to the enumeration; the attributes
 in that *attribute-specifier-seq* are thereafter considered attributes
 of the enumeration whenever it is named. A `:` following “`enum`
-*identifier*” is parsed as part of an *enum-base*. This resolves a
-potential ambiguity between the declaration of an enumeration with an
-*enum-base* and the declaration of an unnamed bit-field of enumeration
-type.
 ``` cpp
    struct S {
      enum E : int {};
      enum E : int {};           // error: redeclaration of enumeration
    };
 ```
 The enumeration type declared with an *enum-key* of only `enum` is an
-unscoped enumeration, and its *enumerator*s are *unscoped enumerators*.
-The *enum-key*s `enum class` and `enum struct` are semantically
-equivalent; an enumeration type declared with one of these is a *scoped
-enumeration*, and its *enumerator*s are *scoped enumerators*. The
-optional *identifier* shall not be omitted in the declaration of a
-scoped enumeration. The *type-specifier-seq* of an *enum-base* shall
-name an integral type; any cv-qualification is ignored. An
-*opaque-enum-declaration* declaring an unscoped enumeration shall not
-omit the *enum-base*. The identifiers in an *enumerator-list* are
-declared as constants, and can appear wherever constants are required.
-An *enumerator-definition* with `=` gives the associated *enumerator*
-the value indicated by the *constant-expression*. If the first
-*enumerator* has no *initializer*, the value of the corresponding
 constant is zero. An *enumerator-definition* without an *initializer*
 gives the *enumerator* the value obtained by increasing the value of the
 previous *enumerator* by one.
 ``` cpp
 enum { a, b, c=0 };
 enum { d, e, f=e+2 };
 ```
 defines `a`, `c`, and `d` to be zero, `b` and `e` to be `1`, and `f` to
 be `3`.
 An *opaque-enum-declaration* is either a redeclaration of an enumeration
-in the current scope or a declaration of a new enumeration. An
-enumeration declared by an *opaque-enum-declaration* has fixed
-underlying type and is a complete type. The list of enumerators can be
-provided in a later redeclaration with an *enum-specifier*. A scoped
-enumeration shall not be later redeclared as unscoped or with a
 different underlying type. An unscoped enumeration shall not be later
 redeclared as scoped and each redeclaration shall include an *enum-base*
 specifying the same underlying type as in the original declaration.
 If the *enum-key* is followed by a *nested-name-specifier*, the
@@ -1441,12 +1765,12 @@ declared directly in the class or namespace to which the
 *nested-name-specifier* refers (i.e., neither inherited nor introduced
 by a *using-declaration*), and the *enum-specifier* shall appear in a
 namespace enclosing the previous declaration.
 Each enumeration defines a type that is different from all other types.
-Each enumeration also has an underlying type. The underlying type can be
-explicitly specified using an *enum-base*. For a scoped enumeration
 type, the underlying type is `int` if it is not explicitly specified. In
 both of these cases, the underlying type is said to be *fixed*.
 Following the closing brace of an *enum-specifier*, each enumerator has
 the type of its enumeration. If the underlying type is fixed, the type
 of each enumerator prior to the closing brace is the underlying type and
@@ -1486,29 +1810,31 @@ unless the value of an enumerator cannot fit in an `int` or
 is as if the enumeration had a single enumerator with value 0.
 For an enumeration whose underlying type is fixed, the values of the
 enumeration are the values of the underlying type. Otherwise, for an
 enumeration where eₘin is the smallest enumerator and eₘax is the
-largest, the values of the enumeration are the values in the range bₘᵢₙ
-to bₘₐₓ, defined as follows: Let K be 1 for a two’s complement
-representation and 0 for a one’s complement or sign-magnitude
-representation. bₘₐₓ is the smallest value greater than or equal to
-max(|eₘᵢₙ| - K, |eₘₐₓ|) and equal to $2^M-1$, where M is a non-negative
-integer. bₘᵢₙ is zero if eₘᵢₙ is non-negative and -(bₘₐₓ+K) otherwise.
 The size of the smallest bit-field large enough to hold all the values
-of the enumeration type is max(M,1) if bₘᵢₙ is zero and M+1 otherwise.
 It is possible to define an enumeration that has values not defined by
 any of its enumerators. If the *enumerator-list* is empty, the values of
 the enumeration are as if the enumeration had a single enumerator with
 value 0.[^4]
-Two enumeration types are *layout-compatible* if they have the same
-*underlying type*.
 The value of an enumerator or an object of an unscoped enumeration type
 is converted to an integer by integral promotion ([[conv.prom]]).
 ``` cpp
   enum color { red, yellow, green=20, blue };
   color col = red;
   color* cp = &col;
   if (*cp == blue)              // ...
@@ -1520,15 +1846,12 @@ type. The possible values of an object of type `color` are `red`,
 `yellow`, `green`, `blue`; these values can be converted to the integral
 values `0`, `1`, `20`, and `21`. Since enumerations are distinct types,
 objects of type `color` can be assigned only values of type `color`.
 ``` cpp
-color c = 1;                    // error: type mismatch,
- // no conversion from int to color
-int i = yellow;                 // OK: yellow converted to integral value 1
-                                // integral promotion
 ```
 Note that this implicit `enum` to `int` conversion is not provided for a
 scoped enumeration:
@@ -1537,15 +1860,18 @@ enum class Col { red, yellow, green };
 int x = Col::red;               // error: no Col to int conversion
 Col y = Col::red;
 if (y) { }                      // error: no Col to bool conversion
 ```
 Each *enum-name* and each unscoped *enumerator* is declared in the scope
 that immediately contains the *enum-specifier*. Each scoped *enumerator*
 is declared in the scope of the enumeration. These names obey the scope
-rules defined for all names in ([[basic.scope]]) and (
-[[basic.lookup]]).
 ``` cpp
 enum direction { left='l', right='r' };
 void g()  {
@@ -1561,14 +1887,18 @@ void h()  {
   a = high;                     // error: high not in scope
   a = altitude::low;            // OK
 }
 ```
 An enumerator declared in class scope can be referred to using the class
 member access operators (`::`, `.` (dot) and `->` (arrow)), see
 [[expr.ref]].
 ``` cpp
 struct X {
   enum direction { left='l', right='r' };
   int f(int i) { return i==left ? 0 : i==right ? 1 : 2; }
 };
@@ -1581,10 +1911,22 @@ void g(X* p) {
   i = p->f(p->left);            // OK
   // ...
 }
 ```
 ## Namespaces <a id="basic.namespace">[[basic.namespace]]</a>
 A namespace is an optionally-named declarative region. The name of a
 namespace can be used to access entities declared in that namespace;
 that is, the members of the namespace. Unlike other declarative regions,
@@ -1594,72 +1936,67 @@ more translation units.
 The outermost declarative region of a translation unit is a namespace;
 see  [[basic.scope.namespace]].
 ### Namespace definition <a id="namespace.def">[[namespace.def]]</a>
-The grammar for a *namespace-definition* is
 ``` bnf
 namespace-name:
- original-namespace-name
         namespace-alias
 ```
-``` bnf
-original-namespace-name:
-        identifier
-```
 ``` bnf
 namespace-definition:
         named-namespace-definition
         unnamed-namespace-definition
 ```
 ``` bnf
 named-namespace-definition:
- original-namespace-definition
-        extension-namespace-definition
-```
-``` bnf
-original-namespace-definition:
-        'inline'ₒₚₜ 'namespace' identifier '{' namespace-body '}'
-```
-``` bnf
-extension-namespace-definition:
-        'inline'ₒₚₜ 'namespace' original-namespace-name '{' namespace-body '}'
 ```
 ``` bnf
 unnamed-namespace-definition:
-        'inline'ₒₚₜ 'namespace {' namespace-body '}'
 ```
 ``` bnf
 namespace-body:
         declaration-seqₒₚₜ
 ```
-The *identifier* in an *original-namespace-definition* shall not have
-been previously defined in the declarative region in which the
-*original-namespace-definition* appears. The *identifier* in an
-*original-namespace-definition* is the name of the namespace.
-Subsequently in that declarative region, it is treated as an
-*original-namespace-name*.
-The *original-namespace-name* in an *extension-namespace-definition*
-shall have previously been defined in an *original-namespace-definition*
-in the same declarative region.
 Every *namespace-definition* shall appear in the global scope or in a
 namespace scope ([[basic.scope.namespace]]).
 Because a *namespace-definition* contains *declaration*s in its
 *namespace-body* and a *namespace-definition* is itself a *declaration*,
-it follows that *namespace-definitions* can be nested.
 ``` cpp
 namespace Outer {
   int i;
   namespace Inner {
@@ -1668,16 +2005,20 @@ namespace Outer {
     void g() { i++; }           // Inner::i
   }
 }
 ```
 The *enclosing namespaces* of a declaration are those namespaces in
 which the declaration lexically appears, except for a redeclaration of a
 namespace member outside its original namespace (e.g., a definition as
 specified in  [[namespace.memdef]]). Such a redeclaration has the same
 enclosing namespaces as the original declaration.
 ``` cpp
 namespace Q {
   namespace V {
     void f();                   // enclosing namespaces are the global namespace, Q, and Q::V
     class C { void m(); };
@@ -1688,55 +2029,94 @@ namespace Q {
   void V::C::m() {              // enclosing namespaces are the global namespace, Q, and Q::V
   }
 }
 ```
 If the optional initial `inline` keyword appears in a
 *namespace-definition* for a particular namespace, that namespace is
 declared to be an *inline namespace*. The `inline` keyword may be used
-on an *extension-namespace-definition* only if it was previously used on
-the *original-namespace-definition* for that namespace.
 Members of an inline namespace can be used in most respects as though
 they were members of the enclosing namespace. Specifically, the inline
 namespace and its enclosing namespace are both added to the set of
 associated namespaces used in argument-dependent lookup (
 [[basic.lookup.argdep]]) whenever one of them is, and a
 *using-directive* ([[namespace.udir]]) that names the inline namespace
 is implicitly inserted into the enclosing namespace as for an unnamed
 namespace ([[namespace.unnamed]]). Furthermore, each member of the
-inline namespace can subsequently be explicitly instantiated (
-[[temp.explicit]]) or explicitly specialized ([[temp.expl.spec]]) as
-though it were a member of the enclosing namespace. Finally, looking up
-a name in the enclosing namespace via explicit qualification (
-[[namespace.qual]]) will include members of the inline namespace brought
-in by the *using-directive* even if there are declarations of that name
-in the enclosing namespace.
 These properties are transitive: if a namespace `N` contains an inline
 namespace `M`, which in turn contains an inline namespace `O`, then the
 members of `O` can be used as though they were members of `M` or `N`.
 The *inline namespace set* of `N` is the transitive closure of all
 inline namespaces in `N`. The *enclosing namespace set* of `O` is the
 set of namespaces consisting of the innermost non-inline namespace
 enclosing an inline namespace `O`, together with any intervening inline
 namespaces.
 #### Unnamed namespaces <a id="namespace.unnamed">[[namespace.unnamed]]</a>
 An *unnamed-namespace-definition* behaves as if it were replaced by
 ``` bnf
-'inline'ₒₚₜ 'namespace' unique '{ /* empty body */ }'
-'using namespace' unique ';'
-'namespace' unique '{' namespace-body '}'
 ```
 where `inline` appears if and only if it appears in the
-*unnamed-namespace-definition*, all occurrences of *unique* in a
 translation unit are replaced by the same identifier, and this
-identifier differs from all other identifiers in the entire program.[^5]
 ``` cpp
 namespace { int i; }            // unique ::i
 void f() { i++; }               // unique ::i++
@@ -1754,64 +2134,95 @@ void h() {
   A::i++;                       // A::unique ::i
   j++;                          // A::unique ::j
 }
 ```
 #### Namespace member definitions <a id="namespace.memdef">[[namespace.memdef]]</a>
-Members (including explicit specializations of templates (
-[[temp.expl.spec]])) of a namespace can be defined within that
-namespace.
 ``` cpp
 namespace X {
-  void f() { /* ... */ }
 }
 ```
 Members of a named namespace can also be defined outside that namespace
 by explicit qualification ([[namespace.qual]]) of the name being
 defined, provided that the entity being defined was already declared in
 the namespace and the definition appears after the point of declaration
 in a namespace that encloses the declaration’s namespace.
 ``` cpp
 namespace Q {
   namespace V {
     void f();
   }
-  void V::f() { /* ... */ }     // OK
-  void V::g() { /* ... */ }     // error: g() is not yet a member of V
   namespace V {
     void g();
   }
 }
 namespace R {
-  void Q::V::g() { /* ... */ }  // error: R doesn't enclose Q
 }
 ```
-Every name first declared in a namespace is a member of that namespace.
 If a `friend` declaration in a non-local class first declares a class,
-function, class template or function template[^6] the friend is a member
 of the innermost enclosing namespace. The `friend` declaration does not
 by itself make the name visible to unqualified lookup (
 [[basic.lookup.unqual]]) or qualified lookup ([[basic.lookup.qual]]).
-The name of the friend will be visible in its namespace if a matching
-declaration is provided at namespace scope (either before or after the
-class definition granting friendship). If a friend function or function
-template is called, its name may be found by the name lookup that
-considers functions from namespaces and classes associated with the
-types of the function arguments ([[basic.lookup.argdep]]). If the name
-in a `friend` declaration is neither qualified nor a *template-id* and
-the declaration is a function or an *elaborated-type-specifier*, the
-lookup to determine whether the entity has been previously declared
-shall not consider any scopes outside the innermost enclosing namespace.
-The other forms of `friend` declarations cannot declare a new member of
-the innermost enclosing namespace and thus follow the usual lookup
-rules.
 ``` cpp
 // Assume f and g have not yet been declared.
 void h(int);
 template <class T> void f2(T);
@@ -1827,12 +2238,12 @@ namespace A {
   };
   // A::f, A::g and A::h are not visible here
   X x;
   void g() { f(x); }            // definition of A::g
-  void f(X) { /* ... */}       // definition of A::f
-  void h(int) { /* ... */ } // definition of A::h
   // A::f, A::g and A::h are visible here and known to be friends
 }
 using A::x;
@@ -1841,10 +2252,12 @@ void h() {
   A::X::f(x);                   // error: f is not a member of A::X
   A::X::Y::g();                 // error: g is not a member of A::X::Y
 }
 ```
 ### Namespace alias <a id="namespace.alias">[[namespace.alias]]</a>
 A *namespace-alias-definition* declares an alternate name for a
 namespace according to the following grammar:
@@ -1863,57 +2276,75 @@ qualified-namespace-specifier:
     nested-name-specifierₒₚₜ namespace-name
 ```
 The *identifier* in a *namespace-alias-definition* is a synonym for the
 name of the namespace denoted by the *qualified-namespace-specifier* and
-becomes a *namespace-alias*. When looking up a *namespace-name* in a
 *namespace-alias-definition*, only namespace names are considered, see
-[[basic.lookup.udir]].
 In a declarative region, a *namespace-alias-definition* can be used to
 redefine a *namespace-alias* declared in that declarative region to
-refer only to the namespace to which it already refers. the following
-declarations are well-formed:
 ``` cpp
-namespace Company_with_very_long_name { /* ... */ }
 namespace CWVLN = Company_with_very_long_name;
 namespace CWVLN = Company_with_very_long_name;  // OK: duplicate
 namespace CWVLN = CWVLN;
 ```
-A *namespace-name* or *namespace-alias* shall not be declared as the
-name of any other entity in the same declarative region. A
-*namespace-name* defined at global scope shall not be declared as the
-name of any other entity in any global scope of the program. No
-diagnostic is required for a violation of this rule by declarations in
-different translation units.
 ### The `using` declaration <a id="namespace.udecl">[[namespace.udecl]]</a>
-A *using-declaration* introduces a name into the declarative region in
-which the *using-declaration* appears.
 ``` bnf
 using-declaration:
-    'using typename'ₒₚₜ nested-name-specifier unqualified-id ';'
-    'using ::' unqualified-id ';'
 ```
-The member name specified in a *using-declaration* is declared in the
-declarative region in which the *using-declaration* appears. Only the
-specified name is so declared; specifying an enumeration name in a
-*using-declaration* does not declare its enumerators in the
-*using-declaration*’s declarative region. If a *using-declaration* names
-a constructor ([[class.qual]]), it implicitly declares a set of
-constructors in the class in which the *using-declaration* appears (
-[[class.inhctor]]); otherwise the name specified in a
-*using-declaration* is a synonym for a set of declarations in another
-namespace or class.
 Every *using-declaration* is a *declaration* and a *member-declaration*
-and so can be used in a class definition.
 ``` cpp
 struct B {
   void f(char);
   void g(char);
@@ -1926,16 +2357,32 @@ struct D : B {
   void f(int) { f('c'); }       // calls B::f(char)
   void g(int) { g('c'); }       // recursively calls D::g(int)
 };
 ```
-In a *using-declaration* used as a *member-declaration*, the
-*nested-name-specifier* shall name a base class of the class being
-defined. If such a *using-declaration* names a constructor, the
-*nested-name-specifier* shall name a direct base class of the class
-being defined; otherwise it introduces the set of declarations found by
-member name lookup ([[class.member.lookup]],  [[class.qual]]).
 ``` cpp
 class C {
   int g();
 };
@@ -1946,25 +2393,30 @@ class D2 : public B {
   using B::x;                   // OK: x is a union member of base B
   using C::g;                   // error: C isn't a base of D2
 };
 ```
-Since destructors do not have names, a *using-declaration* cannot refer
-to a destructor for a base class. Since specializations of member
-templates for conversion functions are not found by name lookup, they
-are not considered when a *using-declaration* specifies a conversion
-function ([[temp.mem]]). If an assignment operator brought from a base
-class into a derived class scope has the signature of a copy/move
-assignment operator for the derived class ([[class.copy]]), the
 *using-declaration* does not by itself suppress the implicit declaration
-of the derived class assignment operator; the copy/move assignment
-operator from the base class is hidden or overridden by the
-implicitly-declared copy/move assignment operator of the derived class,
-as described below.
 A *using-declaration* shall not name a *template-id*.
 ``` cpp
 struct A {
   template <class T> void f(T);
   template <class T> struct X { };
 };
@@ -1972,34 +2424,39 @@ struct B : A {
   using A::f<double>;           // ill-formed
   using A::X<int>;              // ill-formed
 };
 ```
 A *using-declaration* shall not name a namespace.
 A *using-declaration* shall not name a scoped enumerator.
-A *using-declaration* for a class member shall be a
 *member-declaration*.
 ``` cpp
 struct X {
   int i;
   static int s;
 };
 void f() {
-  using X::i; // error: X::i is a class member
- // and this is not a member declaration.
-  using X::s;       // error: X::s is a class member
-                    // and this is not a member declaration.
 }
 ```
 Members declared by a *using-declaration* can be referred to by explicit
-qualification just like other member names ([[namespace.qual]]). In a
-*using-declaration*, a prefix `::` refers to the global namespace.
 ``` cpp
 void f();
 namespace A {
@@ -2016,78 +2473,83 @@ void h()
   X::f();                       // calls ::f
   X::g();                       // calls A::g
 }
 ```
 A *using-declaration* is a *declaration* and can therefore be used
 repeatedly where (and only where) multiple declarations are allowed.
 ``` cpp
 namespace A {
   int i;
 }
 namespace A1 {
-  using A::i;
-  using A::i;       // OK: double declaration
-}
-void f() {
-  using A::i;
-  using A::i;       // error: double declaration
 }
 struct B {
   int i;
 };
 struct X : B {
-  using B::i;
-  using B::i;       // error: double member declaration
 };
 ```
-Members added to the namespace after the *using-declaration* are not
-considered when a use of the name is made. Thus, additional overloads
-added after the *using-declaration* are ignored, but default function
-arguments ([[dcl.fct.default]]), default template arguments (
 [[temp.param]]), and template specializations ([[temp.class.spec]],
-[[temp.expl.spec]]) are considered.
 ``` cpp
 namespace A {
   void f(int);
 }
-using A::f;         // f is a synonym for A::f;
-                    // that is, for A::f(int).
 namespace A {
   void f(char);
 }
 void foo() {
-  f('a');           // calls f(int),
-}                   // even though f(char) exists.
 void bar() {
-  using A::f;       // f is a synonym for A::f;
-                    // that is, for A::f(int) and A::f(char).
   f('a');           // calls f(char)
 }
 ```
-Partial specializations of class templates are found by looking up the
-primary class template and then considering all partial specializations
-of that template. If a *using-declaration* names a class template,
-partial specializations introduced after the *using-declaration* are
-effectively visible because the primary template is visible (
-[[temp.class.spec]]).
 Since a *using-declaration* is a declaration, the restrictions on
 declarations of the same name in the same declarative region (
 [[basic.scope]]) also apply to *using-declaration*s.
 ``` cpp
 namespace A {
   int x;
 }
@@ -2114,22 +2576,29 @@ void func() {
   x = 99;           // assigns to A::x
   struct x x1;      // x1 has class type B::x
 }
 ```
 If a function declaration in namespace scope or block scope has the same
 name and the same parameter-type-list ([[dcl.fct]]) as a function
 introduced by a *using-declaration*, and the declarations do not declare
 the same function, the program is ill-formed. If a function template
 declaration in namespace scope has the same name, parameter-type-list,
 return type, and template parameter list as a function template
-introduced by a *using-declaration*, the program is ill-formed. Two
-*using-declaration*s may introduce functions with the same name and the
-same parameter-type-list. If, for a call to an unqualified function
 name, function overload resolution selects the functions introduced by
 such *using-declaration*s, the function call is ill-formed.
 ``` cpp
 namespace B {
   void f(int);
   void f(double);
 }
@@ -2146,17 +2615,23 @@ void h() {
   f(1);             // error: ambiguous: B::f(int) or C::f(int)?
   void f(int);      // error: f(int) conflicts with C::f(int) and B::f(int)
 }
 ```
-When a *using-declaration* brings names from a base class into a derived
-class scope, member functions and member function templates in the
 derived class override and/or hide member functions and member function
 templates with the same name, parameter-type-list ([[dcl.fct]]),
 cv-qualification, and *ref-qualifier* (if any) in a base class (rather
-than conflicting). For *using-declaration*s that name a constructor,
-see  [[class.inhctor]].
 ``` cpp
 struct B {
   virtual void f(int);
   virtual void f(char);
@@ -2180,32 +2655,70 @@ void k(D* p)
   p->f(1);          // calls D::f(int)
   p->f('a');        // calls B::f(char)
   p->g(1);          // calls B::g(int)
   p->g('a');        // calls D::g(char)
 }
 ```
-For the purpose of overload resolution, the functions which are
-introduced by a *using-declaration* into a derived class will be treated
-as though they were members of the derived class. In particular, the
 implicit `this` parameter shall be treated as if it were a pointer to
 the derived class rather than to the base class. This has no effect on
 the type of the function, and in all other respects the function remains
-a member of the base class.
-The access rules for inheriting constructors are specified in
-[[class.inhctor]]; otherwise all instances of the name mentioned in a
-*using-declaration* shall be accessible. In particular, if a derived
-class uses a *using-declaration* to access a member of a base class, the
-member name shall be accessible. If the name is that of an overloaded
-member function, then all functions named shall be accessible. The base
-class members mentioned by a *using-declaration* shall be visible in the
-scope of at least one of the direct base classes of the class where the
-*using-declaration* is specified. Because a *using-declaration*
-designates a base class member (and not a member subobject or a member
-function of a base class subobject), a *using-declaration* cannot be
-used to resolve inherited member ambiguities. For example,
 ``` cpp
 struct A { int x(); };
 struct B : A { };
 struct C : A {
@@ -2216,18 +2729,26 @@ struct C : A {
 struct D : B, C {
   using C::x;
   int x(double);
 };
 int f(D* d) {
-  return d->x();    // ambiguous: B::x or C::x
 }
 ```
-The alias created by the *using-declaration* has the usual accessibility
-for a *member-declaration*. A *using-declaration* that names a
-constructor does not create aliases; see  [[class.inhctor]] for the
-pertinent accessibility rules.
 ``` cpp
 class A {
 private:
     void f(char);
@@ -2242,11 +2763,13 @@ class B : public A {
 public:
   using A::g;       // B::g is a public synonym for A::g
 };
 ```
-If a *using-declaration* uses the keyword `typename` and specifies a
 dependent name ([[temp.dep]]), the name introduced by the
 *using-declaration* is treated as a *typedef-name* ([[dcl.typedef]]).
 ### Using directive <a id="namespace.udir">[[namespace.udir]]</a>
@@ -2254,26 +2777,34 @@ dependent name ([[temp.dep]]), the name introduced by the
 using-directive:
     attribute-specifier-seqₒₚₜ 'using namespace' nested-name-specifierₒₚₜ namespace-name ';'
 ```
 A *using-directive* shall not appear in class scope, but may appear in
-namespace scope or in block scope. When looking up a *namespace-name* in
-a *using-directive*, only namespace names are considered, see
-[[basic.lookup.udir]]. The optional *attribute-specifier-seq* appertains
-to the *using-directive*.
 A *using-directive* specifies that the names in the nominated namespace
 can be used in the scope in which the *using-directive* appears after
 the *using-directive*. During unqualified name lookup (
 [[basic.lookup.unqual]]), the names appear as if they were declared in
 the nearest enclosing namespace which contains both the
-*using-directive* and the nominated namespace. In this context,
-“contains” means “contains directly or indirectly”.
 A *using-directive* does not add any members to the declarative region
 in which it appears.
 ``` cpp
 namespace A {
   int i;
   namespace B {
     namespace C {
@@ -2298,15 +2829,22 @@ namespace A {
 void f4() {
   i = 5;            // ill-formed; neither i is visible
 }
 ```
 For unqualified lookup ([[basic.lookup.unqual]]), the *using-directive*
 is transitive: if a scope contains a *using-directive* that nominates a
 second namespace that itself contains *using-directive*s, the effect is
 as if the *using-directive*s from the second namespace also appeared in
-the first. For qualified lookup, see  [[namespace.qual]].
 ``` cpp
 namespace M {
   int i;
 }
@@ -2345,21 +2883,27 @@ namespace B {
     int n = j;      // D::j hides B::j
   }
 }
 ```
-If a namespace is extended by an *extension-namespace-definition* after
-a *using-directive* for that namespace is given, the additional members
-of the extended namespace and the members of namespaces nominated by
-*using-directive*s in the *extension-namespace-definition* can be used
-after the *extension-namespace-definition*.
 If name lookup finds a declaration for a name in two different
 namespaces, and the declarations do not declare the same entity and do
-not declare functions, the use of the name is ill-formed. In particular,
-the name of a variable, function or enumerator does not hide the name of
-a class or enumeration declared in a different namespace. For example,
 ``` cpp
 namespace A {
   class X { };
   extern "C"   int g();
@@ -2373,24 +2917,31 @@ namespace B {
 using namespace A;
 using namespace B;
 void f() {
   X(1);             // error: name X found in two namespaces
-  g();              // okay: name g refers to the same entity
-  h();              // okay: overload resolution selects A::h
 }
 ```
 During overload resolution, all functions from the transitive search are
 considered for argument matching. The set of declarations found by the
-transitive search is unordered. In particular, the order in which
-namespaces were considered and the relationships among the namespaces
-implied by the *using-directive*s do not cause preference to be given to
-any of the declarations found by the search. An ambiguity exists if the
-best match finds two functions with the same signature, even if one is
-in a namespace reachable through *using-directive*s in the namespace of
-the other.[^7]
 ``` cpp
 namespace D {
   int d1;
   void f(char);
@@ -2419,35 +2970,44 @@ void f() {
   f(1);             // error: ambiguous: D::f(int) or E::f(int)?
   f('a');           // OK: D::f(char)
 }
 ```
 ## The `asm` declaration <a id="dcl.asm">[[dcl.asm]]</a>
 An `asm` declaration has the form
 ``` bnf
 asm-definition:
-    'asm (' string-literal ') ;'
 ```
 The `asm` declaration is conditionally-supported; its meaning is
-*implementation-defined*. Typically it is used to pass information
-through the implementation to an assembler.
 ## Linkage specifications <a id="dcl.link">[[dcl.link]]</a>
 All function types, function names with external linkage, and variable
-names with external linkage have a *language linkage*. Some of the
-properties associated with an entity with language linkage are specific
-to each implementation and are not described here. For example, a
-particular language linkage may be associated with a particular form of
-representing names of objects and functions with external linkage, or
-with a particular calling convention, etc. The default language linkage
-of all function types, function names, and variable names is C++language
-linkage. Two function types with different language linkages are
-distinct types even if they are otherwise identical.
 Linkage ([[basic.link]]) between C++and non-C++code fragments can be
 achieved using a *linkage-specification*:
 ``` bnf
@@ -2458,103 +3018,112 @@ linkage-specification:
 The *string-literal* indicates the required language linkage. This
 International Standard specifies the semantics for the *string-literal*s
 `"C"` and `"C++"`. Use of a *string-literal* other than `"C"` or `"C++"`
 is conditionally-supported, with *implementation-defined* semantics.
-Therefore, a linkage-specification with a *string-literal* that is
-unknown to the implementation requires a diagnostic. It is recommended
-that the spelling of the *string-literal* be taken from the document
-defining that language. For example, `Ada` (not `ADA`) and `Fortran` or
-`FORTRAN`, depending on the vintage.
 Every implementation shall provide for linkage to functions written in
 the C programming language, `"C"`, and linkage to C++functions, `"C++"`.
 ``` cpp
 complex sqrt(complex);          // C++linkage by default
 extern "C" {
   double sqrt(double);          // C linkage
 }
 ```
 Linkage specifications nest. When linkage specifications nest, the
 innermost one determines the language linkage. A linkage specification
 does not establish a scope. A *linkage-specification* shall occur only
 in namespace scope ([[basic.scope]]). In a *linkage-specification*, the
 specified language linkage applies to the function types of all function
 declarators, function names with external linkage, and variable names
 with external linkage declared within the *linkage-specification*.
 ``` cpp
-extern "C" void f1(void(*pf)(int));
- // the name f1 and its function type have C language
-                                // linkage; pf is a pointer to a C function
 extern "C" typedef void FUNC();
 FUNC f2;                        // the name f2 has C++language linkage and the
                                 // function's type has C language linkage
-extern "C" FUNC f3;             // the name of function f3 and the function's type
- // have C language linkage
-void (*pf2)(FUNC*);             // the name of the variable pf2 has C++linkage and
- // the type of pf2 is pointer to C++function that
-                                // takes one parameter of type pointer to C function
 extern "C" {
-  static void f4();             // the name of the function f4 has
-                                // internal linkage (not C language
-                                // linkage) and the function's type
-                                // has C language linkage.
 }
 extern "C" void f5() {
-  extern void f4();             // OK: Name linkage (internal)
-                                // and function type linkage (C
-                                // language linkage) obtained from
-                                // previous declaration.
 }
-extern void f4();               // OK: Name linkage (internal)
-                                // and function type linkage (C
-                                // language linkage) obtained from
-                                // previous declaration.
 void f6() {
-  extern void f4();             // OK: Name linkage (internal)
-                                // and function type linkage (C
-                                // language linkage) obtained from
-                                // previous declaration.
 }
 ```
 A C language linkage is ignored in determining the language linkage of
 the names of class members and the function type of class member
 functions.
 ``` cpp
 extern "C" typedef void FUNC_c();
 class C {
- void mf1(FUNC_c*); // the name of the function mf1 and the member
-                                // function's type have C++language linkage; the
-                                // parameter has type pointer to C function
- FUNC_c mf2; // the name of the function mf2 and the member
-                                // function's type have C++language linkage
-   static FUNC_c* q;            // the name of the data member q has C++language
- // linkage and the data member's type is pointer to
-                                // C function
 };
 extern "C" {
   class X {
- void mf(); // the name of the function mf and the member
-                                // function's type have C++language linkage
- void mf2(void(*)()); // the name of the function mf2 has C++language
-                                // linkage; the parameter has type pointer to
-                                // C function
   };
 }
 ```
 If two declarations declare functions with the same name and
-*parameter-type-list* ([[dcl.fct]]) to be members of the same namespace
 or declare objects with the same name to be members of the same
 namespace and the declarations give the names different language
 linkages, the program is ill-formed; no diagnostic is required if the
 declarations appear in different translation units. Except for functions
 with C++linkage, a function declaration without a linkage specification
@@ -2569,20 +3138,24 @@ Two declarations for a function with C language linkage with the same
 function name (ignoring the namespace names that qualify it) that appear
 in different namespace scopes refer to the same function. Two
 declarations for a variable with C language linkage with the same name
 (ignoring the namespace names that qualify it) that appear in different
 namespace scopes refer to the same variable. An entity with C language
-linkage shall not be declared with the same name as an entity in global
 scope, unless both declarations denote the same entity; no diagnostic is
 required if the declarations appear in different translation units. A
 variable with C language linkage shall not be declared with the same
 name as a function with C language linkage (ignoring the namespace names
 that qualify the respective names); no diagnostic is required if the
-declarations appear in different translation units. Only one definition
-for an entity with a given name with C language linkage may appear in
-the program (see  [[basic.def.odr]]); this implies that such an entity
-must not be defined in more than one namespace scope.
 ``` cpp
 int x;
 namespace A {
   extern "C" int f();
@@ -2591,40 +3164,45 @@ namespace A {
   extern "C" int x();               // ill-formed: same name as global-space object x
 }
 namespace B {
   extern "C" int f();               // A::f and B::f refer to the same function
-  extern "C" int g() { return 1; }  // ill-formed, the function g
-                                    // with C language linkage has two definitions
 }
 int A::f() { return 98; }           // definition for the function f with C language linkage
 extern "C" int h() { return 97; }   // definition for the function h with C language linkage
                                     // A::h and ::h refer to the same function
 ```
 A declaration directly contained in a *linkage-specification* is treated
 as if it contains the `extern` specifier ([[dcl.stc]]) for the purpose
 of determining the linkage of the declared name and whether it is a
 definition. Such a declaration shall not specify a storage class.
 ``` cpp
 extern "C" double f();
 static double f();                  // error
 extern "C" int i;                   // declaration
 extern "C" {
   int i;                            // definition
 }
 extern "C" static void g();         // error
 ```
-Because the language linkage is part of a function type, when
-indirecting through a pointer to C function, the function to which the
-resulting lvalue refers is considered a C function.
 Linkage from C++to objects defined in other languages and to objects
-defined in C++from other languages is implementation-defined and
 language-dependent. Only where the object layout strategies of two
 language implementations are similar enough can such linkage be
 achieved.
 ## Attributes <a id="dcl.attr">[[dcl.attr]]</a>
@@ -2639,20 +3217,25 @@ attribute-specifier-seq:
   attribute-specifier-seqₒₚₜ attribute-specifier
 ```
 ``` bnf
 attribute-specifier:
-  '[' '[' attribute-list ']' ']'
   alignment-specifier
 ```
 ``` bnf
 alignment-specifier:
   'alignas (' type-id '...'ₒₚₜ ')'
   'alignas (' constant-expression '...'ₒₚₜ ')'
 ```
 ``` bnf
 attribute-list:
   attributeₒₚₜ
   attribute-list ',' attributeₒₚₜ
   attribute '...'
@@ -2680,84 +3263,114 @@ attribute-namespace:
     identifier
 ```
 ``` bnf
 attribute-argument-clause:
-    '(' balanced-token-seq ')'
 ```
 ``` bnf
 balanced-token-seq:
-    balanced-tokenₒₚₜ
     balanced-token-seq balanced-token
 ```
 ``` bnf
 balanced-token:
-    '(' balanced-token-seq ')'
-    '[' balanced-token-seq ']'
-    '{' balanced-token-seq '}'
     any *token* other than a parenthesis, a bracket, or a brace
 ```
-For each individual attribute, the form of the *balanced-token-seq* will
-be specified.
 In an *attribute-list*, an ellipsis may appear only if that
 *attribute*’s specification permits it. An *attribute* followed by an
 ellipsis is a pack expansion ([[temp.variadic]]). An
 *attribute-specifier* that contains no *attribute*s has no effect. The
-order in which the *attribute-tokens* appear in an *attribute-list* is
 not significant. If a keyword ([[lex.key]]) or an alternative token (
 [[lex.digraph]]) that satisfies the syntactic requirements of an
 *identifier* ([[lex.name]]) is contained in an *attribute-token*, it is
 considered an identifier. No name lookup ([[basic.lookup]]) is
 performed on any of the identifiers contained in an *attribute-token*.
 The *attribute-token* determines additional requirements on the
-*attribute-argument-clause* (if any). The use of an
-*attribute-scoped-token* is conditionally-supported, with
-*implementation-defined* behavior. Each implementation should choose a
-distinctive name for the *attribute-namespace* in an
-*attribute-scoped-token*.
 Each *attribute-specifier-seq* is said to *appertain* to some entity or
 statement, identified by the syntactic context where it appears (Clause
 [[stmt.stmt]], Clause  [[dcl.dcl]], Clause  [[dcl.decl]]). If an
 *attribute-specifier-seq* that appertains to some entity or statement
-contains an *attribute* that is not allowed to apply to that entity or
-statement, the program is ill-formed. If an *attribute-specifier-seq*
-appertains to a friend declaration ([[class.friend]]), that declaration
-shall be a definition. No *attribute-specifier-seq* shall appertain to
-an explicit instantiation ([[temp.explicit]]).
-For an *attribute-token* not specified in this International Standard,
-the behavior is *implementation-defined*.
 Two consecutive left square bracket tokens shall appear only when
-introducing an *attribute-specifier*. If two consecutive left square
-brackets appear where an *attribute-specifier* is not allowed, the
-program is ill-formed even if the brackets match an alternative grammar
-production.
 ``` cpp
 int p[10];
 void f() {
   int x = 42, y[5];
-  int(p[[x] { return x; }()]);  // error: invalid attribute on a nested
-                                // declarator-id and not a function-style cast of
- // an element of p.
- y[[] { return 2; }()] = 2; // error even though attributes are not allowed
-                                // in this context.
 }
 ```
 ### Alignment specifier <a id="dcl.align">[[dcl.align]]</a>
 An *alignment-specifier* may be applied to a variable or to a class data
 member, but it shall not be applied to a bit-field, a function
-parameter, an *exception-declaration* ([[except.handle]]), or a
-variable declared with the `register` storage class specifier. An
 *alignment-specifier* may also be applied to the declaration or
 definition of a class (in an *elaborated-type-specifier* (
 [[dcl.type.elab]]) or *class-head* (Clause  [[class]]), respectively)
 and to the declaration or definition of an enumeration (in an
 *opaque-enum-declaration* or *enum-head*, respectively ([[dcl.enum]])).
@@ -2766,103 +3379,85 @@ An *alignment-specifier* with an ellipsis is a pack expansion (
 When the *alignment-specifier* is of the form `alignas(`
 *constant-expression* `)`:
 - the *constant-expression* shall be an integral constant expression
-- if the constant expression evaluates to a fundamental alignment, the
- alignment requirement of the declared entity shall be the specified
-  fundamental alignment
-- if the constant expression evaluates to an extended alignment and the
-  implementation supports that alignment in the context of the
-  declaration, the alignment of the declared entity shall be that
-  alignment
-- if the constant expression evaluates to an extended alignment and the
   implementation does not support that alignment in the context of the
-  declaration, the program is ill-formed
-- if the constant expression evaluates to zero, the alignment specifier
-  shall have no effect
-- otherwise, the program is ill-formed.
-When the *alignment-specifier* is of the form `alignas(` *type-id* `)`,
-it shall have the same effect as `alignas({}alignof(`*type-id*`))` (
-[[expr.alignof]]).
-When multiple *alignment-specifier*s are specified for an entity, the
-alignment requirement shall be set to the strictest specified alignment.
 The combined effect of all *alignment-specifier*s in a declaration shall
 not specify an alignment that is less strict than the alignment that
 would be required for the entity being declared if all
-*alignment-specifier*s were omitted (including those in other
-declarations).
 If the defining declaration of an entity has an *alignment-specifier*,
 any non-defining declaration of that entity shall either specify
 equivalent alignment or have no *alignment-specifier*. Conversely, if
 any declaration of an entity has an *alignment-specifier*, every
 defining declaration of that entity shall specify an equivalent
 alignment. No diagnostic is required if declarations of an entity have
 different *alignment-specifier*s in different translation units.
 ``` cpp
 // Translation unit #1:
-struct S { int x; } s, p = &s;
 // Translation unit #2:
-struct alignas(16) S;           // error: definition of S lacks alignment; no
-extern S* p;                    // diagnostic required
 ```
 An aligned buffer with an alignment requirement of `A` and holding `N`
-elements of type `T` other than `char`, `signed char`, or
-`unsigned char` can be declared as:
 ``` cpp
 alignas(T) alignas(A) T buffer[N];
 ```
 Specifying `alignas(T)` ensures that the final requested alignment will
 not be weaker than `alignof(T)`, and therefore the program will not be
 ill-formed.
 ``` cpp
 alignas(double) void f();                           // error: alignment applied to function
 alignas(double) unsigned char c[sizeof(double)];    // array of characters, suitably aligned for a double
 extern unsigned char c[sizeof(double)];             // no alignas necessary
 alignas(float)
   extern unsigned char c[sizeof(double)];           // error: different alignment in declaration
 ```
-### Noreturn attribute <a id="dcl.attr.noreturn">[[dcl.attr.noreturn]]</a>
-The *attribute-token* `noreturn` specifies that a function does not
-return. It shall appear at most once in each *attribute-list* and no
-*attribute-argument-clause* shall be present. The attribute may be
-applied to the *declarator-id* in a function declaration. The first
-declaration of a function shall specify the `noreturn` attribute if any
-declaration of that function specifies the `noreturn` attribute. If a
-function is declared with the `noreturn` attribute in one translation
-unit and the same function is declared without the `noreturn` attribute
-in another translation unit, the program is ill-formed; no diagnostic
-required.
-If a function `f` is called where `f` was previously declared with the
-`noreturn` attribute and `f` eventually returns, the behavior is
-undefined. The function may terminate by throwing an exception.
-Implementations are encouraged to issue a warning if a function marked
-`[[noreturn]]` might return.
-``` cpp
-[[ noreturn ]] void f() {
-  throw "error";        // OK
-}
-[[ noreturn ]] void q(int i) { // behavior is undefined if called with an argument <= 0
-  if (i > 0)
-    throw "positive";
-}
-```
 ### Carries dependency attribute <a id="dcl.attr.depend">[[dcl.attr.depend]]</a>
 The *attribute-token* `carries_dependency` specifies dependency
 propagation into and out of functions. It shall appear at most once in
@@ -2885,14 +3480,17 @@ declaration of that function specifies the `carries_dependency`
 attribute for that parameter. If a function or one of its parameters is
 declared with the `carries_dependency` attribute in its first
 declaration in one translation unit and the same function or one of its
 parameters is declared without the `carries_dependency` attribute in its
 first declaration in another translation unit, the program is
-ill-formed; no diagnostic required.
-The `carries_dependency` attribute does not change the meaning of the
-program, but may result in generation of more efficient code.
 ``` cpp
 /* Translation unit A. */
 struct foo { int* a; int* b; };
@@ -2933,42 +3531,194 @@ Function `g`’s second parameter has a `carries_dependency` attribute,
 but its first parameter does not. Therefore, function `h`’s first call
 to `g` carries a dependency into `g`, but its second call does not. The
 implementation might need to insert a fence prior to the second call to
 `g`.
 ### Deprecated attribute <a id="dcl.attr.deprecated">[[dcl.attr.deprecated]]</a>
 The *attribute-token* `deprecated` can be used to mark names and
 entities whose use is still allowed, but is discouraged for some reason.
-in particular, `deprecated` is appropriate for names and entities that
-are deemed obsolescent or unsafe. It shall appear at most once in each
-*attribute-list*. An *attribute-argument-clause* may be present and, if
-present, it shall have the form:
 ``` cpp
 ( string-literal )
 ```
-the *string-literal* in the *attribute-argument-clause* could be used to
-explain the rationale for deprecation and/or to suggest a replacing
-entity.
 The attribute may be applied to the declaration of a class, a
-*typedef-name*, a variable, a non-static data member, a function, an
-enumeration, or a template specialization.
 A name or entity declared without the `deprecated` attribute can later
-be re-declared with the attribute and vice-versa. Thus, an entity
-initially declared without the attribute can be marked as deprecated by
-a subsequent redeclaration. However, after an entity is marked as
-deprecated, later redeclarations do not un-deprecate the entity.
 Redeclarations using different forms of the attribute (with or without
 the *attribute-argument-clause* or with different
 *attribute-argument-clause*s) are allowed.
-Implementations may use the `deprecated `attribute to produce a
-diagnostic message in case the program refers to a name or entity other
-than to declare it, after a declaration that specifies the attribute.
-The diagnostic message may include the text provided within the
-*attribute-argument-clause* of any `deprecated` attribute applied to the
-name or entity.

 ```
 ``` bnf
 declaration:
     block-declaration
+    nodeclspec-function-declaration
     function-definition
     template-declaration
+    deduction-guide
     explicit-instantiation
     explicit-specialization
     linkage-specification
     namespace-definition
     empty-declaration
     static_assert-declaration
     alias-declaration
     opaque-enum-declaration
 ```
+``` bnf
+nodeclspec-function-declaration:
+    attribute-specifier-seqₒₚₜ declarator ';'
+```
 ``` bnf
 alias-declaration:
+    'using' identifier attribute-specifier-seqₒₚₜ '=' defining-type-id ';'
 ```
 ``` bnf
 simple-declaration:
+    decl-specifier-seq init-declarator-listₒₚₜ ';'
+    attribute-specifier-seq decl-specifier-seq init-declarator-list ';'
+    attribute-specifier-seqₒₚₜ decl-specifier-seq ref-qualifierₒₚₜ '[' identifier-list ']' initializer ';'
 ```
 ``` bnf
 static_assert-declaration:
+  'static_assert' '(' constant-expression ')' ';'
   'static_assert' '(' constant-expression ',' string-literal ')' ';'
 ```
 ``` bnf
 empty-declaration:
 ``` bnf
 attribute-declaration:
     attribute-specifier-seq ';'
 ```
+[*Note 1*: *asm-definition*s are described in  [[dcl.asm]], and
 *linkage-specification*s are described in  [[dcl.link]].
 *Function-definition*s are described in  [[dcl.fct.def]] and
+*template-declaration*s and *deduction-guide*s are described in Clause
+[[temp]]. *Namespace-definition*s are described in  [[namespace.def]],
 *using-declaration*s are described in  [[namespace.udecl]] and
+*using-directive*s are described in  [[namespace.udir]]. — *end note*]
+A *simple-declaration* or *nodeclspec-function-declaration* of the form
 ``` bnf
 attribute-specifier-seqₒₚₜ decl-specifier-seqₒₚₜ init-declarator-listₒₚₜ ';'
 ```
 is divided into three parts. Attributes are described in  [[dcl.attr]].
 *decl-specifier*s, the principal components of a *decl-specifier-seq*,
 are described in  [[dcl.spec]]. *declarator*s, the components of an
 *init-declarator-list*, are described in Clause  [[dcl.decl]]. The
+*attribute-specifier-seq* appertains to each of the entities declared by
+the *declarator*s of the *init-declarator-list*.
+[*Note 2*: In the declaration for an entity, attributes appertaining to
+that entity may appear at the start of the declaration and after the
+*declarator-id* for that declaration. — *end note*]
+[*Example 1*:
 ``` cpp
 [[noreturn]] void f [[noreturn]] ();    // OK
 ```
+— *end example*]
 Except where otherwise specified, the meaning of an
 *attribute-declaration* is *implementation-defined*.
 A declaration occurs in a scope ([[basic.scope]]); the scope rules are
 summarized in  [[basic.lookup]]. A declaration that declares a function
 names being declared by the declaration (as *class-name*s, *enum-name*s,
 or *enumerator*s, depending on the syntax). In such cases, the
 *decl-specifier-seq* shall introduce one or more names into the program,
 or shall redeclare a name introduced by a previous declaration.
+[*Example 2*:
 ``` cpp
 enum { };           // ill-formed
 typedef class { };  // ill-formed
 ```
+— *end example*]
+In a *static_assert-declaration*, the *constant-expression* shall be a
+contextually converted constant expression of type `bool` (
+[[expr.const]]). If the value of the expression when so converted is
+`true`, the declaration has no effect. Otherwise, the program is
+ill-formed, and the resulting diagnostic message ([[intro.compliance]])
+shall include the text of the *string-literal*, if one is supplied,
 except that characters not in the basic source character set (
 [[lex.charset]]) are not required to appear in the diagnostic message.
+[*Example 3*:
 ``` cpp
+static_assert(char(-1) < 0, "this library requires plain 'char' to be signed");
 ```
+— *end example*]
 An *empty-declaration* has no effect.
+A *simple-declaration* with an *identifier-list* is called a *structured
+binding declaration* ([[dcl.struct.bind]]). The *decl-specifier-seq*
+shall contain only the *type-specifier* `auto` ([[dcl.spec.auto]]) and
+*cv-qualifier*s. The *initializer* shall be of the form “`=`
+*assignment-expression*”, of the form “`{` *assignment-expression* `}`”,
+or of the form “`(` *assignment-expression* `)`”, where the
+*assignment-expression* is of array or non-union class type.
 Each *init-declarator* in the *init-declarator-list* contains exactly
 one *declarator-id*, which is the name declared by that
 *init-declarator* and hence one of the names declared by the
+declaration. The *defining-type-specifier*s ([[dcl.type]]) in the
 *decl-specifier-seq* and the recursive *declarator* structure of the
 *init-declarator* describe a type ([[dcl.meaning]]), which is then
 associated with the name being declared by the *init-declarator*.
 If the *decl-specifier-seq* contains the `typedef` specifier, the
 definition unless it contains the `extern` specifier and has no
 initializer ([[basic.def]]). A definition causes the appropriate amount
 of storage to be reserved and any appropriate initialization (
 [[dcl.init]]) to be done.
+A *nodeclspec-function-declaration* shall declare a constructor,
+destructor, or conversion function.[^1]
+[*Note 3*: A *nodeclspec-function-declaration* can only be used in a
+*template-declaration* (Clause  [[temp]]), *explicit-instantiation* (
+[[temp.explicit]]), or *explicit-specialization* (
+[[temp.expl.spec]]). — *end note*]
 ## Specifiers <a id="dcl.spec">[[dcl.spec]]</a>
 The specifiers that can be used in a declaration are
 ``` bnf
 decl-specifier:
     storage-class-specifier
+ defining-type-specifier
     function-specifier
     'friend'
     'typedef'
     'constexpr'
+    'inline'
 ```
 ``` bnf
 decl-specifier-seq:
     decl-specifier attribute-specifier-seqₒₚₜ
 appertains to the type determined by the preceding *decl-specifier*s (
 [[dcl.meaning]]). The *attribute-specifier-seq* affects the type only
 for the declaration it appears in, not other declarations involving the
 same type.
+Each *decl-specifier* shall appear at most once in a complete
+*decl-specifier-seq*, except that `long` may appear twice.
 If a *type-name* is encountered while parsing a *decl-specifier-seq*, it
 is interpreted as part of the *decl-specifier-seq* if and only if there
+is no previous *defining-type-specifier* other than a *cv-qualifier* in
+the *decl-specifier-seq*. The sequence shall be self-consistent as
+described below.
+[*Example 1*:
 ``` cpp
 typedef char* Pc;
 static Pc;                      // error: name missing
 ```
 ``` cpp
 void f(const Pc);               // void f(char* const) (not const char*)
 void g(const int Pc);           // void g(const int)
 ```
+— *end example*]
+[*Note 1*:
 Since `signed`, `unsigned`, `long`, and `short` by default imply `int`,
 a *type-name* appearing after one of those specifiers is treated as the
 name being (re)declared.
+[*Example 2*:
 ``` cpp
 void h(unsigned Pc);            // void h(unsigned int)
 void k(unsigned int Pc);        // void k(unsigned int)
 ```
+— *end example*]
+— *end note*]
 ### Storage class specifiers <a id="dcl.stc">[[dcl.stc]]</a>
 The storage class specifiers are
 ``` bnf
 storage-class-specifier:
     'static'
     'thread_local'
     'extern'
     'mutable'
 ```
 *decl-specifier-seq*, except that `thread_local` may appear with
 `static` or `extern`. If `thread_local` appears in any declaration of a
 variable it shall be present in all declarations of that entity. If a
 *storage-class-specifier* appears in a *decl-specifier-seq*, there can
 be no `typedef` specifier in the same *decl-specifier-seq* and the
+*init-declarator-list* or *member-declarator-list* of the declaration
+shall not be empty (except for an anonymous union declared in a named
+namespace or in the global namespace, which shall be declared `static` (
+[[class.union.anon]])). The *storage-class-specifier* applies to the
+name declared by each *init-declarator* in the list and not to any names
+declared by other specifiers. A *storage-class-specifier* other than
+`thread_local` shall not be specified in an explicit specialization (
+[[temp.expl.spec]]) or an explicit instantiation ([[temp.explicit]])
+directive.
+[*Note 1*: A variable declared without a *storage-class-specifier* at
+block scope or declared as a function parameter has automatic storage
+duration by default ([[basic.stc.auto]]). — *end note*]
 The `thread_local` specifier indicates that the named entity has thread
 storage duration ([[basic.stc.thread]]). It shall be applied only to
 the names of variables of namespace or block scope and to the names of
 static data members. When `thread_local` is applied to a variable of
 block scope the *storage-class-specifier* `static` is implied if no
 other *storage-class-specifier* appears in the *decl-specifier-seq*.
 The `static` specifier can be applied only to names of variables and
+functions and to anonymous unions ([[class.union.anon]]). There can be
+no `static` function declarations within a block, nor any `static`
+function parameters. A `static` specifier used in the declaration of a
+variable declares the variable to have static storage duration (
 [[basic.stc.static]]), unless accompanied by the `thread_local`
 specifier, which declares the variable to have thread storage duration (
 [[basic.stc.thread]]). A `static` specifier can be used in declarations
 of class members;  [[class.static]] describes its effect. For the
 linkage of a name declared with a `static` specifier, see
 [[basic.link]].
 The `extern` specifier can be applied only to the names of variables and
 functions. The `extern` specifier cannot be used in the declaration of
 class members or function parameters. For the linkage of a name declared
+with an `extern` specifier, see  [[basic.link]].
+[*Note 2*: The `extern` keyword can also be used in
+*explicit-instantiation*s and *linkage-specification*s, but it is not a
+*storage-class-specifier* in such contexts. — *end note*]
 The linkages implied by successive declarations for a given entity shall
 agree. That is, within a given scope, each declaration declaring the
 same variable name or the same overloading of a function name shall
 imply the same linkage. Each function in a given set of overloaded
 functions can have a different linkage, however.
+[*Example 1*:
 ``` cpp
 static char* f();               // f() has internal linkage
 char* f()                       // f() still has internal linkage
+  { ... }
 char* g();                      // g() has external linkage
 static char* g()                // error: inconsistent linkage
+  { ... }
 void h();
 inline void h();                // external linkage
 inline void l();
 extern int d;                   // d has external linkage
 static int d;                   // error: inconsistent linkage
 ```
+— *end example*]
 The name of a declared but undefined class can be used in an `extern`
 declaration. Such a declaration can only be used in ways that do not
 require a complete class type.
+[*Example 2*:
 ``` cpp
 struct S;
 extern S a;
 extern S f();
 extern void g(S);
   g(a);                         // error: S is incomplete
   f();                          // error: S is incomplete
 }
 ```
+— *end example*]
+The `mutable` specifier shall appear only in the declaration of a
+non-static data member ([[class.mem]]) whose type is neither
+const-qualified nor a reference type.
+[*Example 3*:
 ``` cpp
 class X {
   mutable const int* p;         // OK
   mutable int* const q;         // ill-formed
 };
 ```
+— *end example*]
 The `mutable` specifier on a class data member nullifies a `const`
 specifier applied to the containing class object and permits
 modification of the mutable class member even though the rest of the
 object is `const` ([[dcl.type.cv]]).
 can be used only in function declarations.
 ``` bnf
 function-specifier:
     'virtual'
     'explicit'
 ```
 The `virtual` specifier shall be used only in the initial declaration of
 a non-static class member function; see  [[class.virtual]].
 The `explicit` specifier shall be used only in the declaration of a
 constructor or conversion function within its class definition; see
 Declarations containing the *decl-specifier* `typedef` declare
 identifiers that can be used later for naming fundamental (
 [[basic.fundamental]]) or compound ([[basic.compound]]) types. The
 `typedef` specifier shall not be combined in a *decl-specifier-seq* with
+any other kind of specifier except a *defining-type-specifier*, and it
+shall not be used in the *decl-specifier-seq* of a
+*parameter-declaration* ([[dcl.fct]]) nor in the *decl-specifier-seq*
+of a *function-definition* ([[dcl.fct.def]]). If a `typedef` specifier
+appears in a declaration without a *declarator*, the program is
+ill-formed.
 ``` bnf
 typedef-name:
     identifier
 ```
 Within the scope of its declaration, a *typedef-name* is syntactically
 equivalent to a keyword and names the type associated with the
 identifier in the way described in Clause  [[dcl.decl]]. A
 *typedef-name* is thus a synonym for another type. A *typedef-name* does
 not introduce a new type the way a class declaration ([[class.name]])
+or enum declaration does.
+[*Example 1*:
+After
 ``` cpp
 typedef int MILES, *KLICKSP;
 ```
 MILES distance;
 extern KLICKSP metricp;
 ```
 are all correct declarations; the type of `distance` is `int` and that
+of `metricp` is “pointer to `int`”.
+— *end example*]
 A *typedef-name* can also be introduced by an *alias-declaration*. The
 *identifier* following the `using` keyword becomes a *typedef-name* and
 the optional *attribute-specifier-seq* following the *identifier*
+appertains to that *typedef-name*. Such a *typedef-name* has the same
+semantics as if it were introduced by the `typedef` specifier. In
+particular, it does not define a new type.
+[*Example 2*:
 ``` cpp
 using handler_t = void (*)(int);
 extern handler_t ignore;
 extern void (*ignore)(int);         // redeclare ignore
 using cell = pair<void*, cell*>;    // ill-formed
 ```
+— *end example*]
+The *defining-type-specifier-seq* of the *defining-type-id* shall not
+define a class or enumeration if the *alias-declaration* is the
+*declaration* of a *template-declaration*.
 In a given non-class scope, a `typedef` specifier can be used to
 redefine the name of any type declared in that scope to refer to the
 type to which it already refers.
+[*Example 3*:
 ``` cpp
+typedef struct s { ... } s;
 typedef int I;
 typedef int I;
 typedef I I;
 ```
+— *end example*]
 In a given class scope, a `typedef` specifier can be used to redefine
 any *class-name* declared in that scope that is not also a
 *typedef-name* to refer to the type to which it already refers.
+[*Example 4*:
 ``` cpp
 struct S {
   typedef struct A { } A;       // OK
   typedef struct B B;           // OK
   typedef A A;                  // error
 };
 ```
+— *end example*]
 If a `typedef` specifier is used to redefine in a given scope an entity
 that can be referenced using an *elaborated-type-specifier*, the entity
 can continue to be referenced by an *elaborated-type-specifier* or as an
 enumeration or class name in an enumeration or class definition
 respectively.
+[*Example 5*:
 ``` cpp
 struct S;
 typedef struct S S;
 int main() {
   struct S* p;                  // OK
 }
 struct S { };                   // OK
 ```
+— *end example*]
 In a given scope, a `typedef` specifier shall not be used to redefine
 the name of any type declared in that scope to refer to a different
 type.
+[*Example 6*:
 ``` cpp
+class complex { ... };
 typedef int complex;            // error: redefinition
 ```
+— *end example*]
 Similarly, in a given scope, a class or enumeration shall not be
 declared with the same name as a *typedef-name* that is declared in that
 scope and refers to a type other than the class or enumeration itself.
+[*Example 7*:
 ``` cpp
 typedef int complex;
+class complex { ... }; // error: redefinition
 ```
+— *end example*]
+[*Note 1*:  A *typedef-name* that names a class type, or a cv-qualified
+version thereof, is also a *class-name* ([[class.name]]). If a
+*typedef-name* is used to identify the subject of an
+*elaborated-type-specifier* ([[dcl.type.elab]]), a class definition
+(Clause  [[class]]), a constructor declaration ([[class.ctor]]), or a
+destructor declaration ([[class.dtor]]), the program is
+ill-formed. — *end note*]
+[*Example 8*:
 ``` cpp
 struct S {
   S();
   ~S();
 S a = T();                      // OK
 struct T * p;                   // error
 ```
+— *end example*]
 If the typedef declaration defines an unnamed class (or enum), the first
 *typedef-name* declared by the declaration to be that class type (or
 enum type) is used to denote the class type (or enum type) for linkage
 purposes only ([[basic.link]]).
+[*Example 9*:
 ``` cpp
 typedef struct { } *ps, S;      // S is the class name for linkage purposes
 ```
+— *end example*]
 ### The `friend` specifier <a id="dcl.friend">[[dcl.friend]]</a>
 The `friend` specifier is used to specify access to class members; see
 [[class.friend]].
 ### The `constexpr` specifier <a id="dcl.constexpr">[[dcl.constexpr]]</a>
 The `constexpr` specifier shall be applied only to the definition of a
+variable or variable template or the declaration of a function or
+function template. A function or static data member declared with the
+`constexpr` specifier is implicitly an inline function or variable (
+[[dcl.inline]]). If any declaration of a function or function template
+has a `constexpr` specifier, then all its declarations shall contain the
+`constexpr` specifier.
+[*Note 1*: An explicit specialization can differ from the template
+declaration with respect to the `constexpr` specifier. — *end note*]
+[*Note 2*: Function parameters cannot be declared
+`constexpr`. — *end note*]
+[*Example 1*:
 ``` cpp
 constexpr void square(int &x);  // OK: declaration
 constexpr int bufsz = 1024;     // OK: definition
 constexpr struct pixel {        // error: pixel is a type
      return x + 1;
 }
 extern constexpr int memsz;     // error: not a definition
 ```
+— *end example*]
 A `constexpr` specifier used in the declaration of a function that is
 not a constructor declares that function to be a *constexpr function*.
 Similarly, a `constexpr` specifier used in a constructor declaration
+declares that constructor to be a *constexpr constructor*.
+The definition of a constexpr function shall satisfy the following
+requirements:
 - it shall not be virtual ([[class.virtual]]);
 - its return type shall be a literal type;
 - each of its parameter types shall be a literal type;
 - its *function-body* shall be `= delete`, `= default`, or a
   *compound-statement* that does not contain
   - an *asm-definition*,
   - a `goto` statement,
+  - an identifier label ([[stmt.label]]),
   - a *try-block*, or
   - a definition of a variable of non-literal type or of static or
     thread storage duration or for which no initialization is performed.
+[*Example 2*:
 ``` cpp
 constexpr int square(int x)
   { return x * x; }             // OK
 constexpr long long_max()
   { return 2147483647; }        // OK
   while (--n > 0) r *= x;
   return r;
 }
 ```
+— *end example*]
+The definition of a constexpr constructor shall satisfy the following
+requirements:
 - the class shall not have any virtual base classes;
 - each of the parameter types shall be a literal type;
+- its *function-body* shall not be a *function-try-block*.
 In addition, either its *function-body* shall be `= delete`, or it shall
+satisfy the following requirements:
 - either its *function-body* shall be `= default`, or the
   *compound-statement* of its *function-body* shall satisfy the
+ requirements for a *function-body* of a constexpr function;
+- every non-variant non-static data member and base class subobject
   shall be initialized ([[class.base.init]]);
 - if the class is a union having variant members ([[class.union]]),
   exactly one of them shall be initialized;
 - if the class is a union-like class, but is not a union, for each of
   its anonymous union members having variant members, exactly one of
   them shall be initialized;
 - for a non-delegating constructor, every constructor selected to
+  initialize non-static data members and base class subobjects shall be
+  a constexpr constructor;
 - for a delegating constructor, the target constructor shall be a
+  constexpr constructor.
+[*Example 3*:
 ``` cpp
 struct Length {
   constexpr explicit Length(int i = 0) : val(i) { }
 private:
   int val;
 };
 ```
+— *end example*]
+For a constexpr function or constexpr constructor that is neither
+defaulted nor a template, if no argument values exist such that an
+invocation of the function or constructor could be an evaluated
+subexpression of a core constant expression ([[expr.const]]), or, for a
+constructor, a constant initializer for some object (
+[[basic.start.static]]), the program is ill-formed, no diagnostic
 required.
+[*Example 4*:
 ``` cpp
 constexpr int f(bool b)
   { return b ? throw 0 : 0; }           // OK
 constexpr int f() { return f(true); }   // ill-formed, no diagnostic required
   constexpr D() : B(global) { }         // ill-formed, no diagnostic required
                                         // lvalue-to-rvalue conversion on non-constant global
 };
 ```
+— *end example*]
+If the instantiated template specialization of a constexpr function
 template or member function of a class template would fail to satisfy
+the requirements for a constexpr function or constexpr constructor, that
+specialization is still a constexpr function or constexpr constructor,
+even though a call to such a function cannot appear in a constant
+expression. If no specialization of the template would satisfy the
+requirements for a constexpr function or constexpr constructor when
+considered as a non-template function or constructor, the template is
+ill-formed, no diagnostic required.
+A call to a constexpr function produces the same result as a call to an
+equivalent non-constexpr function in all respects except that
+- a call to a constexpr function can appear in a constant expression (
+  [[expr.const]]) and
+- copy elision is mandatory in a constant expression ([[class.copy]]).
+The `constexpr` specifier has no effect on the type of a constexpr
+function or a constexpr constructor.
+[*Example 5*:
 ``` cpp
 constexpr int bar(int x, int y)         // OK
     { return x + y + x*y; }
 // ...
 int bar(int x, int y)                   // error: redefinition of bar
     { return x * 2 + 3 * y; }
 ```
+— *end example*]
 A `constexpr` specifier used in an object declaration declares the
 object as `const`. Such an object shall have literal type and shall be
+initialized. In any `constexpr` variable declaration, the
+full-expression of the initialization shall be a constant expression (
+[[expr.const]]).
+[*Example 6*:
 ``` cpp
 struct pixel {
   int x, y;
 };
 constexpr pixel ur = { 1294, 1024 };    // OK
 constexpr pixel origin;                 // error: initializer missing
 ```
+— *end example*]
+### The `inline` specifier <a id="dcl.inline">[[dcl.inline]]</a>
+The `inline` specifier can be applied only to the declaration or
+definition of a variable or function.
+A function declaration ([[dcl.fct]],  [[class.mfct]], [[class.friend]])
+with an `inline` specifier declares an *inline function*. The inline
+specifier indicates to the implementation that inline substitution of
+the function body at the point of call is to be preferred to the usual
+function call mechanism. An implementation is not required to perform
+this inline substitution at the point of call; however, even if this
+inline substitution is omitted, the other rules for inline functions
+specified in this section shall still be respected.
+A variable declaration with an `inline` specifier declares an *inline
+variable*.
+A function defined within a class definition is an inline function.
+The `inline` specifier shall not appear on a block scope
+declaration.[^2] If the `inline` specifier is used in a friend function
+declaration, that declaration shall be a definition or the function
+shall have previously been declared inline.
+An inline function or variable shall be defined in every translation
+unit in which it is odr-used and shall have exactly the same definition
+in every case ([[basic.def.odr]]).
+[*Note 1*: A call to the inline function or a use of the inline
+variable may be encountered before its definition appears in the
+translation unit. — *end note*]
+If the definition of a function or variable appears in a translation
+unit before its first declaration as inline, the program is ill-formed.
+If a function or variable with external linkage is declared inline in
+one translation unit, it shall be declared inline in all translation
+units in which it appears; no diagnostic is required. An inline function
+or variable with external linkage shall have the same address in all
+translation units.
+[*Note 2*: A `static` local variable in an inline function with
+external linkage always refers to the same object. A type defined within
+the body of an inline function with external linkage is the same type in
+every translation unit. — *end note*]
 ### Type specifiers <a id="dcl.type">[[dcl.type]]</a>
 The type-specifiers are
 ``` bnf
 type-specifier:
   simple-type-specifier
   elaborated-type-specifier
   typename-specifier
   cv-qualifier
 ```
     type-specifier attribute-specifier-seqₒₚₜ
     type-specifier type-specifier-seq
 ```
 ``` bnf
+defining-type-specifier:
+ type-specifier
+    class-specifier
+    enum-specifier
+```
+``` bnf
+defining-type-specifier-seq:
+  defining-type-specifier attribute-specifier-seqₒₚₜ
+  defining-type-specifier defining-type-specifier-seq
 ```
 The optional *attribute-specifier-seq* in a *type-specifier-seq* or a
+*defining-type-specifier-seq* appertains to the type denoted by the
+preceding *type-specifier*s or *defining-type-specifier*s (
+[[dcl.meaning]]). The *attribute-specifier-seq* affects the type only
+for the declaration it appears in, not other declarations involving the
+same type.
+As a general rule, at most one *defining-type-specifier* is allowed in
+the complete *decl-specifier-seq* of a *declaration* or in a
+*defining-type-specifier-seq*, and at most one *type-specifier* is
+allowed in a *type-specifier-seq*. The only exceptions to this rule are
+the following:
 - `const` can be combined with any type specifier except itself.
 - `volatile` can be combined with any type specifier except itself.
 - `signed` or `unsigned` can be combined with `char`, `long`, `short`,
   or `int`.
 - `short` or `long` can be combined with `int`.
 - `long` can be combined with `double`.
 - `long` can be combined with `long`.
 Except in a declaration of a constructor, destructor, or conversion
+function, at least one *defining-type-specifier* that is not a
+*cv-qualifier* shall appear in a complete *type-specifier-seq* or a
+complete *decl-specifier-seq*.[^3]
+[*Note 1*: *enum-specifier*s, *class-specifier*s, and
+*typename-specifier*s are discussed in [[dcl.enum]], Clause  [[class]],
+and [[temp.res]], respectively. The remaining *type-specifier*s are
+discussed in the rest of this section. — *end note*]
+#### The *cv-qualifier*s <a id="dcl.type.cv">[[dcl.type.cv]]</a>
+There are two *cv-qualifier*s, `const` and `volatile`. Each
 *cv-qualifier* shall appear at most once in a *cv-qualifier-seq*. If a
 *cv-qualifier* appears in a *decl-specifier-seq*, the
+*init-declarator-list* or *member-declarator-list* of the declaration
+shall not be empty.
+[*Note 1*:  [[basic.type.qualifier]] and [[dcl.fct]] describe how
+cv-qualifiers affect object and function types. — *end note*]
+Redundant cv-qualifications are ignored.
+[*Note 2*: For example, these could be introduced by
+typedefs. — *end note*]
+[*Note 3*: Declaring a variable `const` can affect its linkage (
+[[dcl.stc]]) and its usability in constant expressions (
+[[expr.const]]). As described in  [[dcl.init]], the definition of an
+object or subobject of const-qualified type must specify an initializer
+or be subject to default-initialization. — *end note*]
 A pointer or reference to a cv-qualified type need not actually point or
 refer to a cv-qualified object, but it is treated as if it does; a
 const-qualified access path cannot be used to modify an object even if
 the object referenced is a non-const object and can be modified through
+some other access path.
+[*Note 4*: Cv-qualifiers are supported by the type system so that they
+cannot be subverted without casting (
+[[expr.const.cast]]). — *end note*]
 Except that any class member declared `mutable` ([[dcl.stc]]) can be
 modified, any attempt to modify a `const` object during its lifetime (
 [[basic.life]]) results in undefined behavior.
+[*Example 1*:
 ``` cpp
 const int ci = 3;                       // cv-qualified (initialized as required)
 ci = 4;                                 // ill-formed: attempt to modify const
 int i = 2;                              // not cv-qualified
 const int* ciq = new const int (3);     // initialized as required
 int* iq = const_cast<int*>(ciq);        // cast required
 *iq = 4;                                // undefined: modifies a const object
 ```
+For another example,
 ``` cpp
 struct X {
   mutable int i;
   int j;
 Y* p = const_cast<Y*>(&y);              // cast away const-ness of y
 p->x.i = 99;                            // well-formed: mutable member can be modified
 p->x.j = 99;                            // undefined: modifies a const member
 ```
+— *end example*]
+The semantics of an access through a volatile glvalue are
+*implementation-defined*. If an attempt is made to access an object
+defined with a volatile-qualified type through the use of a non-volatile
+glvalue, the behavior is undefined.
+[*Note 5*: `volatile` is a hint to the implementation to avoid
+aggressive optimization involving the object because the value of the
+object might be changed by means undetectable by an implementation.
+Furthermore, for some implementations, `volatile` might indicate that
+special hardware instructions are required to access the object. See
+[[intro.execution]] for detailed semantics. In general, the semantics of
+`volatile` are intended to be the same in C++as they are in
+C. — *end note*]
 #### Simple type specifiers <a id="dcl.type.simple">[[dcl.type.simple]]</a>
 The simple type specifiers are
 ``` bnf
 simple-type-specifier:
     nested-name-specifierₒₚₜ type-name
     nested-name-specifier 'template' simple-template-id
+    nested-name-specifierₒₚₜ template-name
     'char'
     'char16_t'
     'char32_t'
     'wchar_t'
     'bool'
 decltype-specifier:
   'decltype' '(' expression ')'
   'decltype' '(' 'auto' ')'
 ```
+The *simple-type-specifier* `auto` is a placeholder for a type to be
+deduced ([[dcl.spec.auto]]). A *type-specifier* of the form
+`typename`ₒₚₜ  *nested-name-specifier*ₒₚₜ  *template-name* is a
+placeholder for a deduced class type ([[dcl.type.class.deduct]]). The
+*template-name* shall name a class template that is not an
+injected-class-name. The other *simple-type-specifier*s specify either a
 previously-declared type, a type determined from an expression, or one
 of the fundamental types ([[basic.fundamental]]). Table
 [[tab:simple.type.specifiers]] summarizes the valid combinations of
 *simple-type-specifier*s and the types they specify.
 **Table: *simple-type-specifier*{s} and the types they specify** <a id="tab:simple.type.specifiers">[tab:simple.type.specifiers]</a>
+| Specifier(s)           | Type                                   |
 | ---------------------- | -------------------------------------- |
 | *type-name*            | the type named                         |
 | *simple-template-id*   | the type as defined in~ [[temp.names]] |
+| *template-name*        | placeholder for a type to be deduced   |
 | char                   | ``char''                               |
 | unsigned char          | ``unsigned char''                      |
 | signed char            | ``signed char''                        |
 | char16_t               | ``char16_t''                           |
 | char32_t               | ``char32_t''                           |
 | float                  | ``float''                              |
 | double                 | ``double''                             |
 | long double            | ``long double''                        |
 | void                   | ``void''                               |
 | auto                   | placeholder for a type to be deduced   |
+| decltype(auto)         | placeholder for a type to be deduced   |
 | decltype(*expression*) | the type as defined below              |
+When multiple *simple-type-specifier*s are allowed, they can be freely
+intermixed with other *decl-specifier*s in any order.
+[*Note 1*: It is *implementation-defined* whether objects of `char`
+type are represented as signed or unsigned quantities. The `signed`
+specifier forces `char` objects to be signed; it is redundant in other
+contexts. — *end note*]
 For an expression `e`, the type denoted by `decltype(e)` is defined as
 follows:
+- if `e` is an unparenthesized *id-expression* naming a structured
+ binding ([[dcl.struct.bind]]), `decltype(e)` is the referenced type
+ as given in the specification of the structured binding declaration;
+- otherwise, if `e` is an unparenthesized *id-expression* or an
+  unparenthesized class member access ([[expr.ref]]), `decltype(e)` is
+  the type of the entity named by `e`. If there is no such entity, or if
+  `e` names a set of overloaded functions, the program is ill-formed;
 - otherwise, if `e` is an xvalue, `decltype(e)` is `T&&`, where `T` is
   the type of `e`;
 - otherwise, if `e` is an lvalue, `decltype(e)` is `T&`, where `T` is
   the type of `e`;
 - otherwise, `decltype(e)` is the type of `e`.
 The operand of the `decltype` specifier is an unevaluated operand
 (Clause  [[expr]]).
+[*Example 1*:
 ``` cpp
 const int&& foo();
 int i;
 struct A { double x; };
 const A* a = new A();
+decltype(foo()) x1 = 17; // type is const int&&
 decltype(i) x2;                 // type is int
 decltype(a->x) x3;              // type is double
 decltype((a->x)) x4 = x3;       // type is const double&
 ```
+— *end example*]
+[*Note 2*: The rules for determining types involving `decltype(auto)`
+are specified in  [[dcl.spec.auto]]. — *end note*]
+If the operand of a *decltype-specifier* is a prvalue, the temporary
+materialization conversion is not applied ([[conv.rval]]) and no result
+object is provided for the prvalue. The type of the prvalue may be
+incomplete.
+[*Note 3*: As a result, storage is not allocated for the prvalue and it
+is not destroyed. Thus, a class type is not instantiated as a result of
+being the type of a function call in this context. In this context, the
+common purpose of writing the expression is merely to refer to its type.
+In that sense, a *decltype-specifier* is analogous to a use of a
+*typedef-name*, so the usual reasons for requiring a complete type do
+not apply. In particular, it is not necessary to allocate storage for a
+temporary object or to enforce the semantic constraints associated with
+invoking the type’s destructor. — *end note*]
+[*Note 4*: Unlike the preceding rule, parentheses have no special
+meaning in this context. — *end note*]
+[*Example 2*:
 ``` cpp
 template<class T> struct A { ~A() = delete; };
 template<class T> auto h()
   -> A<T>;
 template<class T> auto i(T)     // identity
   -> T;
 template<class T> auto f(T)     // #1
+  -> decltype(i(h<T>()));       // forces completion of A<T> and implicitly uses A<T>::~A()
+                                // for the temporary introduced by the use of h().
+                                // (A temporary is not introduced as a result of the use of i().)
 template<class T> auto f(T)     // #2
   -> void;
 auto g() -> void {
+  f(42);                        // OK: calls #2. (#1 is not a viable candidate: type deduction
+                                // fails~([temp.deduct]) because A<int>::~{A()} is implicitly used in its
+                                // decltype-specifier)
 }
 template<class T> auto q(T)
+  -> decltype((h<T>()));        // does not force completion of A<T>; A<T>::~A() is not implicitly
+                                // used within the context of this decltype-specifier
 void r() {
+  q(42);                        // Error: deduction against q succeeds, so overload resolution selects
+                                // the specialization ``q(T) -> decltype((h<T>())) [with T=int]''.
                                 // The return type is A<int>, so a temporary is introduced and its
                                 // destructor is used, so the program is ill-formed.
 }
 ```
+— *end example*]
 #### Elaborated type specifiers <a id="dcl.type.elab">[[dcl.type.elab]]</a>
 ``` bnf
 elaborated-type-specifier:
     class-key attribute-specifier-seqₒₚₜ nested-name-specifierₒₚₜ identifier
 resolves to a *class-name* or *enum-name*, the
 *elaborated-type-specifier* introduces it into the declaration the same
 way a *simple-type-specifier* introduces its *type-name*. If the
 *identifier* resolves to a *typedef-name* or the *simple-template-id*
 resolves to an alias template specialization, the
+*elaborated-type-specifier* is ill-formed.
+[*Note 1*:
+This implies that, within a class template with a template
+*type-parameter* `T`, the declaration
 ``` cpp
 friend class T;
 ```
 is ill-formed. However, the similar declaration `friend T;` is allowed (
 [[class.friend]]).
+— *end note*]
 The *class-key* or `enum` keyword present in the
 *elaborated-type-specifier* shall agree in kind with the declaration to
 which the name in the *elaborated-type-specifier* refers. This rule also
 applies to the form of *elaborated-type-specifier* that declares a
 *class-name* or `friend` class since it can be construed as referring to
 [[dcl.enum]]), the `union` *class-key* shall be used to refer to a union
 (Clause  [[class]]), and either the `class` or `struct` *class-key*
 shall be used to refer to a class (Clause  [[class]]) declared using the
 `class` or `struct` *class-key*.
+[*Example 1*:
 ``` cpp
 enum class E { a, b };
 enum E x = E::a;                // OK
 ```
+— *end example*]
+#### The `auto` specifier <a id="dcl.spec.auto">[[dcl.spec.auto]]</a>
+The `auto` and `decltype(auto)` *type-specifier*s are used to designate
+a placeholder type that will be replaced later by deduction from an
+initializer. The `auto` *type-specifier* is also used to introduce a
+function type having a *trailing-return-type* or to signify that a
+lambda is a generic lambda ([[expr.prim.lambda.closure]]). The `auto`
+*type-specifier* is also used to introduce a structured binding
+declaration ([[dcl.struct.bind]]).
 The placeholder type can appear with a function declarator in the
 *decl-specifier-seq*, *type-specifier-seq*, *conversion-function-id*, or
 *trailing-return-type*, in any context where such a declarator is valid.
 If the function declarator includes a *trailing-return-type* (
+[[dcl.fct]]), that *trailing-return-type* specifies the declared return
+type of the function. Otherwise, the function declarator shall declare a
+function. If the declared return type of the function contains a
+placeholder type, the return type of the function is deduced from
+non-discarded `return` statements, if any, in the body of the function (
+[[stmt.if]]).
 If the `auto` *type-specifier* appears as one of the *decl-specifier*s
 in the *decl-specifier-seq* of a *parameter-declaration* of a
 *lambda-expression*, the lambda is a *generic lambda* (
+[[expr.prim.lambda.closure]]).
+[*Example 1*:
 ``` cpp
 auto glambda = [](int i, auto a) { return i; };     // OK: a generic lambda
 ```
+— *end example*]
 The type of a variable declared using `auto` or `decltype(auto)` is
+deduced from its initializer. This use is allowed in an initializing
+declaration ([[dcl.init]]) of a variable. `auto` or `decltype(auto)`
+shall appear as one of the *decl-specifier*s in the *decl-specifier-seq*
+and the *decl-specifier-seq* shall be followed by one or more
+*declarator*s, each of which shall be followed by a non-empty
 *initializer*. In an *initializer* of the form
 ``` cpp
 ( expression-list )
 ```
 the *expression-list* shall be a single *assignment-expression*.
+[*Example 2*:
 ``` cpp
 auto x = 5;                     // OK: x has type int
 const auto *v = &x, u = 6;      // OK: v has type const int*, u has type const int
 static auto y = 0.0;            // OK: y has type double
 auto int r;                     // error: auto is not a storage-class-specifier
 auto f() -> int;                // OK: f returns int
 auto g() { return 0.0; }        // OK: g returns double
 auto h();                       // OK: h's return type will be deduced when it is defined
 ```
+— *end example*]
+A placeholder type can also be used in the *type-specifier-seq* in the
+*new-type-id* or *type-id* of a *new-expression* ([[expr.new]]) and as
+a *decl-specifier* of the *parameter-declaration*'s *decl-specifier-seq*
+in a *template-parameter* ([[temp.param]]).
 A program that uses `auto` or `decltype(auto)` in a context not
 explicitly allowed in this section is ill-formed.
 If the *init-declarator-list* contains more than one *init-declarator*,
 they shall all form declarations of variables. The type of each declared
+variable is determined by placeholder type deduction (
+[[dcl.type.auto.deduct]]), and if the type that replaces the placeholder
+type is not the same in each deduction, the program is ill-formed.
+[*Example 3*:
 ``` cpp
 auto x = 5, *y = &x;            // OK: auto is int
 auto a = 5, b = { 1, 2 };       // error: different types for auto
 ```
+— *end example*]
 If a function with a declared return type that contains a placeholder
+type has multiple non-discarded `return` statements, the return type is
+deduced for each such `return` statement. If the type deduced is not the
+same in each deduction, the program is ill-formed.
 If a function with a declared return type that uses a placeholder type
+has no non-discarded `return` statements, the return type is deduced as
+though from a `return` statement with no operand at the closing brace of
+the function body.
+[*Example 4*:
 ``` cpp
 auto  f() { }                   // OK, return type is void
 auto* g() { }                   // error, cannot deduce auto* from void()
 ```
+— *end example*]
 If the type of an entity with an undeduced placeholder type is needed to
 determine the type of an expression, the program is ill-formed. Once a
+non-discarded `return` statement has been seen in a function, however,
+the return type deduced from that statement can be used in the rest of
+the function, including in other `return` statements.
+[*Example 5*:
 ``` cpp
 auto n = n;                     // error, n's type is unknown
 auto f();
 void g() { &f; }                // error, f's return type is unknown
   else
     return sum(i-1)+i;          // OK, sum's return type has been deduced
 }
 ```
+— *end example*]
 Return type deduction for a function template with a placeholder in its
 declared type occurs when the definition is instantiated even if the
 function body contains a `return` statement with a non-type-dependent
+operand.
+[*Note 1*: Therefore, any use of a specialization of the function
+template will cause an implicit instantiation. Any errors that arise
+from this instantiation are not in the immediate context of the function
+type and can result in the program being ill-formed (
+[[temp.deduct]]). — *end note*]
+[*Example 6*:
 ``` cpp
 template <class T> auto f(T t) { return t; }    // return type deduced at instantiation time
 typedef decltype(f(1)) fint_t;                  // instantiates f<int> to deduce return type
 template<class T> auto f(T* t) { return *t; }
 void g() { int (*p)(int*) = &f; }               // instantiates both fs to determine return types,
                                                 // chooses second
 ```
+— *end example*]
 Redeclarations or specializations of a function or function template
 with a declared return type that uses a placeholder type shall also use
 that placeholder, not a deduced type.
+[*Example 7*:
 ``` cpp
 auto f();
 auto f() { return 42; }                         // return type is int
 auto f();                                       // OK
 int f();                                        // error, cannot be overloaded with auto f()
   friend T frf(T);
 };
 auto frf(int i) { return i; }                   // not a friend of A<int>
 ```
+— *end example*]
 A function declared with a return type that uses a placeholder type
 shall not be `virtual` ([[class.virtual]]).
 An explicit instantiation declaration ([[temp.explicit]]) does not
 cause the instantiation of an entity declared using a placeholder type,
 but it also does not prevent that entity from being instantiated as
 needed to determine its type.
+[*Example 8*:
 ``` cpp
 template <typename T> auto f(T t) { return t; }
 extern template auto f(int);    // does not instantiate f<int>
 int (*p)(int) = f;              // instantiates f<int> to determine its return type, but an explicit
                                 // instantiation definition is still required somewhere in the program
 ```
+— *end example*]
+##### Placeholder type deduction <a id="dcl.type.auto.deduct">[[dcl.type.auto.deduct]]</a>
+*Placeholder type deduction* is the process by which a type containing a
+placeholder type is replaced by a deduced type.
+A type `T` containing a placeholder type, and a corresponding
+initializer `e`, are determined as follows:
+- for a non-discarded `return` statement that occurs in a function
+  declared with a return type that contains a placeholder type, `T` is
+  the declared return type and `e` is the operand of the `return`
+  statement. If the `return` statement has no operand, then `e` is
+  `void()`;
+- for a variable declared with a type that contains a placeholder type,
+  `T` is the declared type of the variable and `e` is the initializer.
+  If the initialization is direct-list-initialization, the initializer
+  shall be a *braced-init-list* containing only a single
+  *assignment-expression* and `e` is the *assignment-expression*;
+- for a non-type template parameter declared with a type that contains a
+  placeholder type, `T` is the declared type of the non-type template
+  parameter and `e` is the corresponding template argument.
+In the case of a `return` statement with no operand or with an operand
+of type `void`, `T` shall be either `decltype(auto)` or cv `auto`.
+If the deduction is for a `return` statement and `e` is a
+*braced-init-list* ([[dcl.init.list]]), the program is ill-formed.
+If the placeholder is the `auto` *type-specifier*, the deduced type T'
+replacing `T` is determined using the rules for template argument
+deduction. Obtain `P` from `T` by replacing the occurrences of `auto`
+with either a new invented type template parameter `U` or, if the
+initialization is copy-list-initialization, with
+`std::initializer_list<U>`. Deduce a value for `U` using the rules of
+template argument deduction from a function call (
+[[temp.deduct.call]]), where `P` is a function template parameter type
+and the corresponding argument is `e`. If the deduction fails, the
+declaration is ill-formed. Otherwise, T' is obtained by substituting the
+deduced `U` into `P`.
+[*Example 9*:
+``` cpp
+auto x1 = { 1, 2 };             // decltype(x1) is std::initializer_list<int>
+auto x2 = { 1, 2.0 };           // error: cannot deduce element type
+auto x3{ 1, 2 };                // error: not a single element
+auto x4 = { 3 };                // decltype(x4) is std::initializer_list<int>
+auto x5{ 3 };                   // decltype(x5) is int
+```
+— *end example*]
+[*Example 10*:
+``` cpp
+const auto &i = expr;
+```
+The type of `i` is the deduced type of the parameter `u` in the call
+`f(expr)` of the following invented function template:
+``` cpp
+template <class U> void f(const U& u);
+```
+— *end example*]
+If the placeholder is the `decltype(auto)` *type-specifier*, `T` shall
+be the placeholder alone. The type deduced for `T` is determined as
+described in  [[dcl.type.simple]], as though `e` had been the operand of
+the `decltype`.
+[*Example 11*:
+``` cpp
+int i;
+int&& f();
+auto           x2a(i);          // decltype(x2a) is int
+decltype(auto) x2d(i);          // decltype(x2d) is int
+auto           x3a = i;         // decltype(x3a) is int
+decltype(auto) x3d = i;         // decltype(x3d) is int
+auto           x4a = (i);       // decltype(x4a) is int
+decltype(auto) x4d = (i);       // decltype(x4d) is int&
+auto           x5a = f();       // decltype(x5a) is int
+decltype(auto) x5d = f();       // decltype(x5d) is int&&
+auto           x6a = { 1, 2 };  // decltype(x6a) is std::initializer_list<int>
+decltype(auto) x6d = { 1, 2 };  // error, { 1, 2 } is not an expression
+auto          *x7a = &i;        // decltype(x7a) is int*
+decltype(auto)*x7d = &i;        // error, declared type is not plain decltype(auto)
+```
+— *end example*]
+#### Deduced class template specialization types <a id="dcl.type.class.deduct">[[dcl.type.class.deduct]]</a>
+If a placeholder for a deduced class type appears as a *decl-specifier*
+in the *decl-specifier-seq* of an initializing declaration (
+[[dcl.init]]) of a variable, the placeholder is replaced by the return
+type of the function selected by overload resolution for class template
+deduction ([[over.match.class.deduct]]). If the *decl-specifier-seq* is
+followed by an *init-declarator-list* or *member-declarator-list*
+containing more than one *declarator*, the type that replaces the
+placeholder shall be the same in each deduction.
+A placeholder for a deduced class type can also be used in the
+*type-specifier-seq* in the *new-type-id* or *type-id* of a
+*new-expression* ([[expr.new]]), or as the *simple-type-specifier* in
+an explicit type conversion (functional notation) ([[expr.type.conv]]).
+A placeholder for a deduced class type shall not appear in any other
+context.
+[*Example 1*:
+``` cpp
+template<class T> struct container {
+    container(T t) {}
+    template<class Iter> container(Iter beg, Iter end);
+};
+template<class Iter>
+container(Iter b, Iter e) -> container<typename std::iterator_traits<Iter>::value_type>;
+std::vector<double> v = { ... };
+container c(7);                         // OK, deduces int for T
+auto d = container(v.begin(), v.end()); // OK, deduces double for T
+container e{5, 6};                      // error, int is not an iterator
+```
+— *end example*]
 ## Enumeration declarations <a id="dcl.enum">[[dcl.enum]]</a>
 An enumeration is a distinct type ([[basic.compound]]) with named
+constants. Its name becomes an *enum-name* within its scope.
 ``` bnf
 enum-name:
     identifier
 ```
     enum-head '{' enumerator-list ', }'
 ```
 ``` bnf
 enum-head:
+    enum-key attribute-specifier-seqₒₚₜ enum-head-nameₒₚₜ enum-baseₒₚₜ
+```
+``` bnf
+enum-head-name:
+    nested-name-specifierₒₚₜ identifier
 ```
 ``` bnf
 opaque-enum-declaration:
+    enum-key attribute-specifier-seqₒₚₜ nested-name-specifierₒₚₜ identifier enum-baseₒₚₜ ';'
 ```
 ``` bnf
 enum-key:
     'enum'
     enumerator '=' constant-expression
 ```
 ``` bnf
 enumerator:
+    identifier attribute-specifier-seqₒₚₜ
 ```
 The optional *attribute-specifier-seq* in the *enum-head* and the
 *opaque-enum-declaration* appertains to the enumeration; the attributes
 in that *attribute-specifier-seq* are thereafter considered attributes
 of the enumeration whenever it is named. A `:` following “`enum`
+*nested-name-specifier*ₒₚₜ  *identifier*” within the
+*decl-specifier-seq* of a *member-declaration* is parsed as part of an
+*enum-base*.
+[*Note 1*:
+This resolves a potential ambiguity between the declaration of an
+enumeration with an *enum-base* and the declaration of an unnamed
+bit-field of enumeration type.
+[*Example 1*:
 ``` cpp
    struct S {
      enum E : int {};
      enum E : int {};           // error: redeclaration of enumeration
    };
 ```
+— *end example*]
+— *end note*]
+If an *opaque-enum-declaration* contains a *nested-name-specifier*, the
+declaration shall be an explicit specialization ([[temp.expl.spec]]).
 The enumeration type declared with an *enum-key* of only `enum` is an
+*unscoped enumeration*, and its *enumerator*s are *unscoped
+enumerators*. The *enum-key*s `enum class` and `enum struct` are
+semantically equivalent; an enumeration type declared with one of these
+is a *scoped enumeration*, and its *enumerator*s are *scoped
+enumerators*. The optional *identifier* shall not be omitted in the
+declaration of a scoped enumeration. The *type-specifier-seq* of an
+*enum-base* shall name an integral type; any cv-qualification is
+ignored. An *opaque-enum-declaration* declaring an unscoped enumeration
+shall not omit the *enum-base*. The identifiers in an *enumerator-list*
+are declared as constants, and can appear wherever constants are
+required. An *enumerator-definition* with `=` gives the associated
+*enumerator* the value indicated by the *constant-expression*. If the
+first *enumerator* has no *initializer*, the value of the corresponding
 constant is zero. An *enumerator-definition* without an *initializer*
 gives the *enumerator* the value obtained by increasing the value of the
 previous *enumerator* by one.
+[*Example 2*:
 ``` cpp
 enum { a, b, c=0 };
 enum { d, e, f=e+2 };
 ```
 defines `a`, `c`, and `d` to be zero, `b` and `e` to be `1`, and `f` to
 be `3`.
+— *end example*]
+The optional *attribute-specifier-seq* in an *enumerator* appertains to
+that enumerator.
 An *opaque-enum-declaration* is either a redeclaration of an enumeration
+in the current scope or a declaration of a new enumeration.
+[*Note 2*: An enumeration declared by an *opaque-enum-declaration* has
+fixed underlying type and is a complete type. The list of enumerators
+can be provided in a later redeclaration with an
+*enum-specifier*. — *end note*]
+A scoped enumeration shall not be later redeclared as unscoped or with a
 different underlying type. An unscoped enumeration shall not be later
 redeclared as scoped and each redeclaration shall include an *enum-base*
 specifying the same underlying type as in the original declaration.
 If the *enum-key* is followed by a *nested-name-specifier*, the
 *nested-name-specifier* refers (i.e., neither inherited nor introduced
 by a *using-declaration*), and the *enum-specifier* shall appear in a
 namespace enclosing the previous declaration.
 Each enumeration defines a type that is different from all other types.
+Each enumeration also has an *underlying type*. The underlying type can
+be explicitly specified using an *enum-base*. For a scoped enumeration
 type, the underlying type is `int` if it is not explicitly specified. In
 both of these cases, the underlying type is said to be *fixed*.
 Following the closing brace of an *enum-specifier*, each enumerator has
 the type of its enumeration. If the underlying type is fixed, the type
 of each enumerator prior to the closing brace is the underlying type and
 is as if the enumeration had a single enumerator with value 0.
 For an enumeration whose underlying type is fixed, the values of the
 enumeration are the values of the underlying type. Otherwise, for an
 enumeration where eₘin is the smallest enumerator and eₘax is the
+largest, the values of the enumeration are the values in the range bₘin
+to bₘax, defined as follows: Let K be 1 for a two’s complement
+representation and 0 for a ones’ complement or sign-magnitude
+representation. bₘax is the smallest value greater than or equal to
+max(|eₘin| - K, |eₘax|) and equal to $2^M-1$, where M is a non-negative
+integer. bₘin is zero if eₘin is non-negative and -(bₘax+K) otherwise.
 The size of the smallest bit-field large enough to hold all the values
+of the enumeration type is max(M,1) if bₘin is zero and M+1 otherwise.
 It is possible to define an enumeration that has values not defined by
 any of its enumerators. If the *enumerator-list* is empty, the values of
 the enumeration are as if the enumeration had a single enumerator with
 value 0.[^4]
+Two enumeration types are *layout-compatible enumerations* if they have
+the same underlying type.
 The value of an enumerator or an object of an unscoped enumeration type
 is converted to an integer by integral promotion ([[conv.prom]]).
+[*Example 3*:
 ``` cpp
   enum color { red, yellow, green=20, blue };
   color col = red;
   color* cp = &col;
   if (*cp == blue)              // ...
 `yellow`, `green`, `blue`; these values can be converted to the integral
 values `0`, `1`, `20`, and `21`. Since enumerations are distinct types,
 objects of type `color` can be assigned only values of type `color`.
 ``` cpp
+color c = 1;                    // error: type mismatch, no conversion from int to color
+int i = yellow;                 // OK: yellow converted to integral value 1, integral promotion
 ```
 Note that this implicit `enum` to `int` conversion is not provided for a
 scoped enumeration:
 int x = Col::red;               // error: no Col to int conversion
 Col y = Col::red;
 if (y) { }                      // error: no Col to bool conversion
 ```
+— *end example*]
 Each *enum-name* and each unscoped *enumerator* is declared in the scope
 that immediately contains the *enum-specifier*. Each scoped *enumerator*
 is declared in the scope of the enumeration. These names obey the scope
+rules defined for all names in  [[basic.scope]] and  [[basic.lookup]].
+[*Example 4*:
 ``` cpp
 enum direction { left='l', right='r' };
 void g()  {
   a = high;                     // error: high not in scope
   a = altitude::low;            // OK
 }
 ```
+— *end example*]
 An enumerator declared in class scope can be referred to using the class
 member access operators (`::`, `.` (dot) and `->` (arrow)), see
 [[expr.ref]].
+[*Example 5*:
 ``` cpp
 struct X {
   enum direction { left='l', right='r' };
   int f(int i) { return i==left ? 0 : i==right ? 1 : 2; }
 };
   i = p->f(p->left);            // OK
   // ...
 }
 ```
+— *end example*]
+If an *enum-head* contains a *nested-name-specifier*, the
+*enum-specifier* shall refer to an enumeration that was previously
+declared directly in the class or namespace to which the
+*nested-name-specifier* refers, or in an element of the inline namespace
+set ([[namespace.def]]) of that namespace (i.e., not merely inherited
+or introduced by a *using-declaration*), and the *enum-specifier* shall
+appear in a namespace enclosing the previous declaration. In such cases,
+the *nested-name-specifier* of the *enum-head* of the definition shall
+not begin with a *decltype-specifier*.
 ## Namespaces <a id="basic.namespace">[[basic.namespace]]</a>
 A namespace is an optionally-named declarative region. The name of a
 namespace can be used to access entities declared in that namespace;
 that is, the members of the namespace. Unlike other declarative regions,
 The outermost declarative region of a translation unit is a namespace;
 see  [[basic.scope.namespace]].
 ### Namespace definition <a id="namespace.def">[[namespace.def]]</a>
 ``` bnf
 namespace-name:
+ identifier
         namespace-alias
 ```
 ``` bnf
 namespace-definition:
         named-namespace-definition
         unnamed-namespace-definition
+        nested-namespace-definition
 ```
 ``` bnf
 named-namespace-definition:
+ 'inline'ₒₚₜ 'namespace' attribute-specifier-seqₒₚₜ identifier '{' namespace-body '}'
 ```
 ``` bnf
 unnamed-namespace-definition:
+        'inline'ₒₚₜ 'namespace' attribute-specifier-seqₒₚₜ '{' namespace-body '}'
+```
+``` bnf
+nested-namespace-definition:
+        'namespace' enclosing-namespace-specifier '::' identifier '{' namespace-body '}'
+```
+``` bnf
+enclosing-namespace-specifier:
+        identifier
+        enclosing-namespace-specifier '::' identifier
 ```
 ``` bnf
 namespace-body:
         declaration-seqₒₚₜ
 ```
 Every *namespace-definition* shall appear in the global scope or in a
 namespace scope ([[basic.scope.namespace]]).
+In a *named-namespace-definition*, the *identifier* is the name of the
+namespace. If the *identifier*, when looked up (
+[[basic.lookup.unqual]]), refers to a *namespace-name* (but not a
+*namespace-alias*) that was introduced in the namespace in which the
+*named-namespace-definition* appears or that was introduced in a member
+of the inline namespace set of that namespace, the
+*namespace-definition* *extends* the previously-declared namespace.
+Otherwise, the *identifier* is introduced as a *namespace-name* into the
+declarative region in which the *named-namespace-definition* appears.
 Because a *namespace-definition* contains *declaration*s in its
 *namespace-body* and a *namespace-definition* is itself a *declaration*,
+it follows that *namespace-definition*s can be nested.
+[*Example 1*:
 ``` cpp
 namespace Outer {
   int i;
   namespace Inner {
     void g() { i++; }           // Inner::i
   }
 }
 ```
+— *end example*]
 The *enclosing namespaces* of a declaration are those namespaces in
 which the declaration lexically appears, except for a redeclaration of a
 namespace member outside its original namespace (e.g., a definition as
 specified in  [[namespace.memdef]]). Such a redeclaration has the same
 enclosing namespaces as the original declaration.
+[*Example 2*:
 ``` cpp
 namespace Q {
   namespace V {
     void f();                   // enclosing namespaces are the global namespace, Q, and Q::V
     class C { void m(); };
   void V::C::m() {              // enclosing namespaces are the global namespace, Q, and Q::V
   }
 }
 ```
+— *end example*]
 If the optional initial `inline` keyword appears in a
 *namespace-definition* for a particular namespace, that namespace is
 declared to be an *inline namespace*. The `inline` keyword may be used
+on a *namespace-definition* that extends a namespace only if it was
+previously used on the *namespace-definition* that initially declared
+the *namespace-name* for that namespace.
+The optional *attribute-specifier-seq* in a *named-namespace-definition*
+appertains to the namespace being defined or extended.
 Members of an inline namespace can be used in most respects as though
 they were members of the enclosing namespace. Specifically, the inline
 namespace and its enclosing namespace are both added to the set of
 associated namespaces used in argument-dependent lookup (
 [[basic.lookup.argdep]]) whenever one of them is, and a
 *using-directive* ([[namespace.udir]]) that names the inline namespace
 is implicitly inserted into the enclosing namespace as for an unnamed
 namespace ([[namespace.unnamed]]). Furthermore, each member of the
+inline namespace can subsequently be partially specialized (
+[[temp.class.spec]]), explicitly instantiated ([[temp.explicit]]), or
+explicitly specialized ([[temp.expl.spec]]) as though it were a member
+of the enclosing namespace. Finally, looking up a name in the enclosing
+namespace via explicit qualification ([[namespace.qual]]) will include
+members of the inline namespace brought in by the *using-directive* even
+if there are declarations of that name in the enclosing namespace.
 These properties are transitive: if a namespace `N` contains an inline
 namespace `M`, which in turn contains an inline namespace `O`, then the
 members of `O` can be used as though they were members of `M` or `N`.
 The *inline namespace set* of `N` is the transitive closure of all
 inline namespaces in `N`. The *enclosing namespace set* of `O` is the
 set of namespaces consisting of the innermost non-inline namespace
 enclosing an inline namespace `O`, together with any intervening inline
 namespaces.
+A *nested-namespace-definition* with an *enclosing-namespace-specifier*
+`E`, *identifier* `I` and *namespace-body* `B` is equivalent to
+``` cpp
+namespace E { namespace I { B } }
+```
+[*Example 3*:
+``` cpp
+namespace A::B::C {
+  int i;
+}
+```
+The above has the same effect as:
+``` cpp
+namespace A {
+  namespace B {
+    namespace C {
+      int i;
+    }
+  }
+}
+```
+— *end example*]
 #### Unnamed namespaces <a id="namespace.unnamed">[[namespace.unnamed]]</a>
 An *unnamed-namespace-definition* behaves as if it were replaced by
 ``` bnf
+'inline'ₒₚₜ 'namespace' 'unique ' '{ /* empty body */ }'
+'using namespace' 'unique ' ';'
+'namespace' 'unique ' '{' namespace-body '}'
 ```
 where `inline` appears if and only if it appears in the
+*unnamed-namespace-definition* and all occurrences of `unique ` in a
 translation unit are replaced by the same identifier, and this
+identifier differs from all other identifiers in the translation unit.
+The optional *attribute-specifier-seq* in the
+*unnamed-namespace-definition* appertains to `unique `.
+[*Example 1*:
 ``` cpp
 namespace { int i; }            // unique ::i
 void f() { i++; }               // unique ::i++
   A::i++;                       // A::unique ::i
   j++;                          // A::unique ::j
 }
 ```
+— *end example*]
 #### Namespace member definitions <a id="namespace.memdef">[[namespace.memdef]]</a>
+A declaration in a namespace `N` (excluding declarations in nested
+scopes) whose *declarator-id* is an *unqualified-id* ([[dcl.meaning]]),
+whose *class-head-name* (Clause [[class]]) or *enum-head-name* (
+[[dcl.enum]]) is an *identifier*, or whose *elaborated-type-specifier*
+is of the form *class-key* *attribute-specifier-seq*ₒₚₜ  *identifier* (
+[[dcl.type.elab]]), or that is an *opaque-enum-declaration*, declares
+(or redeclares) its *unqualified-id* or *identifier* as a member of `N`.
+[*Note 1*: An explicit instantiation ([[temp.explicit]]) or explicit
+specialization ([[temp.expl.spec]]) of a template does not introduce a
+name and thus may be declared using an *unqualified-id* in a member of
+the enclosing namespace set, if the primary template is declared in an
+inline namespace. — *end note*]
+[*Example 1*:
 ``` cpp
 namespace X {
+  void f() { ... }        // OK: introduces X::f()
+  namespace M {
+    void g();                   // OK: introduces X::M::g()
+  }
+  using M::g;
+  void g();                     // error: conflicts with X::M::g()
 }
 ```
+— *end example*]
 Members of a named namespace can also be defined outside that namespace
 by explicit qualification ([[namespace.qual]]) of the name being
 defined, provided that the entity being defined was already declared in
 the namespace and the definition appears after the point of declaration
 in a namespace that encloses the declaration’s namespace.
+[*Example 2*:
 ``` cpp
 namespace Q {
   namespace V {
     void f();
   }
+  void V::f() { ... }     // OK
+  void V::g() { ... }     // error: g() is not yet a member of V
   namespace V {
     void g();
   }
 }
 namespace R {
+  void Q::V::g() { ... }  // error: R doesn't enclose Q
 }
 ```
+— *end example*]
 If a `friend` declaration in a non-local class first declares a class,
+function, class template or function template[^5] the friend is a member
 of the innermost enclosing namespace. The `friend` declaration does not
 by itself make the name visible to unqualified lookup (
 [[basic.lookup.unqual]]) or qualified lookup ([[basic.lookup.qual]]).
+[*Note 2*: The name of the friend will be visible in its namespace if a
+matching declaration is provided at namespace scope (either before or
+after the class definition granting friendship). — *end note*]
+If a friend function or function template is called, its name may be
+found by the name lookup that considers functions from namespaces and
+classes associated with the types of the function arguments (
+[[basic.lookup.argdep]]). If the name in a `friend` declaration is
+neither qualified nor a *template-id* and the declaration is a function
+or an *elaborated-type-specifier*, the lookup to determine whether the
+entity has been previously declared shall not consider any scopes
+outside the innermost enclosing namespace.
+[*Note 3*: The other forms of `friend` declarations cannot declare a
+new member of the innermost enclosing namespace and thus follow the
+usual lookup rules. — *end note*]
+[*Example 3*:
 ``` cpp
 // Assume f and g have not yet been declared.
 void h(int);
 template <class T> void f2(T);
   };
   // A::f, A::g and A::h are not visible here
   X x;
   void g() { f(x); }            // definition of A::g
+  void f(X) { ... }       // definition of A::f
+  void h(int) { ... } // definition of A::h
   // A::f, A::g and A::h are visible here and known to be friends
 }
 using A::x;
   A::X::f(x);                   // error: f is not a member of A::X
   A::X::Y::g();                 // error: g is not a member of A::X::Y
 }
 ```
+— *end example*]
 ### Namespace alias <a id="namespace.alias">[[namespace.alias]]</a>
 A *namespace-alias-definition* declares an alternate name for a
 namespace according to the following grammar:
     nested-name-specifierₒₚₜ namespace-name
 ```
 The *identifier* in a *namespace-alias-definition* is a synonym for the
 name of the namespace denoted by the *qualified-namespace-specifier* and
+becomes a *namespace-alias*.
+[*Note 1*: When looking up a *namespace-name* in a
 *namespace-alias-definition*, only namespace names are considered, see
+[[basic.lookup.udir]]. — *end note*]
 In a declarative region, a *namespace-alias-definition* can be used to
 redefine a *namespace-alias* declared in that declarative region to
+refer only to the namespace to which it already refers.
+[*Example 1*:
+The following declarations are well-formed:
 ``` cpp
+namespace Company_with_very_long_name { ... }
 namespace CWVLN = Company_with_very_long_name;
 namespace CWVLN = Company_with_very_long_name;  // OK: duplicate
 namespace CWVLN = CWVLN;
 ```
+— *end example*]
 ### The `using` declaration <a id="namespace.udecl">[[namespace.udecl]]</a>
 ``` bnf
 using-declaration:
+    'using' using-declarator-list ';'
 ```
+``` bnf
+using-declarator-list:
+    using-declarator '...'ₒₚₜ
+ using-declarator-list ',' using-declarator '...'ₒₚₜ
+```
+``` bnf
+using-declarator:
+    'typename'ₒₚₜ nested-name-specifier unqualified-id
+```
+Each *using-declarator* in a *using-declaration* [^6] introduces a set
+of declarations into the declarative region in which the
+*using-declaration* appears. The set of declarations introduced by the
+*using-declarator* is found by performing qualified name lookup (
+[[basic.lookup.qual]], [[class.member.lookup]]) for the name in the
+*using-declarator*, excluding functions that are hidden as described
+below. If the *using-declarator* does not name a constructor, the
+*unqualified-id* is declared in the declarative region in which the
+*using-declaration* appears as a synonym for each declaration introduced
+by the *using-declarator*.
+[*Note 1*: Only the specified name is so declared; specifying an
+enumeration name in a *using-declaration* does not declare its
+enumerators in the *using-declaration*'s declarative
+region. — *end note*]
+If the *using-declarator* names a constructor, it declares that the
+class *inherits* the set of constructor declarations introduced by the
+*using-declarator* from the nominated base class.
 Every *using-declaration* is a *declaration* and a *member-declaration*
+and can therefore be used in a class definition.
+[*Example 1*:
 ``` cpp
 struct B {
   void f(char);
   void g(char);
   void f(int) { f('c'); }       // calls B::f(char)
   void g(int) { g('c'); }       // recursively calls D::g(int)
 };
 ```
+— *end example*]
+In a *using-declaration* used as a *member-declaration*, each
+*using-declarator*'s *nested-name-specifier* shall name a base class of
+the class being defined. If a *using-declarator* names a constructor,
+its *nested-name-specifier* shall name a direct base class of the class
+being defined.
+[*Example 2*:
+``` cpp
+template <typename... bases>
+struct X : bases... {
+  using bases::g...;
+};
+X<B, D> x;                      // OK: B::g and D::g introduced
+```
+— *end example*]
+[*Example 3*:
 ``` cpp
 class C {
   int g();
 };
   using B::x;                   // OK: x is a union member of base B
   using C::g;                   // error: C isn't a base of D2
 };
 ```
+— *end example*]
+[*Note 2*: Since destructors do not have names, a *using-declaration*
+cannot refer to a destructor for a base class. Since specializations of
+member templates for conversion functions are not found by name lookup,
+they are not considered when a *using-declaration* specifies a
+conversion function ([[temp.mem]]). — *end note*]
+If a constructor or assignment operator brought from a base class into a
+derived class has the signature of a copy/move constructor or assignment
+operator for the derived class ([[class.copy]]), the
 *using-declaration* does not by itself suppress the implicit declaration
+of the derived class member; the member from the base class is hidden or
+overridden by the implicitly-declared copy/move constructor or
+assignment operator of the derived class, as described below.
 A *using-declaration* shall not name a *template-id*.
+[*Example 4*:
 ``` cpp
 struct A {
   template <class T> void f(T);
   template <class T> struct X { };
 };
   using A::f<double>;           // ill-formed
   using A::X<int>;              // ill-formed
 };
 ```
+— *end example*]
 A *using-declaration* shall not name a namespace.
 A *using-declaration* shall not name a scoped enumerator.
+A *using-declaration* that names a class member shall be a
 *member-declaration*.
+[*Example 5*:
 ``` cpp
 struct X {
   int i;
   static int s;
 };
 void f() {
+  using X::i; // error: X::i is a class member and this is not a member declaration.
+  using X::s;                   // error: X::s is a class member and this is not a member declaration.
 }
 ```
+— *end example*]
 Members declared by a *using-declaration* can be referred to by explicit
+qualification just like other member names ([[namespace.qual]]).
+[*Example 6*:
 ``` cpp
 void f();
 namespace A {
   X::f();                       // calls ::f
   X::g();                       // calls A::g
 }
 ```
+— *end example*]
 A *using-declaration* is a *declaration* and can therefore be used
 repeatedly where (and only where) multiple declarations are allowed.
+[*Example 7*:
 ``` cpp
 namespace A {
   int i;
 }
 namespace A1 {
+  using A::i, A::i;             // OK: double declaration
 }
 struct B {
   int i;
 };
 struct X : B {
+  using B::i, B::i;             // error: double member declaration
 };
 ```
+— *end example*]
+[*Note 3*: For a *using-declaration* whose *nested-name-specifier*
+names a namespace, members added to the namespace after the
+*using-declaration* are not in the set of introduced declarations, so
+they are not considered when a use of the name is made. Thus, additional
+overloads added after the *using-declaration* are ignored, but default
+function arguments ([[dcl.fct.default]]), default template arguments (
 [[temp.param]]), and template specializations ([[temp.class.spec]],
+[[temp.expl.spec]]) are considered. — *end note*]
+[*Example 8*:
 ``` cpp
 namespace A {
   void f(int);
 }
+using A::f;         // f is a synonym for A::f; that is, for A::f(int).
 namespace A {
   void f(char);
 }
 void foo() {
+  f('a');           // calls f(int), even though f(char) exists.
+}
 void bar() {
+  using A::f;       // f is a synonym for A::f; that is, for A::f(int) and A::f(char).
   f('a');           // calls f(char)
 }
 ```
+— *end example*]
+[*Note 4*: Partial specializations of class templates are found by
+looking up the primary class template and then considering all partial
+specializations of that template. If a *using-declaration* names a class
+template, partial specializations introduced after the
+*using-declaration* are effectively visible because the primary template
+is visible ([[temp.class.spec]]). — *end note*]
 Since a *using-declaration* is a declaration, the restrictions on
 declarations of the same name in the same declarative region (
 [[basic.scope]]) also apply to *using-declaration*s.
+[*Example 9*:
 ``` cpp
 namespace A {
   int x;
 }
   x = 99;           // assigns to A::x
   struct x x1;      // x1 has class type B::x
 }
 ```
+— *end example*]
 If a function declaration in namespace scope or block scope has the same
 name and the same parameter-type-list ([[dcl.fct]]) as a function
 introduced by a *using-declaration*, and the declarations do not declare
 the same function, the program is ill-formed. If a function template
 declaration in namespace scope has the same name, parameter-type-list,
 return type, and template parameter list as a function template
+introduced by a *using-declaration*, the program is ill-formed.
+[*Note 5*:
+Two *using-declaration*s may introduce functions with the same name and
+the same parameter-type-list. If, for a call to an unqualified function
 name, function overload resolution selects the functions introduced by
 such *using-declaration*s, the function call is ill-formed.
+[*Example 10*:
 ``` cpp
 namespace B {
   void f(int);
   void f(double);
 }
   f(1);             // error: ambiguous: B::f(int) or C::f(int)?
   void f(int);      // error: f(int) conflicts with C::f(int) and B::f(int)
 }
 ```
+— *end example*]
+— *end note*]
+When a *using-declarator* brings declarations from a base class into a
+derived class, member functions and member function templates in the
 derived class override and/or hide member functions and member function
 templates with the same name, parameter-type-list ([[dcl.fct]]),
 cv-qualification, and *ref-qualifier* (if any) in a base class (rather
+than conflicting). Such hidden or overridden declarations are excluded
+from the set of declarations introduced by the *using-declarator*.
+[*Example 11*:
 ``` cpp
 struct B {
   virtual void f(int);
   virtual void f(char);
   p->f(1);          // calls D::f(int)
   p->f('a');        // calls B::f(char)
   p->g(1);          // calls B::g(int)
   p->g('a');        // calls D::g(char)
 }
+struct B1 {
+  B1(int);
+};
+struct B2 {
+  B2(int);
+};
+struct D1 : B1, B2 {
+  using B1::B1;
+  using B2::B2;
+};
+D1 d1(0);           // ill-formed: ambiguous
+struct D2 : B1, B2 {
+  using B1::B1;
+  using B2::B2;
+  D2(int);          // OK: D2::D2(int) hides B1::B1(int) and B2::B2(int)
+};
+D2 d2(0);           // calls D2::D2(int)
 ```
+— *end example*]
+For the purpose of overload resolution, the functions that are
+introduced by a *using-declaration* into a derived class are treated as
+though they were members of the derived class. In particular, the
 implicit `this` parameter shall be treated as if it were a pointer to
 the derived class rather than to the base class. This has no effect on
 the type of the function, and in all other respects the function remains
+a member of the base class. Likewise, constructors that are introduced
+by a *using-declaration* are treated as though they were constructors of
+the derived class when looking up the constructors of the derived
+class ([[class.qual]]) or forming a set of overload candidates (
+[[over.match.ctor]], [[over.match.copy]], [[over.match.list]]). If such
+a constructor is selected to perform the initialization of an object of
+class type, all subobjects other than the base class from which the
+constructor originated are implicitly initialized (
+[[class.inhctor.init]]).
+In a *using-declarator* that does not name a constructor, all members of
+the set of introduced declarations shall be accessible. In a
+*using-declarator* that names a constructor, no access check is
+performed. In particular, if a derived class uses a *using-declarator*
+to access a member of a base class, the member name shall be accessible.
+If the name is that of an overloaded member function, then all functions
+named shall be accessible. The base class members mentioned by a
+*using-declarator* shall be visible in the scope of at least one of the
+direct base classes of the class where the *using-declarator* is
+specified.
+[*Note 6*:
+Because a *using-declarator* designates a base class member (and not a
+member subobject or a member function of a base class subobject), a
+*using-declarator* cannot be used to resolve inherited member
+ambiguities.
+[*Example 12*:
 ``` cpp
 struct A { int x(); };
 struct B : A { };
 struct C : A {
 struct D : B, C {
   using C::x;
   int x(double);
 };
 int f(D* d) {
+  return d->x();    // error: overload resolution selects A::x, but A is an ambiguous base class
 }
 ```
+— *end example*]
+— *end note*]
+A synonym created by a *using-declaration* has the usual accessibility
+for a *member-declaration*. A *using-declarator* that names a
+constructor does not create a synonym; instead, the additional
+constructors are accessible if they would be accessible when used to
+construct an object of the corresponding base class, and the
+accessibility of the *using-declaration* is ignored.
+[*Example 13*:
 ``` cpp
 class A {
 private:
     void f(char);
 public:
   using A::g;       // B::g is a public synonym for A::g
 };
 ```
+— *end example*]
+If a *using-declarator* uses the keyword `typename` and specifies a
 dependent name ([[temp.dep]]), the name introduced by the
 *using-declaration* is treated as a *typedef-name* ([[dcl.typedef]]).
 ### Using directive <a id="namespace.udir">[[namespace.udir]]</a>
 using-directive:
     attribute-specifier-seqₒₚₜ 'using namespace' nested-name-specifierₒₚₜ namespace-name ';'
 ```
 A *using-directive* shall not appear in class scope, but may appear in
+namespace scope or in block scope.
+[*Note 1*: When looking up a *namespace-name* in a *using-directive*,
+only namespace names are considered, see
+[[basic.lookup.udir]]. — *end note*]
+The optional *attribute-specifier-seq* appertains to the
+*using-directive*.
 A *using-directive* specifies that the names in the nominated namespace
 can be used in the scope in which the *using-directive* appears after
 the *using-directive*. During unqualified name lookup (
 [[basic.lookup.unqual]]), the names appear as if they were declared in
 the nearest enclosing namespace which contains both the
+*using-directive* and the nominated namespace.
+[*Note 2*: In this context, “contains” means “contains directly or
+indirectly”. — *end note*]
 A *using-directive* does not add any members to the declarative region
 in which it appears.
+[*Example 1*:
 ``` cpp
 namespace A {
   int i;
   namespace B {
     namespace C {
 void f4() {
   i = 5;            // ill-formed; neither i is visible
 }
 ```
+— *end example*]
 For unqualified lookup ([[basic.lookup.unqual]]), the *using-directive*
 is transitive: if a scope contains a *using-directive* that nominates a
 second namespace that itself contains *using-directive*s, the effect is
 as if the *using-directive*s from the second namespace also appeared in
+the first.
+[*Note 3*: For qualified lookup, see
+[[namespace.qual]]. — *end note*]
+[*Example 2*:
 ``` cpp
 namespace M {
   int i;
 }
     int n = j;      // D::j hides B::j
   }
 }
 ```
+— *end example*]
+If a namespace is extended ([[namespace.def]]) after a
+*using-directive* for that namespace is given, the additional members of
+the extended namespace and the members of namespaces nominated by
+*using-directive*s in the extending *namespace-definition* can be used
+after the extending *namespace-definition*.
 If name lookup finds a declaration for a name in two different
 namespaces, and the declarations do not declare the same entity and do
+not declare functions, the use of the name is ill-formed.
+[*Note 4*:
+In particular, the name of a variable, function or enumerator does not
+hide the name of a class or enumeration declared in a different
+namespace. For example,
 ``` cpp
 namespace A {
   class X { };
   extern "C"   int g();
 using namespace A;
 using namespace B;
 void f() {
   X(1);             // error: name X found in two namespaces
+  g();              // OK: name g refers to the same entity
+  h();              // OK: overload resolution selects A::h
 }
 ```
+— *end note*]
 During overload resolution, all functions from the transitive search are
 considered for argument matching. The set of declarations found by the
+transitive search is unordered.
+[*Note 5*: In particular, the order in which namespaces were considered
+and the relationships among the namespaces implied by the
+*using-directive*s do not cause preference to be given to any of the
+declarations found by the search. — *end note*]
+An ambiguity exists if the best match finds two functions with the same
+signature, even if one is in a namespace reachable through
+*using-directive*s in the namespace of the other.[^7]
+[*Example 3*:
 ``` cpp
 namespace D {
   int d1;
   void f(char);
   f(1);             // error: ambiguous: D::f(int) or E::f(int)?
   f('a');           // OK: D::f(char)
 }
 ```
+— *end example*]
 ## The `asm` declaration <a id="dcl.asm">[[dcl.asm]]</a>
 An `asm` declaration has the form
 ``` bnf
 asm-definition:
+ attribute-specifier-seqₒₚₜ 'asm (' string-literal ') ;'
 ```
 The `asm` declaration is conditionally-supported; its meaning is
+*implementation-defined*. The optional *attribute-specifier-seq* in an
+*asm-definition* appertains to the `asm` declaration.
+[*Note 1*: Typically it is used to pass information through the
+implementation to an assembler. — *end note*]
 ## Linkage specifications <a id="dcl.link">[[dcl.link]]</a>
 All function types, function names with external linkage, and variable
+names with external linkage have a *language linkage*.
+[*Note 1*: Some of the properties associated with an entity with
+language linkage are specific to each implementation and are not
+described here. For example, a particular language linkage may be
+associated with a particular form of representing names of objects and
+functions with external linkage, or with a particular calling
+convention, etc. — *end note*]
+The default language linkage of all function types, function names, and
+variable names is C++language linkage. Two function types with different
+language linkages are distinct types even if they are otherwise
+identical.
 Linkage ([[basic.link]]) between C++and non-C++code fragments can be
 achieved using a *linkage-specification*:
 ``` bnf
 The *string-literal* indicates the required language linkage. This
 International Standard specifies the semantics for the *string-literal*s
 `"C"` and `"C++"`. Use of a *string-literal* other than `"C"` or `"C++"`
 is conditionally-supported, with *implementation-defined* semantics.
+[*Note 2*: Therefore, a linkage-specification with a *string-literal*
+that is unknown to the implementation requires a
+diagnostic. — *end note*]
+[*Note 3*: It is recommended that the spelling of the *string-literal*
+be taken from the document defining that language. For example, `Ada`
+(not `ADA`) and `Fortran` or `FORTRAN`, depending on the
+vintage. — *end note*]
 Every implementation shall provide for linkage to functions written in
 the C programming language, `"C"`, and linkage to C++functions, `"C++"`.
+[*Example 1*:
 ``` cpp
 complex sqrt(complex);          // C++linkage by default
 extern "C" {
   double sqrt(double);          // C linkage
 }
 ```
+— *end example*]
 Linkage specifications nest. When linkage specifications nest, the
 innermost one determines the language linkage. A linkage specification
 does not establish a scope. A *linkage-specification* shall occur only
 in namespace scope ([[basic.scope]]). In a *linkage-specification*, the
 specified language linkage applies to the function types of all function
 declarators, function names with external linkage, and variable names
 with external linkage declared within the *linkage-specification*.
+[*Example 2*:
 ``` cpp
+extern "C"                      // the name f1 and its function type have C language linkage;
+  void f1(void(*pf)(int));      // pf is a pointer to a C function
 extern "C" typedef void FUNC();
 FUNC f2;                        // the name f2 has C++language linkage and the
                                 // function's type has C language linkage
+extern "C" FUNC f3;             // the name of function f3 and the function's type have C language linkage
+void (*pf2)(FUNC*);             // the name of the variable pf2 has C++linkage and the type
+                                // of pf2 is ``pointer to C++function that takes one parameter of type
+                                // pointer to C function''
 extern "C" {
+  static void f4();             // the name of the function f4 has internal linkage (not C language linkage)
+                                // and the function's type has C language linkage.
 }
 extern "C" void f5() {
+  extern void f4();             // OK: Name linkage (internal) and function type linkage (C language linkage)
+                                // obtained from previous declaration.
 }
+extern void f4();               // OK: Name linkage (internal) and function type linkage (C language linkage)
+                                // obtained from previous declaration.
 void f6() {
+  extern void f4();             // OK: Name linkage (internal) and function type linkage (C language linkage)
+                                // obtained from previous declaration.
 }
 ```
+— *end example*]
 A C language linkage is ignored in determining the language linkage of
 the names of class members and the function type of class member
 functions.
+[*Example 3*:
 ``` cpp
 extern "C" typedef void FUNC_c();
 class C {
+ void mf1(FUNC_c*); // the name of the function mf1 and the member function's type have
+                                // C++language linkage; the parameter has type ``pointer to C function''
+ FUNC_c mf2; // the name of the function mf2 and the member function's type have
+                                // C++language linkage
+  static FUNC_c* q;             // the name of the data member q has C++language linkage and
+                                // the data member's type is ``pointer to C function''
 };
 extern "C" {
   class X {
+ void mf(); // the name of the function mf and the member function's type have
+                                // C++language linkage
+ void mf2(void(*)()); // the name of the function mf2 has C++language linkage;
+                                // the parameter has type ``pointer to C function''
   };
 }
 ```
+— *end example*]
 If two declarations declare functions with the same name and
+parameter-type-list ([[dcl.fct]]) to be members of the same namespace
 or declare objects with the same name to be members of the same
 namespace and the declarations give the names different language
 linkages, the program is ill-formed; no diagnostic is required if the
 declarations appear in different translation units. Except for functions
 with C++linkage, a function declaration without a linkage specification
 function name (ignoring the namespace names that qualify it) that appear
 in different namespace scopes refer to the same function. Two
 declarations for a variable with C language linkage with the same name
 (ignoring the namespace names that qualify it) that appear in different
 namespace scopes refer to the same variable. An entity with C language
+linkage shall not be declared with the same name as a variable in global
 scope, unless both declarations denote the same entity; no diagnostic is
 required if the declarations appear in different translation units. A
 variable with C language linkage shall not be declared with the same
 name as a function with C language linkage (ignoring the namespace names
 that qualify the respective names); no diagnostic is required if the
+declarations appear in different translation units.
+[*Note 4*: Only one definition for an entity with a given name with C
+language linkage may appear in the program (see  [[basic.def.odr]]);
+this implies that such an entity must not be defined in more than one
+namespace scope. — *end note*]
+[*Example 4*:
 ``` cpp
 int x;
 namespace A {
   extern "C" int f();
   extern "C" int x();               // ill-formed: same name as global-space object x
 }
 namespace B {
   extern "C" int f();               // A::f and B::f refer to the same function
+  extern "C" int g() { return 1; }  // ill-formed, the function g with C language linkage has two definitions
 }
 int A::f() { return 98; }           // definition for the function f with C language linkage
 extern "C" int h() { return 97; }   // definition for the function h with C language linkage
                                     // A::h and ::h refer to the same function
 ```
+— *end example*]
 A declaration directly contained in a *linkage-specification* is treated
 as if it contains the `extern` specifier ([[dcl.stc]]) for the purpose
 of determining the linkage of the declared name and whether it is a
 definition. Such a declaration shall not specify a storage class.
+[*Example 5*:
 ``` cpp
 extern "C" double f();
 static double f();                  // error
 extern "C" int i;                   // declaration
 extern "C" {
   int i;                            // definition
 }
 extern "C" static void g();         // error
 ```
+— *end example*]
+[*Note 5*: Because the language linkage is part of a function type,
+when indirecting through a pointer to C function, the function to which
+the resulting lvalue refers is considered a C function. — *end note*]
 Linkage from C++to objects defined in other languages and to objects
+defined in C++from other languages is *implementation-defined* and
 language-dependent. Only where the object layout strategies of two
 language implementations are similar enough can such linkage be
 achieved.
 ## Attributes <a id="dcl.attr">[[dcl.attr]]</a>
   attribute-specifier-seqₒₚₜ attribute-specifier
 ```
 ``` bnf
 attribute-specifier:
+  '[' '[' attribute-using-prefixₒₚₜ attribute-list ']' ']'
   alignment-specifier
 ```
 ``` bnf
 alignment-specifier:
   'alignas (' type-id '...'ₒₚₜ ')'
   'alignas (' constant-expression '...'ₒₚₜ ')'
 ```
+``` bnf
+attribute-using-prefix:
+  'using' attribute-namespace ':'
+```
 ``` bnf
 attribute-list:
   attributeₒₚₜ
   attribute-list ',' attributeₒₚₜ
   attribute '...'
     identifier
 ```
 ``` bnf
 attribute-argument-clause:
+    '(' balanced-token-seqₒₚₜ ')'
 ```
 ``` bnf
 balanced-token-seq:
+    balanced-token
     balanced-token-seq balanced-token
 ```
 ``` bnf
 balanced-token:
+    '(' balanced-token-seqₒₚₜ ')'
+    '[' balanced-token-seqₒₚₜ ']'
+    '{' balanced-token-seqₒₚₜ '}'
     any *token* other than a parenthesis, a bracket, or a brace
 ```
+If an *attribute-specifier* contains an *attribute-using-prefix*, the
+*attribute-list* following that *attribute-using-prefix* shall not
+contain an *attribute-scoped-token* and every *attribute-token* in that
+*attribute-list* is treated as if its *identifier* were prefixed with
+`N::`, where `N` is the *attribute-namespace* specified in the
+*attribute-using-prefix*.
+[*Note 1*: This rule imposes no constraints on how an
+*attribute-using-prefix* affects the tokens in an
+*attribute-argument-clause*. — *end note*]
+[*Example 1*:
+``` cpp
+[[using CC: opt(1), debug]]         // same as [[CC::opt(1), CC::debug]]
+  void f() {}
+[[using CC: opt(1)]] [[CC::debug]]  // same as [[CC::opt(1)]] [[CC::debug]]
+  void g() {}
+[[using CC: CC::opt(1)]]            // error: cannot combine using and scoped attribute token
+  void h() {}
+```
+— *end example*]
+[*Note 2*: For each individual attribute, the form of the
+*balanced-token-seq* will be specified. — *end note*]
 In an *attribute-list*, an ellipsis may appear only if that
 *attribute*’s specification permits it. An *attribute* followed by an
 ellipsis is a pack expansion ([[temp.variadic]]). An
 *attribute-specifier* that contains no *attribute*s has no effect. The
+order in which the *attribute-token*s appear in an *attribute-list* is
 not significant. If a keyword ([[lex.key]]) or an alternative token (
 [[lex.digraph]]) that satisfies the syntactic requirements of an
 *identifier* ([[lex.name]]) is contained in an *attribute-token*, it is
 considered an identifier. No name lookup ([[basic.lookup]]) is
 performed on any of the identifiers contained in an *attribute-token*.
 The *attribute-token* determines additional requirements on the
+*attribute-argument-clause* (if any).
 Each *attribute-specifier-seq* is said to *appertain* to some entity or
 statement, identified by the syntactic context where it appears (Clause
 [[stmt.stmt]], Clause  [[dcl.dcl]], Clause  [[dcl.decl]]). If an
 *attribute-specifier-seq* that appertains to some entity or statement
+contains an *attribute* or *alignment-specifier* that is not allowed to
+apply to that entity or statement, the program is ill-formed. If an
+*attribute-specifier-seq* appertains to a friend declaration (
+[[class.friend]]), that declaration shall be a definition. No
+*attribute-specifier-seq* shall appertain to an explicit instantiation (
+[[temp.explicit]]).
+For an *attribute-token* (including an *attribute-scoped-token*) not
+specified in this International Standard, the behavior is
+*implementation-defined*. Any *attribute-token* that is not recognized
+by the implementation is ignored.
+[*Note 3*: Each implementation should choose a distinctive name for the
+*attribute-namespace* in an *attribute-scoped-token*. — *end note*]
 Two consecutive left square bracket tokens shall appear only when
+introducing an *attribute-specifier* or within the *balanced-token-seq*
+of an *attribute-argument-clause*.
+[*Note 4*: If two consecutive left square brackets appear where an
+*attribute-specifier* is not allowed, the program is ill-formed even if
+the brackets match an alternative grammar production. — *end note*]
+[*Example 2*:
 ``` cpp
 int p[10];
 void f() {
   int x = 42, y[5];
+  int(p[[x] { return x; }()]);  // error: invalid attribute on a nested declarator-id and
+                                // not a function-style cast of an element of p.
+  y[[] { return 2; }()] = 2;    // error even though attributes are not allowed in this context.
+ int i [[vendor::attr([[]])]]; // well-formed implementation-defined attribute.
 }
 ```
+— *end example*]
 ### Alignment specifier <a id="dcl.align">[[dcl.align]]</a>
 An *alignment-specifier* may be applied to a variable or to a class data
 member, but it shall not be applied to a bit-field, a function
+parameter, or an *exception-declaration* ([[except.handle]]). An
 *alignment-specifier* may also be applied to the declaration or
 definition of a class (in an *elaborated-type-specifier* (
 [[dcl.type.elab]]) or *class-head* (Clause  [[class]]), respectively)
 and to the declaration or definition of an enumeration (in an
 *opaque-enum-declaration* or *enum-head*, respectively ([[dcl.enum]])).
 When the *alignment-specifier* is of the form `alignas(`
 *constant-expression* `)`:
 - the *constant-expression* shall be an integral constant expression
+- if the constant expression does not evaluate to an alignment value (
+ [[basic.align]]), or evaluates to an extended alignment and the
   implementation does not support that alignment in the context of the
+  declaration, the program is ill-formed.
+An *alignment-specifier* of the form `alignas(` *type-id* `)` has the
+same effect as `alignas({}alignof(` *type-id* `))` ([[expr.alignof]]).
+The alignment requirement of an entity is the strictest nonzero
+alignment specified by its *alignment-specifier*s, if any; otherwise,
+the *alignment-specifier*s have no effect.
 The combined effect of all *alignment-specifier*s in a declaration shall
 not specify an alignment that is less strict than the alignment that
 would be required for the entity being declared if all
+*alignment-specifier*s appertaining to that entity were omitted.
+[*Example 1*:
+``` cpp
+struct alignas(8) S {};
+struct alignas(1) U {
+  S s;
+};  // error: U specifies an alignment that is less strict than if the alignas(1) were omitted.
+```
+— *end example*]
 If the defining declaration of an entity has an *alignment-specifier*,
 any non-defining declaration of that entity shall either specify
 equivalent alignment or have no *alignment-specifier*. Conversely, if
 any declaration of an entity has an *alignment-specifier*, every
 defining declaration of that entity shall specify an equivalent
 alignment. No diagnostic is required if declarations of an entity have
 different *alignment-specifier*s in different translation units.
+[*Example 2*:
 ``` cpp
 // Translation unit #1:
+struct S { int x; } s, *p = &s;
 // Translation unit #2:
+struct alignas(16) S;           // error: definition of S lacks alignment, no diagnostic required
+extern S* p;
 ```
+— *end example*]
+[*Example 3*:
 An aligned buffer with an alignment requirement of `A` and holding `N`
+elements of type `T` can be declared as:
 ``` cpp
 alignas(T) alignas(A) T buffer[N];
 ```
 Specifying `alignas(T)` ensures that the final requested alignment will
 not be weaker than `alignof(T)`, and therefore the program will not be
 ill-formed.
+— *end example*]
+[*Example 4*:
 ``` cpp
 alignas(double) void f();                           // error: alignment applied to function
 alignas(double) unsigned char c[sizeof(double)];    // array of characters, suitably aligned for a double
 extern unsigned char c[sizeof(double)];             // no alignas necessary
 alignas(float)
   extern unsigned char c[sizeof(double)];           // error: different alignment in declaration
 ```
+— *end example*]
 ### Carries dependency attribute <a id="dcl.attr.depend">[[dcl.attr.depend]]</a>
 The *attribute-token* `carries_dependency` specifies dependency
 propagation into and out of functions. It shall appear at most once in
 attribute for that parameter. If a function or one of its parameters is
 declared with the `carries_dependency` attribute in its first
 declaration in one translation unit and the same function or one of its
 parameters is declared without the `carries_dependency` attribute in its
 first declaration in another translation unit, the program is
+ill-formed, no diagnostic required.
+[*Note 1*: The `carries_dependency` attribute does not change the
+meaning of the program, but may result in generation of more efficient
+code. — *end note*]
+[*Example 1*:
 ``` cpp
 /* Translation unit A. */
 struct foo { int* a; int* b; };
 but its first parameter does not. Therefore, function `h`’s first call
 to `g` carries a dependency into `g`, but its second call does not. The
 implementation might need to insert a fence prior to the second call to
 `g`.
+— *end example*]
 ### Deprecated attribute <a id="dcl.attr.deprecated">[[dcl.attr.deprecated]]</a>
 The *attribute-token* `deprecated` can be used to mark names and
 entities whose use is still allowed, but is discouraged for some reason.
+[*Note 1*: In particular, `deprecated` is appropriate for names and
+entities that are deemed obsolescent or unsafe. — *end note*]
+It shall appear at most once in each *attribute-list*. An
+*attribute-argument-clause* may be present and, if present, it shall
+have the form:
 ``` cpp
 ( string-literal )
 ```
+[*Note 2*: The *string-literal* in the *attribute-argument-clause*
+could be used to explain the rationale for deprecation and/or to suggest
+a replacing entity. — *end note*]
 The attribute may be applied to the declaration of a class, a
+*typedef-name*, a variable, a non-static data member, a function, a
+namespace, an enumeration, an enumerator, or a template specialization.
 A name or entity declared without the `deprecated` attribute can later
+be redeclared with the attribute and vice-versa.
+[*Note 3*: Thus, an entity initially declared without the attribute can
+be marked as deprecated by a subsequent redeclaration. However, after an
+entity is marked as deprecated, later redeclarations do not un-deprecate
+the entity. — *end note*]
 Redeclarations using different forms of the attribute (with or without
 the *attribute-argument-clause* or with different
 *attribute-argument-clause*s) are allowed.
+[*Note 4*: Implementations may use the `deprecated` attribute to
+produce a diagnostic message in case the program refers to a name or
+entity other than to declare it, after a declaration that specifies the
+attribute. The diagnostic message may include the text provided within
+the *attribute-argument-clause* of any `deprecated` attribute applied to
+the name or entity. — *end note*]
+### Fallthrough attribute <a id="dcl.attr.fallthrough">[[dcl.attr.fallthrough]]</a>
+The *attribute-token* `fallthrough` may be applied to a null statement (
+[[stmt.expr]]); such a statement is a fallthrough statement. The
+*attribute-token* `fallthrough` shall appear at most once in each
+*attribute-list* and no *attribute-argument-clause* shall be present. A
+fallthrough statement may only appear within an enclosing `switch`
+statement ([[stmt.switch]]). The next statement that would be executed
+after a fallthrough statement shall be a labeled statement whose label
+is a case label or default label for the same `switch` statement. The
+program is ill-formed if there is no such statement.
+[*Note 1*: The use of a fallthrough statement is intended to suppress a
+warning that an implementation might otherwise issue for a case or
+default label that is reachable from another case or default label along
+some path of execution. Implementations are encouraged to issue a
+warning if a fallthrough statement is not dynamically
+reachable. — *end note*]
+[*Example 1*:
+``` cpp
+void f(int n) {
+  void g(), h(), i();
+  switch (n) {
+  case 1:
+  case 2:
+    g();
+    [[fallthrough]];
+  case 3:                       // warning on fallthrough discouraged
+    h();
+  case 4:                       // implementation may warn on fallthrough
+    i();
+    [[fallthrough]];            // ill-formed
+  }
+}
+```
+— *end example*]
+### Maybe unused attribute <a id="dcl.attr.unused">[[dcl.attr.unused]]</a>
+The *attribute-token* `maybe_unused` indicates that a name or entity is
+possibly intentionally unused. It shall appear at most once in each
+*attribute-list* and no *attribute-argument-clause* shall be present.
+The attribute may be applied to the declaration of a class, a
+*typedef-name*, a variable, a non-static data member, a function, an
+enumeration, or an enumerator.
+[*Note 1*: For an entity marked `maybe_unused`, implementations are
+encouraged not to emit a warning that the entity is unused, or that the
+entity is used despite the presence of the attribute. — *end note*]
+A name or entity declared without the `maybe_unused` attribute can later
+be redeclared with the attribute and vice versa. An entity is considered
+marked after the first declaration that marks it.
+[*Example 1*:
+``` cpp
+[[maybe_unused]] void f([[maybe_unused]] bool thing1,
+                        [[maybe_unused]] bool thing2) {
+  [[maybe_unused]] bool b = thing1 && thing2;
+  assert(b);
+}
+```
+Implementations are encouraged not to warn that `b` is unused, whether
+or not `NDEBUG` is defined.
+— *end example*]
+### Nodiscard attribute <a id="dcl.attr.nodiscard">[[dcl.attr.nodiscard]]</a>
+The *attribute-token* `nodiscard` may be applied to the *declarator-id*
+in a function declaration or to the declaration of a class or
+enumeration. It shall appear at most once in each *attribute-list* and
+no *attribute-argument-clause* shall be present.
+[*Note 1*: A nodiscard call is a function call expression that calls a
+function previously declared `nodiscard`, or whose return type is a
+possibly cv-qualified class or enumeration type marked `nodiscard`.
+Appearance of a nodiscard call as a potentially-evaluated
+discarded-value expression (Clause  [[expr]]) is discouraged unless
+explicitly cast to `void`. Implementations are encouraged to issue a
+warning in such cases. This is typically because discarding the return
+value of a nodiscard call has surprising consequences. — *end note*]
+[*Example 1*:
+``` cpp
+struct [[nodiscard]] error_info { ... };
+error_info enable_missile_safety_mode();
+void launch_missiles();
+void test_missiles() {
+  enable_missile_safety_mode(); // warning encouraged
+  launch_missiles();
+}
+error_info &foo();
+void f() { foo(); }             // warning not encouraged: not a nodiscard call, because neither
+                                // the (reference) return type nor the function is declared nodiscard
+```
+— *end example*]
+### Noreturn attribute <a id="dcl.attr.noreturn">[[dcl.attr.noreturn]]</a>
+The *attribute-token* `noreturn` specifies that a function does not
+return. It shall appear at most once in each *attribute-list* and no
+*attribute-argument-clause* shall be present. The attribute may be
+applied to the *declarator-id* in a function declaration. The first
+declaration of a function shall specify the `noreturn` attribute if any
+declaration of that function specifies the `noreturn` attribute. If a
+function is declared with the `noreturn` attribute in one translation
+unit and the same function is declared without the `noreturn` attribute
+in another translation unit, the program is ill-formed, no diagnostic
+required.
+If a function `f` is called where `f` was previously declared with the
+`noreturn` attribute and `f` eventually returns, the behavior is
+undefined.
+[*Note 1*: The function may terminate by throwing an
+exception. — *end note*]
+[*Note 2*: Implementations are encouraged to issue a warning if a
+function marked `[[noreturn]]` might return. — *end note*]
+[*Example 1*:
+``` cpp
+[[ noreturn ]] void f() {
+  throw "error";                // OK
+}
+[[ noreturn ]] void q(int i) {  // behavior is undefined if called with an argument <= 0
+  if (i > 0)
+    throw "positive";
+}
+```
+— *end example*]

Diff to HTML by rtfpessoa