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 MSVC2012NovCTP (according to the standard text and a test with gcc 4.7.1), I cannot figure out why the following behavior occurs:

#include <iostream>  enum charEnum : char { A = 'A' };  void fct(char)      { std::cout << "fct(char)"      << std::endl; } void fct(int)       { std::cout << "fct(int)"       << std::endl; } void fct(long long) { std::cout << "fct(long long)" << std::endl; }  int main()  {     fct('A');     fct(A); } 

Both MSVC2012NovCTP and gcc 4.7.1 agree on this output:

fct(char)
fct(int)

Shouldn't A be converted from charEnum to char? Why is A being converted to int?

EDIT: clang complains that the call is ambiguous, which agrees with my interpretation below; that said, I would still find it much more intuitive if it were only considered to be the underlying type.

---

Two relevant standard excerpts are §7.2/9:

The value of an enumerator or an object of an unscoped enumeration type is converted to an integer by integral promotion (4.5)

And §4.5/4:

A prvalue of an unscoped enumeration type whose underlying type is fixed (7.2) can be converted to a prvalue of its underlying type. Moreover, if integral promotion can be applied to its underlying type, a prvalue of an unscoped enumeration type whose underlying type is fixed can also be converted to a prvalue of the promoted underlying type.

So charEnum can either be converted to char, or any integral promotion of char, such as int.

But this is vague to me because "can" doesn't quite say which will actually be chosen. If anything, this should be ambiguous with this wording because no preference is given between char or any of its promotions. If you comment out fct(int), then the call is ambiguous. Why is int special?

The only thing I can think of is that integral promotions are applied recursively, but nothing I see mandates it.

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).