[iterator.concept.winc] - C++20 → C++23

Files changed (1) hide show

tmp/tmpx85c1n2y/{from.md → to.md} +90 -60

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

@@ -5,99 +5,126 @@ that can be incremented with the pre- and post-increment operators. The
 increment operations are not required to be equality-preserving, nor is
 the type required to be `equality_comparable`.
 ``` cpp
 template<class T>
- inline constexpr bool is-integer-like = see below; // exposition only
 template<class T>
- inline constexpr bool is-signed-integer-like = see below; // exposition only
 template<class I>
   concept weakly_incrementable =
- default_initializable<I> && movable<I> &&
     requires(I i) {
       typename iter_difference_t<I>;
       requires is-signed-integer-like<iter_difference_t<I>>;
       { ++i } -> same_as<I&>;   // not required to be equality-preserving
       i++;                      // not required to be equality-preserving
     };
 ```
 A type `I` is an *integer-class type* if it is in a set of
-implementation-defined class types that behave as integer types do, as
-defined in below.
 The range of representable values of an integer-class type is the
-continuous set of values over which it is defined. The values 0 and 1
-are part of the range of every integer-class type. If any negative
-numbers are part of the range, the type is a
-*signed-integer-class type*; otherwise, it is an
-*unsigned-integer-class type*.
-For every integer-class type `I`, let `B(I)` be a hypothetical extended
-integer type of the same signedness with the smallest width
-[[basic.fundamental]] capable of representing the same range of values.
-The width of `I` is equal to the width of `B(I)`.
-Let `a` and `b` be objects of integer-class type `I`, let `x` and `y` be
-objects of type `B(I)` as described above that represent the same values
-as `a` and `b` respectively, and let `c` be an lvalue of any integral
-type.
-- For every unary operator `@` for which the expression `@x` is
-  well-formed, `@a` shall also be well-formed and have the same value,
-  effects, and value category as `@x` provided that value is
-  representable by `I`. If `@x` has type `bool`, so too does `@a`; if
-  `@x` has type `B(I)`, then `@a` has type `I`.
 - For every assignment operator `@=` for which `c @= x` is well-formed,
   `c @= a` shall also be well-formed and shall have the same value and
   effects as `c @= x`. The expression `c @= a` shall be an lvalue
   referring to `c`.
-- For every binary operator `@` for which `x @ y` is well-formed,
-  `a @ b` shall also be well-formed and shall have the same value,
- effects, and value category as `x @ y` provided that value is
- representable by `I`. If `x @ y` has type `bool`, so too does `a @ b`;
- if `x @ y` has type `B(I)`, then `a @ b` has type `I`.
-Expressions of integer-class type are explicitly convertible to any
-integral type. Expressions of integral type are both implicitly and
-explicitly convertible to any integer-class type. Conversions between
-integral and integer-class types do not exit via an exception.
 An expression `E` of integer-class type `I` is contextually convertible
 to `bool` as if by `bool(E != I(0))`.
 All integer-class types model `regular` [[concepts.object]] and
-`totally_ordered` [[concept.totallyordered]].
 A value-initialized object of integer-class type has value 0.
 For every (possibly cv-qualified) integer-class type `I`,
-`numeric_limits<I>` is specialized such that:
-- `numeric_limits<I>::is_specialized` is `true`,
-- `numeric_limits<I>::is_signed` is `true` if and only if `I` is a
-  signed-integer-class type,
-- `numeric_limits<I>::is_integer` is `true`,
-- `numeric_limits<I>::is_exact` is `true`,
-- `numeric_limits<I>::digits` is equal to the width of the integer-class
-  type,
-- `numeric_limits<I>::digits10` is equal to
-  `static_cast<int>(digits * log10(2))`, and
-- `numeric_limits<I>::min()` and `numeric_limits<I>::max()` return the
-  lowest and highest representable values of `I`, respectively, and
-  `numeric_limits<I>::lowest()` returns `numeric_limits<I>::{}min()`.
-A type `I` is *integer-like* if it models `integral<I>` or if it is an
-integer-class type. A type `I` is *signed-integer-like* if it models
-`signed_integral<I>` or if it is a signed-integer-class type. A type `I`
-is *unsigned-integer-like* if it models `unsigned_integral<I>` or if it
-is an unsigned-integer-class type.
 `is-integer-like<I>` is `true` if and only if `I` is an integer-like
