CWG3146 [diff.expr] Missing Annex C entry for difference in usual arithmetic conversions for values of enumeration type

[hubert-reinterpretcast]

Full name of submitter (unless configured in github; will be published with the issue): Hubert Tong

Reference (section label): [diff.expr]

Link to reflector thread (if any): N/A

Issue description:

The resolution for FR-030 in WG 14 N3148 clarifies that, in the usual arithmetic conversions, C23 converts values of an enumeration type to the underlying type of the enumeration type. For an unscoped enumeration type whose underlying type is not fixed, C++ instead performs integral promotions (https://wg21.link/conv.prom#3) that do not rely upon the implementation's choice of underlying type as part of the usual arithmetic conversions.

Note: I suspect the C committee might want to change their integral promotion rules for enumeration types instead of their change to their usual arithmetic conversions.

Suggested resolution:

Add a new entry.
Affected subclause: 7.4 [expr.arith.conv]
Change: The usual arithmetic conversions differ, between C and C++, in the treatment of enumeration types with no fixed underlying type. In C++, values of such types are not specified as converting to the underlying type of the enumeration as part of the usual arithmetic conversions. Instead, integral promotions ([conv.prom]) based on the values of the enumeration ([dcl.enum]) are applied.
Rationale: Avoids the difference that can arise in C when replacing an enumeration constant in an expression with a cast of the same enumeration constant to the enumeration type. Allows C++ to treat an enumerator with behavior like that of int even while giving the enumerator the type of its enumeration.
Effect on original feature: Changes to semantics of well-defined feature. Some C expressions that have a dependence upon the implementation-defined underlying type of affected enumeration types will yield different results (as they would if a different underlying type is chosen by the C implementation).
[Example:

typedef enum { E0 } E;
static_assert(((E)E0 - 1 < 0) == (E0 - 1 < 0), "Must pass for C++");

The static_assert may fail in C. —end example]
Difficulty of converting: Programs must add explicit casts to the underlying type.
How widely used: Rare.

[jensmaurer]

Was WG14 alerted of this issue?

[jensmaurer]

@hubert-reinterpretcast , I don't understand what changes in C because of the explicit cast being present vs. looking at the "pure" enumerator. The "pure" enumerator has some integral type in C (was: "always int").

[hubert-reinterpretcast]

Was WG14 alerted of this issue?

Which aspect? The change they made aligns with at least Clang and GCC. I have not mentioned to them the possibility of them updating their integer promotions (which also aligns with implementations) instead.

[hubert-reinterpretcast]

@hubert-reinterpretcast , I don't understand what changes in C because of the explicit cast being present vs. looking at the "pure" enumerator. The "pure" enumerator has some integral type in C (was: "always int").

In C, (E)E0 may, during the usual arithmetic conversions, be converted to unsigned whereas E0 already is of type int.

[hubert-reinterpretcast]

I have not mentioned to them the possibility of them updating their integer promotions (which also aligns with implementations) instead.

It appears that updating C's integer promotions does not obviate the need for their update to the usual arithmetic conversions because their integer promotions do not apply to enumeration types with rank greater than that of int.

The outcome for C++ is that the Annex C entry for the usual arithmetic conversions makes sense to have even though another Annex C entry for the integer promotions may be in order once the dust settles.

[hubert-reinterpretcast]

because their integer promotions do not apply to enumeration types with rank greater than that of int

I'm not sure how to observe the difference aside from using the text of diagnostics, but it seems Clang and GCC don't respect the above.

[hubert-reinterpretcast]

I'm not sure how to observe the difference aside from using the text of diagnostics, but it seems Clang and GCC don't respect the above.

I've informed the C committee that they probably want to change their integer promotions for enumerated types to align either with C implementations like Clang and GCC or with C++.

[jensmaurer]

CWG3146