Title
Integral promotion of enumeration ignores fixed underlying type
Status
cd2
Section
7.3.7 [conv.prom]
Submitter
Alberto Ganesh Barbati

Created on 2008-01-06.00:00:00 last changed 179 months ago

Messages

Date: 2009-07-15.00:00:00

[Voted into WP at July, 2009 meeting.]

Date: 2008-08-15.00:00:00

Proposed resolution (August, 2008):

Move the following text from 7.3.7 [conv.prom] paragraph 2 into a separate paragraph, making the indicated changes, and add the following new paragraph after it:

An rvalue of an unscoped enumeration type whose underlying type is not fixed (9.7.1 [dcl.enum]) can be converted to an rvalue of the first of the following types that can represent all the values of the enumeration (i.e. the values in the range bmin to bmax as described in 9.7.1 [dcl.enum]): int, unsigned int, long int, unsigned long int, long long int, or unsigned long long int. If none of the types in that list can represent all the values of the enumeration, an rvalue of an unscoped enumeration type can be converted to an rvalue of the extended integer type with lowest integer conversion rank (7.3.15 [conv.bool]) greater than the rank of long long in which all the values of the enumeration can be represented. If there are two such extended types, the signed one is chosen.

An rvalue of an unscoped enumeration type whose underlying type is fixed (9.7.1 [dcl.enum]) can be converted to an rvalue of its underlying type. Moreover, if integral promotion can be applied to its underlying type, an rvalue of an unscoped enumeration type whose underlying type is fixed can also be converted to an rvalue of the promoted underlying type.

Date: 2008-06-29.00:00:00

According to 7.3.7 [conv.prom] paragraph 2,

An rvalue of an unscoped enumeration type (9.7.1 [dcl.enum]) can be converted to an rvalue of the first of the following types that can represent all the values of the enumeration (i.e. the values in the range bmin to bmax as described in 9.7.1 [dcl.enum]): int, unsigned int, long int, unsigned long int, long long int, or unsigned long long int.

This wording may have surprising behavior in this case:

    enum E: long { e };

    void f(int);
    void f(long);

    void g() {
        f(e);    // Which f is called?
    }

Intuitively, as the programmer has explicitly expressed preference for long as the underlying type, he/she might expect f(long) to be called. However, if long and int happen to have the same size, then e is promoted to int (as it is the first type in the list that can represent all values of E) and f(int) is called instead.

According to 9.7.1 [dcl.enum] the underlying type of an enumeration is always well-defined for both the fixed and the non-fixed cases, so it makes sense simply to promote to the underlying type unless such a type would itself require promotion.

Suggested resolution:

In 7.3.7 [conv.prom] paragraph 2, replace all the text from “An rvalue of an unscoped enumeration type” through the end of the paragraph with the following:

An rvalue of an unscoped enumeration type (9.7.1 [dcl.enum]) is converted to an rvalue of its underlying type if it is different from char16_t, char32_t, wchar_t, or has integer conversion rank greater than or equal to int. Otherwise, it is converted to an rvalue of the first of the following types that can represent all the values of its underlying type: int, unsigned int, long int, unsigned long int, long long int, or unsigned long long int.

(Note that this wording no longer needs to mention extended integer types as special cases.)

History
Date User Action Args
2010-03-29 00:00:00adminsetstatus: wp -> cd2
2009-11-08 00:00:00adminsetstatus: dr -> wp
2009-08-03 00:00:00adminsetmessages: + msg2227
2009-08-03 00:00:00adminsetstatus: ready -> dr
2009-03-23 00:00:00adminsetstatus: review -> ready
2008-08-25 00:00:00adminsetmessages: + msg1748
2008-08-25 00:00:00adminsetstatus: drafting -> review
2008-06-29 00:00:00adminsetstatus: open -> drafting
2008-01-06 00:00:00admincreate