CWG251 [basic.fundamental] Can a signed/unsigned integer type, standard/extended integer type, or character type be cv-qualified?

[frederick-vs-ja]

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

Reference (section label): [basic.fundamental]

Link to reflector thread (if any):

Issue description:

[basic.fundamental] p12 currently specified cv-qualified versions of standard or extended floating-point types are also standard or extended types respectively. However, it seems that the several terms for integer types only refer to cv-unqualified versions, namely

• standard signed integer types,
• standard unsigned integer types, and
• character types.

It's unclear whether a cv-qualified version of an extended integer type is considered as an an extended integer type.

The issue mainly affects library specifications. E.g. if const int is not considered as a signed integer type, then std::cmp_equal<const int, const int>(42, 42) is ill-formed per [utility.intcmp] p1, while current implementations accept it.

A probably incorrect and undesired reading may be that const int is not considered as a standard signed integer type but can be considered as an extended signed integer type.

Suggested resolution:

[t3nsor]

I don't think const int could possibly be read as being an extended signed integer type under the current wording, since the extended signed integer types are defined as being a category of implementation-defined types, and const int obviously is not implementation-defined. But I agree that there does appear to be a gap in the wording.

[jensmaurer]

I think we're very clear that "standard integer type" is not cv-qualified, because it's built from an explicit list of cv-unqualified types. For extended integer types, it also seems clear that the ones described near the top of [basic.fundamental] are cv-unqualified because of [basic.type.qualifier] p1. If some of them were const-qualified, adding another "const" on top wouldn't deliver a distinct type.

https://eel.is/c++draft/utility.intcmp#1 needs fixing regardless (if const-qualified types are supposed to be supported), but that's an LWG concern.

[frederick-vs-ja]

I found that this is mainly a duplicate of CWG251 (except that "extended integer type" and "character type" were not core terms at that time).

If the inconsistency is intended, I guess we can close CWG251 as NAD.