Travis Vitek wrote:
[...]
Right. That could be another wrinkle. Our traits won't
work with generic code that takes integral_constant<T, V>
by reference.
I don't really see the motivation, but it is obvious that the committee
thought it was important for the standard traits to do so, so we should
probably follow suit in our internal implementation.
If we did decide to do this then we would probably want our own write
__rw_integral_constant and use that internally to avoid namespace
pollution? Then I'd assume we'd want something like the following
example for is_const...
Yes, I think this is close to what we want. The only thing that bugs
me about it is...
template <class T, T v>
struct __rw_integral_constant
{
static const T value = v;
typedef T value_type;
typedef integral_constant<T,v> type;
...this backward dependency on integral_constant, but I don't see how
to break it without template typedefs. I don't think there's a compiler
out there that supports them yet.
};
template <class T>
struct __rw_is_const_impl
{
enum { _C_value = 0 };
};
template <class T>
struct __rw_is_const_impl<const T>
{
enum { _C_value = 1 };
};
template <class T>
struct __rw_is_const
: __rw_integral_constant<bool, __rw_is_const_impl<T>::_C_value>
{
};
template <class T, T v>
struct integral_constant : __rw_integral_constant<T,v>
{
};
template <class T>
struct is_const : integral_constant<bool, __rw_is_const<T>::value>
{
};
Another, and probably far more important reason for keeping the
names of the members the same, to make our implementation traits
look and feel like standard traits, i.e., conform to the traits
requirements. Otherwise the rest of our library won't be able
to easily use the private traits.
But this should only be an issue if we are passing around traits as
template parameters, right?
Right.
All of the scenerios I can think of we would be using
__rw_enable_if or
specialization on non-type template parameters. Can you think of any
case where the name of the member would be important?
I searched the latest draft standard to see if traits were
being used anywhere in the spec but didn't get any hits.
I hadn't thought too deeply about how the traits could be
used, but I have used traits outside of enable_if. I think
its should be easy to contrive code that wouldn't work with
our approach. Let me try:
// transforms T if it satisfies Property<T>
// by applying Transformer<T>, otherwise leaves
// T unchanged:
template <class T,
template <class> Property,
template <class> Transformer>
struct TransformIf;
Yes, if we go with the above approach then this problem just disappears
for any trait inheriting from __rw_integral_constant. For the other
types I can just expose the names that the standard defines.
I'm okay with that if you think that the motivation is there.
I'm not sure the contrived example I gave qualifies as a motivating
use case but it is a use case nonetheless. That said, I don't think
consistency with other uglified names is a compelling enough reason
for us to dismiss even this contrived use case.
Martin
