stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Lemings" <Eric.Lemi...@roguewave.com>
Subject RE: [VOTE] naming convention for variadic template arguments
Date Mon, 30 Jun 2008 16:14:17 GMT
 

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

Mime
View raw message