[dcl.attr] - C++17 → C++20

Files changed (1) hide show

tmp/tmpnvornli_/{from.md → to.md} +504 -90

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

@@ -16,17 +16,17 @@ attribute-specifier:
   alignment-specifier
 ```
 ``` bnf
 alignment-specifier:
- 'alignas (' type-id '...'ₒₚₜ ')'
- 'alignas (' constant-expression '...'ₒₚₜ ')'
 ```
 ``` bnf
 attribute-using-prefix:
- 'using' attribute-namespace ':'
 ```
 ``` bnf
 attribute-list:
   attributeₒₚₜ
@@ -102,45 +102,50 @@ contain an *attribute-scoped-token* and every *attribute-token* in that
 [*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*:
@@ -159,30 +164,27 @@ void f() {
 ### 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]])).
-An *alignment-specifier* with an ellipsis is a pack expansion (
-[[temp.variadic]]).
 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.
@@ -215,11 +217,11 @@ 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 diagnostic required
 extern S* p;
 ```
 — *end example*]
@@ -256,15 +258,15 @@ The *attribute-token* `carries_dependency` specifies dependency
 propagation into and out of functions. 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* of a
 *parameter-declaration* in a function declaration or lambda, in which
 case it specifies that the initialization of the parameter carries a
-dependency to ([[intro.multithread]]) each lvalue-to-rvalue
-conversion ([[conv.lval]]) of that object. The attribute may also be
-applied to the *declarator-id* of a function declaration, in which case
-it specifies that the return value, if any, carries a dependency to the
-evaluation of the function call expression.
 The first declaration of a function shall specify the
 `carries_dependency` attribute for its *declarator-id* if any
 declaration of the function specifies the `carries_dependency`
 attribute. Furthermore, the first declaration of a function shall
@@ -289,11 +291,11 @@ code. — *end note*]
 struct foo { int* a; int* b; };
 std::atomic<struct foo *> foo_head[10];
 int foo_array[10][10];
 [[carries_dependency]] struct foo* f(int i) {
-  return foo_head[i].load(memory_order_consume);
 }
 int g(int* x, int* y [[carries_dependency]]) {
   return kill_dependency(foo_array[*x][*y]);
 }
@@ -316,17 +318,15 @@ void h(int i) {
 The `carries_dependency` attribute on function `f` means that the return
 value carries a dependency out of `f`, so that the implementation need
 not constrain ordering upon return from `f`. Implementations of `f` and
 its caller may choose to preserve dependencies instead of emitting
-hardware memory ordering instructions (a.k.a. fences).
-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`.
 — *end example*]
 ### Deprecated attribute <a id="dcl.attr.deprecated">[[dcl.attr.deprecated]]</a>
@@ -338,12 +338,12 @@ 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*]
@@ -362,35 +362,37 @@ 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) {
@@ -399,76 +401,183 @@ void f(int 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
@@ -495,12 +604,12 @@ If a function `f` is called where `f` was previously declared with the
 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() {
@@ -513,5 +622,310 @@ function marked `[[noreturn]]` might return. — *end note*]
 }
 ```
 — *end example*]

   alignment-specifier
 ```
 ``` bnf
 alignment-specifier:
+  alignas '(' type-id '...'ₒₚₜ ')'
+  alignas '(' constant-expression '...'ₒₚₜ ')'
 ```
 ``` bnf
 attribute-using-prefix:
+  using attribute-namespace ':'
 ```
 ``` bnf
 attribute-list:
   attributeₒₚₜ
 [*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 (
+[[stmt.stmt]], [[dcl.dcl]], [[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.
+[*Note 3*: An *attribute-specifier-seq* cannot appeartain to an
+explicit instantiation [[temp.explicit]]. — *end note*]
 For an *attribute-token* (including an *attribute-scoped-token*) not
+specified in this document, the behavior is *implementation-defined*.
+Any *attribute-token* that is not recognized by the implementation is
+ignored. An *attribute-token* is reserved for future standardization if
+- it is not an *attribute-scoped-token* and is not specified in this
+  document, or
+- it is an *attribute-scoped-token* and its *attribute-namespace* is
+  `std` followed by zero or more digits.
+[*Note 4*: 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 5*: 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*:
 ### 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 of a class
+(in an *elaborated-type-specifier* [[dcl.type.elab]] or *class-head*
+[[class]], respectively). An *alignment-specifier* with an ellipsis is a
+pack expansion [[temp.variadic]].
 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.
 ``` cpp
 // Translation unit #1:
 struct S { int x; } s, *p = &s;
 // Translation unit #2:
+struct alignas(16) S;           // ill-formed, no diagnostic required: definition of S lacks alignment
 extern S* p;
 ```
 — *end example*]
 propagation into and out of functions. 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* of a
 *parameter-declaration* in a function declaration or lambda, in which
 case it specifies that the initialization of the parameter carries a
+dependency to [[intro.multithread]] each lvalue-to-rvalue conversion
+[[conv.lval]] of that object. The attribute may also be applied to the
+*declarator-id* of a function declaration, in which case it specifies
+that the return value, if any, carries a dependency to the evaluation of
+the function call expression.
 The first declaration of a function shall specify the
 `carries_dependency` attribute for its *declarator-id* if any
 declaration of the function specifies the `carries_dependency`
 attribute. Furthermore, the first declaration of a function shall
 struct foo { int* a; int* b; };
 std::atomic<struct foo *> foo_head[10];
 int foo_array[10][10];
 [[carries_dependency]] struct foo* f(int i) {
+  return foo_head[i].load(memory_order::consume);
 }
 int g(int* x, int* y [[carries_dependency]]) {
   return kill_dependency(foo_array[*x][*y]);
 }
 The `carries_dependency` attribute on function `f` means that the return
 value carries a dependency out of `f`, so that the implementation need
 not constrain ordering upon return from `f`. Implementations of `f` and
 its caller may choose to preserve dependencies instead of emitting
+hardware memory ordering instructions (a.k.a. fences). 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`.
 — *end example*]
 ### Deprecated attribute <a id="dcl.attr.deprecated">[[dcl.attr.deprecated]]</a>
 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:
