[basic.types] - C++20 → C++23

Files changed (1) hide show

tmp/tmp8hw1cylt/{from.md → to.md} +264 -137

tmp/tmp8hw1cylt/{from.md → to.md} RENAMED Viewed

@@ -1,20 +1,23 @@
 ## Types <a id="basic.types">[[basic.types]]</a>
 [*Note 1*:  [[basic.types]] and the subclauses thereof impose
 requirements on implementations regarding the representation of types.
 There are two kinds of types: fundamental types and compound types.
 Types describe objects [[intro.object]], references [[dcl.ref]], or
 functions [[dcl.fct]]. — *end note*]
 For any object (other than a potentially-overlapping subobject) of
 trivially copyable type `T`, whether or not the object holds a valid
 value of type `T`, the underlying bytes [[intro.memory]] making up the
 object can be copied into an array of `char`, `unsigned char`, or
-`std::byte` [[cstddef.syn]]. [^18] If the content of that array is
-copied back into the object, the object shall subsequently hold its
-original value.
 [*Example 1*:
 ``` cpp
 constexpr std::size_t N = sizeof(T);
@@ -24,15 +27,16 @@ std::memcpy(buf, &obj, N);      // between these two calls to std::memcpy, obj m
 std::memcpy(&obj, buf, N);      // at this point, each subobject of obj of scalar type holds its original value
 ```
 — *end example*]
-For any trivially copyable type `T`, if two pointers to `T` point to
-distinct `T` objects `obj1` and `obj2`, where neither `obj1` nor `obj2`
-is a potentially-overlapping subobject, if the underlying bytes
-[[intro.memory]] making up `obj1` are copied into `obj2`,[^19] `obj2`
-shall subsequently hold the same value as `obj1`.
 [*Example 2*:
 ``` cpp
 T* t1p;
@@ -51,32 +55,38 @@ The *object representation* of an object of type `T` is the sequence of
 `T` is the set of bits that participate in representing a value of type
 `T`. Bits in the object representation that are not part of the value
 representation are *padding bits*. For trivially copyable types, the
 value representation is a set of bits in the object representation that
 determines a *value*, which is one discrete element of an
-*implementation-defined* set of values.[^20]
 A class that has been declared but not defined, an enumeration type in
 certain contexts [[dcl.enum]], or an array of unknown bound or of
-incomplete element type, is an *incompletely-defined object type*. [^21]
 Incompletely-defined object types and cv `void` are *incomplete types*
-[[basic.fundamental]]. Objects shall not be defined to have an
-incomplete type.
-A class type (such as “`class X`”) might be incomplete at one point in a
 translation unit and complete later on; the type “`class X`” is the same
-type at both points. The declared type of an array object might be an
 array of incomplete class type and therefore incomplete; if the class
 type is completed later on in the translation unit, the array type
 becomes complete; the array type at those two points is the same type.
-The declared type of an array object might be an array of unknown bound
 and therefore be incomplete at one point in a translation unit and
 complete later on; the array types at those two points (“array of
-unknown bound of `T`” and “array of `N` `T`”) are different types. The
-type of a pointer to array of unknown bound, or of a type defined by a
-`typedef` declaration to be an array of unknown bound, cannot be
-completed.
 [*Example 3*:
 ``` cpp
 class X;                        // X is an incomplete type
@@ -87,28 +97,28 @@ UNKA* arrp;                     // arrp is a pointer to an incomplete type
 UNKA** arrpp;
 void foo() {
   xp++;                         // error: X is incomplete
   arrp++;                       // error: incomplete type
-  arrpp++;                      // OK: sizeof UNKA* is known
 }
 struct X { int i; };            // now X is a complete type
 int  arr[10];                   // now the type of arr is complete
 X x;
 void bar() {
   xp = &x;                      // OK; type is ``pointer to X''
-  arrp = &arr;                  // error: different types
-  xp++;                         // OK:  X is complete
   arrp++;                       // error: UNKA can't be completed
 }
 ```
 — *end example*]
-[*Note 2*: The rules for declarations and expressions describe in which
 contexts incomplete types are prohibited. — *end note*]
 An *object type* is a (possibly cv-qualified) type that is not a
 function type, not a reference type, and not cv `void`.
@@ -134,27 +144,30 @@ A type is a *literal type* if it is:
 - a reference type; or
 - an array of literal type; or
 - a possibly cv-qualified class type [[class]] that has all of the
   following properties:
   - it has a constexpr destructor [[dcl.constexpr]],
-  - it is either a closure type [[expr.prim.lambda.closure]], an
- aggregate type [[dcl.init.aggr]], or has at least one constexpr
-    constructor or constructor template (possibly inherited
- [[namespace.udecl]] from a base class) that is not a copy or move
- constructor,
-  - if it is a union, at least one of its non-static data members is of
-    non-volatile literal type, and
-  - if it is not a union, all of its non-static data members and base
-    classes are of non-volatile literal types.
-[*Note 3*: A literal type is one for which it might be possible to
 create an object within a constant expression. It is not a guarantee
 that it is possible to create such an object, nor is it a guarantee that
 any object of that type will be usable in a constant
 expression. — *end note*]
-Two types *cv1* `T1` and *cv2* `T2` are *layout-compatible* types if
 `T1` and `T2` are the same type, layout-compatible enumerations
 [[dcl.enum]], or layout-compatible standard-layout class types
 [[class.mem]].
 ### Fundamental types <a id="basic.fundamental">[[basic.fundamental]]</a>
@@ -190,32 +203,32 @@ arithmetic yields undefined behavior [[expr.pre]]. — *end note*]
 An unsigned integer type has the same object representation, value
 representation, and alignment requirements [[basic.align]] as the
 corresponding signed integer type. For each value x of a signed integer
 type, the value of the corresponding unsigned integer type congruent to
 x modulo 2ᴺ has the same value of corresponding bits in its value
-representation.[^22]
 [*Example 1*: The value -1 of a signed integer type has the same
 representation as the largest value of the corresponding unsigned
 type. — *end example*]
 **Table: Minimum width** <a id="basic.fundamental.width">[basic.fundamental.width]</a>
 | Type            | Minimum width $N$ |
-| ------------- | ----------------- |
 | `signed char`   | 8                 |
-| `short` | 16                |
 | `int`           | 16                |
-| `long` | 32                |
-| `long long` | 64                |
 The width of each signed integer type shall not be less than the values
 specified in [[basic.fundamental.width]]. The value representation of a
 signed or unsigned integer type comprises N bits, where N is the
 respective width. Each set of values for any padding bits
-[[basic.types]] in the object representation are alternative
 representations of the value specified by the value representation.
 [*Note 3*: Padding bits have unspecified value, but cannot cause traps.
 In contrast, see ISO C 6.2.6.2. — *end note*]
@@ -242,30 +255,25 @@ representation, alignment requirements [[basic.align]], and range of
 representable values as the underlying type. Further, each value has the
 same representation in both types.
 Type `char` is a distinct type that has an *implementation-defined*
 choice of “`signed char`” or “`unsigned char`” as its underlying type.
-The values of type `char` can represent distinct codes for all members
-of the implementation’s basic character set. The three types `char`,
-`signed char`, and `unsigned char` are collectively called *ordinary
-character types*. The ordinary character types and `char8_t` are
-collectively called *narrow character types*. For narrow character
-types, each possible bit pattern of the object representation represents
-a distinct value.
 [*Note 5*: This requirement does not hold for other
 types. — *end note*]
 [*Note 6*: A bit-field of narrow character type whose width is larger
 than the width of that type has padding bits; see
-[[basic.types]]. — *end note*]
 Type `wchar_t` is a distinct type that has an *implementation-defined*
-signed or unsigned integer type as its underlying type. The values of
-type `wchar_t` can represent distinct codes for all members of the
-largest extended character set specified among the supported locales
-[[locale]].
 Type `char8_t` denotes a distinct type whose underlying type is
 `unsigned char`. Types `char16_t` and `char32_t` denote distinct types
 whose underlying types are `uint_least16_t` and `uint_least32_t`,
 respectively, in `<cstdint>`.
@@ -276,58 +284,140 @@ value representation, and alignment requirements as an
 `bool` are `true` and `false`.
 [*Note 7*: There are no `signed`, `unsigned`, `short`, or `long bool`
 types or values. — *end note*]
-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*.
 [*Note 8*: Enumerations [[dcl.enum]] are not integral; however,
 unscoped enumerations can be promoted to integral types as specified in
 [[conv.prom]]. — *end note*]
-There are three *floating-point types*: `float`, `double`, and
-`long double`. 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
-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  [[support.limits]]. — *end note*]
-Integral and floating-point types are collectively called *arithmetic*
-types. Specializations of the standard library template
-`std::numeric_limits` [[support.limits]] shall specify the maximum and
-minimum values of each arithmetic type for an implementation.
 A type cv `void` is an incomplete type that cannot be completed; such a
 type has an empty set of values. It is used as the return type for
 functions that do not return a value. Any expression can be explicitly
-converted to type cv `void` ([[expr.type.conv]], [[expr.static.cast]],
-[[expr.cast]]). An expression of type cv `void` shall be used only as an
-expression statement [[stmt.expr]], as an operand of a comma expression
-[[expr.comma]], as a second or third operand of `?:` [[expr.cond]], as
-the operand of `typeid`, `noexcept`, or `decltype`, as the expression in
-a `return` statement [[stmt.return]] for a function with the return type
-cv `void`, or as the operand of an explicit conversion to type
-cv `void`.
 A value of type `std::nullptr_t` is a null pointer constant
 [[conv.ptr]]. Such values participate in the pointer and the
-pointer-to-member conversions ([[conv.ptr]], [[conv.mem]]).
 `sizeof(std::nullptr_t)` shall be equal to `sizeof(void*)`.
 The types described in this subclause are called *fundamental types*.
-[*Note 10*: Even if the implementation defines two or more fundamental
 types to have the same value representation, they are nevertheless
 different types. — *end note*]
 ### Compound types <a id="basic.compound">[[basic.compound]]</a>
 Compound types can be constructed in the following ways:
 - *arrays* of objects of a given type, [[dcl.array]];
@@ -343,17 +433,16 @@ Compound types can be constructed in the following ways:
   a set of types, enumerations and functions for manipulating these
   objects [[class.mfct]], and a set of restrictions on the access to
   these entities [[class.access]];
 - *unions*, which are classes capable of containing objects of different
   types at different times, [[class.union]];
-- *enumerations*, which comprise a set of named constant values. Each
-  distinct enumeration constitutes a different *enumerated type*,
   [[dcl.enum]];
-- *pointers to non-static class members*, [^23] which identify members
- of a given type within objects of a given class, [[dcl.mptr]].
- Pointers to data members and pointers to member functions are
- collectively called *pointer-to-member* types.
 These methods of constructing types can be applied recursively;
 restrictions are mentioned in  [[dcl.meaning]]. Constructing a type such
 that the number of bytes in its object representation exceeds the
 maximum value representable in the type `std::size_t` [[support.types]]
@@ -384,28 +473,29 @@ allowed although there are restrictions on what can be done with them
 - the *null pointer value* for that type, or
 - an *invalid pointer value*.
 A value of a pointer type that is a pointer to or past the end of an
 object *represents the address* of the first byte in memory
-[[intro.memory]] occupied by the object [^24] or the first byte in
-memory after the end of the storage occupied by the object,
-respectively.
 [*Note 2*: A pointer past the end of an object [[expr.add]] is not
-considered to point to an unrelated object of the object’s type that
-might be located at that address. A pointer value becomes invalid when
-the storage it denotes reaches the end of its storage duration; see
-[[basic.stc]]. — *end note*]
-For purposes of pointer arithmetic [[expr.add]] and comparison (
-[[expr.rel]], [[expr.eq]]), a pointer past the end of the last element
-of an array `x` of n elements is considered to be equivalent to a
-pointer to a hypothetical array element n of `x` and an object of type
-`T` that is not an array element is considered to belong to an array
-with one element of type `T`. The value representation of pointer types
-is *implementation-defined*. Pointers to layout-compatible types shall
-have the same value representation and alignment requirements
 [[basic.align]].
 [*Note 3*: Pointers to over-aligned types [[basic.align]] have no
 special representation, but their range of valid values is restricted by
 the extended alignment requirement. — *end note*]
@@ -414,13 +504,12 @@ Two objects *a* and *b* are *pointer-interconvertible* if:
 - they are the same object, or
 - one is a union object and the other is a non-static data member of
   that object [[class.union]], or
 - one is a standard-layout class object and the other is the first
-  non-static data member of that object, or, if the object has no
- non-static data members, any base class subobject of that object
-  [[class.mem]], or
 - there exists an object *c* such that *a* and *c* are
   pointer-interconvertible, and *c* and *b* are
   pointer-interconvertible.
 If two objects are pointer-interconvertible, then they have the same
@@ -429,48 +518,53 @@ the other via a `reinterpret_cast` [[expr.reinterpret.cast]].
 [*Note 4*: An array object and its first element are not
 pointer-interconvertible, even though they have the same
 address. — *end note*]
 A pointer to cv `void` can be used to point to objects of unknown type.
 Such a pointer shall be able to hold any object pointer. An object of
-type cv `void*` shall have the same representation and alignment
-requirements as cv `char*`.
 ### CV-qualifiers <a id="basic.type.qualifier">[[basic.type.qualifier]]</a>
-A type mentioned in  [[basic.fundamental]] and  [[basic.compound]] is a
-*cv-unqualified type*. Each type which is a cv-unqualified complete or
-incomplete object type or is `void` [[basic.types]] has three
-corresponding cv-qualified versions of its type: a *const-qualified*
-version, a *volatile-qualified* version, and a
-*const-volatile-qualified* version. The type of an object
-[[intro.object]] includes the *cv-qualifier*s specified in the
-*decl-specifier-seq* [[dcl.spec]], *declarator* [[dcl.decl]], *type-id*
-[[dcl.name]], or *new-type-id* [[expr.new]] when the object is created.
 - 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 [[basic.align]].[^25]
 Except for array types, a compound type [[basic.compound]] is not
 cv-qualified by the cv-qualifiers (if any) of the types from which it is
 compounded.
 An array type whose elements are cv-qualified is also considered to have
 the same cv-qualifications as its elements.
-[*Note 1*: Cv-qualifiers applied to an array type attach to the
 underlying element type, so the notation “cv `T`”, where `T` is an array
 type, refers to an array whose elements are so-qualified
 [[dcl.array]]. — *end note*]
 [*Example 1*:
@@ -485,12 +579,12 @@ const CA arr2 = { 0 };
 The type of both `arr1` and `arr2` is “array of 5 `const char`”, and the
 array type is considered to be const-qualified.
 — *end example*]
-[*Note 2*: See  [[dcl.fct]] and  [[class.this]] regarding function
-types that have *cv-qualifier*s. — *end note*]
 There is a partial ordering on cv-qualifiers, so that a type can be said
 to be *more cv-qualified* than another. [[basic.type.qualifier.rel]]
 shows the relations that constitute this ordering.
@@ -516,40 +610,73 @@ no top-level cv-qualifiers. The type corresponding to the *type-id*
 `volatile int * const` has the top-level cv-qualifier `const`. For a
 class type `C`, the type corresponding to the *type-id*
 `void (C::* volatile)(int) const` has the top-level cv-qualifier
 `volatile`. — *end example*]
-### Integer conversion rank <a id="conv.rank">[[conv.rank]]</a>
 Every integer type has an *integer conversion rank* defined as follows:
 - No two signed integer types other than `char` and `signed
-  char` (if `char` is signed) shall have the same rank, even if they
- have the same representation.
-- The rank of a signed integer type shall be greater than the rank of
- any signed integer type with a smaller width.
-- The rank of `long long int` shall be greater than the rank of
- `long int`, which shall be greater than the rank of `int`, which shall
- be greater than the rank of `short int`, which shall be greater than
-  the rank of `signed char`.
-- The rank of any unsigned integer type shall equal the rank of the
   corresponding signed integer type.
-- The rank of any standard integer type shall be greater than the rank
- of any extended integer type with the same width.
-- The rank of `char` shall equal the rank of `signed char` and
   `unsigned char`.
-- The rank of `bool` shall be less than the rank of all other standard
- integer types.
-- The ranks of `char8_t`, `char16_t`, `char32_t`, and `wchar_t` shall
- equal the ranks of their underlying types [[basic.fundamental]].
 - The rank of any extended signed integer type relative to another
   extended signed integer type with the same width is
   *implementation-defined*, but still subject to the other rules for
   determining the integer conversion rank.
 - For all integer types `T1`, `T2`, and `T3`, if `T1` has greater rank
-  than `T2` and `T2` has greater rank than `T3`, then `T1` shall have
- greater rank than `T3`.
 [*Note 1*: The integer conversion rank is used in the definition of the
 integral promotions [[conv.prom]] and the usual arithmetic conversions
 [[expr.arith.conv]]. — *end note*]

 ## Types <a id="basic.types">[[basic.types]]</a>
+### General <a id="basic.types.general">[[basic.types.general]]</a>
 [*Note 1*:  [[basic.types]] and the subclauses thereof impose
 requirements on implementations regarding the representation of types.
 There are two kinds of types: fundamental types and compound types.
 Types describe objects [[intro.object]], references [[dcl.ref]], or
 functions [[dcl.fct]]. — *end note*]
 For any object (other than a potentially-overlapping subobject) of
 trivially copyable type `T`, whether or not the object holds a valid
 value of type `T`, the underlying bytes [[intro.memory]] making up the
 object can be copied into an array of `char`, `unsigned char`, or
+`std::byte` [[cstddef.syn]].[^14]
+If the content of that array is copied back into the object, the object
+shall subsequently hold its original value.
 [*Example 1*:
 ``` cpp
 constexpr std::size_t N = sizeof(T);
 std::memcpy(&obj, buf, N);      // at this point, each subobject of obj of scalar type holds its original value
 ```
 — *end example*]
+For two distinct objects `obj1` and `obj2` of trivially copyable type
+`T`, where neither `obj1` nor `obj2` is a potentially-overlapping
+subobject, if the underlying bytes [[intro.memory]] making up `obj1` are
+copied into `obj2`,[^15]
+`obj2` shall subsequently hold the same value as `obj1`.
 [*Example 2*:
 ``` cpp
 T* t1p;
 `T` is the set of bits that participate in representing a value of type
 `T`. Bits in the object representation that are not part of the value
 representation are *padding bits*. For trivially copyable types, the
 value representation is a set of bits in the object representation that
 determines a *value*, which is one discrete element of an
+*implementation-defined* set of values.[^16]
 A class that has been declared but not defined, an enumeration type in
 certain contexts [[dcl.enum]], or an array of unknown bound or of
+incomplete element type, is an *incompletely-defined object type*.[^17]
 Incompletely-defined object types and cv `void` are *incomplete types*
+[[basic.fundamental]].
+[*Note 2*: Objects cannot be defined to have an incomplete type
+[[basic.def]]. — *end note*]
+A class type (such as “`class X`”) can be incomplete at one point in a
 translation unit and complete later on; the type “`class X`” is the same
+type at both points. The declared type of an array object can be an
 array of incomplete class type and therefore incomplete; if the class
 type is completed later on in the translation unit, the array type
 becomes complete; the array type at those two points is the same type.
+The declared type of an array object can be an array of unknown bound
 and therefore be incomplete at one point in a translation unit and
 complete later on; the array types at those two points (“array of
+unknown bound of `T`” and “array of `N` `T`”) are different types.
+[*Note 3*: The type of a pointer or reference to array of unknown bound
+permanently points to or refers to an incomplete type. An array of
+unknown bound named by a `typedef` declaration permanently refers to an
+incomplete type. In either case, the array type cannot be
+completed. — *end note*]
 [*Example 3*:
 ``` cpp
 class X;                        // X is an incomplete type
 UNKA** arrpp;
 void foo() {
   xp++;                         // error: X is incomplete
   arrp++;                       // error: incomplete type
+  arrpp++;                      // OK, sizeof UNKA* is known
 }
 struct X { int i; };            // now X is a complete type
 int  arr[10];                   // now the type of arr is complete
 X x;
 void bar() {
   xp = &x;                      // OK; type is ``pointer to X''
+  arrp = &arr;                  // OK; qualification conversion[conv.qual]
+  xp++;                         // OK, X is complete
   arrp++;                       // error: UNKA can't be completed
 }
 ```
 — *end example*]
+[*Note 4*: The rules for declarations and expressions describe in which
 contexts incomplete types are prohibited. — *end note*]
 An *object type* is a (possibly cv-qualified) type that is not a
 function type, not a reference type, and not cv `void`.
 - a reference type; or
 - an array of literal type; or
 - a possibly cv-qualified class type [[class]] that has all of the
   following properties:
   - it has a constexpr destructor [[dcl.constexpr]],
+  - all of its non-static non-variant data members and base classes are
+ of non-volatile literal types, and
+  - it
+ - is a closure type [[expr.prim.lambda.closure]],
+ - is an aggregate union type that has either no variant members or
+ at least one variant member of non-volatile literal type,
+ - is a non-union aggregate type for which each of its anonymous
+ union members satisfies the above requirements for an aggregate
+      union type, or
+    - has at least one constexpr constructor or constructor template
+      (possibly inherited [[namespace.udecl]] from a base class) that is
+      not a copy or move constructor.
+[*Note 5*: A literal type is one for which it might be possible to
 create an object within a constant expression. It is not a guarantee
 that it is possible to create such an object, nor is it a guarantee that
 any object of that type will be usable in a constant
 expression. — *end note*]
+Two types *cv1* `T1` and *cv2* `T2` are *layout-compatible types* if
 `T1` and `T2` are the same type, layout-compatible enumerations
 [[dcl.enum]], or layout-compatible standard-layout class types
 [[class.mem]].
 ### Fundamental types <a id="basic.fundamental">[[basic.fundamental]]</a>
 An unsigned integer type has the same object representation, value
 representation, and alignment requirements [[basic.align]] as the
 corresponding signed integer type. For each value x of a signed integer
 type, the value of the corresponding unsigned integer type congruent to
 x modulo 2ᴺ has the same value of corresponding bits in its value
+representation.[^18]
 [*Example 1*: The value -1 of a signed integer type has the same
 representation as the largest value of the corresponding unsigned
 type. — *end example*]
 **Table: Minimum width** <a id="basic.fundamental.width">[basic.fundamental.width]</a>
 | Type            | Minimum width $N$ |
+| --------------- | ----------------- |
 | `signed char`   | 8                 |
+| `short int` | 16                |
 | `int`           | 16                |
+| `long int` | 32                |
+| `long long int` | 64                |
 The width of each signed integer type shall not be less than the values
 specified in [[basic.fundamental.width]]. The value representation of a
 signed or unsigned integer type comprises N bits, where N is the
 respective width. Each set of values for any padding bits
+[[basic.types.general]] in the object representation are alternative
 representations of the value specified by the value representation.
 [*Note 3*: Padding bits have unspecified value, but cannot cause traps.
 In contrast, see ISO C 6.2.6.2. — *end note*]
 representable values as the underlying type. Further, each value has the
 same representation in both types.
 Type `char` is a distinct type that has an *implementation-defined*
 choice of “`signed char`” or “`unsigned char`” as its underlying type.
+The three types `char`, `signed char`, and `unsigned char` are
+collectively called *ordinary character types*. The ordinary character
+types and `char8_t` are collectively called *narrow character types*.
+For narrow character types, each possible bit pattern of the object
+representation represents a distinct value.
 [*Note 5*: This requirement does not hold for other
 types. — *end note*]
 [*Note 6*: A bit-field of narrow character type whose width is larger
 than the width of that type has padding bits; see
+[[basic.types.general]]. — *end note*]
 Type `wchar_t` is a distinct type that has an *implementation-defined*
+signed or unsigned integer type as its underlying type.
 Type `char8_t` denotes a distinct type whose underlying type is
 `unsigned char`. Types `char16_t` and `char32_t` denote distinct types
 whose underlying types are `uint_least16_t` and `uint_least32_t`,
 respectively, in `<cstdint>`.
 `bool` are `true` and `false`.
 [*Note 7*: There are no `signed`, `unsigned`, `short`, or `long bool`
 types or values. — *end note*]
+The types `char`, `wchar_t`, `char8_t`, `char16_t`, and `char32_t` are
+collectively called *character types*. The character types, `bool`, the
+signed and unsigned integer types, and cv-qualified versions
+[[basic.type.qualifier]] thereof, are collectively termed *integral
 types*. A synonym for integral type is *integer type*.
 [*Note 8*: Enumerations [[dcl.enum]] are not integral; however,
 unscoped enumerations can be promoted to integral types as specified in
 [[conv.prom]]. — *end note*]
+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 [[basic.type.qualifier]] thereof, are collectively
+termed *standard floating-point types*. An implementation may also
+provide additional types that represent floating-point values and define
+them (and cv-qualified versions thereof) to be *extended floating-point
+types*. The standard and extended floating-point types are collectively
+termed *floating-point types*.
+[*Note 9*: Any additional implementation-specific types representing
+floating-point values that are not defined by the implementation to be
+extended floating-point types are not considered to be floating-point
+types, and this document imposes no requirements on them or their
+interactions with floating-point types. — *end note*]
+Except as specified in [[basic.extended.fp]], the object and value
+representations and accuracy of operations of floating-point types are
 *implementation-defined*.
+Integral and floating-point types are collectively termed *arithmetic
+types*.
+[*Note 10*: Properties of the arithmetic types, such as their minimum
+and maximum representable value, can be queried using the facilities in
+the standard library headers `<limits>`, `<climits>`, and
+`<cfloat>`. — *end note*]
 A type cv `void` is an incomplete type that cannot be completed; such a
 type has an empty set of values. It is used as the return type for
 functions that do not return a value. Any expression can be explicitly
+converted to type cv `void`
+[[expr.type.conv]], [[expr.static.cast]], [[expr.cast]]. An expression
+of type cv `void` shall be used only as an expression statement
+[[stmt.expr]], as an operand of a comma expression [[expr.comma]], as a
+second or third operand of `?:` [[expr.cond]], as the operand of
+`typeid`, `noexcept`, or `decltype`, as the expression in a `return`
+statement [[stmt.return]] for a function with the return type cv `void`,
+or as the operand of an explicit conversion to type cv `void`.
 A value of type `std::nullptr_t` is a null pointer constant
 [[conv.ptr]]. Such values participate in the pointer and the
+pointer-to-member conversions [[conv.ptr]], [[conv.mem]].
 `sizeof(std::nullptr_t)` shall be equal to `sizeof(void*)`.
 The types described in this subclause are called *fundamental types*.
+[*Note 11*: Even if the implementation defines two or more fundamental
 types to have the same value representation, they are nevertheless
 different types. — *end note*]
+### Optional extended floating-point types <a id="basic.extended.fp">[[basic.extended.fp]]</a>
+If the implementation supports an extended floating-point type
+[[basic.fundamental]] whose properties are specified by the ISO/IEC/IEEE
+60559 floating-point interchange format binary16, then the
+*typedef-name* `std::float16_t` is defined in the header `<stdfloat>`
+and names such a type, the macro `__STDCPP_FLOAT16_T__` is defined
+[[cpp.predefined]], and the floating-point literal suffixes `f16` and
+`F16` are supported [[lex.fcon]].
+If the implementation supports an extended floating-point type whose
+properties are specified by the ISO/IEC/IEEE 60559 floating-point
+interchange format binary32, then the *typedef-name* `std::float32_t` is
+defined in the header `<stdfloat>` and names such a type, the macro
+`__STDCPP_FLOAT32_T__` is defined, and the floating-point literal
+suffixes `f32` and `F32` are supported.
+If the implementation supports an extended floating-point type whose
+properties are specified by the ISO/IEC/IEEE 60559 floating-point
+interchange format binary64, then the *typedef-name* `std::float64_t` is
+defined in the header `<stdfloat>` and names such a type, the macro
+`__STDCPP_FLOAT64_T__` is defined, and the floating-point literal
+suffixes `f64` and `F64` are supported.
+If the implementation supports an extended floating-point type whose
+properties are specified by the ISO/IEC/IEEE 60559 floating-point
+interchange format binary128, then the *typedef-name* `std::float128_t`
+is defined in the header `<stdfloat>` and names such a type, the macro
+`__STDCPP_FLOAT128_T__` is defined, and the floating-point literal
+suffixes `f128` and `F128` are supported.
+If the implementation supports an extended floating-point type with the
+properties, as specified by ISO/IEC/IEEE 60559, of radix (b) of 2,
+storage width in bits (k) of 16, precision in bits (p) of 8, maximum
+exponent (emax) of 127, and exponent field width in bits (w) of 8, then
+the *typedef-name* `std::bfloat16_t` is defined in the header
+`<stdfloat>` and names such a type, the macro `__STDCPP_BFLOAT16_T__` is
+defined, and the floating-point literal suffixes `bf16` and `BF16` are
+supported.
+[*Note 1*: A summary of the parameters for each type is given in
+[[basic.extended.fp]]. The precision p includes the implicit 1 bit at
+the beginning of the mantissa, so the storage used for the mantissa is
+p-1 bits. ISO/IEC/IEEE 60559 does not assign a name for a type having
+the parameters specified for `std::bfloat16_t`. — *end note*]
+**Table: Properties of named extended floating-point types** <a id="basic.extended.fp">[basic.extended.fp]</a>
+| Parameter                         | `float16_t` | `float32_t` | `float64_t` | `float128_t` | `bfloat16_t` |
+| --------------------------------- | ----------- | ----------- | ----------- | ------------ | ------------ |
+| ISO/IEC/IEEE 60559 name           | binary16    | binary32    | binary64    | binary128    |              |
+| $k$, storage width in bits        | 16          | 32          | 64          | 128          | 16           |
+| $p$, precision in bits            | 11          | 24          | 53          | 113          | 8            |
+| $emax$, maximum exponent          | 15          | 127         | 1023        | 16383        | 127          |
+| $w$, exponent field width in bits | 5           | 8           | 11          | 15           | 8            |
+*Recommended practice:* Any names that the implementation provides for
+the extended floating-point types described in this subsection that are
+in addition to the names defined in the `<stdfloat>` header should be
+chosen to increase compatibility and interoperability with the
+interchange types `_Float16`, `_Float32`, `_Float64`, and `_Float128`
+defined in ISO/IEC TS 18661-3 and with future versions of the C
+standard.
 ### Compound types <a id="basic.compound">[[basic.compound]]</a>
 Compound types can be constructed in the following ways:
 - *arrays* of objects of a given type, [[dcl.array]];
   a set of types, enumerations and functions for manipulating these
   objects [[class.mfct]], and a set of restrictions on the access to
   these entities [[class.access]];
 - *unions*, which are classes capable of containing objects of different
   types at different times, [[class.union]];
+- *enumerations*, which comprise a set of named constant values,
   [[dcl.enum]];
+- *pointers to non-static class members*,[^19] which identify members of
+  a given type within objects of a given class, [[dcl.mptr]]. Pointers
+  to data members and pointers to member functions are collectively
+  called *pointer-to-member* types.
 These methods of constructing types can be applied recursively;
 restrictions are mentioned in  [[dcl.meaning]]. Constructing a type such
 that the number of bytes in its object representation exceeds the
 maximum value representable in the type `std::size_t` [[support.types]]
 - the *null pointer value* for that type, or
 - an *invalid pointer value*.
 A value of a pointer type that is a pointer to or past the end of an
 object *represents the address* of the first byte in memory
+[[intro.memory]] occupied by the object[^20]
+or the first byte in memory after the end of the storage occupied by the
+object, respectively.
 [*Note 2*: A pointer past the end of an object [[expr.add]] is not
+considered to point to an unrelated object of the object’s type, even if
+the unrelated object is located at that address. A pointer value becomes
+invalid when the storage it denotes reaches the end of its storage
+duration; see [[basic.stc]]. — *end note*]
+For purposes of pointer arithmetic [[expr.add]] and comparison
+[[expr.rel]], [[expr.eq]], a pointer past the end of the last element of
+an array `x` of n elements is considered to be equivalent to a pointer
+to a hypothetical array element n of `x` and an object of type `T` that
+is not an array element is considered to belong to an array with one
+element of type `T`. The value representation of pointer types is
+*implementation-defined*. Pointers to layout-compatible types shall have
+the same value representation and alignment requirements
 [[basic.align]].
 [*Note 3*: Pointers to over-aligned types [[basic.align]] have no
 special representation, but their range of valid values is restricted by
 the extended alignment requirement. — *end note*]
 - they are the same object, or
 - one is a union object and the other is a non-static data member of
   that object [[class.union]], or
 - one is a standard-layout class object and the other is the first
+  non-static data member of that object or any base class subobject of
+ that object [[class.mem]], or
 - there exists an object *c* such that *a* and *c* are
   pointer-interconvertible, and *c* and *b* are
   pointer-interconvertible.
 If two objects are pointer-interconvertible, then they have the same
 [*Note 4*: An array object and its first element are not
 pointer-interconvertible, even though they have the same
 address. — *end note*]
+A byte of storage *b* is *reachable through* a pointer value that points
+to an object *x* if there is an object *y*, pointer-interconvertible
+with *x*, such that *b* is within the storage occupied by *y*, or the
+immediately-enclosing array object if *y* is an array element.
 A pointer to cv `void` can be used to point to objects of unknown type.
 Such a pointer shall be able to hold any object pointer. An object of
+type “pointer to cv `void`” shall have the same representation and
+alignment requirements as an object of type “pointer to cv `char`”.
 ### CV-qualifiers <a id="basic.type.qualifier">[[basic.type.qualifier]]</a>
+Each 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 types in each such group shall
+have the same representation and alignment requirements
+[[basic.align]].[^21]
+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.
+[*Note 1*: The type of an object [[intro.object]] includes the
+*cv-qualifier*s specified in the *decl-specifier-seq* [[dcl.spec]],
+*declarator* [[dcl.decl]], *type-id* [[dcl.name]], or *new-type-id*
+[[expr.new]] when the object is created. — *end note*]
 Except for array types, a compound type [[basic.compound]] is not
 cv-qualified by the cv-qualifiers (if any) of the types from which it is
 compounded.
 An array type whose elements are cv-qualified is also considered to have
 the same cv-qualifications as its elements.
+[*Note 2*: Cv-qualifiers applied to an array type attach to the
 underlying element type, so the notation “cv `T`”, where `T` is an array
 type, refers to an array whose elements are so-qualified
 [[dcl.array]]. — *end note*]
 [*Example 1*:
 The type of both `arr1` and `arr2` is “array of 5 `const char`”, and the
 array type is considered to be const-qualified.
 — *end example*]
+[*Note 3*: See  [[dcl.fct]] and  [[over.match.funcs]] regarding
+function types that have *cv-qualifier*s. — *end note*]
 There is a partial ordering on cv-qualifiers, so that a type can be said
 to be *more cv-qualified* than another. [[basic.type.qualifier.rel]]
 shows the relations that constitute this ordering.
 `volatile int * const` has the top-level cv-qualifier `const`. For a
 class type `C`, the type corresponding to the *type-id*
 `void (C::* volatile)(int) const` has the top-level cv-qualifier
 `volatile`. — *end example*]
+### Conversion ranks <a id="conv.rank">[[conv.rank]]</a>
 Every integer type has an *integer conversion rank* defined as follows:
 - No two signed integer types other than `char` and `signed
+  char` (if `char` is signed) have the same rank, even if they have the
+  same representation.
+- The rank of a signed integer type is greater than the rank of any
+  signed integer type with a smaller width.
+- The rank of `long long int` is greater than the rank of `long int`,
+  which is greater than the rank of `int`, which is greater than the
+  rank of `short int`, which is greater than the rank of `signed char`.
+- The rank of any unsigned integer type equals the rank of the
   corresponding signed integer type.
+- The rank of any standard integer type is greater than the rank of any
+  extended integer type with the same width.
+- The rank of `char` equals the rank of `signed char` and
   `unsigned char`.
+- The rank of `bool` is less than the rank of all standard integer
+  types.
+- The ranks of `char8_t`, `char16_t`, `char32_t`, and `wchar_t` equal
+  the ranks of their underlying types [[basic.fundamental]].
 - The rank of any extended signed integer type relative to another
   extended signed integer type with the same width is
   *implementation-defined*, but still subject to the other rules for
   determining the integer conversion rank.
 - For all integer types `T1`, `T2`, and `T3`, if `T1` has greater rank
+  than `T2` and `T2` has greater rank than `T3`, then `T1` has greater
+  rank than `T3`.
 [*Note 1*: The integer conversion rank is used in the definition of the
 integral promotions [[conv.prom]] and the usual arithmetic conversions
 [[expr.arith.conv]]. — *end note*]
