4

I have found a possible contradiction in the working draft of standard C++. First I present the facts, and my question comes at the end.

When the integer conversion ranks are established, [conv.rank]/1.1 says

No two signed integer types [...] shall have the same integer conversion rank, even if they have the same representation.

[basic.fundamental]/8 says:

Type wchar_t is a distinct type that has an implementation-defined signed or unsigned integer type as its underlying type.

Finally, [conv.rank]/1.8:

The ranks of char8_t, char16_t, char32_t, and wchar_t shall equal the ranks of their underlying types ([basic.fundamental]).

In case that wchar_t be implemented as a signed integer type, it would have the same rank as its underlying type, which is a distinct type of some other integer type.

Thus, we have two different signed integer types with identical rank, in contradiction with [conv.rank]/1.1.

Is this an actual contradiction, or I am misunderstanding when two trivially copyable types are distinct types in C++?

Barry
  • 286,269
  • 29
  • 621
  • 977
pablo1977
  • 4,281
  • 1
  • 15
  • 41

1 Answers1

6

we have two different signed integer types

I see nowhere in the standard that it says that wchar_t is a "signed integer type". Or an "unsigned integer type". I see where it says that it is an "integer type":

Types bool, char, wchar_­t, char8_­t, char16_­t, char32_­t, and the signed and unsigned integer types are collectively called integral types. A synonym for integral type is integer type.

But the definition of "signed integer type" does not include wchar_t. That is, the standard clearly allows for the existence of "integer types" that are neither "signed integer types" nor "unsigned integer types".

And the statement from [conv.rank] does not apply to such types.

Nicol Bolas
  • 449,505
  • 63
  • 781
  • 982
  • Hm... That's possibly still problematic. Standard does not assign (un-)signedness to any of these types – technically, though, it's just not possible that they are neither signed nor unsigned. Do we have two differing definitions of '(un-)signedness'? – Aconcagua Mar 02 '21 at 02:04
  • 2
    @Aconcagua I have been convinced by Nicol Bolas, since it seems tht **signed integer types** and **unsigned integer types** are mere names of certain classes of integer types. The underlying type of `char8_t` is `unsigned char`, but the classification of `char8_t` is not **unsigned integer type**, but just another integer type. – pablo1977 Mar 02 '21 at 02:15
  • @Aconcagua: "*it's just not possible that they are neither signed nor unsigned*" Why not? If you forget the English language and just take the terms as specifically defined by the standard, then you're left with something like this: types A, B, C are X types, types D, E, F are Y types, and the types Q, R, and all X&Y types are Z types. Regardless of what words are used for X, Y and Z, if the standard does not define a *relationship* between them, then there is no relationship. – Nicol Bolas Mar 02 '21 at 02:28
  • I've been considering the implementation on concrete systems. At least on the ones we have today any such type *will* be either signed or unsigned. Actually I've been satisfied with @pablo1977 's comment already, though (see his `char8_t` example) ;) – Aconcagua Mar 02 '21 at 02:48
  • 1
    @Aconcagua 1)`char` 2)`unsigned char` 3)`signed char` can all be defined as different types. So actually I see it as a third type: *non-signedness*. – Robert Andrzejuk Mar 02 '21 at 09:35
  • 1
    @RobertAndrzejuk `char` is always defined as a different type of `unsignec char` and `signed char`. However, `char` always behave the same as `unsigned char` or well `signed char`. All integer types (excepting `bool`) behaves the same as some underlying ***unsigned or signed integer type***. However, being classified as ***signed or unsigned integer type*** or just left it out, it is just a matter of classification. – pablo1977 Mar 02 '21 at 14:27
  • @pablo1977 So a better name for it would be `anon-signdness` :-p – Robert Andrzejuk Mar 02 '21 at 14:30
  • @RobertAndrzejuk I agree. Perhaps the wording in standards is not the best. – pablo1977 Mar 02 '21 at 14:32