N2843 = 09-0033
Jens Maurer <Jens.Maurer@gmx.net>
Alisdair Meredith <public@alisdairm.net>
2009-03-08

Pack Expansion and Attributes

Motivation

This paper addresses the following national body comments on the CD1 ballot:

  • UK-103 Pack expansion in attributes
  • UK-204 TR1 aligned_union template

    • The aligned_union template in the library was intended to provide simple support for union-like types whose elements may support non-trivial constructors and destructors. When this support was added directly into the language the library template was deemed superfluous, and removed. (This was a TR1 extension, so there are no back-compatibility issues).

    However, it has emerged that there remains at least one use case for the feature. When trying to create a 'discriminated union' template using variadic templates, it is not possible to to declare the members of the union via a pack-expansion. This requires a fall-back on an aligned_union like utility.

    This would be significantly easier to write if the [[align]] attribute supported a pack-expansion to return the strictest alignment. This feature is already supported if the types are listed individually, but the grammar does not yet support pack expansion within an attribute. This is seen as the motivating example to extend the attribute grammar to support pack expansion, where the named attribute explicitly documents support.

    This paper addresses both the grammar issue, and the specific case of the align attribute. We believe this adequately addresses the problems motivating aligned union, so reject the proposed resolution for comment UK-204. Aligned_union should not be restored to the type traits library.

    Subtle Issues

    One of the isssues the design of attributes paid careful attention to is the ability to use a macro to specify attributes, with the possibility that the macro expands to nothing, leaving potentially spurious comma or sequences of commas in the attribute-list after macro expansion.

    In wording support for parameter pack expansion, care has been taken that the optional ellipsis and pack expansion do not introduce problems with spurious commas.

    Proposed Wording Changes

    Change in 7.6.1 dcl.attr.grammar paragraph 1 as indicated:
    ... 
    attribute-list:
       attributeopt ...opt
       attribute-list , attributeopt ...opt
    ...
    Change in 7.6.1 dcl.attr.grammar paragraph 3:
    In an attribute-list, an ellipsis may only appear immediately following an attribute and only if that attribute's specification permits it. An attribute followed by an ellipsis is a pack expansion (14.5.3 temp.variadic). An attribute-specifier that contains no attributes has no effect. ...
    Change in 7.6.2 dcl.align paragraph 1 as indicated:
    The attribute may be followed by an ellipsis. The attribute can be applied to a variable that is neither a function parameter nor declared with the register storage class specifier and to a class data member that is not a bit-field.
    Add to the end of the list in 14.5.3 temp.variadic paragraph 4: