Re: [boost] Re: type_traits / is_compound

[Howard Hinnant]

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost