Travis Vitek wrote:
>  
> 
> Martin Sebor wrote:
>> 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.
> 
> Can you think of a reason why this 'feature' would be important?

Derivation from integral_constant?

The original proposal explains the motivation for the base class:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1345.html

   There is one potential problem with integral constant members that
   should be raised: these require an out of line definition as well
   as an inline initialisation (but see issues 48 and 82). One
   implementation strategy that avoids the problem of having to provide
   lots of definitions for these static members, would be to have the
   traits classes inherit from a common base class:

   template <bool b> struct boolian_traits {
     static const bool value = b;
   };
   template <bool b> bool boolian_traits<b>::value;

   typedef boolian_traits<true> true_type;
   typedef boolian_traits<false> false_type;

   template <class T> struct is_void : public false_type {};
   template <> struct is_void<void> : public true_type {};

> 
>>> 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.
> 
> Actually, this was originally a typo on my part, but I do see where this
> is going. I haven't read about template typedefs, but it seems that
> there would be a serious problem caused by the cyclic dependency.

I don't know about serious but it does probably mean that we will
need to expose integral_constant among our private names and let
it "leak" into the std namespace wherever any of our private type
traits are used. Unless someone can come up with a way to avoid
it we might as well drop __rw_integral_constant and derive all
our private traits directly from integral_constant instead.


> 
>>> };
> 
>>>> 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.
>>
> 
> I'm starting to think that the above example is not motivating at all.
> There is no reason that any of our library code would ever need to use
> the public types because those types are just alternate names for the
> internal implmentation types. If we are writing code to be used in other
> parts of our implementation, then we would always use the internal _C_
> names.

That's true for the standard traits, but not for user-defined ones.
Of course, that would only be an issue in the unlikely event that
we decided to expose an interface where users could supply their
own traits. Still, I don't see any benefit in avoiding the standard
names, value and type, in our private traits. We'll just end up with
more of these names in our implementation than there already are.

Martin