<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>
<head>
  <title>A Case for Template Aliasing</title>
  <meta http-equiv="author" content="Walter E. Brown">
  <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  <meta http-equiv="content-style-type" content="text/css">
  <link rev="made"
	href="mailto:wb@fnal.gov?subject=A%20Case%20for%20Template%20Aliasing">

  <style type="text/css">
      .blackOnWhite,
	  body
      {
	  background-color: #ffffff;
	  font-color: #000000;
      }
      .center
      {
	  text-align: center;
      }
      .head,
	  h2
      {
	  font-size: 140%;
	  font-weight: bold;
	  padding-top: 3pt;
	  text-decoration: underline;
      }
      .noBorder,
	  img
      {
	  border-style: none;
      }
      .red
      {
	  color: red;
      }
      .roundBullet,
	  ul
      {
	  list-style-type: disc;
      }
      .sansSerif,
	  body,
	  br,
	  html,
	  p,
	  table,
	  tbody,
	  td,
	  tr
      {
	  font-family: Tahoma, Arial, Helvetica, sans-serif;
      }
      .squareBullet,
	  ul ul
      {
	  list-style-type: square;
      }
    </style>
    <style type="text/css" media="print">
      .justify,
	  p
      {
	  text-align: justify;
      }
    </style>
</head>


<body>

<center><h1>A Case for Template Aliasing</h1></center>


<table align="right" cellspacing="0" cellpadding="0"
  summary="Document information">
<tr>
  <td align="right"><b><I>Document number:</I></B></td>
  <td>&nbsp; WG21/N1451 = J16/03-0034</td>
</tr>
<tr>
  <td align="right"><b><I>Date:</I></B></td>
  <td>&nbsp; April 25, 2003</td>
</tr>
<tr>
  <td align="right"><b><I>Project:</I></B></td>
  <td>&nbsp; Programming Language C++</td>
</tr>
<tr>
  <td align="right"><b><I>Reference:</I></B></td>
  <td>&nbsp; ISO/IEC IS 14882:2003(E)</td>
</tr>
<tr>
  <td align="right"><b><I>Reply to:</I></B></td>
  <td>&nbsp; Walter E. Brown &lt;<a href="mailto:wb@fnal.gov?subject=Special%20Functions%20proposal">wb@fnal.gov</a>&gt;</td>
</tr>
<tr>
  <td></td>
  <td>&nbsp; Mail Station 234<br></td>
</tr>
<tr>
  <td></td>
  <td>&nbsp; Fermi National Accelerator Laboratory<br></td>
</tr>
<tr>
  <td></td>
  <td>&nbsp; Batavia, IL  60510-0500, USA<br></td>
</tr>
</table>

<br clear="all">
<hr>


<h2>Contents</h2>

<blockquote>
  <table width="75%"
    summary="Contents">

  <tr><td align="right">1.&nbsp;</td><td><a href="#Fore">   Foreword</a></td>
      <td align="right">7.&nbsp;</td><td><a href="#Aliases">The Case for Template Aliasing</a></td>
  </tr>

  <tr><td align="right">2.&nbsp;</td><td><a href="#Plan">   Outline of this Paper</a></td>
      <td align="right">8.&nbsp;</td><td><a href="#Summary">Summary</a></td>
  </tr>

  <tr><td align="right">3.&nbsp;</td><td><a href="#Recap">  Recap of N1406</a></td>
      <td align="right">9.&nbsp;</td><td><a href="#After">  Afterword</a></td>
  </tr>

  <tr><td align="right">4.&nbsp;</td><td><a href="#Recent"> Developments</a></td>
      <td align="right">10.&nbsp;</td><td><a href="#Ack">   Acknowledgments</a></td>
  </tr>

  <tr><td align="right">5.&nbsp;</td><td><a href="#Domain"> The Problem Domain</a></td>
      <td align="right">11.&nbsp;</td><td><a href="#Ref">   References</a></td>
  </tr>

  <tr><td align="right">6.&nbsp;</td><td><a href="#Impl">   A Notional Implementation</a></td>
  </tr>

  </table>
</blockquote>


