[iterator.concepts] - C++20 → C++23

Files changed (1) hide show

tmp/tmp_m2604y8/{from.md → to.md} +106 -77

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

@@ -30,11 +30,10 @@ struct I {
   I operator++(int);
   I& operator--();
   I operator--(int);
   bool operator==(I) const;
-  bool operator!=(I) const;
 };
 ```
 `iterator_traits<I>::iterator_category` denotes `input_iterator_tag`,
 and `ITER_CONCEPT(I)` denotes `random_access_iterator_tag`.
@@ -69,14 +68,10 @@ template<class In>
 ```
 Given a value `i` of type `I`, `I` models `indirectly_readable` only if
 the expression `*i` is equality-preserving.
-[*Note 1*: The expression `*i` is indirectly required to be valid via
-the exposition-only `dereferenceable` concept
-[[iterator.synopsis]]. — *end note*]
 #### Concept  <a id="iterator.concept.writable">[[iterator.concept.writable]]</a>
 The `indirectly_writable` concept specifies the requirements for writing
 a value into an iterator’s referenced object.
@@ -96,11 +91,11 @@ template<class Out, class T>
 Let `E` be an expression such that `decltype((E))` is `T`, and let `o`
 be a dereferenceable object of type `Out`. `Out` and `T` model
 `indirectly_writable<Out, T>` only if
 - If `Out` and `T` model
-  `indirectly_readable<Out> && same_as<iter_value_t<Out>, decay_t<T>{>}`,
   then `*o` after any above assignment is equal to the value of `E`
   before the assignment.
 After evaluating any above assignment expression, `o` is not required to
 be dereferenceable.
@@ -126,99 +121,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
@@ -227,17 +249,20 @@ 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*]
 #### Concept  <a id="iterator.concept.inc">[[iterator.concept.inc]]</a>
 The `incrementable` concept specifies requirements on types that can be
 incremented with the pre- and post-increment operators. The increment
@@ -274,13 +299,12 @@ The `input_or_output_iterator` concept forms the basis of the iterator
 concept taxonomy; every iterator models `input_or_output_iterator`. This
 concept specifies operations for dereferencing and incrementing an
 iterator. Most algorithms will require additional operations to compare
 iterators with sentinels [[iterator.concept.sentinel]], to read
 [[iterator.concept.input]] or write [[iterator.concept.output]] values,
-or to provide a richer set of iterator movements (
-[[iterator.concept.forward]], [[iterator.concept.bidir]],
-[[iterator.concept.random.access]]).
 ``` cpp
 template<class I>
   concept input_or_output_iterator =
     requires(I i) {
@@ -302,19 +326,20 @@ denote a range.
 ``` cpp
 template<class S, class I>
   concept sentinel_for =
     semiregular<S> &&
     input_or_output_iterator<I> &&
-    weakly-equality-comparable-with<S, I>; // See [concept.equalitycomparable]
 ```
 Let `s` and `i` be values of type `S` and `I` such that \[`i`, `s`)
 denotes a range. Types `S` and `I` model `sentinel_for<S, I>` only if
 - `i == s` is well-defined.
 - If `bool(i != s)` then `i` is dereferenceable and \[`++i`, `s`)
   denotes a range.
 The domain of `==` is not static. Given an iterator `i` and sentinel `s`
 such that \[`i`, `s`) denotes a range and `i != s`, `i` and `s` are not
 required to continue to denote a range after incrementing any other
 iterator equal to `i`. Consequently, `i == s` is no longer required to
@@ -348,11 +373,11 @@ and `I` model `sized_sentinel_for<S, I>` only if
 - If -N is representable by `iter_difference_t<I>`, then `i - s` is
   well-defined and equals -N.
 ``` cpp
 template<class S, class I>
