https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115939
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|NEW |RESOLVED
Target Milestone|--- |14.3
--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #1)
> 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).
Done for GCC 15 by r15-4337-g0515b2436b7c7e (that doesn't backport cleanly but
it shouldn't be hard to resolve the merge conflicts, and I think I should
backport it to gcc-14).
> Secondly, we could add operator== for the actual iterator type, so that
> there's no derived-to-base conversion needed to find a candidate.
Done for GCC 14.3 by r14-11450-gb5d04ffcdf3007 and GCC 15 by
r15-3130-g591b71993f15ed
I'm going to close this as fixed, I don't plan to change the gcc-13 branch.
