[boost] Re: Type Traits, Take Two

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2000-01-08 14:04:26

John Maddock wrote on 1/8/2000 7:55 AM
>However - I worry about the complexity of type_traits and the number of
>templates we seem to have acquired - in particular is_integral duplicates
>numeric_limits<>::is_integral exactly - as implemented they are required to
>always give the same result.  Given that we are using section 3.9 as a
>guide could we not depreciate is_builtin_integral and make is_integral
>behave as is_builtin_integral does now?  As an asside I think with this
>change we could also remove the dependance on numeric_limits<> completely
>(without increase in code size), and in doing so improve portability -
>there does seem to be a problem with <limits> implementations in general.

I agree with this general sentiment.  I see different semantics between 
the type traits is_integral and the numeric_limits is_integral.

>OK now I'm going to throw in a radical idea - so feel free to shoot me
>down!!
>
>What if we bring back a type traits class as follows, which would be the
>only documented member of type_types.hpp:

<chuckle>  The circle is now complete. :-)

>Implementation would use a simplified form of our existing fundamentals
>(which could be moved into the implementation namespace) - I think there is
>an oportunity here both to reduce the amount of code, and the number of
>classes, and work around the arguments we've been having about whether a
>value can be called "type", and whether a cv-qualified int is an integral
>type or not.  On the other hand maybe not: I don't want to swap one lot of
>indecision for another :-)

I agree this does sidestep the value vs type issue.  But it does not 
sidestep the issue of whether cv-qualified types answer yes or no to 
is_type.  Either answer can be implemented in either design.  I still 
vote for cv-types answering yes to is_type (via either the separates or 
the enum design).

On code proliferation:  It seems to me that the trade off is a 
proliferation of structs vs a proliferation of enums.  Either works.  The 
interface seems to me to be about the same size either way.  You either 
have to remember the names of a bunch of structs:

is_pointer
is_reference
is_member_pointer
is_array
...

or the names of a bunch of enums:

is_pointer
is_reference
is_member_pointer
is_array
... 

So the question comes down to which has the best interface:

is_pointer<T>::value

or

type_traits<T>::category == is_pointer

I can easily imagine that either would be preferred by different 
individuals.

Personally I've grown fond of is_pointer<T>::value because it is less 
typing and fewer words to remember.  But my own first attempt at this 
stuff used enums much like you suggest.  And it worked fine.

I'm not positive, but the enum design may be easier to port to compilers 
lacking the latest template goodies.

-Howard