<h2>Figures</h2>
<blockquote>

  <ol>
    <li><a href="#Fig_1">Examples of Physical Quantities</a>
    <li><a href="#Fig_2">Two Categories of Commensurate Physical Quantities</a>
    <li><a href="#Fig_3">Determining Products of Physical Quantities</a>
    <li><a href="#Fig_4">Examples of Physical Quantities' Signatures</a>
    <li><a href="#Fig_5">Physical Quantities Implementation Sketch</a>
    <li><a href="#Fig_6">Examples of Desired Template-id Aliases</a>
    <li><a href="#Fig_7">Two Equivalent Function Implementations</a>
    <li><a href="#Fig_8">A Candidate Syntax for Template Aliasing</a>
    <li><a href="#Fig_9">Examples of Commensuration via a Shared Alias</a>
    <li><a href="#Fig_10">Applied Template Aliasing</a>
    <li><a href="#Fig_11">EWG Working Syntax for Template Aliasing</a>
  </ol>

</blockquote>

<hr>


<h2><a name="Fore">1. Foreword</a></h2>

<p>This paper is based on a presentation given by the author to the
members of WG21 and J16 at a joint meeting held the morning of April 8,
2003.  It immediately followed a talk by Herb Sutter based on his paper,
"Proposed Addition to C++: Typedef Templates" [<a href="#HS">Sutter</a>].
</p>

<p>Sutter's paper had been prepared pursuant to outcomes of discussions on
this topic, notably during Evolution Working Group meetings held October
21-25, 2002, in Santa Cruz, California.  In the paper and corresponding
talk, Sutter presented two distinct approaches to the proposed new
language feature, recommending one of the two approaches for further
consideration.  However, we had reasons to prefer the other approach.
Accordingly, we prepared our 8 April presentation in order to set forth
what we believed to be a compelling example motivating our preference.</p>

<p>In preparing the present paper, we introduced some changes from the
8 April presentation on which it is based:  In addition to adaptations
due to the different stylistic and formatting conventions, we have
corrected typographical errors, have slightly extended some of the
examples and expanded their exposition, and have added new sections:
this <a href="#Fore">Foreword</a>; an <a href="#Plan">Outline of this
Paper</a>; an <a href="#Ack">Acknowledgment</a> section; a section
giving <a href="#Ref">References</a> to the literature; and a brief
<a href="#After">Afterword</a> to incorporate a few, more recent,
developments.</p>


<h2><a name="Plan">2. Outline of this paper</a></h2>

<p>After a brief recap of [<a href="#HS">Sutter</a>], we will describe
a few relevant developments that have taken place since its October
2002 publication.  This will be followed by a high-level exposition
of the problem domain on which our examples are based.  A notional
implementation of this problem domain is then presented, setting the
stage for our use of the typedef templates feature under discussion.</p>

<p>After showing our application for this feature, we present a code
comparison illustrating the desirability of the alternative approach
to typedef templates.  An even more realistic application follows,
underscoring the desirability of the typedef aliasing alternative we
recommend.  We conclude with a brief series of questions intended to
point out the areas in which the aliasing alternative seems to provide
more appropriate behavior.</p>


<h2><a name="Recap">3. Recap of N1406</a></h2>

<p>In his paper, Sutter explicates and proposes a new feature, "typedef
templates," for C++0x.  The feature is motivated via the desire "to allow
the programmer to create a synonym for a template where some, but not all,
actual template arguments are fixed" [&sect;1].  The feature itself would
permit the introduction of "a parameterized synonym" [&sect;2.1].</p>

<p>Sutter goes on to describe two distinct possible semantic models for
the typedef template feature.  Using the nomenclature "Specialization"
for option 1 and "Everything Else" for option 2, the paper asserts that
these models are mutually exclusive, and then recommends option 1, the
specialization model, for further consideration.  As Sutter puts it,
"This paper proposes Option 1, thus favoring specialization at the
expense of matching, deduction, and same-declarations . . . ."</p>


<h2><a name="Recent">4. Developments</a></h2>

<p>Since publication of [<a href="#HS">Sutter</a>], both Gabriel
Dos Reis [<a href="#DosReis">Dos Reis</a>] and David Vandevoorde [<a
href="#Vandevoorde1">Vandevoorde1</a>] communicated their opinions that
the two semantic models outlined by Sutter are not necessarily mutually
exclusive.  This is potentially quite significant:  as respected members
of noted compiler implementation teams, these gentlemen have considerable
expertise in the analysis of computer programming language features.
It may thus be possible that sufficiently clever language design and
implementation may permit the two semantic models to coexist.  This would
be a desirable outcome since both models appear to be useful to C++
programmers.</p>

