Talk:cpp/named req/Iterator

I currently wonder where comparison (==, !=) comes in as requirement - until now I always thought it must be possible to compare any two iterators (of the same type) for equality and inequality?

Is this an indirect consequence of some other requirement?

Mwe (talk) 09:29, 6 July 2015 (PDT)

equality/inequality is defined for some (but not all, and possibly changing over time) set values of an LegacyInputIterator, and for all values of LegacyForwardIterator that are for the same sequence --Cubbi (talk) 11:23, 6 July 2015 (PDT)

Thanks! So, in an attempt to come up with an example of an iterator that is "an LegacyIterator only", not also an LegacyInputIterator or LegacyForwardIterator: I can dress-up an algorithm generating an - at least in principle - "unbounded" sequence (say primes or random numbers) with an interface using operator*() to fetch the current value and operator++() / operator++(int) to set the next value and it's perfect a model of the (pure) LegacyIterator concept and might be used to fill a container with std::copy_n.

What about adding an example like that to clarify what the "pure" LegacyIterator is good for?

Or do you prefer to give (usage) examples only for concrete classes and/or functions?

Mwe (talk) 03:36, 7 July 2015 (PDT)

I don't know what it is useful for, since it doesn't necessarily allow reading from or writing to the referenced element. It seems like a pure abstraction to me. --Cubbi (talk) 06:41, 7 July 2015 (PDT)

wilhelmtell (talk) 06:29, 12 October 2016 (PDT) There was a "see below" note on incrementable iterators. If there are any notes to add on that, I think we should add them; otherwise, I removed that "see below" note.

the note the "see below" referred to was the last sentence in the page: "Iterators for which the behavior of the expression ++i is defined are called incrementable." --Cubbi (talk) 06:44, 12 October 2016 (PDT)

---

All Iterators recently became LegacyIterators, through the use of global replace in Template:named req/core: LegacyIterator.

I think this hurts readability (there's nothing in any of the pages that explains why they'd be legacy), but more importantly, I don't think these requirements are actually legacy. Looking at P0896R3 (The One Ranges Proposal, AKA Merging the Ranges TS), section 22.3.1 is updated to talk about the Iterator concepts, but the preexisting iterator requirements are in no way obsoleted. Specifically, 22.3.1.3 (Which seems to be adopted as-is in n4791):

The six categories of iterators correspond to the iterator concepts InputIterator (22.3.4.9), OutputIterator (22.3.4.10), ForwardIterator (22.3.4.11), BidirectionalIterator (22.3.4.12) RandomAccessIterator (22.3.4.13), and ContiguousIterator (22.3.4.14), respectively. The generic term iterator refers to any type that models the Iterator concept (22.3.4.6).

So, I think this change should be reverted. D0sboots (talk) 15:02, 27 December 2018 (PST)

In C++17 and before there were only five categories (no ContiguousIterator). They are now renamed to Cpp17Iterator etc in the draft standard and are specified in [iterator.cpp17]. The six categories you see are new categories. --114.222.58.164 15:20, 27 December 2018 (PST)

Ah, I see now. The new iterator categories are introduced in section 22.3.1, and defined in terms of the new iterator concepts in 22.3.4. The (old) Cpp17Iterator categories are laid out in section 22.3.5.

In that case, I amend my earlier request, and suggest that the re-write be changed from "LegacyIterator" to "Cpp17Iterator" to line up with the standard. (I can do it myself, but it seems like the sort of thing there should be some kind of consensus for.) D0sboots (talk) 20:31, 2 January 2019 (PST)

Unlike the standard, the names we pick need to work for all relevant standard revisions. I'm not going to document a C++98 component as requiring a Cpp17Thingamabob. That's a non-starter. T. Canens (talk) 01:57, 3 January 2019 (PST)

I guess the main issue I have with "Legacy" is that it is very similar to "Deprecated" - it implies that this thing is out-of-date or obsolete, and you should switch to the newer version. The problem is that in this case, the newer version doesn't exist yet - as the FAQ says, the focus of the site is currently on the latest published version of C++, which is C++17. C++20 won't be published for at least a year yet. Yes, we have high confidence that the state of iterators won't change much between now and when C++20 is formalized, but as long as the current iterator categories are the latest ones according to the current standard, it feels wrong to mark them as "legacy."

I wish I had a magic better name to suggest, but all the ones I can think of have their own issues. ("OriginalIterator", "Cpp98Iterator", "NonConceptIterator", just leaving it and taking the duplicate name hit, ...) My preferred approach would be "use Legacy, but hold off until C++20 is the official language." But that may not be workable for some technical migration reason... D0sboots (talk) 17:39, 3 January 2019 (PST)

I guess the real problem is, we need to clarify that iterators that satisfy the LegacyFooIterator requirements aren't themselves legacy or subject to removal. E.g. cpp/iterator/insert_iterator currently says "std::insert_iterator is an LegacyOutputIterator ...", but it should probably read "std::insert_iterator is an iterator that satisfies the requirements of LegacyOutputIterator, and ..." --D41D8CD98F (talk) 00:47, 4 January 2019 (PST)