Bug 97934 - Adding an operator== breaks implicit operator== generation from defaulted <=>
Summary: Adding an operator== breaks implicit operator== generation from defaulted <=>
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 10.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: rejects-valid
Depends on:
Blocks:
 
Reported: 2020-11-21 22:09 UTC by Barry Revzin
Modified: 2021-09-23 07:13 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2020-11-21 00:00:00

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Barry Revzin 2020-11-21 22:09:27 UTC 
Reduced example:

#include <compare>

struct X
{
    auto operator<=>(X const&) const = default;
    auto operator==(int i) const;
};

bool f(X x) {
    return x == x;
}

gcc trunk rejects this saying no matching candidate. The presence of the unrelated operator== seems to prevent the generation of X::operator==(X const&) const from the defaulted <=>.
Comment 1 Marek Polacek 2020-11-21 22:20:47 UTC 
Confirmed.
Comment 2 ensadc 2020-11-22 01:59:56 UTC 
Per [class.compare.default] (http://eel.is/c++draft/class.compare.default#5.sentence-1 ), the == operator is implicitly generated if the member-specification does not declare *any* operator==. So the current behavior seems correct?
Comment 3 Fedor Chelnokov 2021-09-23 07:13:29 UTC 
I believe, GCC is correct here as well as other compilers: https://gcc.godbolt.org/z/4nrdedbGd