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

Files changed (1) hide show

tmp/tmpc1a6frl9/{from.md → to.md} +56 -15

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

@@ -17,11 +17,11 @@ attribute-specifier:
 ```
 ``` bnf
 alignment-specifier:
   'alignas (' type-id '...'ₒₚₜ ')'
-  'alignas (' alignment-expression '...'ₒₚₜ ')'
 ```
 ``` bnf
 attribute-list:
   attributeₒₚₜ
@@ -104,18 +104,18 @@ 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: malformed 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.
 }
@@ -123,20 +123,24 @@ 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, the formal parameter of a catch clause ([[except.handle]]),
-or a variable declared with the `register` storage class specifier. An
-*alignment-specifier* may also be applied to the declaration of a class
-or enumeration type. An *alignment-specifier* with an ellipsis is a pack
-expansion ([[temp.variadic]]).
 When the *alignment-specifier* is of the form `alignas(`
-*assignment-expression* `)`:
-- the *assignment-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
@@ -268,18 +272,18 @@ int foo_array[10][10];
 [[carries_dependency]] struct foo* f(int i) {
   return foo_head[i].load(memory_order_consume);
 }
-[[carries_dependency]] int g(int* x, int* y) {
   return kill_dependency(foo_array[*x][*y]);
 }
 /* Translation unit B. */
 [[carries_dependency]] struct foo* f(int i);
-[[carries_dependency]] int* g(int* x, int* y);
 int c = 3;
 void h(int i) {
   struct foo* p;
@@ -294,11 +298,48 @@ 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 argument has a `carries_dependency` attribute, but
-its first argument 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`.

 ```
 ``` bnf
 alignment-specifier:
   'alignas (' type-id '...'ₒₚₜ ')'
+  'alignas (' constant-expression '...'ₒₚₜ ')'
 ```
 ``` bnf
 attribute-list:
   attributeₒₚₜ
 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]])).
+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 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
 [[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]);
 }
 /* Translation unit B. */
 [[carries_dependency]] struct foo* f(int i);
+int g(int* x, int* y [[carries_dependency]]);
 int c = 3;
 void h(int i) {
   struct foo* p;
 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`.
+### 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.

Diff to HTML by rtfpessoa