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.