- inline constexpr bool disable_sized_sentinel_for = false;
 ```
 *Remarks:* Pursuant to [[namespace.std]], users may specialize
 `disable_sized_sentinel_for` for cv-unqualified non-array object types
 `S` and `I` if `S` and/or `I` is a program-defined type. Such
@@ -416,13 +441,13 @@ be a dereferenceable object of type `I`. `I` and `T` model
 ``` cpp
 *i = E;
 ++i;
 ```
-[*Note 2*: Algorithms on output iterators should never attempt to pass
-through the same iterator twice. They should be single-pass
-algorithms. — *end note*]
 #### Concept  <a id="iterator.concept.forward">[[iterator.concept.forward]]</a>
 The `forward_iterator` concept adds copyability, equality comparison,
 and the multi-pass guarantee, specified below.
@@ -450,11 +475,11 @@ range.
 Two dereferenceable iterators `a` and `b` of type `X` offer the
 *multi-pass guarantee* if:
 - `a == b` implies `++a == ++b` and
-- The expression `((void)[](X x){++x;}(a), *a)` is equivalent to the
   expression `*a`.
 [*Note 2*: The requirement that `a == b` implies `++a == ++b` and the
 removal of the restrictions on the number of assignments through a
 mutable iterator (which applies to output iterators) allow the use of
@@ -560,8 +585,12 @@ non-dereferenceable iterator of type `I` such that `b` is reachable from
 `a` and `c` is reachable from `b`, and let `D` be
 `iter_difference_t<I>`. The type `I` models `contiguous_iterator` only
 if
 - `to_address(a) == addressof(*a)`,
-- `to_address(b) == to_address(a) + D(b - a)`, and
-- `to_address(c) == to_address(a) + D(c - a)`.

   I operator++(int);
   I& operator--();
   I operator--(int);
   bool operator==(I) const;
 };
 ```
 `iterator_traits<I>::iterator_category` denotes `input_iterator_tag`,
 and `ITER_CONCEPT(I)` denotes `random_access_iterator_tag`.
 ```
 Given a value `i` of type `I`, `I` models `indirectly_readable` only if
 the expression `*i` is equality-preserving.
 #### Concept  <a id="iterator.concept.writable">[[iterator.concept.writable]]</a>
 The `indirectly_writable` concept specifies the requirements for writing
 a value into an iterator’s referenced object.
 Let `E` be an expression such that `decltype((E))` is `T`, and let `o`
 be a dereferenceable object of type `Out`. `Out` and `T` model
 `indirectly_writable<Out, T>` only if
 - If `Out` and `T` model
+  `indirectly_readable<Out> && same_as<iter_value_t<Out>, decay_t<T>>`,
   then `*o` after any above assignment is equal to the value of `E`
   before the assignment.
 After evaluating any above assignment expression, `o` is not required to
 be dereferenceable.
 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*]
 #### Concept  <a id="iterator.concept.inc">[[iterator.concept.inc]]</a>
 The `incrementable` concept specifies requirements on types that can be
 incremented with the pre- and post-increment operators. The increment
 concept taxonomy; every iterator models `input_or_output_iterator`. This
 concept specifies operations for dereferencing and incrementing an
 iterator. Most algorithms will require additional operations to compare
 iterators with sentinels [[iterator.concept.sentinel]], to read
 [[iterator.concept.input]] or write [[iterator.concept.output]] values,
+or to provide a richer set of iterator movements
+[[iterator.concept.forward]], [[iterator.concept.bidir]], [[iterator.concept.random.access]].
 ``` cpp
 template<class I>
   concept input_or_output_iterator =
     requires(I i) {
 ``` cpp
 template<class S, class I>
   concept sentinel_for =
     semiregular<S> &&
     input_or_output_iterator<I> &&
+    weakly-equality-comparable-with<S, I>; // see [concept.equalitycomparable]
 ```
 Let `s` and `i` be values of type `S` and `I` such that \[`i`, `s`)
 denotes a range. Types `S` and `I` model `sentinel_for<S, I>` only if
 - `i == s` is well-defined.
 - If `bool(i != s)` then `i` is dereferenceable and \[`++i`, `s`)
   denotes a range.
+- `assignable_from<I&, S>` is either modeled or not satisfied.
 The domain of `==` is not static. Given an iterator `i` and sentinel `s`
 such that \[`i`, `s`) denotes a range and `i != s`, `i` and `s` are not
 required to continue to denote a range after incrementing any other
 iterator equal to `i`. Consequently, `i == s` is no longer required to
 - If -N is representable by `iter_difference_t<I>`, then `i - s` is
   well-defined and equals -N.
 ``` cpp
 template<class S, class I>
+  constexpr bool disable_sized_sentinel_for = false;
 ```
 *Remarks:* Pursuant to [[namespace.std]], users may specialize
 `disable_sized_sentinel_for` for cv-unqualified non-array object types
 `S` and `I` if `S` and/or `I` is a program-defined type. Such
 ``` cpp
 *i = E;
 ++i;
 ```
+*Recommended practice:* The implementation of an algorithm on output
+iterators should never attempt to pass through the same iterator twice;
+such an algorithm should be a single-pass algorithm.
 #### Concept  <a id="iterator.concept.forward">[[iterator.concept.forward]]</a>
 The `forward_iterator` concept adds copyability, equality comparison,
 and the multi-pass guarantee, specified below.
 Two dereferenceable iterators `a` and `b` of type `X` offer the
 *multi-pass guarantee* if:
 - `a == b` implies `++a == ++b` and
+- the expression `((void)[](X x){++x;}(a), *a)` is equivalent to the
   expression `*a`.
 [*Note 2*: The requirement that `a == b` implies `++a == ++b` and the
 removal of the restrictions on the number of assignments through a
 mutable iterator (which applies to output iterators) allow the use of
 `a` and `c` is reachable from `b`, and let `D` be
 `iter_difference_t<I>`. The type `I` models `contiguous_iterator` only
 if
 - `to_address(a) == addressof(*a)`,
+- `to_address(b) == to_address(a) + D(b - a)`,
+- `to_address(c) == to_address(a) + D(c - a)`,
+- `ranges::iter_move(a)` has the same type, value category, and effects
+  as `std::move(*a)`, and
+- if `ranges::iter_swap(a, b)` is well-formed, it has effects equivalent
+  to `ranges::swap(*a, *b)`.

Diff to HTML by rtfpessoa