+``` bnf
+'(' 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*]
 Redeclarations using different forms of the attribute (with or without
 the *attribute-argument-clause* or with different
 *attribute-argument-clause*s) are allowed.
+*Recommended practice:* Implementations should 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 should include the text
+provided within the *attribute-argument-clause* of any `deprecated`
+attribute applied to the name or entity.
 ### 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 and, if
+the fallthrough statement is contained in an iteration statement, the
+next statement shall be part of the same execution of the substatement
+of the innermost enclosing iteration statement. The program is
+ill-formed if there is no such statement.
+*Recommended practice:* The use of a fallthrough statement should
+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 should issue a
+warning if a fallthrough statement is not dynamically reachable.
 [*Example 1*:
 ``` cpp
 void f(int n) {
   case 1:
   case 2:
     g();
     [[fallthrough]];
   case 3:                       // warning on fallthrough discouraged
+    do {
+      [[fallthrough]];          // error: next statement is not part of the same substatement execution
+    } while (false);
+  case 6:
+    do {
+      [[fallthrough]];          // error: next statement is not part of the same substatement execution
+    } while (n--);
+  case 7:
+    while (false) {
+      [[fallthrough]];          // error: next statement is not part of the same substatement execution
+    }
+  case 5:
     h();
   case 4:                       // implementation may warn on fallthrough
     i();
+    [[fallthrough]];            // error
   }
 }
 ```
 — *end example*]
+### Likelihood attributes <a id="dcl.attr.likelihood">[[dcl.attr.likelihood]]</a>
+The *attribute-token*s `likely` and `unlikely` may be applied to labels
+or statements. The *attribute-token*s `likely` and `unlikely` shall
+appear at most once in each *attribute-list* and no
+*attribute-argument-clause* shall be present. The *attribute-token*
+`likely` shall not appear in an *attribute-specifier-seq* that contains
+the *attribute-token* `unlikely`.
+*Recommended practice:* The use of the `likely` attribute is intended to
+allow implementations to optimize for the case where paths of execution
+including it are arbitrarily more likely than any alternative path of
+execution that does not include such an attribute on a statement or
+label. The use of the `unlikely` attribute is intended to allow
+implementations to optimize for the case where paths of execution
+including it are arbitrarily more unlikely than any alternative path of
+execution that does not include such an attribute on a statement or
+label. A path of execution includes a label if and only if it contains a
+jump to that label.
+[*Note 1*: Excessive usage of either of these attributes is liable to
+result in performance degradation. — *end note*]
+[*Example 1*:
+``` cpp
+void g(int);
+int f(int n) {
+  if (n > 5) [[unlikely]] {     // n > 5 is considered to be arbitrarily unlikely
+    g(0);
+    return n * 2 + 1;
+  }
+  switch (n) {
+  case 1:
+    g(1);
+    [[fallthrough]];
+  [[likely]] case 2:            // n == 2 is considered to be arbitrarily more
+    g(2);                       // likely than any other value of n
+    break;
+  }
+  return 3;
+}
+```
+— *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 (including a structured binding declaration),
+a non-static data member, a function, an enumeration, or an enumerator.
 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.
+*Recommended practice:* For an entity marked `maybe_unused`,
+implementations should not emit a warning that the entity or its
+structured bindings (if any) are used or unused. For a structured
+binding declaration not marked `maybe_unused`, implementations should
+not emit such a warning unless all of its structured bindings are
+unused.
 [*Example 1*:
 ``` cpp
 [[maybe_unused]] void f([[maybe_unused]] bool thing1,
                         [[maybe_unused]] bool thing2) {
   [[maybe_unused]] bool b = thing1 && thing2;
   assert(b);
 }
 ```
+Implementations should not 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*. An
+*attribute-argument-clause* may be present and, if present, shall have
+the form:
+``` bnf
+'(' string-literal ')'
+```
+A name or entity declared without the `nodiscard` attribute can later be
+redeclared with the attribute and vice-versa.
+[*Note 1*: Thus, an entity initially declared without the attribute can
+be marked as `nodiscard` by a subsequent redeclaration. However, after
+an entity is marked as `nodiscard`, later redeclarations do not remove
+the `nodiscard` from 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.
+A *nodiscard type* is a (possibly cv-qualified) class or enumeration
+type marked `nodiscard` in a reachable declaration. A *nodiscard call*
+is either
+- a function call expression [[expr.call]] that calls a function
+  declared `nodiscard` in a reachable declaration or whose return type
+  is a nodiscard type, or
+- an explicit type conversion ([[expr.type.conv]],
+  [[expr.static.cast]], [[expr.cast]]) that constructs an object through
+  a constructor declared `nodiscard` in a reachable declaration, or that
+  initializes an object of a nodiscard type.
+*Recommended practice:* Appearance of a nodiscard call as a
+potentially-evaluated discarded-value expression [[expr.prop]] is
+discouraged unless explicitly cast to `void`. Implementations should
+issue a warning in such cases.
+[*Note 2*: This is typically because discarding the return value of a
+nodiscard call has surprising consequences. — *end note*]
+The *string-literal* in a `nodiscard` *attribute-argument-clause* should
+be used in the message of the warning as the rationale for why the
+result should not be discarded.
 [*Example 1*:
 ``` cpp
