Issue 3289: Cannot opt out of C++17 iterator-ness without also opting out of C++20 iterator-ness

This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Resolved status.

3289. Cannot opt out of C++17 iterator-ness without also opting out of C++20 iterator-ness

Section: 24.3.2.3 [iterator.traits], 24.5.5.2 [common.iter.types] Status: Resolved Submitter: Eric Niebler Opened: 2019-09-11 Last modified: 2021-05-18

Priority: 2

View all other issues in [iterator.traits].

View all issues with Resolved status.

Discussion:

The way to non-intrusively say that a type doesn't satisfy the C++17 iterator requirements is to specialize std::iterator_traits and not provide the nested typedefs. However, if a user were to do that, she would also be saying that the type is not a C++20 iterator. That is because readable and weakly_incrementable are specified in terms of iter_value_t and iter_difference_t. Those aliases check to see if std::iterator_traits has been specialized (answer: yes), and if so resolve to std::iterator_traits::value_type and std::iterator_traits::difference_type respectively.

The proper way to opt out of C++17 iterator-ness while opting in to C++20 iterator-ness would be to specialize std::iterator_traits and specify all the nested typedefs except ::iterator_category. That's a bit weird and may throw off code that is expecting all the typedefs to be there, or none of them, so instead we can suggest users to set the iterator_category typedef to denote output_iterator_tag, which is a harmless lie; generic C++17 code will get the message: this iterator is not a c++17 input iterator, which is the salient bit.

We then must fix up all the places in the Ranges clause that make faulty assumptions about an iterator's iterator_category typedef (as distinct from the iterator concept that it models).

[2019-10-19 Issue Prioritization]

Priority to 1 after reflector discussion.

[2019-11 Wednesday night Issue processing in Belfast]

Much discussion; no consensus that this is a good approach. Need to coordinate between this and 3283⁽ⁱ⁾

Previous resolution [SUPERSEDED]:

This wording is relative to N4830.
Modify 24.3.2.3 [iterator.traits] as indicated:

-4- Explicit or partial specializations of iterator_traits may have a member type iterator_concept that is used to indicate conformance to the iterator concepts (24.3.4 [iterator.concepts]). [Example: To indicate conformance to the input_iterator concept but a lack of conformance to the Cpp17InputIterator requirements (24.3.5.3 [input.iterators]), an iterator_traits specialization might have iterator_concept denote input_iterator_tag and iterator_category denote output_iterator_tag. — end example]

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

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

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

(1.2) — iterator_category denotes forward_iterator_tag if iterator_traits::iterator_category models derived_from<forward_iterator_tag>; otherwise it denotes input_iterator_tagiterator_traits::iterator_category.

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

Modify 25.7.8.3 [range.filter.iterator] as indicated:

-3- iterator::iterator_category is defined as follows:

(3.1) — Let C denote the type iterator_traits<iterator_t<V>>::iterator_category.

(3.2) — If C models derived_from<bidirectional_iterator_tag>, then iterator_category denotes bidirectional_iterator_tag.

~~(3.3) — Otherwise, if C models derived_from<forward_iterator_tag>, then iterator_category denotes forward_iterator_tag.~~

(3.4) — Otherwise, iterator_category denotes input_iterator_tagC.

Modify 25.7.14.3 [range.join.iterator] as indicated:

-3- iterator::iterator_category is defined as follows:

(3.1) — Let OUTERC denote iterator_traits<iterator_t<Base>>::iterator_category, and let INNERC denote iterator_traits<iterator_t<range_reference_t<Base>>>::iterator_category.

(3.?) — If OUTERC does not model derived_from<input_iterator_tag>, iterator_category denotes OUTERC.

(3.?) — Otherwise, if INNERC does not model derived_from<input_iterator_tag>, iterator_category denotes INNERC.

(3.2) — Otherwise, iIf ref_is_glvalue is true,

(3.2.1) — If OUTERC and INNERC each model derived_from<bidirectional_iterator_tag>, iterator_category denotes bidirectional_iterator_tag.

(3.2.2) — Otherwise, if OUTERC and INNERC each model derived_from<forward_iterator_tag>, iterator_category denotes forward_iterator_tag.

(3.3) — Otherwise, iterator_category denotes input_iterator_tag.
Modify [range.split.outer] as indicated:
namespace std::ranges {
 template<class V, class Pattern>
 template<bool Const>
 struct split_view<V, Pattern>::outer_iterator {
 private:
 […]
 public:
 using iterator_concept =
 conditional_t<forward_range<Base>, forward_iterator_tag, input_iterator_tag>;
 using iterator_category = see belowinput_iterator_tag;
 […]
 };
 […]
}
-?- The typedef-name iterator_category denotes input_iterator_tag if iterator_traits<iterator_t<Base>>::iterator_category models derived_from<input_iterator_tag>, and iterator_traits<iterator_t<Base>>::iterator_category otherwise.
-1- Many of the following specifications refer to the notional member current of outer_iterator. current is equivalent to current_ if V models forward_range, and parent_->current_ otherwise.
Modify [range.split.inner] as indicated:

