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

Files changed (1) hide show

tmp/tmpl3l2g_u5/{from.md → to.md} +279 -107

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

@@ -10,20 +10,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 '...'
@@ -51,84 +56,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]])).
@@ -137,103 +172,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
@@ -256,14 +273,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; };
@@ -304,42 +324,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.

   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