[Voted into WP at October, 2009 meeting.]

Proposed resolution (July, 2009):

1. 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 scoped enumeration type (9.7.1 [dcl.enum]), no conversions are performed, and if the other operand does not have the same type, the expression is ill-formed.

• If either operand is of type long double...

2. 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 unscoped enumeration or integral type...

3. Change 7.6.2 [expr.unary] paragraphs 7-8 and 10 as follows:

The operand of the unary + operator shall have arithmetic, unscoped enumeration, or pointer type...

The operand of the unary - operator shall have arithmetic or unscoped enumeration type...

The operand of ~ shall have integral or unscoped enumeration type...

4. Change 7.6.2.8 [expr.new] paragraph 6 as follows:

...The expression in a noptr-new-declarator shall be of integral type, unscoped enumeration type, or a class type for which a single non-explicit conversion function to integral or unscoped enumeration type exists (11.4.8 [class.conv]). If the expression...

5. Change 7.6.5 [expr.mul] paragraph 2 as follows:

The operands of * and / shall have arithmetic or unscoped enumeration type; the operands of % shall have integral or unscoped enumeration type....

6. Change 7.6.6 [expr.add] paragraph 1-2 as follows:

...For addition, either both operands shall have arithmetic or unscoped enumeration type, or one operand shall be a pointer to a completely-defined effective object type and the other shall have integral or unscoped enumeration type.

For subtraction, one of the following shall hold:

• both operands have arithmetic or unscoped 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 unscoped enumeration type.

7. Change 7.6.7 [expr.shift] paragraph 1 as follows:

...The operands shall be of integral or unscoped enumeration type...

8. Change 7.6.9 [expr.rel] paragraph 4 as follows:

If both operands (after conversions) are of arithmetic or enumeration type, each of the operators shall yield true if the specified relationship is true and false if it is false.

9. Change 7.6.11 [expr.bit.and] paragraph 1 as follows:

...The operator applies only to integral or unscoped enumeration operands.

10. Change 7.6.12 [expr.xor] paragraph 1 as follows:

...The operator applies only to integral or unscoped enumeration operands.

11. Change 7.6.13 [expr.or] paragraph 1 as follows:

...The operator applies only to integral or unscoped enumeration operands.

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