[Bug libstdc++/115939] Cannot unambiguously compare iterators in std::unordered_map with mapped type std::expected<std::any, Y>>

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115939

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2024-07-15
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I think this is the expected (no pun intended) behaviour. It's a consequence of
std::any being constructible from anything, so the operator== for expected<T,E>
is a candidate for ... well ... anything. Your std::expected<std::any, Y> can
be constructed from nearly every possible type, so the equality comparison
considers a conversion to std::expected<std::any, Y> to be viable, and then use
the operator== for std::expected.

It doesn't help that the operator== is a hidden friend, so only found by ADL,
because your unordered_map::iterator has std::expected<std::any,Y> as an
associated class, so the hidden friend is a candidate.

The way libstdc++ defines the equality operator for unordered_map::iterator
also involves conversions, from unordered_map::iterator to its
_Node_iterator_base base class, so the C++ standard considers them ambiguous.
Without -pedantic GCC does the right thing.

I see two possible solutions to this, but neither of them is possible for you.

Firstly, I have a C++ standard proposal to constrain operator==(expected<T,E>,
U), so that it will not be viable if std::expected<T,E> is not equality
comparable with U (which ti isn't in this case, because U is the
unordered_map::iterator).

Secondly, we could add operator== for the actual iterator type, so that there's
no derived-to-base conversion needed to find a candidate.

I think the only workarounds available to you are to not use -pedantic, and to
not use std::any in this way, where it greedily converts from anything.