Proposed resolution:

This wording is relative to N4928.

1. Modify [iterator.concept.winc] as indicated:

   -3- The range of representable values of an integer-class type is the continuous set of values over which it is defined. For any integer-class type, its range of representable values is either -2^N-1 to 2^N-1 - 1 (inclusive) for some integer N, in which case it is a signed-integer-class type, or 0 to 2^N - 1 (inclusive) for some integer N, in which case it is an unsigned-integer-class type. In both cases, N is called the width of the integer-class type. The width of an integer-class type is greater than that of every standard integral type of the same signedness.

   […]

   -6- Expressions of integer-class type are explicitly convertible to any integer-like type, and implicitly convertible to any integral type or integer-class type of equal or greater width and the same signedness. Expressions of integral type are both implicitly and explicitly convertible to any integer-class type, and implicitly convertible to any integer-class type that can represent all values of the source type. Conversions between integral and integer-class types and between two integer-class types do not exit via an exception. The result of such a conversion is the unique value of the destination type that is congruent to the source modulo 2^N, where N is the width of the destination type.

[ 2023-03-22; Reflector poll ]

Set priority to 3 after reflector poll. "Proposed resolution is insufficient. A lot of the wording depends on the fact that the range of widths of integer-class types and that of integer types are disjoint. And it also disallows signed integer -> unsigned integer-class conversion and by extension mixed ops, which is seriously breaking (e.g., it disallows x += 1)."

Currently integer-class types are required to be wider than every integer type ([iterator.concept.winc]/3). As a result, if compiler provides extended integer types later whose width are not less than that of an integer-class type, then integer-class types with that width must be abandoned, which seems ABI-breaking (see also LWG 3828).

I think we should allow some extended integer types to be wider than some integer-class types.