Created on 2023-10-27.00:00:00 last changed 3 weeks ago
This wording is relative to N4964.
Modify [range.iota.iterator] as indicated:
[Drafting note: When W only models input_or_output_iterator, it implies that its pre- and post-increment are not equality-preserving, so iterator_concept should be input_iterator_tag.]
-1- iterator::iterator_concept is defined as follows:
If W models advanceable, then iterator_concept is random_access_iterator_tag.
(1.2) — Otherwise, if W models decrementable, then iterator_concept is bidirectional_iterator_tag.
(1.3) — Otherwise, if W models incrementable, then iterator_concept is forward_iterator_tag.
(1.4) — Otherwise, iterator_concept is input_iterator_tag.
[ 2023-11-07; Reflector poll ]
Set priority to 3 after reflector poll.
"This would change the iterator concept for types which model
advanceable but do not model
random_access_iterator. A type with +=
and -= and operator* will currently get
but this proposed resolution would change it to
"If we want to handle this case (and not leave it as IFNDR - the type
incrementable) then we need to account
for it everywhere we are currently using
equality_comparable?), and not just in the concept."
When W models incrementable, the iota_view iterator will be a forward_iterator, which accidentally makes iota_view<istream_iterator<int>> satisfies forward_range, which is obviously incorrect.Since iterator types are well within the domain of W, it seems more appropriate and accurate to define the iterator_concept through the iterator concept in this case.
|2023-11-07 18:35:04||admin||set||messages: + msg13822|
|2023-10-28 13:17:11||admin||set||messages: + msg13775|