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