Proposed resolution (December, 2018):

Change 9.12.2 [dcl.align] paragraph 1 as follows:

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 (14.4 [except.handle]). An alignment-specifier may also be applied to the declaration of a class (in an elaborated-type-specifier (9.2.9.5 [dcl.type.elab]) or class-head ( Clause 11 [class]), respectively) and to the declaration of an enumeration (in an opaque-enum-declaration or enum-head, respectively (9.7.1 [dcl.enum])). An alignment-specifier with an ellipsis...

Notes from the November, 2018 meeting:

CWG agreed to remove permission for alignas to be applied to enumerations. The class case is already handled by the wording in 7.6.2.5 [expr.sizeof] paragraph 2 that the size of a class “includes any padding required for placing objects of that type in an array.”

Notes from the April, 2018 teleconference:

It appears that the same question exists for class types that are directly given extended alignment, as opposed to receiving it from a subobject.

[Accepted as a DR at the February, 2019 meeting.]

There is implementation variance in the treatment of an example like:

  enum struct alignas(64) A {};
  A a[10];

The Standard does not appear to indicate whether padding bits are added to the object representation for an enumeration or not, affecting the result of sizeof and the alignment of the array elements.

If the extended alignment does not affect the object representation of the type, it would be useful to specify that the array declaration is ill-formed because it requires violating the alignment requirement (and similarly for an array new-expression where the bound is known at compile time).