-1- The typedef-name iterator_category denotes forward_iterator_tag if iterator_traits<iterator_t<Base>>::iterator_category models derived_from<forward_iterator_tag>, and input_iterator_tagiterator_traits<iterator_t<Base>>::iterator_category otherwise.

[2020-02-10, Prague]

The issue is out of sync with the current working draft, Daniel provides a synchronized merge.

[2020-02-13, Prague; Priority reduced to 2 after LWG discussion]

[2021-05-18 Resolved by the adoption of P2259R1 at the February 2021 plenary. Status changed: New → Resolved.]

Proposed resolution:

This wording is relative to N4849.

Modify 24.3.2.3 [iterator.traits] as indicated:

-4- Explicit or partial specializations of iterator_traits may have a member type iterator_concept that is used to indicate conformance to the iterator concepts (24.3.4 [iterator.concepts]). [Example: To indicate conformance to the input_iterator concept but a lack of conformance to the Cpp17InputIterator requirements (24.3.5.3 [input.iterators]), an iterator_traits specialization might have iterator_concept denote input_iterator_tag and iterator_category denote output_iterator_tag. — end example]
Modify 24.5.5.2 [common.iter.types] as indicated:
-1- The 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 iterator_traits::iterator_category models derived_from<forward_iterator_tag>; otherwise it denotes input_iterator_tagiterator_traits::iterator_category.
3. (1.3) — If the expression a.operator->() is well-formed, where a is an lvalue of type const common_iterator<I, S>, then pointer denotes the type of that expression. Otherwise, pointer denotes void.
Modify 25.7.8.3 [range.filter.iterator] as indicated:
-3- iterator::iterator_category is defined as follows:
1. (3.1) — Let C denote the type iterator_traits<iterator_t<V>>::iterator_category.
2. (3.2) — If C models derived_from<bidirectional_iterator_tag>, then iterator_category denotes bidirectional_iterator_tag.
3. ~~(3.3) — Otherwise, if C models derived_from<forward_iterator_tag>, then iterator_category denotes forward_iterator_tag.~~
4. (3.4) — Otherwise, iterator_category denotes C.
Modify 25.7.14.3 [range.join.iterator] as indicated:
-2- iterator::iterator_category is defined as follows:
1. (2.1) — Let OUTERC denote iterator_traits<iterator_t<Base>>::iterator_category, and let INNERC denote iterator_traits<iterator_t<range_reference_t<Base>>>::iterator_category.
2. (2.?) — If OUTERC does not model derived_from<input_iterator_tag>, iterator_category denotes OUTERC.
3. (2.?) — Otherwise, if INNERC does not model derived_from<input_iterator_tag>, iterator_category denotes INNERC.
4. (2.2) — Otherwise, iIf ref-is-glvalue is true and OUTERC and INNERC each model derived_from<bidirectional_iterator_tag>, iterator_category denotes bidirectional_iterator_tag.
5. (2.3) — Otherwise, if ref-is-glvalue is true and OUTERC and INNERC each model derived_from<forward_iterator_tag>, iterator_category denotes forward_iterator_tag.
6. (2.4) — Otherwise, if OUTERC and INNERC each model derived_from<input_iterator_tag>, iterator_category denotes input_iterator_tag.
7. (2.5) — Otherwise, iterator_category denotes output_iterator_tag.
Modify [range.split.outer] as indicated:

[Drafting note: The previous wording change has been adjusted to follow the pattern used in [range.split.inner] p1.]
```
namespace std::ranges {
 template<class V, class Pattern>
 template<bool Const>
 struct split_view<V, Pattern>::outer_iterator {
 private:
 […]
 public:
 using iterator_concept =
 conditional_t<forward_range<Base>, forward_iterator_tag, input_iterator_tag>;
 using iterator_category = see belowinput_iterator_tag;
 […]
 };
 […]
}
```
-?- The typedef-name iterator_category denotes:
1. (?.?) — input_iterator_tag if iterator_traits<iterator_t<Base>>::iterator_category models derived_from<input_iterator_tag>;
2. (?.?) — otherwise, iterator_traits<iterator_t<Base>>::iterator_category.
-1- Many of the following specifications refer to the notional member current of outer-iterator. current is equivalent to current_ if V models forward_range, and parent_->current_ otherwise.