Proposed resolution:

Add a new row to the table in [meta.trans.other]:

Table 41 -- Other transformations

Template	Condition	Comments
template< class T > struct enum_base;	T shall be an enumeration type ([dcl.enum])	The member typedef type shall name the underlying type of the enum T.

[ 2009-10 Santa Cruz: ]

NAD EditorialResolved. Solved by N2984.

[ Addressed in N2947. ]

[ 2009-05-23 Alisdair adds: ]

Just to confirm that the BSI originator of this comment assumed it did indeed imply a compiler intrinsic. Rather than request a Core extension, it seemed in keeping with that the type traits interface provides a library API to unspecified compiler features - where we require several other traits (e.g. has_trivial_*) to get the 'right' answer now, unlike in TR1.

[ Batavia (2009-05): ]

Pete observes (and Tom concurs) that the proposed resolution seems to require compiler support for its implementation, as it seems necessary to look at the range of values of the enumerated type. To a first approximation, a library solution could give an answer based on the size of the type. If the user has specialized numeric_limits for the enumerated type, then the library might be able to do better, but there is no such requirement. Keep status as Open and solicit input from CWG.

Addresses UK 98 [CD1]

It would be useful to be able to determine the underlying type of an arbitrary enumeration type. This would allow safe casting to an integral type (especially needed for scoped enums, which do not promote), and would allow use of numeric_limits. In general it makes generic programming with enumerations easier.