+Every floating-point type has a *floating-point conversion rank* defined
+as follows:
+- The rank of a floating point type `T` is greater than the rank of any
+  floating-point type whose set of values is a proper subset of the set
+  of values of `T`.
+- The rank of `long double` is greater than the rank of `double`, which
+  is greater than the rank of `float`.
+- Two extended floating-point types with the same set of values have
+  equal ranks.
+- An extended floating-point type with the same set of values as exactly
+  one cv-unqualified standard floating-point type has a rank equal to
+  the rank of that standard floating-point type.
+- An extended floating-point type with the same set of values as more
+  than one cv-unqualified standard floating-point type has a rank equal
+  to the rank of `double`.
+[*Note 2*: The conversion ranks of floating-point types `T1` and `T2`
+are unordered if the set of values of `T1` is neither a subset nor a
+superset of the set of values of `T2`. This can happen when one type has
+both a larger range and a lower precision than the other. — *end note*]
+Floating-point types that have equal floating-point conversion ranks are
+ordered by floating-point conversion subrank. The subrank forms a total
+order among types with equal ranks. The types `std::float16_t`,
+`std::float32_t`, `std::float64_t`, and `std::float128_t`
+[[stdfloat.syn]] have a greater conversion subrank than any standard
+floating-point type with equal conversion rank. Otherwise, the
+conversion subrank order is *implementation-defined*.
+[*Note 3*: The floating-point conversion rank and subrank are used in
+the definition of the usual arithmetic conversions
+[[expr.arith.conv]]. — *end note*]

Diff to HTML by rtfpessoa