https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122224
--- Comment #13 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Gast128 from comment #12)
> I would also prefer a compile time error if --it or (it - n) is not there
> instead of routing it to ++it. One get a compilation error with
> _GLIBCXX_CONCEPT_CHECKS but jwakely on Reddit (you?) stated that these
> checks are broken.
Yes, they only check for the C++98 requirements, as I said in comment 9 above.
I already explained above that a compile-time error is not going to happen, I
consider it unacceptable.
But as also explained above, there is no "routing it to ++it" because it's now
a no-op, or aborts with hardened checks enabled.
> We recently got a crash when porting to Linux since on MSVC
> std::unordered_map supports bidirectional iterators while on GCC it's only
> forward iterators (as cpppreference state that this is the minimum). The
> code compiled fine but gave a crash when invoking std::prev(umap.cend()).
That will be a no-op, or abort at runtime now:
/home/jwakely/gcc/16/include/c++/16.0.0/bits/stl_iterator_base_funcs.h:203:
constexpr void std::__advance(_InputIterator&, _Distance, input_iterator_tag)
[with _InputIterator = __detail::_Node_const_iterator<pair<const int, int>,
false, false>; _Distance = long int]: Assertion '__n >= 0' failed.
Aborted (core dumped)
>
> Also it seems that iterator category calculation is not always precise.
> Consider following example:
>
> struct Dummy
> {
> int GetId() const
> {
> return m_id;
> }
>
> int m_id = 0;
> };
>
>
> std::vector<Dummy> vec;
>
> auto rng = vec | std::views::transform(&Dummy::GetId);
>
> using It = decltype(rng.end());
> using ItCat = typename std::iterator_traits<It>::iterator_category;
>
> static_assert(std::is_same_v<ItCat, std::input_iterator_tag>);
>
> The input iterator category is both determined by MSVC and GCC.
