Jason,

The type "std::iterator<T>", is not dumb.

Actually this type is a controller over the container it was templated for.

In other words, the "std::iterator<T>" specialization knows exactly what it encloses. And that is manifested in the implementation of the operators:

operator ++ // the 2 flavors 

operator --   // also the 2 flavors,  post and pre

operator *

For a random access iterator these operators are trivial and mimic the plain pointer behavior.

But for "std::list", "std::set"...etc they are not trivial since they need to know how to jump to the next element and dereference it.

Knowing this, we can conclude that these "std::iterator" specializations have a knowledge of their container elements, thus they know where that container ends, they just need to call "std::end(container)"

The proper question is: where in the implementation we should call "std::end"?

If we put it inside the operators which move the index (like "operator++()"), it will not be efficient since we are adding 2 instructions, (especially if the access to the elements is linear like in the forward list), the extra instructions are:

-1 a fetch for a value, namely "std::end"

-2 and a test against it.

So, the silliest solution is to add a member method to the "std::iterator" class i.e

operator bool() const noexcept {return *this == m_containerPtr->end();}

So in a bool context it will be called naturally. Expl

while (++iter) {};

Otherwise,  there is no cost for what you don't use.

This member function is, strangely, absent in all specifications of the different types of iterators classes.(legacyrandom..., legacyfoward...etc).

My proposal for "null_iter" if of different paradigm.

But for now, i would like to read your comments on the above.

I will elaborate the paradigm of "null_iter", if need raises.

Regards

Nadir