Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [VOTE] naming convention for variadic template arguments
Date: Mon, 30 Jun 2008 10:14:17 -0600
Message-ID: 
 <CFFDD219128FD94FB4F92B99F52D0A4901DB0605@exchmail01.Blue.Roguewave.Com>
Thread-Topic: [VOTE] naming convention for variadic template arguments
Thread-Index: AcjZSzyqibiEF1pqTquNkjHgZNhI0ABfF5sA
References: <20080616211649.7F90A23889F3@eris.apache.org>
 <48600F33.8000908@roguewave.com> <48655619.3020602@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A4901DB0600@exchmail01.Blue.Roguewave.Com>
 <CFFDD219128FD94FB4F92B99F52D0A49465BF3@exchmail01.Blue.Roguewave.Com>
 <4866800C.8070008@roguewave.com>
From: "Eric Lemings" <Eric.Lemings@roguewave.com>
To: <dev@stdcxx.apache.org>

=20

> -----Original Message-----
> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
> Sent: Saturday, June 28, 2008 12:17 PM
> To: dev@stdcxx.apache.org
> Subject: Re: [VOTE] naming convention for variadic template arguments
>=20
> Travis Vitek wrote:
> >=20
> >=20
> >> Eric Lemings wrote:
...
> >=20
> >> In this case, it depends on whether the two parameters are=20
> actually part
> >> of the same type list.  If _TypesT and _Types are actually=20
> part of the
> >> same type list then they should be named either _TypeT and _TypesT
> >> respectively (or _Type and _Types as shown in #2).  If=20
> they are not part
> >> of the same type list, then they should be named _TypeT and _TypesU
> >> (similar to #4).
>=20
> This makes sense. The only potential problem is that (I suspect)
> it may not necessarily be known at the point of the declaration
> of every template whether the types are related or not (just like
> an InputIterator in some container member function templates may
> not be an iterator at all but size_type). But that case can be
> handled by simply assuming that the types are related (analogous
> to the InputIterator case).

That's a slightly different case.  This parameter, whether it is an
iterator or an offset type, is still separate from the other parameters.

In the variadic template case (e.g. _Head, _Tail...), the parameters
are logically the same template parameter; that is, they are actually
part of the same type list and only named separately to to implement
the variadic template.

>=20
...
>=20
> I realize the convention I proposed has at least one other
> shortcoming in that it doesn't scale to member templates:
>=20
>      template <class _TypeT, class... _Types>
>      struct Parent {
>          template <class _TypeU, class... _Types???>
>          Child {
>              template <class _TypeV, class... _Types???>
>              Grandchild { };
>          };
>      };
>=20
> To account for this, taking into account the existing convention
> (and assuming your _TTypes was really meant to be _TypesT), the
> generic case would look like so:
>=20
>      template <class... _TypesT>
>      struct Parent {
>          template <class... _TypesU>
>          Child {
>              template <class... _TypesV>
>              Grandchild { };
>          };
>      };
>=20
> Applying Brad's proposal (if I understand it correctly) to related
> types, we'd have this:
>=20
>      template <class _TypeT, class... _TypesT>
>      struct Parent {
>          template <class _TypeU, class... _TypesU>
>          Child {
>              template <class _TypeV, class... _TypesV>
>              Grandchild { };
>          };
>      };
>=20
> and for unrelated types this:
>=20
>      template <class _TypeT, class... _TypesU>
>      struct Parent {
>          template <class _TypeV, class... _TypesW>
>          Child {
>              template <class _TypeX, class... _TypesY>
>              Grandchild { };
>          };
>      };
>=20
> Does this look okay to everyone?

Uhm, that depends.  :)

Are you proposing that we are limited only to these specific names or to
this naming _pattern_?  (I would prefer to specify conventions --
especially new conventions -- as patterns rather than limiting them to
specific rules.)

In other words, I (prefer to) only use the name "Type" (or "TypeT") when
the template parameter can actually be any type: no requirements, no
restrictions.  If, for example, the template parameter must be an
integral type, would the following naming conventions for variadic
templates also apply?

For type lists:

    template <class _IntTypeT, class... _IntTypesT>
    struct Parent {
        template <class _IntTypeU, class... _IntTypesU>
        Child {
            template <class _IntTypeV, class... _IntTypesV>
            Grandchild { };
        };
    };

For types other than type lists:

    template <class _IntTypeT, class... _IntTypesU>
    struct Parent {
        template <class _IntTypeV, class... _IntTypesW>
        Child {
            template <class _IntTypeX, class... _IntTypesY>
            Grandchild { };
           };
     };

If we are proposing this pattern as a naming convention for variadic
template parameters, then I would find that acceptable.

Brad.