Re: [boost] Fwd: Re: Is const int a signed integer type?

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2000-10-21 12:18:25

I stated and lost this argument nearly a year ago.  But as the subject 
has resurfaced, I'll restate it for the benefit of those that were not 
involved in the discussions at that time:

There are (or should be) 10 fundamental classifications:

is_integral
is_floating
is_void
is_pointer
is_reference
is_member_pointer
is_array
is_enum
is_union
is_class

These correspond to the text in section 3.9 of the standard.  In my 
opinion, any type that one can generate, you should be able to throw at 
these ten structs and have it test positive for one and only one test.  
Admittedly, is_enum and and is_union will not work without either 
compiler help, or extra attention from client code.

The fact that top level const is stripped off during template argument 
deduction is not really pertinent to the discussion as these 
classification structs could be very useful in meta-programming where 
template argument deduction often does not play a role.

I don't claim to be insightful enough to be able to foresee all (any?) of 
the applications where these structs might be useful.  I have found a few 
of them useful in my own work (mainly is_reference where top-level const 
is not a concern anyway).

The way I read the standard, const int (or int* const) is an integral 
type (or pointer type) that happens to be const, and so is_integral<const 
int> (is_pointer<int*const>) should answer true.  The standards 
committee* agrees that const int is an integral type (but of course has 
no opinion on what boost:is_integral should do).

[Footnote*  If Mike Miller says it is so, you can take it to the bank.]

A possible alternative would be to expand the base set:

is_integral
is_const_integral
is_volatile_integral
is_const_volatile_integral
is_pointer
is_const_ pointer
is_volatile_ pointer
is_const_volatile_ pointer
etc...

That way you could still be able to say:  Throw your type at this set of 
classification structs and one and only one will answer true.  But this 
seems overly verbose to me when we could instead simply say (for example)

is_integral && is_const, instead of is_const_integral

FWIW, I feel the same way about is_extension and is_signed.  I'd rather 
see:

is_integral && is_signed rather than is_signed_integral
and
is_integral && is_extension rather than is_extension_integral
and
is_integral && is_signed && is_extension rather than 
is_extension_signed_integral
and etc.

Of course one can get where you need to go with either design.  So this 
is purely a stylistic argument, not one of functionality.  I personally 
feel that the interface is simpler and easier to remember with fewer 
non-combination names that can be combined with && (or || etc.) as needed.

-Howard