Iterator concepts

[Quasar Chunawala]

Hi @APalley, @Daniel Duffy, @Paul Lopez,

From skimming through named requirements and iterator concepts on cppreference.com, I draw the inference that prior to C++20, things like InputIterator(now LegacyInputIterator) ForwardIterator(now LegacyForwardIterator) only existed as named requirements (as defined in the standard) and not baked in in the language. The burden to ensure that a type T satisfies a requirement R lies with the algorithm user. Also, I imagine, you can't write a trait(type metafunction), for something like a, RandomAccessIterator which must support O(1) constant-time ++ and += operations.

So, pre- C++20 iterator concepts aren't actually concepts in the sense of the C++20 language feature.

With C++20, these requirements have been formalized as C++ concepts. The older STL algorithm variants have been left untouched. For instance, if you look at std::find, an implementation would have the interface:

template< class InputIt, class T >
InputIt find( InputIt first, InputIt last, const T& value );

So, it doesn't use concepts in the template header. The user of the legacy algorithms has to vouch for the passed types to satisfy the legacy requirements stated in the standard, otherwise the call will cause undefined behavior.

But, the newer ranges algorithms, for example, ranges::find constrain the arguments to satisfy various predicates.

template< std::input_iterator I, ...>,
constexpr I find(I first,...)

Is my understanding correct; is my deduction/inference is on spot, or do you have some thoughts.

 

[Daniel Duffy]

So, pre- C++20 iterator concepts aren't actually concepts in the sense of the C++20 language feature.
DD probably not

With C++20, these requirements have been formalized as C++ concepts. The older STL algorithm variants have been left untouched. For instance, if you look at std::find, an implementation would have the interface:
DD If it ain't broke, don't fix it.