Re: [boost] Re: type_traits / is_compound

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2002-12-17 13:35:01

On Tuesday, December 17, 2002, at 11:54  AM, Daniel Frey wrote:

> It might be useful to distinguish classes into unions and non-unions,
> but the standard clearly says that a union *is* a class (9/1).

The standard also "clearly" says that unions and classes are different 
categories of types (3.9.2/1). ;-)

I think it is most clear that the standard authors did not anticipate 
the type traits library, or if they did, simply had much bigger issues 
to work on at the time.

> It seems
> that it makes sense to detect unions,

Yes, very much so.  You can derive from classes, but you can not derive 
from unions (9.5/1).  Traits such as is_empty rely on being able to 
differentiate classes and unions because of this.

> but AFAIK it's not possible to do
> this automatically.

Agreed.

> It requires the user to tell us about all unions,
> which is dangerous if we rely on the detection of unions.

Agreed.

> Maybe we
> should go for this way:
>
> - is_class detects classes, structs and unions automatically
> - is_union detects unions with the help from the user
>
> If you really need a 'real class' or struct, you test for (is_class &&
> !is_union). Or we could create another helpers like is_non_union.
> Thoughts?

As the type traits library is currently a proposal before the standards 
committee, imho we need to be *very* clear about the interface.  And we 
need to specify the interface that will be most beneficial to the 
generations of C++ programmers to come, even if that interface is not 
implementable in C++98.  Already C++ compilers are coming to market in 
which is_union *is* implementable via extensions (Metrowerks Pro 8 for 
example).

I strongly feel that is_class answers yes to classes and structs and no 
to unions.  And is_union should answer yes only to unions.  This is the 
best interface and is consistent with section 3.9 of the standard 
(which was used to design the type traits library).  The fact that it 
can not currently be portably implemented is simply an unfortunate 
circumstance that will (hopefully) become less true in the near future.

-Howard