New iterator requirements

I noticed that most if not all containers now require their ::iterator type to satisfy LegacySomethingIterator instead of SomethingIterator.

For example, std::vector<>::iterator now requires:

iterator LegacyRandomAccessIterator

This seems to be the same for most of the other containers, all requiring their iterators to go from SomethingIterator to LegacySomethingIterator.

There are also the "new" requirements that took the names of the old requirements, such as RandomAccessIterator, why were these added? It seems to me that the new variants just shadow the legacy variants, no differences.

Why were new ones created in the first place, their requirements look the same to me. Why don't the new ones just replace the old requirements instead of right now having 2 different names for them (e.g. RandomAccessIterator and LegacyRandomAccessIterator)?


These are not new things, hence the term "legacy". This is simply how the cppreference site chooses to reconcile the fact that C++20 will have two different things that are both "concepts" called "RandomAccessIterator" (well, until C++20 decided to rename their version random_access_iterator).

Pre-C++20, a "concept" was just a set of requirements in the standard that represented the behavior expected of certain template parameters. In C++20, with concepts becoming an actual language feature, that needed to shift. The problem is that the Ranges concept of "RandomAccessIterator" is not the same as the old-style "concept" of "RandomAccessIterator".

Since C++ considers them both to be "concepts" (though only the newer one is a concept in the language sense), they would both have the same page name on the Wiki. And MediaWiki doesn't really allow that.

So the maintainers of the site settled on using "Legacy" to differentiate them. Note that the actual standard doesn't use this "Legacy" prefix.

Note that the C++20 standard does have a prefix for the older concepts: "Cpp17". So the old concept would be "Cpp17RandomAccessIterator". That was not deemed appropriate for Cppreference for obvious reasons.