Return-Path: 
 <dev-return-7730-apmail-stdcxx-dev-archive=stdcxx.apache.org@stdcxx.apache.org>
Delivered-To: apmail-stdcxx-dev-archive@www.apache.org
Received: (qmail 823 invoked from network); 2 Jun 2008 20:14:42 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 2 Jun 2008 20:14:42 -0000
Received: (qmail 44377 invoked by uid 500); 2 Jun 2008 20:14:45 -0000
Delivered-To: apmail-stdcxx-dev-archive@stdcxx.apache.org
Received: (qmail 44363 invoked by uid 500); 2 Jun 2008 20:14:45 -0000
Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@stdcxx.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@stdcxx.apache.org>
List-Post: <mailto:dev@stdcxx.apache.org>
List-Id: <dev.stdcxx.apache.org>
Reply-To: dev@stdcxx.apache.org
Delivered-To: mailing list dev@stdcxx.apache.org
Received: (qmail 44352 invoked by uid 99); 2 Jun 2008 20:14:45 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Jun 2008 13:14:45 -0700
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: local policy)
Received: from [208.30.140.160] (HELO moroha.roguewave.com) (208.30.140.160)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Jun 2008 20:13:50 +0000
Received: from nebula.bco.roguewave.com ([10.70.3.27])
	by moroha.roguewave.com (8.13.6/8.13.6) with ESMTP id m52KEBJ2020479
	for <dev@stdcxx.apache.org>; Mon, 2 Jun 2008 20:14:11 GMT
Message-ID: <48445493.4080400@roguewave.com>
Date: Mon, 02 Jun 2008 14:14:11 -0600
From: Martin Sebor <sebor@roguewave.com>
Organization: Rogue Wave Software, Inc.
User-Agent: Thunderbird 2.0.0.12 (X11/20080226)
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>
 <48409378.3010407@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A499AA871@exchmail01.Blue.Roguewave.Com>
 <CFFDD219128FD94FB4F92B99F52D0A49010A37F5@exchmail01.Blue.Roguewave.Com>
In-Reply-To: 
 <CFFDD219128FD94FB4F92B99F52D0A49010A37F5@exchmail01.Blue.Roguewave.Com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org

Eric Lemings wrote:
>  
> 
>> -----Original Message-----
>> From: Travis Vitek [mailto:Travis.Vitek@roguewave.com] 
>> Sent: Friday, May 30, 2008 6:28 PM
>> To: dev@stdcxx.apache.org
>> Subject: RE: type_traits progress
>>
>>  
>>
>> 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?
>>
>>>> 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.
> 
> Yeah it looks like a typo to me too.  Should it be:
> 
> 	typedef __rw_integral_constant<T,v> type;
> 
> In all cases I've seen, `type' refers to type of self for identity
> properties.  This typedef would not hold up the identity property.

IIUC, for every specialization X of integral_constant, this
must hold:

   is_same<X, typename X::type>::value == true

With integral_constant derived from __rw_integral_constant
the condition would fail.

Martin