Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (athena.apache.org: domain of msebor@gmail.com designates
 66.249.82.237 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:organization:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:sender;
        b=GXK7TIJ3Y6iS8GmrtbpTLtJy3+wo4d8Tyr/8PQUvB8j1cl/aKJl0JcfIEAyPnPsXsNYZQBLQ5/aO5U8oY3Rww/8r2EZ2KFWWhiCKK7lPNsLkZCi9DtlJDjI3Bxr773wkxOrVZCWinNSnsb1NZ97/tyq9Jm5yUBm+4MHuXBjQPrs=
Message-ID: <48409378.3010407@roguewave.com>
Date: Fri, 30 May 2008 17:53:28 -0600
From: Martin Sebor <sebor@roguewave.com>
Organization: Rogue Wave Software, Inc.
User-Agent: Thunderbird 2.0.0.14 (X11/20080501)
MIME-Version: 1.0
To: dev@stdcxx.apache.org
Subject: Re: type_traits progress
References: 
 <CFFDD219128FD94FB4F92B99F52D0A499AA862@exchmail01.Blue.Roguewave.Com>
 <483B79A1.4070808@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A499AA864@exchmail01.Blue.Roguewave.Com>
 <483C67BA.6070209@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A499AA86C@exchmail01.Blue.Roguewave.Com>
 <48401E00.2090709@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A499AA86D@exchmail01.Blue.Roguewave.Com>
In-Reply-To: 
 <CFFDD219128FD94FB4F92B99F52D0A499AA86D@exchmail01.Blue.Roguewave.Com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: Martin Sebor <msebor@gmail.com>

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