-type. `is-signed-integer-like<I>` is `true` if and only if I is a
 signed-integer-like type.
 Let `i` be an object of type `I`. When `i` is in the domain of both pre-
 and post-increment, `i` is said to be *incrementable*. `I` models
 `weakly_incrementable<I>` only if
@@ -106,13 +133,16 @@ and post-increment, `i` is said to be *incrementable*. `I` models
 - If `i` is incrementable, then both `++i` and `i++` advance `i` to the
   next element.
 - If `i` is incrementable, then `addressof(++i)` is equal to
   `addressof(i)`.
-[*Note 1*: For `weakly_incrementable` types, `a` equals `b` does not
 imply that `++a` equals `++b`. (Equality does not guarantee the
-substitution property or referential transparency.) Algorithms on weakly
-incrementable types should never attempt to pass through the same
-incrementable value twice. They should be single-pass algorithms. These
-algorithms can be used with istreams as the source of the input data
-through the `istream_iterator` class template. — *end note*]

 increment operations are not required to be equality-preserving, nor is
 the type required to be `equality_comparable`.
 ``` cpp
 template<class T>
+  constexpr bool is-integer-like = see below; // exposition only
 template<class T>
+  constexpr bool is-signed-integer-like = see below; // exposition only
 template<class I>
   concept weakly_incrementable =
+    movable<I> &&
     requires(I i) {
       typename iter_difference_t<I>;
       requires is-signed-integer-like<iter_difference_t<I>>;
       { ++i } -> same_as<I&>;   // not required to be equality-preserving
       i++;                      // not required to be equality-preserving
     };
 ```
 A type `I` is an *integer-class type* if it is in a set of
+*implementation-defined* types that behave as integer types do, as
+defined below.
+[*Note 1*: An integer-class type is not necessarily a class
+type. — *end note*]
 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ᴺ⁻¹ to 2ᴺ⁻¹-1
+(inclusive) for some integer N, in which case it is a
+*signed-integer-class type*, or 0 to 2ᴺ-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 integral type of the
+same signedness.
+A type `I` other than cv `bool` is *integer-like* if it models
+`integral<I>` or if it is an integer-class type. An integer-like type
+`I` is *signed-integer-like* if it models `signed_integral<I>` or if it
+is a signed-integer-class type. An integer-like type `I` is
+*unsigned-integer-like* if it models `unsigned_integral<I>` or if it is
+an unsigned-integer-class type.
+For every integer-class type `I`, let `B(I)` be a unique hypothetical
+extended integer type of the same signedness with the same width
+[[basic.fundamental]] as `I`.
+[*Note 2*: The corresponding hypothetical specialization
+`numeric_limits<B(I)>` meets the requirements on `numeric_limits`
+specializations for integral types [[numeric.limits]]. — *end note*]
+For every integral type `J`, let `B(J)` be the same type as `J`.
+Expressions of integer-class type are explicitly convertible to any
+integer-like type, and implicitly convertible to any 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. 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ᴺ, where N is the width of the
+destination type.
+Let `a` be an object of integer-class type `I`, let `b` be an object of
+integer-like type `I2` such that the expression `b` is implicitly
+convertible to `I`, let `x` and `y` be, respectively, objects of type
+`B(I)` and `B(I2)` as described above that represent the same values as
+`a` and `b`, and let `c` be an lvalue of any integral type.
+- The expressions `a++` and `a--` shall be prvalues of type `I` whose
+  values are equal to that of `a` prior to the evaluation of the
+  expressions. The expression `a++` shall modify the value of `a` by
+  adding `1` to it. The expression `a--` shall modify the value of `a`
+  by subtracting `1` from it.
+- The expressions `++a`, `--a`, and `&a` shall be expression-equivalent
+  to `a += 1`, `a -= 1`, and `addressof(a)`, respectively.
+- For every *unary-operator* `@` other than `&` for which the expression
+  `@x` is well-formed, `@a` shall also be well-formed and have the same
+  value, effects, and value category as `@x`. If `@x` has type `bool`,
+  so too does `@a`; if `@x` has type `B(I)`, then `@a` has type `I`.
 - For every assignment operator `@=` for which `c @= x` is well-formed,
   `c @= a` shall also be well-formed and shall have the same value and
   effects as `c @= x`. The expression `c @= a` shall be an lvalue
   referring to `c`.
