Rationale:

2008-9-16 San Francisco: Issue pulled by author prior to being reviewed by the LWG.

Proposed resolution:

Add the following to the synopsis in [meta.type.synop] under "other transformations":

template< class T > struct direct_base_class;
template< class T > struct direct_derived_class;
template< class T > struct root_base_class;

Add three new entries to table 51 ([meta.trans.other]) with the following content

Template	Condition	Comments
template< class T > struct direct_base_class;	T shall be a complete type.	The member typedef type shall equal the accessible unambiguous direct base class of T. If no such type exists, the member typedef type shall equal T.
template< class T > struct direct_derived_class;	T shall be a complete type.	The member typedef type shall equal the unambiguous type which has T as an accessible unambiguous direct base class. If no such type exists, the member typedef type shall equal T.
template< class T > struct root_base_class;	T shall be a complete type.	The member typedef type shall equal the accessible unambiguous most indirect base class of T. If no such type exists, the member typedef type shall equal T.

The type traits library contains various traits to dealt with polymorphic types, e.g. std::has_virtual_destructor, std::is_polymorphic and std::is_base_of. However, there is no way to compute the unique public base class of a type if such one exists. Such a trait could be very useful if one needs to instantiate a specialization made for the root class whenever a derived class is passed as parameter. For example, imagine that you wanted to specialize std::hash for a class hierarchy---instead of specializing each class, you could specialize the std::hash<root_class> and provide a partial specialization that worked for all derived classes.

This ability---to specify operations in terms of their equivalent in the root class---can be done with e.g. normal functions, but there is, AFAIK, no way to do it for class templates. Being able to access compile-time information about the type-hierachy can be very powerful, and I therefore also suggest traits that computes the directly derived class whenever that is possible.

If the computation can not be done, the traits should fall back on an identity transformation. I expect this gives the best overall usability.