You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by Martin Sebor <se...@roguewave.com> on 2008/06/27 23:05:29 UTC
[VOTE] naming convention for variadic template arguments (was: Re:
svn commit: r668318 - in /stdcxx/branches/4.3.x: include/rw/_tuple.h include/rw/_tuple_traits.h
include/tuple tests/utilities/20.tuple.cnstr.cpp)
This thread kind of fizzled out so let me resurrect it and reiterate
the proposed naming convention to follow unless more specific names
are appropriate:
template <class _TypeT, class... _Types> # 1
This is in contrast to other styles, including:
template <class _Type, class... _Types> # 2
template <class _HeadT, class... _TailT> # 3
template <class _TType, class... _UTypes> # 4
The rationale for the proposed convention (#1) is that:
A) unlike the alternatives, the first name (_TypeT) follows
a well-established and entrenched convention for template
parameters used throughout the library
B) also unlike the alternatives, it is being used in the
implementation of <type_traits>
C) unlike (#2) (although not as well as #3) it more clearly
distinguishes between the name of the first parameter and
the parameter pack
Check the box below to vote:
[ ] In favor
[ ] Opposed (suggest an improvement and rationale)
Martin Sebor wrote:
> elemings@apache.org wrote:
>> Author: elemings
>> Date: Mon Jun 16 14:16:48 2008
>> New Revision: 668318
>>
>> URL: http://svn.apache.org/viewvc?rev=668318&view=rev
>> Log:
>> 2008-06-16 Eric Lemings <er...@roguewave.com>
>>
>> STDCXX-958
>> * include/tuple, include/rw/_tuple.h, include/rw/_tuple_traits.h:
>> Add initial version of headers defining tuple interface and
>> implementation. (Only tested on Linux/gcc-4.3 platforms so far.)
>> * tests/utilities/20.tuple.cnstr.cpp: Rough outline of first
>> tuple test program.
>>
> [...]
>> +# if !defined _RWSTD_NO_VARIADIC_TEMPLATES
>> +
>> +
>> +_RWSTD_NAMESPACE (std) {
>> +
>> +
>> +// 20.3.1, class template tuple:
>> +
>> +/**
>> + * @defgroup tuple Tuples [tuple]
>> + *
>> + * A fixed-size collection of values with variable, heterogenous types.
>> + * This class template is used to instantatiate tuple types. A tuple
>> + * type specifies zero or more element types for defining tuple values.
>> + * A tuple value can be constructed from a tuple type that holds one
>> + * value for each element type in the tuple.
>> + *
>> + * @param Types A list of zero or more types. No applicable type
>> + * requirements or restrictions.
>> + */
>> +template < class... Types >
>
> Please follow the established convention and drop the spaces
> before class and before the closing pointy brace. Thanks! :)
>
>> +class tuple;
>> +
>> +/**
>> + * @internal
>> + * The template specialization for empty tuples.
>> + */
>> +_RWSTD_SPECIALIZED_CLASS
>> +class tuple< >
>
> Also please remove the space between the pointy braces here.
>
>> +{
>> + // empty
>> +};
>> +
>> +/**
>> + * @internal
>> + * The basic template specialization for most tuples. This class
>> + * template is used to instantiate all tuple types except for empty
>> + * tuples and tuples with exactly two element types.
>> + *
>> + * @param _HeadT First element type (required).
>> + * @param _TailT Template parameter pack for remaining element types.
>> + */
>> +template < class _HeadT, class... _TailT >
>
> In the interest of consistency we should adopt the same naming
> convention for the names of variadic template parameters. We
> have _TypeT and and Types in traits, _HeadT and _TailT here,
> and TTypes and UTypes in the standard. Which one should it
> be?
>
>> +class tuple< _HeadT, _TailT... >
>> + : tuple< _TailT... >
>> +{
>> + typedef tuple< _TailT... > _Base;
>> +
>> +protected:
>> +
>> + _HeadT _C_head;
>
> Why protected and not private?
>
>> +
>> +public:
>> +
>> + /**
>> + * Construct tuple with default values.
>> + */
>> + tuple ()
>> + : _C_head (), _Base () { /* empty */ }
>
> Unless tuple is somehow different from other (non-variadic
> classes) I think _Base() here should be listed first, because
> it's initialized first, no?
>
>> +
>> + /**
>> + * Copy construct tuple from a different tuple value.
>> + * @param __tuple Another tuple value with same type.
>> + */
>> + tuple (const tuple& __tuple)
>> + : _C_head (__tuple._C_head), _Base (__tuple) { /* empty */ }
>
> Same as above.
>
>> +
>> + /**
>> + * Copy assign tuple from a different tuple value.
>> + * @param __tuple Another tuple value with same type.
>> + */
>> + tuple& operator= (const tuple& __tuple) {
>> + _C_head = __tuple._C_head;
>> + _Base::operator= (__tuple);
>
> Similarly to the ctor, the base assignment operator should
> probably be invoked first.
>
>> + return *this;
>> + }
>> +
>> + _EXPLICIT
>> + tuple (const _HeadT& __head, const _TailT&... __tail)
>> + : _C_head (__head), _Base (__tail...) { /* empty */ }
>> +
>> +# if !defined _RWSTD_NO_RVALUE_REFERENCES
>> +
>> + tuple (tuple&& __tuple)
>> + : _C_head (std::move (__tuple._C_head))
>> + , _Base (std::forward<_Base> (__tuple)) { /* empty */ }
>
> The initialization order should follow the default ctor case
> (i.e., _Base first). Also, the existing convention doesn't
> drop the comma.
>
>> +
>> + tuple& operator= (tuple&& __tuple) {
>> + _C_head = std::move (__tuple._C_head);
>> + _Base::operator= (__tuple);
>
> Same as the other assignment operator.
>
> Also, I think it would make the class easier to read if
> overloads were kept together wherever possible (i.e., all
> ctors, all assignment operators, etc.) Although I think
> I see why you didn't -- to avoid duplicating the rvalue
> references test. Hmm. Have we decided on the list of
> required compiler features yet? I saw your Compiler
> Requirements page on the wiki (thanks for starting it,
> btw.) and rvalue references isn't there. Do we think we
> can provide a useful implementation of C++ 0x without
> rvalue references?
>
>> + return *this;
>> + }
>> +
>> +# endif // !defined _RWSTD_NO_RVALUE_REFERENCES
>> +
>> +# if !defined _RWSTD_NO_MEMBER_TEMPLATES
>
> I think we can safely rely on member templates in C++ 0x.
> Do we all agree?
> [...]
>> Added: stdcxx/branches/4.3.x/include/rw/_tuple_traits.h
> [...]
>> +template <class _Type>
>> +struct constructible_with_allocator_prefix;
>> +
>> +/**
>> + * Allows tuple construction with an allocator prefix argument. This
>> + * trait informs other library components that tuple can be constructed
>> + * with an allocator preï¬x argument.
> ^^^^^^^^
>
> Looks like an unreadable character has sneaked in here.
>
> [...]
>> Added: stdcxx/branches/4.3.x/include/tuple
> [...]
>> +
>> +#if defined _RWSTD_NO_EXT_CXX_0X
>> +# error _RWSTD_NO_EXT_CXX_0X defined and C++0x header included
>> +#endif // defined _RWSTD_NO_EXT_CXX_0X
>> +
>> +#ifndef _RWSTD_TUPLE_INCLUDED
>> +# define _RWSTD_TUPLE_INCLUDED
>> +
>> +# include <rw/_tuple.h>
>> +# include <rw/_tuple_traits.h>
>> +
>> +
>> +_RWSTD_NAMESPACE (__rw) {
>> +
>> +struct __rw_ignore { /* empty */ };
>> +
>> +/// Transforms _Type into a suitable make_tuple() return type.
>> +template <class _Type>
>> +struct __rw_make_tuple {
>> + /// @todo Deduce correct return type.
>> + typedef _Type type;
>> +};
>> +
>> +} // namespace __rw
>> +
>> +
>> +_RWSTD_NAMESPACE (std) {
>> +
>> +
>> +// 20.3.3, tuple creation functions:
>> +
>> +const _RW::__rw_ignore ignore = _RW::__rw_ignore ();
>
> This either needs to be static or preferably defined out
> of line (in a .cpp file). Ditto for std::allocator_arg
> in rw/_allocator.h.
>
>> +
> [...]
>> +// 20.3.1.4, tuple helper classes:
>> +
>> +template <class>
>
> Please don't omit the names of template parameters. I wish
> we could but I don't think aCC 3 supports it yet.
>
>> +class tuple_size; // undefined
>> +
>> +template <class... _Types>
>> +class tuple_size<tuple<_Types...> >;
>> +
>> +template <int, class>
>> +class tuple_element; // undefined
>> +
>> +template <int _Index, class... _Types>
>> +class tuple_element<_Index, tuple<_Types...> >;
>> +
>> +
>> +// 20.3.1.5, element access:
>> +
>> +template <int _Index, class... _Types>
>> +_TYPENAME tuple_element<_Index, tuple<_Types...> >::type&
>> +get (tuple<_Types...>&);
>> +
>> +template <int _Index, class ... _Types>
>> +_TYPENAME tuple_element<_Index, tuple<_Types...> >::type const&
>
> The const should come before tuple_element.
>
>> +get (const tuple<_Types...>&);
>> +
>> +
>> +// 20.3.1.6, relational operators:
>> +
>> +template <class... _TypesT, class... _TypesU>
>> +bool operator== (const tuple<_TypesT...>& __x,
>> + const tuple<_TypesU...>& __y);
>
> I think aCC 6 gives a remark for function argument names
> in function prototypes.
>
>> +
>> +template <class... _TypesT, class... _TypesU>
>> +bool operator< (const tuple<_TypesT...>& __x,
>> + const tuple<_TypesU...>& __y);
>> +
>> +/**
>> + * @param __x Tuple value on LHS of operator.
>> + * @param __y Tuple value on RHS of operator.
>> + * @return !(__x == __y)
>> + */
>> +template <class... _TypesT, class... _TypesU>
>> +bool operator!= (const tuple<_TypesT...>& __x,
>> + const tuple<_TypesU...>& __y)
>> +{
>> + return !(__x == __y);
>> +}
>
> This and all other function templates defined here need to
> be declared inline.
>
> Martin
RE: [VOTE] naming convention for variadic template arguments (was: Re: svn commit: r668318 - in /stdcxx/branches/4.3.x: include/rw/_tuple.h include/rw/_tuple_traits.h include/tuple tests/utilities/20.tuple.cnstr.cpp)
Posted by Eric Lemings <Er...@roguewave.com>.
This mean you're quiting SourcePro/Rogue Wave but and starting
work on STDCXX now that know one can tell you otherwise? :P
> -----Original Message-----
> From: Liviu Nicoara [mailto:Liviu.Nicoara@roguewave.com]
> Sent: Friday, June 27, 2008 3:10 PM
> To: dev@stdcxx.apache.org; dev@stdcxx.apache.org
> Subject: RE: [VOTE] naming convention for variadic template
> arguments (was: Re: svn commit: r668318 - in
> /stdcxx/branches/4.3.x: include/rw/_tuple.h
> include/rw/_tuple_traits.h include/tuple
> tests/utilities/20.tuple.cnstr.cpp)
>
> > -----Original Message-----
> > From: Martin Sebor on behalf of Martin Sebor
> > Sent: Fri 6/27/2008 3:05 PM
> > To: dev@stdcxx.apache.org
> > Subject: [VOTE] naming convention for variadic template
> arguments (was: Re: svn commit: r668318 - in
> /stdcxx/branches/4.3.x: include/rw/_tuple.h
> include/rw/_tuple_traits.h include/tuple
> tests/utilities/20.tuple.cnstr.cpp)
> >
> > This thread kind of fizzled out so let me resurrect it and reiterate
> > the proposed naming convention to follow unless more specific names
> > are appropriate:
> >
> > template <class _TypeT, class... _Types> # 1
> >
> > [...]
> > Check the box below to vote:
> >
>
> [x] In favor (of #1)
> [ ] Opposed (suggest an improvement and rationale)
>
> -L
>
RE: [VOTE] naming convention for variadic template arguments (was: Re: svn commit: r668318 - in /stdcxx/branches/4.3.x: include/rw/_tuple.h include/rw/_tuple_traits.h include/tuple tests/utilities/20.tuple.cnstr.cpp)
Posted by Liviu Nicoara <Li...@roguewave.com>.
> -----Original Message-----
> From: Martin Sebor on behalf of Martin Sebor
> Sent: Fri 6/27/2008 3:05 PM
> To: dev@stdcxx.apache.org
> Subject: [VOTE] naming convention for variadic template arguments (was: Re: svn commit: r668318 - in /stdcxx/branches/4.3.x: include/rw/_tuple.h include/rw/_tuple_traits.h include/tuple tests/utilities/20.tuple.cnstr.cpp)
>
> This thread kind of fizzled out so let me resurrect it and reiterate
> the proposed naming convention to follow unless more specific names
> are appropriate:
>
> template <class _TypeT, class... _Types> # 1
>
> [...]
> Check the box below to vote:
>
[x] In favor (of #1)
[ ] Opposed (suggest an improvement and rationale)
-L
Re: [VOTE] naming convention for variadic template arguments
Posted by Martin Sebor <se...@roguewave.com>.
Eric Lemings wrote:
>
[...]
> If we are proposing this pattern as a naming convention for variadic
> template parameters, then I would find that acceptable.
As I said in the VOTE post:
"...the proposed naming convention to follow unless more
specific names are appropriate"
When it's known that all the types model the same concept,
using the name of the concept instead of the generic TypeT
certainly sounds like a good idea. That's also why we have
template parameters named InputIter[ator] and similar in
the existing code base rather than just TypeT and TypeU
everywhere.
That said, I hope not to get too distracted by a discussion
of hypothetical cases. The point of this vote is to
[re]establish consistency in areas where newly added code
has started to diverge. If we find in the future that the
convention doesn't adequately cover some new cases we can
certainly revisit it and tighten things up to address the
cases we missed this time.
Martin
RE: [VOTE] naming convention for variadic template arguments
Posted by Eric Lemings <Er...@roguewave.com>.
> -----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.
Re: [VOTE] naming convention for variadic template arguments
Posted by Martin Sebor <se...@roguewave.com>.
Travis Vitek wrote:
>
>
>> Eric Lemings wrote:
>>> Martin Sebor
>>>
>>> This thread kind of fizzled out so let me resurrect it and reiterate
>>> the proposed naming convention to follow unless more specific names
>>> are appropriate:
>>>
>>> template <class _TypeT, class... _Types> # 1
>>>
>>> This is in contrast to other styles, including:
>>>
>>> template <class _Type, class... _Types> # 2
>>> template <class _HeadT, class... _TailT> # 3
>>> template <class _TType, class... _UTypes> # 4
>>>
>>> The rationale for the proposed convention (#1) is that:
>>>
>>> A) unlike the alternatives, the first name (_TypeT) follows
>>> a well-established and entrenched convention for template
>>> parameters used throughout the library
>>> B) also unlike the alternatives, it is being used in the
>>> implementation of <type_traits>
>>> C) unlike (#2) (although not as well as #3) it more clearly
>>> distinguishes between the name of the first parameter and
>>> the parameter pack
>>>
>
> [...]
>
>> 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).
>>
>> In any case, a plural name should implicitly denote a template parameter
>> pack (which actually should rule out #3 even though I've already been
>> using it). :P
Agreed.
>>
>> Brad.
>
> I'm with Brad
Yet each of you is using different names both in your code and
in your responses to this thread...
>
>> Check the box below to vote:
>>
>> [ ] In favor
>> [x] Opposed (suggest an improvement and rationale)
>>
>
> I think the names really depend on the intent and where it is being used. If you have a parameter pack that is essentially a single typelist, like so...
>
> template <class... _TTypes> struct S;
>
> I'd expect the first template parameter and the parameter pack to have similar names. The above will likely break down to the following recursive template declaration...
>
> template <class _TypeT> struct S;
> template <class _TypeT, class... _TTypes> struct S;
Did you mean _TTypes or _TypesT?
There's not a single occurrence of _TTypes in any of your or Brad's
code. You use _Types and Brad _Types, _TypesT, _TailT, or _TailT1
(with the trailing T and 1 possible being U or 2, as needed).
I will assume you meant _TypesT and _TypesU because that's what
you've been using in your code. It also seems more in keeping
with the naming convention for ordinary (non-variadic) template
parameters. Plus I like how the T or U at end stands out. Other
than that, I don't really care all that much if we end up with
_TTypes or _TypesT. What I do care about is consistency.
>
> If, on the other hand, the first argument stands alone and the parameter pack is a typelist, then I'd expect something more like the following...
>
> template <class _TypeT, class... _UTypes> struct S;
>
> template <class _TypeT, class _TypeU> struct S;
> template <class _TypeT, class _TypeU, class... _UTypes> struct S;
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?
Martin
RE: [VOTE] naming convention for variadic template arguments (was: Re: svn commit: r668318 - in /stdcxx/branches/4.3.x: include/rw/_tuple.h include/rw/_tuple_traits.h include/tuple tests/utilities/20.tuple.cnstr.cpp)
Posted by Travis Vitek <Tr...@roguewave.com>.
>Eric Lemings wrote:
>> Martin Sebor
>>
>> This thread kind of fizzled out so let me resurrect it and reiterate
>> the proposed naming convention to follow unless more specific names
>> are appropriate:
>>
>> template <class _TypeT, class... _Types> # 1
>>
>> This is in contrast to other styles, including:
>>
>> template <class _Type, class... _Types> # 2
>> template <class _HeadT, class... _TailT> # 3
>> template <class _TType, class... _UTypes> # 4
>>
>> The rationale for the proposed convention (#1) is that:
>>
>> A) unlike the alternatives, the first name (_TypeT) follows
>> a well-established and entrenched convention for template
>> parameters used throughout the library
>> B) also unlike the alternatives, it is being used in the
>> implementation of <type_traits>
>> C) unlike (#2) (although not as well as #3) it more clearly
>> distinguishes between the name of the first parameter and
>> the parameter pack
>>
[...]
>
>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).
>
>In any case, a plural name should implicitly denote a template parameter
>pack (which actually should rule out #3 even though I've already been
>using it). :P
>
>Brad.
I'm with Brad
> Check the box below to vote:
>
> [ ] In favor
> [x] Opposed (suggest an improvement and rationale)
>
I think the names really depend on the intent and where it is being used. If you have a parameter pack that is essentially a single typelist, like so...
template <class... _TTypes> struct S;
I'd expect the first template parameter and the parameter pack to have similar names. The above will likely break down to the following recursive template declaration...
template <class _TypeT> struct S;
template <class _TypeT, class... _TTypes> struct S;
If, on the other hand, the first argument stands alone and the parameter pack is a typelist, then I'd expect something more like the following...
template <class _TypeT, class... _UTypes> struct S;
template <class _TypeT, class _TypeU> struct S;
template <class _TypeT, class _TypeU, class... _UTypes> struct S;
Travis
RE: [VOTE] naming convention for variadic template arguments (was: Re: svn commit: r668318 - in /stdcxx/branches/4.3.x: include/rw/_tuple.h include/rw/_tuple_traits.h include/tuple tests/utilities/20.tuple.cnstr.cpp)
Posted by Eric Lemings <Er...@roguewave.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
> Sent: Friday, June 27, 2008 3:05 PM
> To: dev@stdcxx.apache.org
> Subject: [VOTE] naming convention for variadic template
> arguments (was: Re: svn commit: r668318 - in
> /stdcxx/branches/4.3.x: include/rw/_tuple.h
> include/rw/_tuple_traits.h include/tuple
> tests/utilities/20.tuple.cnstr.cpp)
>
> This thread kind of fizzled out so let me resurrect it and reiterate
> the proposed naming convention to follow unless more specific names
> are appropriate:
>
> template <class _TypeT, class... _Types> # 1
>
> This is in contrast to other styles, including:
>
> template <class _Type, class... _Types> # 2
> template <class _HeadT, class... _TailT> # 3
> template <class _TType, class... _UTypes> # 4
>
> The rationale for the proposed convention (#1) is that:
>
> A) unlike the alternatives, the first name (_TypeT) follows
> a well-established and entrenched convention for template
> parameters used throughout the library
> B) also unlike the alternatives, it is being used in the
> implementation of <type_traits>
> C) unlike (#2) (although not as well as #3) it more clearly
> distinguishes between the name of the first parameter and
> the parameter pack
>
> Check the box below to vote:
>
> [ ] In favor
> [x] Opposed (suggest an improvement and rationale)
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).
In any case, a plural name should implicitly denote a template parameter
pack (which actually should rule out #3 even though I've already been
using it). :P
Brad.