This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Resolved status.
Section: 21.3.8.7 [meta.trans.other] Status: Resolved Submitter: Alisdair Meredith Opened: 2009-03-12 Last modified: 2016-01-28
Priority: Not Prioritized
View all other issues in [meta.trans.other].
View all issues with Resolved status.
Discussion:
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.
[ 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.
[ 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.
[ Addressed in N2947. ]
[ 2009-10 Santa Cruz: ]
NAD EditorialResolved. Solved by N2984.
Proposed resolution:
Add a new row to the table in 21.3.8.7 [meta.trans.other]:
Table 41 -- Other transformations Template Condition Comments template< class T > struct enum_base; T shall be an enumeration type (9.7.1 [dcl.enum]) The member typedef type shall name the underlying type of the enum T.