This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 117a. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2025-04-13
[Voted into WP at October, 2009 meeting.]
A number of the operators described in Clause 7 [expr] take operands of enumeration type, relying on the “usual arithmetic conversions” (Clause 7 [expr] paragraph 10) to convert them to an appropriate integral type. The assumption behind this pattern is invalid when one or more of the operands has a scoped enumeration type.
Each operator that accepts operands of enumeration type should be evaluated as to whether the operation makes sense for scoped enumerations (for example, it is probably a good idea to allow comparison of operands having the same scoped enumeration type and conditional expressions in which the second and third operands have the same scoped enumeration type) and, if so, create a special case. The usual arithmetic conversions should not be invoked for scoped enumeration types.
(See also issue 880.)
Proposed resolution (July, 2009):
Change Clause 7 [expr] paragraph 10 as follows:
...This pattern is called the usual arithmetic conversions, which are defined as follows:
If either operand is of type long double...
Change 7.6.1.2 [expr.sub] paragraph 1 as follows:
...One of the expressions shall have the type “pointer to T” and the other shall have enumeration or integral type...
Change 7.6.2 [expr.unary] paragraphs 7-8 and 10 as follows:
The operand of the unary + operator shall have arithmetic, enumeration, or pointer type...
The operand of the unary - operator shall have arithmetic or enumeration type...
The operand of ~ shall have integral or enumeration type...
Change 7.6.2.8 [expr.new] paragraph 6 as follows:
...The expression in a noptr-new-declarator shall be of integral type, enumeration type, or a class type for which a single non-explicit conversion function to integral or enumeration type exists (11.4.8 [class.conv]). If the expression...
Change 7.6.5 [expr.mul] paragraph 2 as follows:
The operands of * and / shall have arithmetic or enumeration type; the operands of % shall have integral or enumeration type....
Change 7.6.6 [expr.add] paragraph 1-2 as follows:
...For addition, either both operands shall have arithmetic or enumeration type, or one operand shall be a pointer to a completely-defined effective object type and the other shall have integral or enumeration type.
For subtraction, one of the following shall hold:
both operands have arithmetic or enumeration type; or
both operands are pointers to cv-qualified or cv-unqualified versions of the same completely-defined effective object type; or
the left operand is a pointer to a completely-defined effective object type and the right operand has integral or enumeration type.
Change 7.6.7 [expr.shift] paragraph 1 as follows:
...The operands shall be of integral or enumeration type...
Change 7.6.9 [expr.rel] paragraph 4 as follows:
If both operands (after conversions) are of arithmetic type, each of the operators shall yield true if the specified relationship is true and false if it is false.
Change 7.6.11 [expr.bit.and] paragraph 1 as follows:
...The operator applies only to integral or enumeration operands.
Change 7.6.12 [expr.xor] paragraph 1 as follows:
...The operator applies only to integral or enumeration operands.
Change 7.6.13 [expr.or] paragraph 1 as follows:
...The operator applies only to integral or enumeration operands.