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

Files changed (1) hide show

tmp/tmpeknxjejv/{from.md → to.md} +204 -146

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

@@ -36,11 +36,11 @@ access iterators*, and *contiguous iterators*, as shown in
 The six categories of iterators correspond to the iterator concepts
 - `input_iterator` [[iterator.concept.input]],
 - `output_iterator` [[iterator.concept.output]],
 - `forward_iterator` [[iterator.concept.forward]],
-- `bidirectional_iterator` [[iterator.concept.bidir]]
 - `random_access_iterator` [[iterator.concept.random.access]], and
 - `contiguous_iterator` [[iterator.concept.contiguous]],
 respectively. The generic term *iterator* refers to any type that models
 the `input_or_output_iterator` concept [[iterator.concept.iterator]].
@@ -71,22 +71,16 @@ value pointing past the last element of the array, so for any iterator
 type there is an iterator value that points past the last element of a
 corresponding sequence. Such a value is called a *past-the-end value*.
 Values of an iterator `i` for which the expression `*i` is defined are
 called *dereferenceable*. The library never assumes that past-the-end
 values are dereferenceable. Iterators can also have singular values that
-are not associated with any sequence.
-[*Example 1*: After the declaration of an uninitialized pointer `x` (as
-with `int* x;`), `x` must always be assumed to have a singular value of
-a pointer. — *end example*]
-Results of most expressions are undefined for singular values; the only
-exceptions are destroying an iterator that holds a singular value, the
-assignment of a non-singular value to an iterator that holds a singular
-value, and, for iterators that meet the *Cpp17DefaultConstructible*
-requirements, using a value-initialized iterator as the source of a copy
-or move operation.
 [*Note 2*: This guarantee is not offered for default-initialization,
 although the distinction only matters for types with trivial default
 constructors such as pointers or aggregates holding
 pointers. — *end note*]
@@ -107,18 +101,18 @@ elements in the data structure starting with the element pointed to by
 first iterator `j` such that `j == s`.
 A sentinel `s` is called *reachable from* an iterator `i` if and only if
 there is a finite sequence of applications of the expression `++i` that
 makes `i == s`. If `s` is reachable from `i`, \[`i`, `s`) denotes a
-valid range.
 A *counted range* `i`+\[0, `n`) is empty if `n == 0`; otherwise,
 `i`+\[0, `n`) refers to the `n` elements in the data structure starting
 with the element pointed to by `i` and up to but not including the
 element, if any, pointed to by the result of `n` applications of `++i`.
-A counted range `i`+\[0, `n`) is valid if and only if `n == 0`; or `n`
-is positive, `i` is dereferenceable, and `++i`+\[0, `-``-``n`) is valid.
 The result of the application of library functions to invalid ranges is
 undefined.
 All the categories of iterators require only those functions that are
@@ -214,10 +208,16 @@ template<class T>
   requires is_object_v<T>
 struct cond-value-type<T> {
   using value_type = remove_cv_t<T>;
 };
 template<class> struct indirectly_readable_traits { };
 template<class T>
 struct indirectly_readable_traits<T*>
   : cond-value-type<T> { };