<p>Vandevoorde also suggested ([<a href="#Vandevoorde1">Vandevoorde1</a>
and <a href="#Vandevoorde2">Vandevoorde2</a>]) alternate terminology
to denote the semantics of Sutter's option 2.  In contrast to the
rather informal "Everything Else" parlance, Vandevoorde offered the
term "template aliasing" to identify this semantic alternative to the
"specialization" semantics of typedef templates.  Because Vandevoorde's
suggested nomenclature seems to provide a somewhat more precise indication
of the desired intent of that semantic option, we will adopt it in the
remainder of this paper, and recommend its future use as the terminology
of choice to describe this variant of the feature under discussion.</p>

<p>Finally, the present author has come to the conclusion that, of the two
semantic models identified by Sutter, the now-renamed "template aliasing"
model is preferable to the initially recommended specialization model.
In the remainder of this paper, we will present our reasons for this
preference, expressed in the form of examples from a problem domain we
will introduce in the next section.</p>


<h2><a name="Domain">5. The Problem Domain</a></h2>

<p>Our examples are rooted in a problem domain known as "Physical
Quantities" ("PQ" or "PQs" for short).  According to International
Standard 31, physical quantities "are used for the quantitative
description of physical phenomena" [<a href="#ISO31">ISO31</a>, part 0].
</p>

<p>Pursuant to [<a href="#ISO1000">ISO1000</a>], the International
System of Units (SI), <a href="#Fig_1">Figure 1</a> presents several
examples of PQs.  The left column lists SI's seven prescribed <i>base
quantities</i>, while the right column illustrates a number of <i>derived
quantities</i>.  Base quantities are treated as fundamental in that no
base quantity depends on any other base quantity.  In contrast, each
derived quantity can be expressed as some product of base quantities.</p>

<a name="Fig_1"></a>
<table width="75%" align="center" cellpadding="5"
  summary="Examples of Physical Quantities">
<caption>Figure 1. Examples of Physical Quantities</caption>

<tr>
  <td width="40%" valign="baseline" style="background-color: lightgrey">
    <u>SI's Base Quantities</u><br>
      <br>
      &nbsp;&nbsp;&nbsp;1.&nbsp;length<br>
      &nbsp;&nbsp;&nbsp;2.&nbsp;mass<br>
      &nbsp;&nbsp;&nbsp;3.&nbsp;time<br>
      &nbsp;&nbsp;&nbsp;4.&nbsp;temperature<br>
      &nbsp;&nbsp;&nbsp;5.&nbsp;current<br>
      &nbsp;&nbsp;&nbsp;6.&nbsp;amount of substance<br>
      &nbsp;&nbsp;&nbsp;7.&nbsp;luminous intensity<br>
  </td>

  <td width="20%">&nbsp;</td>

  <td width="40%" valign="baseline" style="background-color: lightgrey">
    <u>Some Derived Quantities</u><br>
      <br>
      &nbsp;&nbsp;&nbsp;&bull;&nbsp;area<br>
      &nbsp;&nbsp;&nbsp;&bull;&nbsp;volume<br>
      &nbsp;&nbsp;&nbsp;&bull;&nbsp;velocity<br>
      &nbsp;&nbsp;&nbsp;&bull;&nbsp;acceleration<br>
      &nbsp;&nbsp;&nbsp;&bull;&nbsp;force<br>
      &nbsp;&nbsp;&nbsp;&bull;&nbsp;energy<br>
      &nbsp;&nbsp;&nbsp;&bull;&nbsp;electric charge<br>
      &nbsp;&nbsp;&nbsp;&bull;&nbsp;<i>etc.</i><br>
  </td>
</tr>

</table>

<p>PQs group into "categories ... which are mutually comparable" [<a
href="#ISO31">ISO31</a>, part 0].  This property of a category's PQs is
commonly known as <i>commensuration</i>.  <a href="#Fig_2">Figure 2</a>
presents two examples of PQ categories: each column constitutes a category
of commensurate PQs.</p>

<a name="Fig_2"></a>
<table width="75%" align="center" cellpadding="5"
  summary="Two Categories of Commensurate Physical Quantities">
