Proposed resolution (April, 2021):

1. Change 6.8.2 [basic.fundamental] paragraphs 11 and 12 as follows, splitting paragraph 12 as indicated:

Types bool, char, wchar_t, char8_t, char16_t, char32_t, and the signed and unsigned integer types, and cv-qualified versions (6.8.5 [basic.type.qualifier]) thereof, are collectively called termed integral types. A synonym for integral type is integer type. [Note 8: Enumerations (9.7.1 [dcl.enum]) are not integral; however, unscoped enumerations can be promoted to integral types as specified in 7.3.7 [conv.prom]. —end note]

There are three floating-point types: The three distinct types float, double, and long double can represent floating-point numbers. The type double provides at least as much precision as float, and the type long double provides at least as much precision as double. The set of values of the type float is a subset of the set of values of the type double; the set of values of the type double is a subset of the set of values of the type long double. The types float, double, and long double, and cv-qualified versions (6.8.5 [basic.type.qualifier]) thereof, are collectively termed floating-point types. The value representation of floating-point types is implementation-defined. [Note 9: This document imposes no requirements on the accuracy of floating-point operations; see also 17.3 [support.limits]. —end note]

Integral and floating-point types are collectively called termed arithmetic types. Specializations of the standard library template std::numeric_limits (17.3 [support.limits]) shall specify the maximum and minimum values of each arithmetic type for an implementation.

2. Change 6.8.5 [basic.type.qualifier] paragraph 1 as follows, splitting the paragraph as indicated:

A type mentioned in 6.8.2 [basic.fundamental] and 6.8.4 [basic.compound] is a cv-unqualified type. Each type which is a cv-unqualified object type or is void (6.8 [basic.types]) has three corresponding cv-qualified versions of its type other than a function or reference type is part of a group of four distinct, but related, types: a cv-unqualified version, a const-qualified version, a volatile-qualified version, and a const-volatile-qualified version. The type of an object (6.7.2 [intro.object]) includes the cv-qualifiers specified in the decl-specifier-seq (9.2 [dcl.spec]), declarator (9.3 [dcl.decl]), type-id (9.3.2 [dcl.name]), or new-type-id (7.6.2.8 [expr.new]) when the object is created. The types in each such group shall have the same representation and alignment requirements (6.7.6 [basic.align]). [Footnote: The same representation and alignment requirements are meant to imply interchangeability as arguments to functions, return values from functions, and non-static data members of unions. —end footnote] A function or reference type is always cv-unqualified.

• A const object is an object of type const T or a non-mutable subobject of a const object.

• A volatile object is an object of type volatile T or a subobject of a volatile object.

• A const volatile object is an object of type const volatile T, a non-mutable subobject of a const volatile object, a const subobject of a volatile object, or a non-mutable volatile subobject of a const object.

The cv-qualified or cv-unqualified versions of a type are distinct types; however, they shall have the same representation and alignment requirements (6.7.6 [basic.align]).⁴⁰ [Note: The type of an object (6.7.2 [intro.object]) includes the cv-qualifiers specified in the decl-specifier-seq (9.2 [dcl.spec]), declarator (9.3 [dcl.decl]), type-id (9.3.2 [dcl.name]), or new-type-id (7.6.2.8 [expr.new]) when the object is created. —end note]

3. Change 12.5 [over.built] paragraphs 2-10 as follows:

In this subclause, the term promoted integral type is used to refer to those cv-unqualified integral types which are preserved by integral promotion (7.3.7 [conv.prom]) (including e.g. int and long but excluding e.g. char ). [Note 2: In all cases where a promoted integral type is required, an operand of unscoped enumeration type will be acceptable by way of the integral promotions. —end note]

In the remainder of this subclause, vq represents either volatile or no cv-qualifier.

For every pair (T, vq), where T is an a cv-unqualified arithmetic type other than bool or a cv-unqualified pointer to (possibly cv-qualified) object type, there exist candidate operator functions of the form

vq T& operator++(vq T&);
T operator++(vq T&, int);

For every pair (T, vq), where T is an arithmetic type other than bool, there exist candidate operator functions of the form

vq T& operator--(vq T&);
T operator--(vq T&, int);

For every pair (T, vq), where T is a cv-qualified or cv-unqualified object type, there exist candidate operator functions of the form

T*vq& operator++(T*vq&);
T*vq& operator--(T*vq&);
T*    operator++(T*vq&, int);
T*    operator--(T*vq&, int);

For every cv-qualified or cv-unqualified (possibly cv-qualified) object type T and for every function type T that has neither cv-qualifiers nor a ref-qualifier, there exist candidate operator functions of the form

T& operator*(T*);

For every function type T that does not have cv-qualifiers or a ref-qualifier, there exist candidate operator functions of the form

T& operator*(T*);

For every type T there exist candidate operator functions of the form

T* operator+(T*);

For every cv-unqualified floating-point or promoted integral type T, there exist candidate operator functions of the form

T operator+(T);
Tl operator-(T);

[Drafting note: Clause 21 [meta] regarding type traits appropriately handles cv-qualified and cv-unqualified types and does not require revision.]

Notes from the July, 2020 teleconference:

CWG felt that no changes should be made to 12.5 [over.built].

[Accepted as a DR at the June, 2021 meeting.]

According to the definitions in 6.8.2 [basic.fundamental], the arithmetic types include only the non-cv-qualified versions. In the taxonomy of fundamental types, the first mention of “cv-qualified versions of these types” is for scalar types (6.8 [basic.types] paragraph 9). However, 7.6.1.6 [expr.post.incr] paragraph 1 and 7.6.2.3 [expr.pre.incr] paragraph 1 both say:

The type of the operand shall be an arithmetic type other than cv bool, or...

which is a contradiction, since cv-qualified bool is not an arithmetic type. Similarly, 7.6.19 [expr.ass] paragraph 6 requires an arithmetic type for += and -=. D.4 [depr.volatile.type] deprecates the increment and decrement operators when applied to volatile-qualified arithmetic types, but the wording already made those ill-formed (since the normative wording requires an arithmetic type and not a possibly cv-qualified version thereof).

A related question is whether 12.5 [over.built], which explicitly allows for cv-qualified arithmetic types, should also note the deprecation.

See also issue 2185.