[v3] ext/type_traits.h

[Paolo Carlini]

Hi Howard,

>> Ah, yes, as far as __add_signed and __remove_signed are concerned,  
>> the ellipsis can be removed, no additional specializations are  
>> needed, AFAICS (well, at some point we'll get compiler support for  
>> the traits, then no specializations at all ;)
>
>
> So __add_signed<unsigned char>::type is unsigned char
> So __add_signed<unsigned int>::type is unsigned int
>
> ?
>
> In the use cases I've personally been involved with, I had an  
> integral type T which could be either signed or unsigned, and I  
> needed to get its unsigned counterpart (or signed counterpart).   
> Actually the former (unsigned counterpart) was my more common need.   
> Having to spell that typename __add_unsigned<typename  
> __remove_signed<T>::type>::type seems cumbersome.
>
> Are there use cases for __add_signed, as opposed to __to_signed?  If  
> all it operates on is char (non-identity operation) I'm having  
> trouble coming up motivation for its existence.

I see. All in all, I'm coming to think that, whereas __add_signed & co 
make perfect sense to me *as implementation details* probably the 
eventual __to_signed and __to_unsigned make much more sense to the users 
of the library (or elsewhere in the library itself as implementation aids).

In short, if you ask me, I agree with you, I would try to finalize from 
the C++0x point of view something like __to_signed and __to_unsigned.

Paolo.