> -----Original Message-----
> From: Martin Sebor [mailto:[EMAIL PROTECTED] 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
>
> Travis Vitek wrote:
> >
> >
> >> Eric Lemings wrote:
...
> >
> >> In this case, it depends on whether the two parameters are
> actually part
> >> of the same type list. If _TypesT and _Types are actually
> 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
> they are not part
> >> of the same type list, then they should be named _TypeT and _TypesU
> >> (similar to #4).
>
> 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.
>
...
>
> I realize the convention I proposed has at least one other
> shortcoming in that it doesn't scale to member templates:
>
> template <class _TypeT, class... _Types>
> struct Parent {
> template <class _TypeU, class... _Types???>
> Child {
> template <class _TypeV, class... _Types???>
> Grandchild { };
> };
> };
>
> 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:
>
> template <class... _TypesT>
> struct Parent {
> template <class... _TypesU>
> Child {
> template <class... _TypesV>
> Grandchild { };
> };
> };
>
> Applying Brad's proposal (if I understand it correctly) to related
> types, we'd have this:
>
> template <class _TypeT, class... _TypesT>
> struct Parent {
> template <class _TypeU, class... _TypesU>
> Child {
> template <class _TypeV, class... _TypesV>
> Grandchild { };
> };
> };
>
> and for unrelated types this:
>
> template <class _TypeT, class... _TypesU>
> struct Parent {
> template <class _TypeV, class... _TypesW>
> Child {
> template <class _TypeX, class... _TypesY>
> Grandchild { };
> };
> };
>
> 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.