+- For every assignment operator `@=` for which `x @= y` is well-formed,
+  `a @= b` shall also be well-formed and shall have the same effects as
+  `x @= y`, except that the value that would be stored into `x` is
+ stored into `a`. The expression `a @= b` shall be an lvalue referring
+ to `a`.
+- For every non-assignment binary operator `@` for which `x @ y` and
+  `y @ x` are well-formed, `a @ b` and `b @ a` shall also be well-formed
+  and shall have the same value, effects, and value category as `x @ y`
+  and `y @ x`, respectively. If `x @ y` or `y @ x` has type `B(I)`, then
+  `a @ b` or `b @ a`, respectively, has type `I`; if `x @ y` or `y @ x`
+  has type `B(I2)`, then `a @ b` or `b @ a`, respectively, has type
+  `I2`; if `x @ y` or `y @ x` has any other type, then `a @ b` or
+  `b @ a`, respectively, has that type.
 An expression `E` of integer-class type `I` is contextually convertible
 to `bool` as if by `bool(E != I(0))`.
 All integer-class types model `regular` [[concepts.object]] and
+`three_way_comparable<strong_ordering>` [[cmp.concept]].
 A value-initialized object of integer-class type has value 0.
 For every (possibly cv-qualified) integer-class type `I`,
+`numeric_limits<I>` is specialized such that each static data member `m`
+has the same value as `numeric_limits<B(I)>::m`, and each static member
+function `f` returns `I(numeric_limits<B(I)>::f())`.
+For any two integer-like types `I1` and `I2`, at least one of which is
+an integer-class type, `common_type_t<I1, I2>` denotes an integer-class
+type whose width is not less than that of `I1` or `I2`. If both `I1` and
+`I2` are signed-integer-like types, then `common_type_t<I1, I2>` is also
+a signed-integer-like type.
 `is-integer-like<I>` is `true` if and only if `I` is an integer-like
+type. `is-signed-integer-like<I>` is `true` if and only if `I` is a
 signed-integer-like type.
 Let `i` be an object of type `I`. When `i` is in the domain of both pre-
 and post-increment, `i` is said to be *incrementable*. `I` models
 `weakly_incrementable<I>` only if
 - If `i` is incrementable, then both `++i` and `i++` advance `i` to the
   next element.
 - If `i` is incrementable, then `addressof(++i)` is equal to
   `addressof(i)`.
+*Recommended practice:* The implementaton of an algorithm on a weakly
+incrementable type should never attempt to pass through the same
+incrementable value twice; such an algorithm should be a single-pass
+algorithm.
+[*Note 3*: For `weakly_incrementable` types, `a` equals `b` does not
 imply that `++a` equals `++b`. (Equality does not guarantee the
+substitution property or referential transparency.) Such algorithms can
+be used with istreams as the source of the input data through the
+`istream_iterator` class template. — *end note*]

Diff to HTML by rtfpessoa