<caption>Figure 2. Two Categories of Commensurate Physical Quantities</caption>

<tr>
  <td width="40%" valign="baseline" style="background-color: lightgrey">
      &nbsp;&nbsp;&nbsp;&bull;&nbsp;length<br>
      &nbsp;&nbsp;&nbsp;&bull;&nbsp;diameter<br>
      &nbsp;&nbsp;&nbsp;&bull;&nbsp;distance<br>
      &nbsp;&nbsp;&nbsp;&bull;&nbsp;perimeter<br>
      &nbsp;&nbsp;&nbsp;&bull;&nbsp;height<br>
      &nbsp;&nbsp;&nbsp;&bull;&nbsp;<i>etc.</i><br>
  </td>

  <td width="20%">&nbsp;</td>

  <td width="40%" valign="baseline" style="background-color: lightgrey">
      &nbsp;&nbsp;&nbsp;&loz;&nbsp;energy<br>
      &nbsp;&nbsp;&nbsp;&loz;&nbsp;heat<br>
      &nbsp;&nbsp;&nbsp;&loz;&nbsp;work<br>
      &nbsp;&nbsp;&nbsp;&loz;&nbsp;enthalpy<br>
      &nbsp;&nbsp;&nbsp;&loz;&nbsp;electron affinity<br>
      &nbsp;&nbsp;&nbsp;&loz;&nbsp;<i>etc.</i><br>
  </td>
</tr>

</table>

<p>It is possible to form expressions based on PQs.  The process
of determining what kind (category) of PQ will result from such an
expression is known as <i>dimensional analysis</i>.  For example, the
sum or difference of commensurate PQs yields a result of the same kind.
However, the sum or difference of incommensurate PQs is not meaningful
and so has no correct result.</p>

<p>In contrast, a product or quotient of PQs is always meaningful, and
yields a result whose kind can be determined from the operands' kinds.
The process is illustrated by the examples in <a href="#Fig_3">Figure
3</a>.  Note that the key intermediate step is to express each PQ as
the product of base quantities raised to powers.</p>

<a name="Fig_3"></a>
<table align="center" cellpadding="5"
  summary="Determining Products of Physical Quantities">
<caption>Figure 3. Determining Products of Physical Quantities</caption>

<tr align="center" style="background-color: lightgrey">
  <td>length &times; area
      &nbsp; &equiv; &nbsp; length<sup>1</sup> &times; length<sup>2</sup>
      &nbsp; &equiv; &nbsp; length<sup>3</sup>
      &nbsp; &equiv; &nbsp; volume
  </td>
</tr>

<tr align="center" style="background-color: lightgrey">
  <td>length / time
      &nbsp; &equiv; &nbsp; length<sup>1</sup> / time<sup>1</sup>
      &nbsp; &equiv; &nbsp; length<sup>1</sup> &times; time<sup>-1</sup>
      &nbsp; &equiv; &nbsp; velocity
  </td>
</tr>

</table>

<p>Because each PQ can be expressed as a specific product of the
seven base quantities, we identify each PQ by a list of the number
of times each base quantity is used in such an alternate expression.
Thus, an area is treated as the product of two lengths (and of no other
base quantities), a volume as the product of three lengths, and so on.
We will use the term <i>PQ signature</i> to denote such a list when it is
in a canonical order (<i>e.g.</i>, the length component always first,
the mass component always second, the time component always third,
<i>etc.</i>), <a href="#Fig_4">Figure 4</a> presents several additional
examples of such PQ signatures.  Note that two PQs can have identical
PQ signatures if and only if they are commensurate.</p>

<a name="Fig_4"></a>
<table align="center" cellspacing="0" cellpadding="3"
  summary="Examples of Physical Quantities' Signatures">
<caption>Figure 4. Examples of Physical Quantities' Signatures</caption>

<tr style="background-color: lightgrey">
  <td><u>Physical Quantity</u></td>
  <td>&nbsp;&nbsp;&nbsp;</td>
  <td><u>PQ Signature</u></td> </tr>

<tr>
  <td>length, height, <i>etc.</i></td>
  <td>&nbsp;&nbsp;&nbsp;</td>
  <td>1, 0, 0, 0, 0, 0, 0</td> </tr>
