Proposed resolution:

This wording is relative to N4950.

1. Modify [common.iterator] as indicated:

   namespace std {
     […]
   
     template<input_iterator I, class S>
     struct iterator_traits<common_iterator<I, S>> {
       using iterator_concept = see below;
       using iterator_category = see below; // not always present
       using value_type = iter_value_t<I>;
       using difference_type = iter_difference_t<I>;
       using pointer = see below;
       using reference = iter_reference_t<I>;
     };
   }
   

2. Modify [common.iter.types] as indicated:

   -?- The nested typedef-name iterator_category of the specialization of iterator_traits for common_iterator<I, S> is defined if and only if iter_difference_t<I> is an integral type. In that case, iterator_category denotes forward_iterator_tag if the qualified-id iterator_traits<I>::iterator_category is valid and denotes a type that models derived_from<forward_iterator_tag>; otherwise it denotes input_iterator_tag.

   -1- The remaining nested typedef-names of the specialization of iterator_traits for common_iterator<I, S> are defined as follows.:

   1. (1.1) — iterator_concept denotes forward_iterator_tag if I models forward_iterator; otherwise it denotes input_iterator_tag.

   2. (1.2) — iterator_category denotes forward_iterator_tag if the qualified-id iterator_traits<I>::iterator_category is valid and denotes a type that models derived_from<forward_iterator_tag>; otherwise it denotes input_iterator_tag.

   3. (1.3) — Let a denote an lvalue of type const common_iterator<I, S>. If the expression a.operator->() is well-formed, then pointer denotes decltype(a.operator->()). Otherwise, pointer denotes void.

[ 2023-11-11 Approved at November 2023 meeting in Kona. Status changed: Voting → WP. ]

[ 2023-06-14 Varna; Move to Ready ]

[ 2023-06-13; Varna; Tomasz provides wording ]

[ 2022-08-23; Reflector poll ]

Set priority to 2 after reflector poll.

"I think common_iterator should reject iterators with integer-class difference types since it can't possibly achieve the design intent of adapting them to Cpp17Iterators."

"I'm not yet convinced that we need to outright reject such uses, but I'm pretty sure that we shouldn't mess with the difference type and that the PR is in the wrong direction."

The partial specialization of iterator_traits for common_iterator is defined in [common.iterator] as

template<input_iterator I, class S>
struct iterator_traits<common_iterator<I, S>> {
  using iterator_concept = see below;
  using iterator_category = see below;
  using value_type = iter_value_t<I>;
  using difference_type = iter_difference_t<I>;
  using pointer = see below;
  using reference = iter_reference_t<I>;
};

where difference_type is defined as iter_difference_t<I> and iterator_category is defined as at least input_iterator_tag. However, when difference_type is an integer-class type, common_iterator does not satisfy Cpp17InputIterator, which makes iterator_category incorrectly defined as input_iterator_tag.

Since the main purpose of common_iterator is to be compatible with the legacy iterator system, which is reflected in its efforts to try to provide the operations required by C++17 iterators even if the underlying iterator does not support it. We should handle this case of difference type incompatibility as well.

The proposed solution is to provide a C++17 conforming difference type by clamping the integer-class type to ptrdiff_t.

Daniel:

The second part of this issue provides an alternative resolution for the first part of LWG 3748 and solves the casting problem mentioned in LWG 3748 as well.