+struct [[nodiscard]] my_scopeguard { ... };
+struct my_unique {
+  my_unique() = default;                                // does not acquire resource
+  [[nodiscard]] my_unique(int fd) { ... }         // acquires resource
+  ~my_unique() noexcept { ... }                   // releases resource, if any
+  ...
+};
 struct [[nodiscard]] error_info { ... };
 error_info enable_missile_safety_mode();
 void launch_missiles();
 void test_missiles() {
+  my_scopeguard();              // warning encouraged
+  (void)my_scopeguard(),        // warning not encouraged, cast to void
+    launch_missiles();          // comma operator, statement continues
+  my_unique(42);                // warning encouraged
+  my_unique();                  // warning not encouraged
   enable_missile_safety_mode(); // warning encouraged
   launch_missiles();
 }
 error_info &foo();
 void f() { foo(); }             // warning not encouraged: not a nodiscard call, because neither
 undefined.
 [*Note 1*: The function may terminate by throwing an
 exception. — *end note*]
+*Recommended practice:* Implementations should issue a warning if a
+function marked `[[noreturn]]` might return.
 [*Example 1*:
 ``` cpp
 [[ noreturn ]] void f() {
 }
 ```
 — *end example*]
+### No unique address attribute <a id="dcl.attr.nouniqueaddr">[[dcl.attr.nouniqueaddr]]</a>
+The *attribute-token* `no_unique_address` specifies that a non-static
+data member is a potentially-overlapping subobject [[intro.object]]. It
+shall appear at most once in each *attribute-list* and no
+*attribute-argument-clause* shall be present. The attribute may
+appertain to a non-static data member other than a bit-field.
+[*Note 1*: The non-static data member can share the address of another
+non-static data member or that of a base class, and any padding that
+would normally be inserted at the end of the object can be reused as
+storage for other members. — *end note*]
+[*Example 1*:
+``` cpp
+template<typename Key, typename Value,
+         typename Hash, typename Pred, typename Allocator>
+class hash_map {
+  [[no_unique_address]] Hash hasher;
+  [[no_unique_address]] Pred pred;
+  [[no_unique_address]] Allocator alloc;
+  Bucket *buckets;
+  // ...
+public:
+  // ...
+};
+```
+Here, `hasher`, `pred`, and `alloc` could have the same address as
+`buckets` if their respective types are all empty.
+— *end example*]
+<!-- Link reference definitions -->
+[basic.align]: basic.md#basic.align
+[basic.compound]: basic.md#basic.compound
+[basic.def]: basic.md#basic.def
+[basic.def.odr]: basic.md#basic.def.odr
+[basic.fundamental]: basic.md#basic.fundamental
+[basic.life]: basic.md#basic.life
+[basic.link]: basic.md#basic.link
+[basic.lookup]: basic.md#basic.lookup
+[basic.lookup.argdep]: basic.md#basic.lookup.argdep
+[basic.lookup.classref]: basic.md#basic.lookup.classref
+[basic.lookup.elab]: basic.md#basic.lookup.elab
+[basic.lookup.qual]: basic.md#basic.lookup.qual
+[basic.lookup.udir]: basic.md#basic.lookup.udir
+[basic.lookup.unqual]: basic.md#basic.lookup.unqual
+[basic.namespace]: #basic.namespace
+[basic.scope]: basic.md#basic.scope
+[basic.scope.block]: basic.md#basic.scope.block
+[basic.scope.declarative]: basic.md#basic.scope.declarative
+[basic.scope.namespace]: basic.md#basic.scope.namespace
+[basic.scope.param]: basic.md#basic.scope.param
+[basic.scope.pdecl]: basic.md#basic.scope.pdecl
+[basic.start]: basic.md#basic.start
+[basic.start.dynamic]: basic.md#basic.start.dynamic
+[basic.start.static]: basic.md#basic.start.static
+[basic.stc]: basic.md#basic.stc
+[basic.stc.auto]: basic.md#basic.stc.auto
+[basic.stc.dynamic]: basic.md#basic.stc.dynamic
+[basic.stc.dynamic.allocation]: basic.md#basic.stc.dynamic.allocation
+[basic.stc.dynamic.deallocation]: basic.md#basic.stc.dynamic.deallocation
+[basic.stc.static]: basic.md#basic.stc.static
+[basic.stc.thread]: basic.md#basic.stc.thread
+[basic.type.qualifier]: basic.md#basic.type.qualifier
+[basic.types]: basic.md#basic.types
+[class]: class.md#class
+[class.access]: class.md#class.access
+[class.base.init]: class.md#class.base.init
+[class.bit]: class.md#class.bit
+[class.compare.default]: class.md#class.compare.default
+[class.conv]: class.md#class.conv
+[class.conv.ctor]: class.md#class.conv.ctor
+[class.conv.fct]: class.md#class.conv.fct
+[class.copy.assign]: class.md#class.copy.assign
+[class.copy.ctor]: class.md#class.copy.ctor
+[class.copy.elision]: class.md#class.copy.elision
+[class.ctor]: class.md#class.ctor
+[class.default.ctor]: class.md#class.default.ctor
+[class.dtor]: class.md#class.dtor
+[class.expl.init]: class.md#class.expl.init
+[class.friend]: class.md#class.friend
+[class.inhctor.init]: class.md#class.inhctor.init
+[class.init]: class.md#class.init
+[class.mem]: class.md#class.mem
+[class.member.lookup]: class.md#class.member.lookup
+[class.mfct]: class.md#class.mfct
+[class.mi]: class.md#class.mi
+[class.name]: class.md#class.name
+[class.pre]: class.md#class.pre
+[class.qual]: basic.md#class.qual
+[class.static]: class.md#class.static
+[class.static.data]: class.md#class.static.data
+[class.temporary]: basic.md#class.temporary
+[class.union]: class.md#class.union
+[class.union.anon]: class.md#class.union.anon
+[class.virtual]: class.md#class.virtual
+[conv]: expr.md#conv
+[conv.array]: expr.md#conv.array
+[conv.func]: expr.md#conv.func
+[conv.lval]: expr.md#conv.lval
+[conv.prom]: expr.md#conv.prom
+[conv.ptr]: expr.md#conv.ptr
+[conv.qual]: expr.md#conv.qual
+[conv.rval]: expr.md#conv.rval
+[coroutine.handle]: support.md#coroutine.handle
+[coroutine.handle.resumption]: support.md#coroutine.handle.resumption
+[dcl.align]: #dcl.align
+[dcl.ambig.res]: #dcl.ambig.res
+[dcl.array]: #dcl.array
+[dcl.asm]: #dcl.asm
+[dcl.attr]: #dcl.attr
+[dcl.attr.depend]: #dcl.attr.depend
+[dcl.attr.deprecated]: #dcl.attr.deprecated
+[dcl.attr.fallthrough]: #dcl.attr.fallthrough
+[dcl.attr.grammar]: #dcl.attr.grammar
+[dcl.attr.likelihood]: #dcl.attr.likelihood
+[dcl.attr.nodiscard]: #dcl.attr.nodiscard
+[dcl.attr.noreturn]: #dcl.attr.noreturn
+[dcl.attr.nouniqueaddr]: #dcl.attr.nouniqueaddr
+[dcl.attr.unused]: #dcl.attr.unused
+[dcl.constexpr]: #dcl.constexpr
+[dcl.constinit]: #dcl.constinit
+[dcl.dcl]: #dcl.dcl
+[dcl.decl]: #dcl.decl
+[dcl.enum]: #dcl.enum
+[dcl.fct]: #dcl.fct
+[dcl.fct.def]: #dcl.fct.def
+[dcl.fct.def.coroutine]: #dcl.fct.def.coroutine
+[dcl.fct.def.default]: #dcl.fct.def.default
+[dcl.fct.def.delete]: #dcl.fct.def.delete
+[dcl.fct.def.general]: #dcl.fct.def.general
+[dcl.fct.default]: #dcl.fct.default
+[dcl.fct.spec]: #dcl.fct.spec
+[dcl.friend]: #dcl.friend
+[dcl.init]: #dcl.init
+[dcl.init.aggr]: #dcl.init.aggr
+[dcl.init.list]: #dcl.init.list
+[dcl.init.ref]: #dcl.init.ref
+[dcl.init.string]: #dcl.init.string
+[dcl.inline]: #dcl.inline
+[dcl.link]: #dcl.link
+[dcl.meaning]: #dcl.meaning
+[dcl.mptr]: #dcl.mptr
+[dcl.name]: #dcl.name
+[dcl.pre]: #dcl.pre
+[dcl.ptr]: #dcl.ptr
+[dcl.ref]: #dcl.ref
+[dcl.spec]: #dcl.spec
+[dcl.spec.auto]: #dcl.spec.auto
+[dcl.stc]: #dcl.stc
+[dcl.struct.bind]: #dcl.struct.bind
+[dcl.type]: #dcl.type
+[dcl.type.auto.deduct]: #dcl.type.auto.deduct
+[dcl.type.class.deduct]: #dcl.type.class.deduct
+[dcl.type.cv]: #dcl.type.cv
+[dcl.type.decltype]: #dcl.type.decltype
+[dcl.type.elab]: #dcl.type.elab
+[dcl.type.simple]: #dcl.type.simple
+[dcl.typedef]: #dcl.typedef
+[depr.volatile.type]: future.md#depr.volatile.type
+[enum]: #enum
+[enum.udecl]: #enum.udecl
+[except.ctor]: except.md#except.ctor
+[except.handle]: except.md#except.handle
+[except.spec]: except.md#except.spec
+[except.throw]: except.md#except.throw
+[expr.alignof]: expr.md#expr.alignof
+[expr.ass]: expr.md#expr.ass
+[expr.await]: expr.md#expr.await
+[expr.call]: expr.md#expr.call
+[expr.cast]: expr.md#expr.cast
+[expr.const]: expr.md#expr.const
+[expr.const.cast]: expr.md#expr.const.cast
+[expr.mptr.oper]: expr.md#expr.mptr.oper
+[expr.new]: expr.md#expr.new
+[expr.post.incr]: expr.md#expr.post.incr
+[expr.pre.incr]: expr.md#expr.pre.incr
+[expr.prim.lambda]: expr.md#expr.prim.lambda
+[expr.prim.this]: expr.md#expr.prim.this
+[expr.prop]: expr.md#expr.prop
+[expr.ref]: expr.md#expr.ref
+[expr.static.cast]: expr.md#expr.static.cast
+[expr.sub]: expr.md#expr.sub
+[expr.type.conv]: expr.md#expr.type.conv
+[expr.unary]: expr.md#expr.unary
+[expr.unary.op]: expr.md#expr.unary.op
+[expr.yield]: expr.md#expr.yield
+[intro.compliance]: intro.md#intro.compliance
+[intro.execution]: basic.md#intro.execution
+[intro.multithread]: basic.md#intro.multithread
+[intro.object]: basic.md#intro.object
+[lex.charset]: lex.md#lex.charset
+[lex.digraph]: lex.md#lex.digraph
+[lex.key]: lex.md#lex.key
+[lex.name]: lex.md#lex.name
+[lex.string]: lex.md#lex.string
+[module.interface]: module.md#module.interface
+[namespace.alias]: #namespace.alias
+[namespace.def]: #namespace.def
+[namespace.memdef]: #namespace.memdef
+[namespace.qual]: basic.md#namespace.qual
+[namespace.udecl]: #namespace.udecl
+[namespace.udir]: #namespace.udir
+[namespace.unnamed]: #namespace.unnamed
+[over]: over.md#over
+[over.binary]: over.md#over.binary
+[over.match]: over.md#over.match
+[over.match.best]: over.md#over.match.best
+[over.match.class.deduct]: over.md#over.match.class.deduct
+[over.match.conv]: over.md#over.match.conv
+[over.match.copy]: over.md#over.match.copy
+[over.match.ctor]: over.md#over.match.ctor
+[over.match.funcs]: over.md#over.match.funcs
+[over.match.list]: over.md#over.match.list
+[over.match.ref]: over.md#over.match.ref
+[over.match.viable]: over.md#over.match.viable
+[over.oper]: over.md#over.oper
+[over.sub]: over.md#over.sub
+[special]: class.md#special
+[stmt.ambig]: stmt.md#stmt.ambig
+[stmt.dcl]: stmt.md#stmt.dcl
+[stmt.expr]: stmt.md#stmt.expr
+[stmt.if]: stmt.md#stmt.if
+[stmt.iter]: stmt.md#stmt.iter
+[stmt.label]: stmt.md#stmt.label
+[stmt.pre]: stmt.md#stmt.pre
+[stmt.return]: stmt.md#stmt.return
+[stmt.return.coroutine]: stmt.md#stmt.return.coroutine
+[stmt.select]: stmt.md#stmt.select
+[stmt.stmt]: stmt.md#stmt.stmt
+[stmt.switch]: stmt.md#stmt.switch
+[support.runtime]: support.md#support.runtime
+[temp.arg.type]: temp.md#temp.arg.type
+[temp.class.spec]: temp.md#temp.class.spec
+[temp.deduct]: temp.md#temp.deduct
+[temp.deduct.call]: temp.md#temp.deduct.call
+[temp.deduct.guide]: temp.md#temp.deduct.guide
+[temp.dep]: temp.md#temp.dep
+[temp.expl.spec]: temp.md#temp.expl.spec
+[temp.explicit]: temp.md#temp.explicit
+[temp.fct]: temp.md#temp.fct
+[temp.inst]: temp.md#temp.inst
+[temp.local]: temp.md#temp.local
+[temp.mem]: temp.md#temp.mem
+[temp.names]: temp.md#temp.names
+[temp.over.link]: temp.md#temp.over.link
+[temp.param]: temp.md#temp.param
+[temp.pre]: temp.md#temp.pre
+[temp.res]: temp.md#temp.res
+[temp.spec]: temp.md#temp.spec
+[temp.variadic]: temp.md#temp.variadic
+[^1]: There is no special provision for a *decl-specifier-seq* that
+    lacks a *type-specifier* or that has a *type-specifier* that only
+    specifies *cv-qualifier*s. The “implicit int” rule of C is no longer
+    supported.
+[^2]: As indicated by syntax, cv-qualifiers are a significant component
+    in function return types.
+[^3]: One can explicitly disambiguate the parse either by introducing a
+    comma (so the ellipsis will be parsed as part of the
+    *parameter-declaration-clause*) or by introducing a name for the
+    parameter (so the ellipsis will be parsed as part of the
+    *declarator-id*).
+[^4]: This means that default arguments cannot appear, for example, in
+    declarations of pointers to functions, references to functions, or
+    `typedef` declarations.
+[^5]: As specified in  [[conv.ptr]], converting an integer literal whose
+    value is `0` to a pointer type results in a null pointer value.
+[^6]: The syntax provides for empty *braced-init-list*s, but nonetheless
+    C++ does not have zero length arrays.
+[^7]: This requires a conversion function [[class.conv.fct]] returning a
+    reference type.
+[^8]: Implementations are permitted to provide additional predefined
+    variables with names that are reserved to the implementation
+    [[lex.name]]. If a predefined variable is not odr-used
+    [[basic.def.odr]], its string value need not be present in the
+    program image.
+[^9]: This set of values is used to define promotion and conversion
+    semantics for the enumeration type. It does not preclude an
+    expression of enumeration type from having a value that falls
+    outside this range.
+[^10]: this implies that the name of the class or function is
+    unqualified.
+[^11]: During name lookup in a class hierarchy, some ambiguities may be
+    resolved by considering whether one member hides the other along
+    some paths [[class.member.lookup]]. There is no such disambiguation
+    when considering the set of names found as a result of following
+    *using-directive*s.
+[^12]: A *using-declaration* with more than one *using-declarator* is
+    equivalent to a corresponding sequence of *using-declaration*s with
+    one *using-declarator* each.

Diff to HTML by rtfpessoa