<tr style="background-color: lightgrey">
  <td>area</td>
  <td>&nbsp;&nbsp;&nbsp;</td>
  <td>2, 0, 0, 0, 0, 0, 0</td> </tr>
<tr>
  <td>volume</td>
  <td>&nbsp;&nbsp;&nbsp;</td>
  <td>3, 0, 0, 0, 0, 0, 0</td> </tr>
<tr style="background-color: lightgrey">
  <td>time</td>
  <td>&nbsp;&nbsp;&nbsp;</td>
  <td>0, 0, 1, 0, 0, 0, 0</td> </tr>
<tr>
  <td>velocity</td>
  <td>&nbsp;&nbsp;&nbsp;</td>
  <td>1, 0,-1, 0, 0, 0, 0</td> </tr>
<tr style="background-color: lightgrey">
  <td>acceleration</td>
  <td>&nbsp;&nbsp;&nbsp;</td>
  <td>1, 0,-2, 0, 0, 0, 0</td> </tr>

</table>


<h2><a name="Impl">6. A Notional Implementation</a></h2>

<p>The implementation sketch in <a href="#Fig_5">Figure 5</a> is neither
complete nor of suitable industrial strength; it is merely intended to
complete the outline of our problem domain as it might be expressed
in code.  Although different in detail, it is similar in nature and
intent to an exposition found in [<a href="#Barton">Barton/Nackman</a>,
&sect;16.5].</p>

<p>In brief, the implementation is based on a class template taking at
least eight template parameters.  Each instantiation of the template will
correspond to a specific kind of physical quantity.  The first template
parameter, <code>R</code>, represents the user's desired representation
type (such as <code>double</code>).  Seven additional template parameters,
one for each of SI's base quantities, collectively denote a PQ signature.
(We have elided many of these additional parameters in order to simplify
the presentation.)</p>

<a name="Fig_5"></a>
<table align="center" cellpadding="5"
  summary="Physical Quantities Implementation Sketch">
<caption>Figure 5. Physical Quantities Implementation Sketch</caption>

<tr style="background-color: lightgrey">
<td><pre style="background-color: lightgrey"><code>template< class R                     // representation type
        , int L, int M, int T, ... >  // PQ signature
struct PQ
{
  R value;

  PQ( R v = R() )
  : value(v)
  { }

  // sum commensurate PQs:
  PQ
  operator += ( PQ rhs )
  {
    this->value += rhs.value;
    return *this ;
  }

  // multiply arbitrary PQs:
  template< int L2, int M2, int T2, ... >
  PQ< R, L+L2, M+M2, T+T2, ... >
  operator * ( PQ< R, L2, M2, T2, ... > rhs )
  {
    typedef PQ< R, L+L2, M+M2, T+T2, ... > result_type;
    return result_type( this->value * rhs.value );
  }

};</code></pre>
</td>
</tr>

</table>


<h2><a name="Aliases">7. The Case for Template Aliasing</a></h2>

<p>The above implementation identifies physical quantities by their PQ
signatures.  Because it is at best unwieldy to express a physical quantity
in this way, we prefer our code to use the physical quantities' more
conventional names.  We would rather write <code>length&lt;R&gt;</code>
than <code>PQ&lt;R,1,0,0,0,0,0,0&gt;</code>.  At the same time, we wish
the compiler to recognize, for purposes of dimensional analysis and
type-checking, the equivalence of these two forms of <i>template-id</i>s.
</p>

<p>Conventionally, such <i>aliasing</i> is accomplished in C++ via
<code>typedef</code>s.  Here, however, we seek a form of parameterized
<code>typedef</code> because the desired form of the aliasing is
based not on types but on templates and their partial specializations.
<a href="#Fig_6">Figure 6</a> provides examples of the sorts of code
equivalence we believe necessary and useful.</p>

<a name="Fig_6"></a>
<table align="center" cellspacing="0" cellpadding="3"
  summary="Examples of Desired Template-id Aliases">
<caption>Figure 6. Examples of Desired Template-id Aliases</caption>

<tr style="background-color: lightgrey">
  <td><u>PQ signature-based Template-id</u></td>
  <td>&nbsp;&nbsp;&nbsp;</td>
  <td><u>Conventionally-named Alias</u></td>
</tr>

