[cfe-dev] Spaceship operator oddity with optional

Arthur O'Dwyer via cfe-dev cfe-dev at lists.llvm.org
Tue Jan 26 08:14:23 PST 2021


On Tue, Jan 26, 2021 at 8:58 AM Nuno Lopes via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

>
> I just bumped into this mysterious behavior with the spaceship operator
> over
> optional:
>
> struct expr {
>   std::strong_ordering operator<=>(const expr &rhs) const;
>   //bool operator==(const expr &rhs) const;
> };
>
> int f() {
>   return std::is_eq(std::optional<expr>() <=> std::optional<expr>());
>   //return std::optional<expr>() == std::optional<expr>();
> }
>
> Function f() returns 0 both on gcc & clang trunk
> (https://gcc.godbolt.org/z/fv85eP).
> However, if you uncomment the operator==() line, the function starts
> returning 1.
>
> The documentation of
> https://en.cppreference.com/w/cpp/utility/optional/operator_cmp just says:
>     7) If bool(lhs) && bool(rhs) is true returns *x <=> *y
>       Otherwise, returns bool(lhs) <=> bool(rhs)
>
> So no word about operator=='s existence.
> Is this a bug in both clang & gcc or just some unobvious 3-way comparison
> rule I'm not aware?
>

I haven't dug deep, but based on your description it's an issue with *GNU
libstdc++*, not an issue with either of the compilers themselves.
Neither libc++ nor Microsoft STL support C++20 optional::operator<=> yet;
libstdc++ is the only library vendor who's tried to implement it, and if
their implementation doesn't match your expectations, then my guess is that
it's a bug in their implementation. (Or, perhaps, a bug in your
expectations — but I give it more than 50/50 it's an implementation bug in
libstdc++. The details of operator-spaceship have changed *many* times in
the past 3 years and maybe GNU libstdc++ is implementing some older
version.)

https://gcc.godbolt.org/z/ofxPss
My guess is that libstdc++ std::optional hasn't caught up to the compiler
changes from
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1185r2.html

HTH,
Arthur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20210126/7a463086/attachment.html>


More information about the cfe-dev mailing list