_LIBCXX_DEBUG value initialized singular iterators assert failures in std algorithms

[Maciej Miera <maciej.miera@gmail.com>]

Hello,

I have tried to introduce an extra level of safety to my codebase and utilize _GLIBCXX_DEBUG in my test builds in order to catch faulty iterators.
However, I have encountered the following problem: I would like to utilize singular, value-initialized iterators as an arbitrary "null range”.
However, this leads to failed assertions in std:: algorithms taking such range.

Consider the following code sample with find_if:

#include <map>
#include <algorithm>
#include <iterator>

#ifndef __cpp_lib_null_iterators
#warning "Not standard compliant"
#endif

int main()
{
    std::multimap<char, int>::iterator it1{};
    std::multimap<char, int>::iterator it2{};

    (void) (it1==it2); // OK
    (void) std::find_if(
        it1, it2, [](const auto& el) { return el.second == 8;});
}

Compiled with -std=c++20 and -D_GLIBCXX_DEBUG it produces the warning "Not standard compliant"
and the execution results in the following assert failure:

/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/bits/stl_algo.h:3875:
In function:
    constexpr _IIter std::find_if(_IIter, _IIter, _Predicate) [with _IIter = 
    gnu_debug::_Safe_iterator<_Rb_tree_iterator<pair<const char, int> >, 
    debug::multimap<char, int>, bidirectional_iterator_tag>; _Predicate = 
    main()::<lambda(const auto:16&)>]

The question is though: is it by design, or is it just a mere oversight? The warning actually suggest the first option.
If it is an intentional design choice, could you provide some rationale behind it, please?

Compiler explorer link with demo below:
https://godbolt.org/z/e8xa5Eoqn

Best regards,
A M. Miera