<tr>
  <td><code>PQ&lt; R, 1,0, 0,0,0,0,0 &gt;</code></td>
  <td>&nbsp;&nbsp;&nbsp;</td>
  <td><code>length&lt; R &gt;</code></td>
</tr>
<tr style="background-color: lightgrey">
  <td><code>PQ&lt; R, 2,0, 0,0,0,0,0 &gt;</code></td>
  <td>&nbsp;&nbsp;&nbsp;</td>
  <td><code>area&lt; R &gt;</code></td>
</tr>
<tr>
  <td><code>PQ&lt; R, 3,0, 0,0,0,0,0 &gt;</code></td>
  <td>&nbsp;&nbsp;&nbsp;</td>
  <td><code>volume&lt; R &gt;</code></td>
</tr>
<tr style="background-color: lightgrey">
  <td><code>PQ&lt; R, 0,0, 1,0,0,0,0 &gt;</code></td>
  <td>&nbsp;&nbsp;&nbsp;</td>
  <td><code>time&lt; R &gt;</code></td>
</tr>
<tr>
  <td><code>PQ&lt; R, 1,0,-1,0,0,0,0 &gt;</code></td>
  <td>&nbsp;&nbsp;&nbsp;</td>
  <td><code>velocity&lt; R &gt;</code></td>
</tr>
<tr style="background-color: lightgrey">
  <td><code>PQ&lt; R, 1,0,-2,0,0,0,0 &gt;</code></td>
  <td>&nbsp;&nbsp;&nbsp;</td>
  <td><code>acceleration&lt; R &gt;</code></td>
</tr>

</table>

<p>To demonstrate the utility and desirability of such aliasing, <a
href="#Fig_7">Figure 7</a> presents two implementations of a rather
straightforward function.  The first version uses only the PQ signature-based
nomenclature, while the second version uses the more conventional
nomenclature that would be made possible by the recommended template
aliasing feature.  It seems clear that the code's legibility and
comprehensibility is greatly enhanced by use of conventional names for
physical quantities.</p>

<a name="Fig_7"></a>
<table align="center" cellpadding="5"
  summary="Two Equivalent Function Implementations">
<caption>Figure 7. Two Equivalent Function Implementations</caption>

<tr style="background-color: lightgrey">
<td><pre><code>template&lt; class R &gt;
PQ&lt;R,1,0,0,0,0,0,0&gt;
h( PQ&lt;R,1,0,0,0,0,0,0&gt; leg1, PQ&lt;R,1,0,0,0,0,0,0&gt; leg2 )
{
  return sqrt( leg1 * leg1  +  leg2 * leg2 );
}</code></pre>
</td></tr>

<tr style="background-color: lightgrey">
<td><pre><code>template&lt; class R &gt;
length&lt;R&gt;
hypotenuse( length&lt;R&gt; leg1, length&lt;R&gt; leg2 )
{
  return sqrt( leg1 * leg1  +  leg2 * leg2 );
}</code></pre>
</td></tr>

</table>

<p>Sutter's proposed syntax (illustrated in <a href="#Fig_8">Figure
8</a>, extended to permit default template arguments) would be one
acceptable means of expressing such equivalences, as would any clean
alternate notation.</p>

<a name="Fig_8"></a>
<table align="center" cellpadding="5"
  summary="A Candidate Syntax for Template Aliasing">
<caption>Figure 8. A Candidate Syntax for Template Aliasing</caption>

<tr style="background-color: lightgrey">
<td><pre><code>template&lt; class R = double &gt;
typedef  PQ&lt; R, 1,0,0,0,0,0,0 &gt;  // declared above
         length&lt; R &gt;;            // declared here</code></pre>
</td></tr>
</table>

<p>Further, Sutter's option 2, dubbed "template aliasing" by Vandevoorde
as described above, would provide the "matching, deduction, and
same-declarations" semantics we seek for such a feature.  Together, these
semantics would permit the compiler to apply the rules of commensuration
as part of the type system.  Commensurate PQs would share a common
alias to identical PQ signature-based template-ids as illustrated
in <a href="#Fig_9">Figure 9</a>; incommensurate PQs would have no
common aliases.  All listed template-ids are equivalent and hence fully
interchangeable; template aliasing must be completely transitive.</p>

<a name="#Fig_9"></a>
<table align="center" cellspacing="0" cellpadding="3"
  summary="Examples of Commensuration via a Shared Alias">
