Why does a value of an enum with a fixed underlying type of char resolve to fct(int) instead of fct(char)?

Question

This problem came up when answering this question about overload resolution with enums.

While the case for long long was definitely a bug in MSVC2012Nov

Answer 1

In C++03, the rule was:

An rvalue of an unscoped enumeration type (7.2 [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 7.2 [dcl.enum]): int, unsigned int, long int, unsigned long int, long long int, or unsigned long long int.

In a C++03 compiler, int would be chosen because it is the first on the list.

---

In C++11, the underlying type was introduced. Accordingly, via 685. Integral promotion of enumeration ignores fixed underlying type , this wording was changed to the paragraph you quoted in §4.5/4 and from reading the defect report, it seems the intention of the committee was for fct(char) (the underlying type) to be chosen.

However, according to the discussion under core issue 1601, the text in C++11 actually makes the conversion ambiguous (fct(char) and fct(int) are both possible and neither is preferred).

The following fix was proposed and accepted into C++14:

A conversion that promotes an enumeration whose underlying type is fixed to its underlying type is better than one that promotes to the promoted underlying type, if the two are different.

Since it was reported as a defect in C++11, compilers should apply this fix when in C++11 mode and call fct(char).