Eric Lemings wrote:
[...]
Please follow the established convention and drop the spaces
before class and before the closing pointy brace. Thanks! :)
It would be a lot easier if these conventions were actually ESTABLISHED.
Until they are established, we're going to be constantly running into
this problem. Don't you agree?
They are fully established (grep for "< class" vs "<class" in our
sources), they're just not formally documented. In the absence of
documentation I suggest you follow the style used in existing code.
It's not that different from the style used in most other projects
including those at Rogue Wave.
I can start a Wiki page for this unless you'd prefer to do it.
Starting a page on coding style sounds like a great idea.
[...]
+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?
It is my opinion that the T and U prefixes/suffixes are only necessary
in binary contexts; i.e. where there are two different types or type
lists.
That may be the case but...
Otherwise, we should use just a plain "Type" name.
...we have an established convention that has the T at the end.
I'm opposed to using different conventions for new vs existing
code and I see no compelling reason to change the thousands of
lines of existing code to conform to a different convention.
What I'd like us to do is establish a convention to use for
variadic templates. The convention that makes the most sense
to me is one that builds on the existing convention for
ordinary (non-variadic) templates. Of the three choices that
I gave initially:
template <class _TypeT, class... _Types> // in type traits
template <class _HeadT, class... _TailT> // in tuple
template <class _TType, class... _UTypes> // in the spec
the one that fits the bill is the first one:
template <class _TypeT, class... _Types>
We can tweak the name of the parameter pack but I don't see
how we can change the name of the first parameter without
deviating from the current convention.
Furthermore, generic "Type" names should only be used in truly
generic contexts; i.e. contexts where just about any type can be
used. Otherwise, the name should imply the restrictions/requirements
on the type; e.g. _ScalarType, _IntConst. In the recursive tuple
case, using generic names would make the code much harder to follow
IMHO.
For the non-variadic case this is quite elegantly handled by
concepts. For example, the new variadic function template
std::min() currently declared in the working paper like so:
template <class T, ... Args>
const T& min (const T& a, const Args&... args);
becomes:
template <LessThanComparable T, LessThanComparable... Args>
requires SameType<T, Args...>
const T& min (const T& a , const Args&... args);
[...]
+template <int _Index, class ... _Types>
+_TYPENAME tuple_element<_Index, tuple<_Types...> >::type const&
The const should come before tuple_element.
For style? They are semantically equivalent though, aren't they?
BTW, this is how it is specified in the draft.
Yes, we discussed consistency at the last meeting. IIUC, the editor
is going to make the appropriate changes to bring the new text into
accord with the existing convention (i.e., change "T const&" to
"const T&").
Martin