<caption>Figure 9. Examples of Commensuration via a Shared Alias</caption>

<tr style="background-color: lightgrey">
  <td><u>Conventional Usage</u></td>
  <td>&nbsp;&nbsp;&nbsp;</td>
  <td><u>PQ signature-based Alias</u></td> </tr>

<tr>
  <td><code>length&lt;R&gt;</code></td>
  <td>&nbsp;&nbsp;&nbsp;</td>
  <td><code>PQ&lt;R,1,0,0,0,0,0,0&gt;</code></td>
</tr>
<tr style="background-color: lightgrey">
  <td><code>diameter&lt;R&gt;</code></td>
  <td>&nbsp;&nbsp;&nbsp;</td>
  <td><i>same as above</i></td>
</tr>
<tr>
  <td><code>distance&lt;R&gt;</code></td>
  <td>&nbsp;&nbsp;&nbsp;</td>
  <td><i>same as above</i></td>
</tr>
<tr style="background-color: lightgrey">
  <td><code>perimeter&lt;R&gt;</code></td>
  <td>&nbsp;&nbsp;&nbsp;</td>
  <td><i>same as above</i></td>
</tr>
<tr>
  <td><code>height&lt;R&gt;</code></td>
  <td>&nbsp;&nbsp;&nbsp;</td>
  <td><i>same as above</i></td>
</tr>
<tr style="background-color: lightgrey">
  <td><code>altitude&lt;R&gt;</code></td>
  <td>&nbsp;&nbsp;&nbsp;</td>
  <td><i>same as above</i></td>
</tr>

</table>

<p><a href="#Fig_10">Figure 10</a> shows one additional application
of template aliasing.  This is the declaration of a function that
applies the physics of <i>Bremsstrahlung</i> in calculating the
energy of a particle after it passed through a piece of material.
This calculation is based on formulas in the <i>Review of Particle
Physics</i> [<a href="#PDG">PDG</a>, &sect;23.4.1].  Its parameters
include the material's composition, density, and thickness, as well as
the particle's energy before encountering the material.</p>

<a name="Fig_10"></a>
<table align="center" cellpadding="5"
  summary="Applied Template Aliasing">
<caption>Figure 10. Applied Template Aliasing</caption>

<tr style="background-color: lightgrey">
<td><pre><code>template&lt; class R &gt;
energy&lt; R &gt;
final_energy( element&lt;R&gt; const &amp;  material
            , density&lt;R&gt; const    how_dense
            , length &lt;R&gt; const    how_thick
            , energy &lt;R&gt; const    starting_energy
            );</code></pre>
</td></tr>

</table>

<p>It seems clear, again from rather straightforward inspection, that
the declaration in <a href="#Fig_10">Figure 10</a> would be considerably
uglier in the absence of the conventional names that template aliasing
could introduce.  More importantly, with all the elided <code>int</code>
parameters exposed, the code would have taken significant effort to
ensure its correctness and, once written, would still be significantly
more difficult to comprehend.</p>


<h2><a name="Summary">8. Summary</a></h2>

<p>In this paper, we have presented a case for the adoption of a new
C++ language feature, template typedefs, and have advocated that this
feature's semantics be those known as template aliasing, formerly referred
to as "Everything Else."  We have presented a compelling use case for
template aliasing in order to explicate the desired semantics, and to
demonstrate significant advantages of the template aliasing semantics
over the "Specialization" semantics.</p>

<p>We believe this feature, with our preferred semantics including
deduction, matching, and same-declarations, would be a useful contribution
to the C++ programming language, for it seems to fill a significant gap
that can not be met today.  While C++ does today encompass the notion
of type identity (typically expressed via <code>typedef</code>), there
is today no comparable means of expressing template identity, with or
without partial specialization.</p>


<h2><a name="After">9. Afterword</a></h2>

<p>The Evolution Working Group has given this topic considerable
attention, both before (<i>e.g.</i>, in [<a href="#DosReis">Dos Reis</a>]
and in [<a href="#Vandevoorde2">Vandevoorde2</a>]) as well as after this
paper's presentation.  A tentative resolution of the underlying issues
has emerged from these deliberations, with syntax (applied to our problem
domain) approximately as shown in <a href="#Fig_11">Figure 11</a>, and
with tentative semantics akin to those advocated herein.  Consistent with
the recent [<a href="#DosReis/Marcus">Dos Reis/Marcus</a>], this feature
is now known as "template aliasing" in preference to Sutter's "typedef
templates" nomenclature, and encompasses a form of specialization as
well.</p>