@@ -230,20 +230,28 @@ struct indirectly_readable_traits<I> {
 template<class I>
 struct indirectly_readable_traits<const I>
   : indirectly_readable_traits<I> { };
-template<class T>
-  requires requires { typename T::value_type; }
 struct indirectly_readable_traits<T>
   : cond-value-type<typename T::value_type> { };
-template<class T>
-  requires requires { typename T::element_type; }
 struct indirectly_readable_traits<T>
   : cond-value-type<typename T::element_type> { };
 template<class T> using iter_value_t = see below;
 ```
 Let R_`I` be `remove_cvref_t<I>`. The type `iter_value_t<I>` denotes
@@ -301,15 +309,15 @@ The definitions in this subclause make use of the following
 exposition-only concepts:
 ``` cpp
 template<class I>
 concept cpp17-iterator =
- copyable<I> && requires(I i) {
     {   *i } -> can-reference;
     {  ++i } -> same_as<I&>;
     { *i++ } -> can-reference;
-  };
 template<class I>
 concept cpp17-input-iterator =
   cpp17-iterator<I> && equality_comparable<I> && requires(I i) {
     typename incrementable_traits<I>::difference_type;
@@ -322,11 +330,11 @@ concept cpp17-input-iterator =
   };
 template<class I>
 concept cpp17-forward-iterator =
   cpp17-input-iterator<I> && constructible_from<I> &&
- is_lvalue_reference_v<iter_reference_t<I>> &&
   same_as<remove_cvref_t<iter_reference_t<I>>,
           typename indirectly_readable_traits<I>::value_type> &&
   requires(I i) {
     {  i++ } -> convertible_to<const I&>;
     { *i++ } -> same_as<iter_reference_t<I>>;
@@ -418,10 +426,16 @@ The members of a specialization `iterator_traits<I>` generated from the
 Explicit or partial specializations of `iterator_traits` may have a
 member type `iterator_concept` that is used to indicate conformance to
 the iterator concepts [[iterator.concepts]].
 `iterator_traits` is specialized for pointers as
 ``` cpp
 namespace std {
   template<class T>
@@ -435,11 +449,11 @@ namespace std {
     using reference         = T&;
   };
 }
 ```
-[*Example 1*:
 To implement a generic `reverse` function, a C++ program can do the
 following:
 ``` cpp
@@ -458,26 +472,23 @@ void reverse(BI first, BI last) {
 }
 ```
 — *end example*]
-### Customization points <a id="iterator.cust">[[iterator.cust]]</a>
 #### `ranges::iter_move` <a id="iterator.cust.move">[[iterator.cust.move]]</a>
 The name `ranges::iter_move` denotes a customization point object
 [[customization.point.object]]. The expression `ranges::iter_move(E)`
 for a subexpression `E` is expression-equivalent to:
 - `iter_move(E)`, if `E` has class or enumeration type and
   `iter_move(E)` is a well-formed expression when treated as an
-  unevaluated operand, with overload resolution performed in a context
- that does not include a declaration of `ranges::iter_move` but does
- include the declaration
-  ``` cpp
-  void iter_move();
-  ```
 - Otherwise, if the expression `*E` is well-formed:
   - if `*E` is an lvalue, `std::move(*E)`;
   - otherwise, `*E`.
 - Otherwise, `ranges::iter_move(E)` is ill-formed. \[*Note 1*: This case
   can result in substitution failure when `ranges::iter_move(E)` appears
@@ -523,20 +534,23 @@ The expression `ranges::iter_swap(E1, E2)` for subexpressions `E1` and
   and does not include a declaration of `ranges::iter_swap`. If the
   function selected by overload resolution does not exchange the values
   denoted by `E1` and `E2`, the program is ill-formed, no diagnostic
   required.
 - Otherwise, if the types of `E1` and `E2` each model
   `indirectly_readable`, and if the reference types of `E1` and `E2`
   model `swappable_with` [[concept.swappable]], then
   `ranges::swap(*E1, *E2)`.
 - Otherwise, if the types `T1` and `T2` of `E1` and `E2` model
   `indirectly_movable_storable<T1, T2>` and
   `indirectly_movable_storable<T2, T1>`, then
   `(void)(*E1 = iter-exchange-move(E2, E1))`, except that `E1` is
   evaluated only once.
-- Otherwise, `ranges::iter_swap(E1, E2)` is ill-formed. \[*Note 1*: This
   case can result in substitution failure when
   `ranges::iter_swap(E1, E2)` appears in the immediate context of a
   template instantiation. — *end note*]
 ### Iterator concepts <a id="iterator.concepts">[[iterator.concepts]]</a>
@@ -571,11 +585,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`.
@@ -610,14 +623,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.
@@ -637,11 +646,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.
@@ -667,99 +676,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
@@ -768,17 +804,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
@@ -815,13 +854,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) {
@@ -843,19 +881,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
@@ -889,11 +928,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
@@ -957,13 +996,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.
@@ -991,11 +1030,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
@@ -1101,15 +1140,21 @@ 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)`.
 ### C++17 iterator requirements <a id="iterator.cpp17">[[iterator.cpp17]]</a>
 In the following sections, `a` and `b` denote values of type `X` or
 `const X`, `difference_type` and `reference` refer to the types
 `iterator_traits<X>::difference_type` and
 `iterator_traits<X>::reference`, respectively, `n` denotes a value of
 `difference_type`, `u`, `tmp`, and `m` denote identifiers, `r` denotes a
@@ -1124,19 +1169,18 @@ value of some type that is writable to the output iterator.
 The *Cpp17Iterator* requirements form the basis of the iterator
 taxonomy; every iterator meets the *Cpp17Iterator* requirements. This
 set of requirements specifies operations for dereferencing and
 incrementing an iterator. Most algorithms will require additional
 operations to read [[input.iterators]] or write [[output.iterators]]
-values, or to provide a richer set of iterator movements (
-[[forward.iterators]], [[bidirectional.iterators]],
-[[random.access.iterators]]).
-A type `X` meets the *Cpp17Iterator* requirements if:
-- `X` meets the *Cpp17CopyConstructible*, *Cpp17CopyAssignable*, and
-  *Cpp17Destructible* requirements [[utility.arg.requirements]] and
- lvalues of type `X` are swappable [[swappable.requirements]], and
 - `iterator_traits<X>::difference_type` is a signed integer type or
   `void`, and
 - the expressions in [[iterator]] are valid and have the indicated
   semantics.
@@ -1158,31 +1202,35 @@ uses that algorithm makes of `==` and `!=`.
 [*Example 1*: The call `find(a,b,x)` is defined only if the value of
 `a` has the property *p* defined as follows: `b` has property *p* and a
 value `i` has property *p* if (`*i==x`) or if (`*i!=x` and `++i` has
 property *p*). — *end example*]
 [*Note 1*: For input iterators, `a == b` does not imply `++a == ++b`.
 (Equality does not guarantee the substitution property or referential
-transparency.) Algorithms on input iterators should never attempt to
-pass through the same iterator twice. They should be *single pass*
-algorithms. Value type `T` is not required to be a *Cpp17CopyAssignable*
-type ([[cpp17.copyassignable]]). These algorithms can be used with
-istreams as the source of the input data through the `istream_iterator`
-class template. — *end note*]
 #### Output iterators <a id="output.iterators">[[output.iterators]]</a>
 A class or pointer type `X` meets the requirements of an output iterator
 if `X` meets the *Cpp17Iterator* requirements [[iterator.iterators]] and
 the expressions in [[outputiterator]] are valid and have the indicated
 semantics.
 [*Note 1*: The only valid use of an `operator*` is on the left side of
 the assignment statement. Assignment through the same value of the
-iterator happens only once. Algorithms on output iterators should never
-attempt to pass through the same iterator twice. They should be
-single-pass algorithms. Equality and inequality might not be
 defined. — *end note*]
 #### Forward iterators <a id="forward.iterators">[[forward.iterators]]</a>
 A class or pointer type `X` meets the requirements of a forward iterator
@@ -1244,85 +1292,95 @@ requirements, the following expressions are valid as shown in
 ### Indirect callable requirements <a id="indirectcallable">[[indirectcallable]]</a>
 #### General <a id="indirectcallable.general">[[indirectcallable.general]]</a>
 There are several concepts that group requirements of algorithms that
-take callable objects ([[func.def]]) as arguments.
 #### Indirect callables <a id="indirectcallable.indirectinvocable">[[indirectcallable.indirectinvocable]]</a>
 The indirect callable concepts are used to constrain those algorithms
-that accept callable objects ([[func.def]]) as arguments.
 ``` cpp
 namespace std {
   template<class F, class I>
     concept indirectly_unary_invocable =
       indirectly_readable<I> &&
       copy_constructible<F> &&
-      invocable<F&, iter_value_t<I>&> &&
       invocable<F&, iter_reference_t<I>> &&
       invocable<F&, iter_common_reference_t<I>> &&
       common_reference_with<
-        invoke_result_t<F&, iter_value_t<I>&>,
         invoke_result_t<F&, iter_reference_t<I>>>;
   template<class F, class I>
     concept indirectly_regular_unary_invocable =
       indirectly_readable<I> &&
       copy_constructible<F> &&
-      regular_invocable<F&, iter_value_t<I>&> &&
       regular_invocable<F&, iter_reference_t<I>> &&
       regular_invocable<F&, iter_common_reference_t<I>> &&
       common_reference_with<
-        invoke_result_t<F&, iter_value_t<I>&>,
         invoke_result_t<F&, iter_reference_t<I>>>;
   template<class F, class I>
     concept indirect_unary_predicate =
       indirectly_readable<I> &&
       copy_constructible<F> &&
-      predicate<F&, iter_value_t<I>&> &&
       predicate<F&, iter_reference_t<I>> &&
       predicate<F&, iter_common_reference_t<I>>;
   template<class F, class I1, class I2>
     concept indirect_binary_predicate =
       indirectly_readable<I1> && indirectly_readable<I2> &&
       copy_constructible<F> &&
-      predicate<F&, iter_value_t<I1>&, iter_value_t<I2>&> &&
-      predicate<F&, iter_value_t<I1>&, iter_reference_t<I2>> &&
-      predicate<F&, iter_reference_t<I1>, iter_value_t<I2>&> &&
       predicate<F&, iter_reference_t<I1>, iter_reference_t<I2>> &&
       predicate<F&, iter_common_reference_t<I1>, iter_common_reference_t<I2>>;
   template<class F, class I1, class I2 = I1>
     concept indirect_equivalence_relation =
       indirectly_readable<I1> && indirectly_readable<I2> &&
       copy_constructible<F> &&
-      equivalence_relation<F&, iter_value_t<I1>&, iter_value_t<I2>&> &&
-      equivalence_relation<F&, iter_value_t<I1>&, iter_reference_t<I2>> &&
-      equivalence_relation<F&, iter_reference_t<I1>, iter_value_t<I2>&> &&
       equivalence_relation<F&, iter_reference_t<I1>, iter_reference_t<I2>> &&
       equivalence_relation<F&, iter_common_reference_t<I1>, iter_common_reference_t<I2>>;
   template<class F, class I1, class I2 = I1>
     concept indirect_strict_weak_order =
       indirectly_readable<I1> && indirectly_readable<I2> &&
       copy_constructible<F> &&
-      strict_weak_order<F&, iter_value_t<I1>&, iter_value_t<I2>&> &&
-      strict_weak_order<F&, iter_value_t<I1>&, iter_reference_t<I2>> &&
-      strict_weak_order<F&, iter_reference_t<I1>, iter_value_t<I2>&> &&
       strict_weak_order<F&, iter_reference_t<I1>, iter_reference_t<I2>> &&
       strict_weak_order<F&, iter_common_reference_t<I1>, iter_common_reference_t<I2>>;
 }
 ```
 #### Class template `projected` <a id="projected">[[projected]]</a>
 Class template `projected` is used to constrain algorithms that accept
-callable objects and projections [[defns.projection]]. It combines a
 `indirectly_readable` type `I` and a callable object type `Proj` into a
 new `indirectly_readable` type whose `reference` type is the result of
 applying `Proj` to the `iter_reference_t` of `I`.
 ``` cpp
@@ -1358,12 +1416,12 @@ different sequences: `indirectly_comparable`.
 below imposes constraints on the concepts’ arguments in addition to
 those that appear in the concepts’ bodies [[range.cmp]]. — *end note*]
 #### Concept  <a id="alg.req.ind.move">[[alg.req.ind.move]]</a>
-The `indirectly_movable` concept specifies the relationship between a
-`indirectly_readable` type and a `indirectly_writable` type between
 which values may be moved.
 ``` cpp
 template<class In, class Out>
   concept indirectly_movable =
@@ -1399,12 +1457,12 @@ iter_value_t<In> obj(ranges::iter_move(i));
 state of the value denoted by `*i` is valid but unspecified
 [[lib.types.movedfrom]].
 #### Concept  <a id="alg.req.ind.copy">[[alg.req.ind.copy]]</a>
-The `indirectly_copyable` concept specifies the relationship between a
-`indirectly_readable` type and a `indirectly_writable` type between
 which values may be copied.
 ``` cpp
 template<class In, class Out>
   concept indirectly_copyable =

 The six categories of iterators correspond to the iterator concepts
 - `input_iterator` [[iterator.concept.input]],
 - `output_iterator` [[iterator.concept.output]],
 - `forward_iterator` [[iterator.concept.forward]],
+- `bidirectional_iterator` [[iterator.concept.bidir]],
 - `random_access_iterator` [[iterator.concept.random.access]], and
 - `contiguous_iterator` [[iterator.concept.contiguous]],
 respectively. The generic term *iterator* refers to any type that models
 the `input_or_output_iterator` concept [[iterator.concept.iterator]].
 type there is an iterator value that points past the last element of a
 corresponding sequence. Such a value is called a *past-the-end value*.
 Values of an iterator `i` for which the expression `*i` is defined are
 called *dereferenceable*. The library never assumes that past-the-end
 values are dereferenceable. Iterators can also have singular values that
+are not associated with any sequence. Results of most expressions are
+undefined for singular values; the only exceptions are destroying an
+iterator that holds a singular value, the assignment of a non-singular
+value to an iterator that holds a singular value, and, for iterators
+that meet the *Cpp17DefaultConstructible* requirements, using a
+value-initialized iterator as the source of a copy or move operation.
 [*Note 2*: This guarantee is not offered for default-initialization,
 although the distinction only matters for types with trivial default
 constructors such as pointers or aggregates holding
 pointers. — *end note*]
 first iterator `j` such that `j == s`.
 A sentinel `s` is called *reachable from* an iterator `i` if and only if
 there is a finite sequence of applications of the expression `++i` that
 makes `i == s`. If `s` is reachable from `i`, \[`i`, `s`) denotes a
+*valid range*.
 A *counted range* `i`+\[0, `n`) is empty if `n == 0`; otherwise,
 `i`+\[0, `n`) refers to the `n` elements in the data structure starting
 with the element pointed to by `i` and up to but not including the
 element, if any, pointed to by the result of `n` applications of `++i`.
+A counted range `i`+\[0, `n`) is *valid* if and only if `n == 0`; or `n`
+is positive, `i` is dereferenceable, and `++i`+\[0, `–n`) is valid.
 The result of the application of library functions to invalid ranges is
 undefined.
 All the categories of iterators require only those functions that are
   requires is_object_v<T>
 struct cond-value-type<T> {
   using value_type = remove_cv_t<T>;
 };
+template<class T>
+  concept has-member-value-type = requires { typename T::value_type; };         // exposition only
+template<class T>
+  concept has-member-element-type = requires { typename T::element_type; };     // exposition only
 template<class> struct indirectly_readable_traits { };
 template<class T>
 struct indirectly_readable_traits<T*>
   : cond-value-type<T> { };
 template<class I>
 struct indirectly_readable_traits<const I>
   : indirectly_readable_traits<I> { };
+template<has-member-value-type T>
 struct indirectly_readable_traits<T>
   : cond-value-type<typename T::value_type> { };
+template<has-member-element-type T>
 struct indirectly_readable_traits<T>
   : cond-value-type<typename T::element_type> { };
+template<has-member-value-type T>
+  requires has-member-element-type<T>
+struct indirectly_readable_traits<T> { };
+template<has-member-value-type T>
+  requires has-member-element-type<T> &&
+           same_as<remove_cv_t<typename T::element_type>, remove_cv_t<typename T::value_type>>
+struct indirectly_readable_traits<T>
+  : cond-value-type<typename T::value_type> { };
 template<class T> using iter_value_t = see below;
 ```
 Let R_`I` be `remove_cvref_t<I>`. The type `iter_value_t<I>` denotes
 exposition-only concepts:
 ``` cpp
 template<class I>
 concept cpp17-iterator =
+  requires(I i) {
     {   *i } -> can-reference;
     {  ++i } -> same_as<I&>;
     { *i++ } -> can-reference;
+  } && copyable<I>;
 template<class I>
 concept cpp17-input-iterator =
   cpp17-iterator<I> && equality_comparable<I> && requires(I i) {
     typename incrementable_traits<I>::difference_type;
   };
 template<class I>
 concept cpp17-forward-iterator =
   cpp17-input-iterator<I> && constructible_from<I> &&
+ is_reference_v<iter_reference_t<I>> &&
   same_as<remove_cvref_t<iter_reference_t<I>>,
           typename indirectly_readable_traits<I>::value_type> &&
   requires(I i) {
     {  i++ } -> convertible_to<const I&>;
     { *i++ } -> same_as<iter_reference_t<I>>;
 Explicit or partial specializations of `iterator_traits` may have a
 member type `iterator_concept` that is used to indicate conformance to
 the iterator concepts [[iterator.concepts]].
+[*Example 1*: To indicate conformance to the `input_iterator` concept
+but a lack of conformance to the *Cpp17InputIterator* requirements
+[[input.iterators]], an `iterator_traits` specialization might have
+`iterator_concept` denote `input_iterator_tag` but not define
+`iterator_category`. — *end example*]
 `iterator_traits` is specialized for pointers as
 ``` cpp
 namespace std {
   template<class T>
     using reference         = T&;
   };
 }
 ```
+[*Example 2*:
 To implement a generic `reverse` function, a C++ program can do the
 following:
 ``` cpp
 }
 ```
 — *end example*]
+### Customization point objects <a id="iterator.cust">[[iterator.cust]]</a>
 #### `ranges::iter_move` <a id="iterator.cust.move">[[iterator.cust.move]]</a>
 The name `ranges::iter_move` denotes a customization point object
 [[customization.point.object]]. The expression `ranges::iter_move(E)`
 for a subexpression `E` is expression-equivalent to:
 - `iter_move(E)`, if `E` has class or enumeration type and
   `iter_move(E)` is a well-formed expression when treated as an
+  unevaluated operand, where the meaning of `iter_move` is established
+ as-if by performing argument-dependent lookup only
+ [[basic.lookup.argdep]].
 - Otherwise, if the expression `*E` is well-formed:
   - if `*E` is an lvalue, `std::move(*E)`;
   - otherwise, `*E`.
 - Otherwise, `ranges::iter_move(E)` is ill-formed. \[*Note 1*: This case
   can result in substitution failure when `ranges::iter_move(E)` appears
   and does not include a declaration of `ranges::iter_swap`. If the
   function selected by overload resolution does not exchange the values
   denoted by `E1` and `E2`, the program is ill-formed, no diagnostic
   required.
+  \[*Note 1*: This precludes calling unconstrained `std::iter_swap`.
+  When the deleted overload is viable, program-defined overloads need to
+  be more specialized [[temp.func.order]] to be selected. — *end note*]
 - Otherwise, if the types of `E1` and `E2` each model
   `indirectly_readable`, and if the reference types of `E1` and `E2`
   model `swappable_with` [[concept.swappable]], then
   `ranges::swap(*E1, *E2)`.
 - Otherwise, if the types `T1` and `T2` of `E1` and `E2` model
   `indirectly_movable_storable<T1, T2>` and
   `indirectly_movable_storable<T2, T1>`, then
   `(void)(*E1 = iter-exchange-move(E2, E1))`, except that `E1` is
   evaluated only once.
+- Otherwise, `ranges::iter_swap(E1, E2)` is ill-formed. \[*Note 2*: This
   case can result in substitution failure when
   `ranges::iter_swap(E1, E2)` appears in the immediate context of a
   template instantiation. — *end note*]
 ### Iterator concepts <a id="iterator.concepts">[[iterator.concepts]]</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)`.
 ### C++17 iterator requirements <a id="iterator.cpp17">[[iterator.cpp17]]</a>
+#### General <a id="iterator.cpp17.general">[[iterator.cpp17.general]]</a>
 In the following sections, `a` and `b` denote values of type `X` or
 `const X`, `difference_type` and `reference` refer to the types
 `iterator_traits<X>::difference_type` and
 `iterator_traits<X>::reference`, respectively, `n` denotes a value of
 `difference_type`, `u`, `tmp`, and `m` denote identifiers, `r` denotes a
 The *Cpp17Iterator* requirements form the basis of the iterator
 taxonomy; every iterator meets the *Cpp17Iterator* requirements. This
 set of requirements specifies operations for dereferencing and
 incrementing an iterator. Most algorithms will require additional
 operations to read [[input.iterators]] or write [[output.iterators]]
+values, or to provide a richer set of iterator movements
+[[forward.iterators]], [[bidirectional.iterators]], [[random.access.iterators]].
+A type `X` meets the requirements if:
+- `X` meets the *Cpp17CopyConstructible*, *Cpp17CopyAssignable*,
+  *Cpp17Swappable*, and *Cpp17Destructible* requirements
+ [[utility.arg.requirements]], [[swappable.requirements]], and
 - `iterator_traits<X>::difference_type` is a signed integer type or
   `void`, and
 - the expressions in [[iterator]] are valid and have the indicated
   semantics.
 [*Example 1*: The call `find(a,b,x)` is defined only if the value of
 `a` has the property *p* defined as follows: `b` has property *p* and a
 value `i` has property *p* if (`*i==x`) or if (`*i!=x` and `++i` has
 property *p*). — *end example*]
+*Recommended practice:* The implementation of an algorithm on input
+iterators should never attempt to pass through the same iterator twice;
+such an algorithm should be a single pass algorithm.
 [*Note 1*: For input iterators, `a == b` does not imply `++a == ++b`.
 (Equality does not guarantee the substitution property or referential
+transparency.) Value type `T` is not required to be a
+*Cpp17CopyAssignable* type ([[cpp17.copyassignable]]). Such an
+algorithm can be used with istreams as the source of the input data
+through the `istream_iterator` class template. — *end note*]
 #### Output iterators <a id="output.iterators">[[output.iterators]]</a>
 A class or pointer type `X` meets the requirements of an output iterator
 if `X` meets the *Cpp17Iterator* requirements [[iterator.iterators]] and
 the expressions in [[outputiterator]] are valid and have the indicated
 semantics.
+*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.
 [*Note 1*: The only valid use of an `operator*` is on the left side of
 the assignment statement. Assignment through the same value of the
+iterator happens only once. Equality and inequality are not necessarily
 defined. — *end note*]
 #### Forward iterators <a id="forward.iterators">[[forward.iterators]]</a>
 A class or pointer type `X` meets the requirements of a forward iterator
 ### Indirect callable requirements <a id="indirectcallable">[[indirectcallable]]</a>
 #### General <a id="indirectcallable.general">[[indirectcallable.general]]</a>
 There are several concepts that group requirements of algorithms that
+take callable objects [[func.def]] as arguments.
+#### Indirect callable traits <a id="indirectcallable.traits">[[indirectcallable.traits]]</a>
+To implement algorithms taking projections, it is necessary to determine
+the projected type of an iterator’s value type. For the exposition-only
+alias template *`indirect-value-t`*, `indirect-value-t<T>` denotes
+- `invoke_result_t<Proj&, indirect-value-t<I>>` if `T` names
+  `projected<I, Proj>`, and
+- `iter_value_t<T>&` otherwise.
 #### Indirect callables <a id="indirectcallable.indirectinvocable">[[indirectcallable.indirectinvocable]]</a>
 The indirect callable concepts are used to constrain those algorithms
+that accept callable objects [[func.def]] as arguments.
 ``` cpp
 namespace std {
   template<class F, class I>
     concept indirectly_unary_invocable =
       indirectly_readable<I> &&
       copy_constructible<F> &&
+      invocable<F&, indirect-value-t<I>> &&
       invocable<F&, iter_reference_t<I>> &&
       invocable<F&, iter_common_reference_t<I>> &&
       common_reference_with<
+        invoke_result_t<F&, indirect-value-t<I>>,
         invoke_result_t<F&, iter_reference_t<I>>>;
   template<class F, class I>
     concept indirectly_regular_unary_invocable =
       indirectly_readable<I> &&
       copy_constructible<F> &&
+      regular_invocable<F&, indirect-value-t<I>> &&
       regular_invocable<F&, iter_reference_t<I>> &&
       regular_invocable<F&, iter_common_reference_t<I>> &&
       common_reference_with<
+        invoke_result_t<F&, indirect-value-t<I>>,
         invoke_result_t<F&, iter_reference_t<I>>>;
   template<class F, class I>
     concept indirect_unary_predicate =
       indirectly_readable<I> &&
       copy_constructible<F> &&
+      predicate<F&, indirect-value-t<I>> &&
       predicate<F&, iter_reference_t<I>> &&
       predicate<F&, iter_common_reference_t<I>>;
   template<class F, class I1, class I2>
     concept indirect_binary_predicate =
       indirectly_readable<I1> && indirectly_readable<I2> &&
       copy_constructible<F> &&
+      predicate<F&, indirect-value-t<I1>, indirect-value-t<I2>> &&
+      predicate<F&, indirect-value-t<I1>, iter_reference_t<I2>> &&
+      predicate<F&, iter_reference_t<I1>, indirect-value-t<I2>> &&
       predicate<F&, iter_reference_t<I1>, iter_reference_t<I2>> &&
       predicate<F&, iter_common_reference_t<I1>, iter_common_reference_t<I2>>;
   template<class F, class I1, class I2 = I1>
     concept indirect_equivalence_relation =
       indirectly_readable<I1> && indirectly_readable<I2> &&
       copy_constructible<F> &&
+      equivalence_relation<F&, indirect-value-t<I1>, indirect-value-t<I2>> &&
+      equivalence_relation<F&, indirect-value-t<I1>, iter_reference_t<I2>> &&
+      equivalence_relation<F&, iter_reference_t<I1>, indirect-value-t<I2>> &&
       equivalence_relation<F&, iter_reference_t<I1>, iter_reference_t<I2>> &&
       equivalence_relation<F&, iter_common_reference_t<I1>, iter_common_reference_t<I2>>;
   template<class F, class I1, class I2 = I1>
     concept indirect_strict_weak_order =
       indirectly_readable<I1> && indirectly_readable<I2> &&
       copy_constructible<F> &&
+      strict_weak_order<F&, indirect-value-t<I1>, indirect-value-t<I2>> &&
+      strict_weak_order<F&, indirect-value-t<I1>, iter_reference_t<I2>> &&
+      strict_weak_order<F&, iter_reference_t<I1>, indirect-value-t<I2>> &&
       strict_weak_order<F&, iter_reference_t<I1>, iter_reference_t<I2>> &&
       strict_weak_order<F&, iter_common_reference_t<I1>, iter_common_reference_t<I2>>;
 }
 ```
 #### Class template `projected` <a id="projected">[[projected]]</a>
 Class template `projected` is used to constrain algorithms that accept
+callable objects and projections [[defns.projection]]. It combines an
 `indirectly_readable` type `I` and a callable object type `Proj` into a
 new `indirectly_readable` type whose `reference` type is the result of
 applying `Proj` to the `iter_reference_t` of `I`.
 ``` cpp
 below imposes constraints on the concepts’ arguments in addition to
 those that appear in the concepts’ bodies [[range.cmp]]. — *end note*]
 #### Concept  <a id="alg.req.ind.move">[[alg.req.ind.move]]</a>
+The `indirectly_movable` concept specifies the relationship between an
+`indirectly_readable` type and an `indirectly_writable` type between
 which values may be moved.
 ``` cpp
 template<class In, class Out>
   concept indirectly_movable =
 state of the value denoted by `*i` is valid but unspecified
 [[lib.types.movedfrom]].
 #### Concept  <a id="alg.req.ind.copy">[[alg.req.ind.copy]]</a>
+The `indirectly_copyable` concept specifies the relationship between an
+`indirectly_readable` type and an `indirectly_writable` type between
 which values may be copied.
 ``` cpp
 template<class In, class Out>
   concept indirectly_copyable =

Diff to HTML by rtfpessoa