<html>
<head>
<title>Pack Expansion and Attributes (rev. 2)</title>
<style type="text/css">
  p {text-align:justify}
  li {text-align:justify}
  ins {background-color:#FFFF99}
  del {background-color:#FF9999}
</style>
</head>

<body>
N2933 = 09-0123<br/>
Jens Maurer &lt;Jens.Maurer@gmx.net><br/>
Alisdair Meredith &lt;public@alisdairm.net><br/>
2009-07-17

<h1>Pack Expansion and Attributes (rev. 2)</h1>

<h2>Motivation</h2>

<p>
This paper addresses the following national body comments on the CD1 ballot:
<li>UK-103 Pack expansion in attributes</li>
<li>UK-204 TR1 aligned_union template</li>
</p>

<p>
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).
</p>

<p>
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.
</p>

<p>
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.
</p>

<p>
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 <b>not</b> be
restored to the type traits library.
</p>

<h2>Subtle Issues</h2>
<p>
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.
</p>
<p>
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.
</p>

<h2>Proposed Wording Changes</h2>

Change in 7.6.1 dcl.attr.grammar paragraph 1 as indicated:
<blockquote>
...
<pre>
attribute-list:
       attribute<sub>opt</sub>
       attribute-list , attribute<sub>opt</sub>
       <ins>attribute ...</ins>
       <ins>attribute-list , attribute ...</ins>
</pre>
...
</blockquote>

Change in 7.6.1 dcl.attr.grammar paragraph 3:

<blockquote>
<ins>In an <em>attribute-list</em>, an ellipsis may appear only
if that attribute's specification permits it.
An <em>attribute</em> followed by an ellipsis is a pack expansion
(14.5.3 temp.variadic).</ins>
An <em>attribute-specifier</em> that contains no <em>attribute</em>s
has no effect. ...
</blockquote>

Change in 7.6.2 dcl.align paragraph 1 as indicated:

<blockquote>
<ins>The <em>attribute</em> may be followed by an ellipsis.</ins> 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.
</blockquote>

Add to the end of the list in 14.5.3 temp.variadic paragraph 4:
<blockquote>
<ul>
<li><ins>In an <em>attribute-list</em> (7.6.1 dcl.attr.grammar); the
pattern is an <em>attribute</em>.</ins></li>
</ul>
</blockquote>

</body>
</html>