<a name="Fig_11"></a>
<table align="center" cellpadding="5"
  summary="EWG Working Syntax for Template Aliasing">
<caption>Figure 11. EWG Working Syntax for Template Aliasing</caption>

<tr style="background-color: lightgrey">
<td><pre><code>template&lt; class R = double &gt;
length = PQ&lt; R, 1,0,0,0,0,0,0 &gt;;</code></pre>
</td></tr>
</table>

<p>Future evolution of this topic may result in a more general approach
to aliasing, encompassing this and other features already part of C++.
For example, namespace aliases and <code>typedef</code>s are in today's
C++, and are certainly forms of aliasing.  While it may become possible to
unify all these features, current thinking on this issue now encompasses
the notion of aliases for templates.</p>


<h2><a name="Ack">10. Acknowledgments</a></h2>

<p>We would like to express our appreciation to Gabriel Dos Reis,
Benjamin Kosnik, Mat Marcus, Bjarne Stroustrup, Herb Sutter, and
David Vandevoorde for their very helpful respective discussions and
correspondence related to this paper's topic.  We are also grateful to
our colleagues Mark Fischler, James Kowalkowski, and Marc Paterno for
their careful reading of earlier drafts of this paper.  Finally, we wish
to recognize the support of the Fermi National Accelerator Laboratory's
Computing Division, sponsors of Fermilab's participation in the C++
standards effort.  Thank you, one and all.</p>

<h2><a name="Ref">11. References</a></h2>

<dl>

  <dt><a name="Barton">[Barton/Nackman]</a>
  <dd>
    Barton, John J., and Lee R. Nackman:
    <i>Scientific and Engineering C++</i>.
    Addison-Wesley, 1994.
    ISBN 0-201-53393-6.
  </dd>

  <dt><a name="DosReis">[Dos Reis]</a>
  <dd>
    Dos Reis, Gabriel:
    <i>typedef template and template typedef</i>.
    Reflector message c++std-ext-5658.
    November 29, 2002.
  </dd>

  <dt><a name="DosReis/Marcus">[Dos Reis/Marcus]</a>
  <dd>
    Dos Reis, Gabriel, and Mat Marcus:
    <i>Proposal to add template aliases to C++</i>.
    WG21/N1449 (same as J16/03-0032): April, 2003.
  </dd>

  <dt><a name="ISO31">[ISO31]</a>
  <dd>
    International Standards Organization:
    "Quantities and units,"
    International Standard ISO 31:1992(E).
    In <i>Quantities and units, Third edition</i>, 1993.
    ISBN 92-67-10185-4.
  </dd>

  <dt><a name="ISO1000">[ISO1000]</a>
  <dd>
    International Standards Organization:
    "SI units and recommendations
    for the use of their multiples and of certain other units,"
    International Standard ISO 1000:1992(E).
    In <i>Quantities and units, Third edition</i>, 1993.
    ISBN 92-67-10185-4.
  </dd>

  <dt><a name="PDG">[PDG]</a>
  <dd>
    Particle Data Group (Groom, D. E., <i>et al.</i>):
    "Review of Particle Physics,"
    <i>Eur. Phys. J. C</i> 15, 1-878 (2000).
  </dd>

  <dt><a name="Sutter">[Sutter]</a>
  <dd>
    Sutter, Herb:
    <i>Proposed Addition to C++: Typedef Templates</i>.
    WG21/N1406 (same as J16/02-0064): October 21, 2002.
  </dd>

  <dt><a name="Vandevoorde1">[Vandevoorde1]</a>
  <dd>
    Vandevoorde, David:
    <i>Personal Conversation</i>.
    April, 2003.
  </dd>

  <dt><a name="Vandevoorde2">[Vandevoorde2]</a>
  <dd>
    Vandevoorde, David:
    <i>Re: typedef template and template typedef</i>.
    Evolution group reflector message c++std-ext-5680.
    December 2, 2002.
  </dd>

</dl>

<hr>

</body>
</html>
