From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id B38723858C00 for ; Mon, 7 Nov 2022 22:04:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B38723858C00 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1667858673; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=J7vytjoEmml4HEW6Q8oQdw3d9sNZXyd9jMa9JOz54q0=; b=RP6GdrstVhM22s0oqJL1CbCmsW4MWakDLcYq9We9vB8qFT3b+KTKR2WC8rhd6pCV23gFyW 8lvZdNTiWdjg3Az2jrBrBujzWTEgtf6rG01uYh0Ix86fU1OYW+Kh/cdwajJ/3NVLARRGNc FymDgZGLcl2kXcGPqFWLespqSgT81Ys= Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-520-NHq01RS8NZSsQpCLVeSpQw-1; Mon, 07 Nov 2022 17:04:32 -0500 X-MC-Unique: NHq01RS8NZSsQpCLVeSpQw-1 Received: by mail-ed1-f72.google.com with SMTP id h9-20020a05640250c900b00461d8ee12e2so9317321edb.23 for ; Mon, 07 Nov 2022 14:04:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=J7vytjoEmml4HEW6Q8oQdw3d9sNZXyd9jMa9JOz54q0=; b=NlvgpdlQYb8JOAPR9dleozw398fN6VffbFv4mXazc6KDislaVEZZz+VMM6f0uWnXsk h0BK++hnu0BOAdEslt57/AEVmmgGjHVtoTyOCJk94ocH+4Vvha4XPkq6ZVyEPb/MjSS6 0e9DJLq7ZQE4u9MkY86IqTGJwLKztIe+x5op58bOhZDLJ4mlkVTxcqntvNVTFZPEBzVX ANSLAmKe7JqMDYhvV+U6TEkZyCaq39JmAw2htQanesC4uvqFo5ytbHscPA01fo/Zyrj4 8cFjKNagnPZhAWLjseERtEd9wh4/4DIWcnX5H3mVNpeGqGjxgovT0k0GzQUXpcsab3Hx XwmA== X-Gm-Message-State: ACrzQf0v31/ngQHbVelKOkNQWIi50RMzhj743VFAtgXbur3kEycE0ho6 DCTZ47f5I+qFL5Ad7gKqBJhTvN5SMn+kWEdt6iderSZXyDZofbGs8tJjEYSa6MjJZk1b+rDXKrB Qbkpb5C1pLFH5uwyE/f3Ms7zJ1nObM7Jm5w== X-Received: by 2002:a17:906:fe46:b0:73d:939a:ec99 with SMTP id wz6-20020a170906fe4600b0073d939aec99mr50392788ejb.169.1667858670945; Mon, 07 Nov 2022 14:04:30 -0800 (PST) X-Google-Smtp-Source: AMsMyM7jFC4dDagl07cJ9IuY+V55gcLW/VJqw9gwtHBJYXVVNAmP+E6rhEa6ERgeZXBUoK2zWD9fzA6bhWMd1g9ibR0= X-Received: by 2002:a17:906:fe46:b0:73d:939a:ec99 with SMTP id wz6-20020a170906fe4600b0073d939aec99mr50392773ejb.169.1667858670738; Mon, 07 Nov 2022 14:04:30 -0800 (PST) MIME-Version: 1.0 References: <20221107205752.2735464-1-jason@redhat.com> In-Reply-To: From: Jonathan Wakely Date: Mon, 7 Nov 2022 22:04:20 +0000 Message-ID: Subject: Re: [PATCH RFC(libstdc++)] c++: implement P2468R2, the equality operator you are looking for To: Jason Merrill Cc: gcc-patches@gcc.gnu.org, Jakub Jelinek X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, 7 Nov 2022 at 21:56, Jonathan Wakely wrote: > > On Mon, 7 Nov 2022 at 20:58, Jason Merrill wrote: > > > > Tested x86_64-pc-linux-gnu. Jonathan, what do you want to do about the library > > test failure? > > > > -- >8 -- > > > > This paper is resolving the problem of well-formed C++17 code becoming > > ambiguous in C++20 due to asymmetrical operator== being compared with itself > > in reverse. I had previously implemented a tiebreaker such that if the two > > candidates were functions with the same parameter types, we would prefer the > > non-reversed candidate. But the committee went with a different approach: > > if there's an operator!= with the same parameter types as the operator==, > > don't consider the reversed form of the ==. > > > > So this patch implements that, and changes my old tiebreaker to give a > > pedwarn if it is used. I also noticed that we were giving duplicate errors > > for some testcases, and fixed the tourney logic to avoid that. > > > > As a result, a lot of tests of the form > > > > struct A { bool operator==(const A&); }; > > > > need to be fixed to add a const function-cv-qualifier, e.g. > > > > struct A { bool operator==(const A&) const; }; > > > > The committee thought such code ought to be fixed, so breaking it was fine. > > > > 18_support/comparisons/algorithms/fallback.cc also breaks with this patch, > > because of the similarly asymmetrical > > > > bool operator==(const S&, S&) { return true; } > > > > I assume this was written this way deliberately, so I'm not sure what to do > > about it. > > Yes, that was deliberate. The compare_strong_order_fallback function > has these constraints: > > template _Up> > requires __strongly_ordered<_Tp, _Up> || __op_eq_lt<_Tp, _Up> > constexpr strong_ordering > operator() [[nodiscard]] (_Tp&& __e, _Up&& __f) const > > And similarly for the other fallbacks. So I wanted to check that two > types that decay to the same type (like S and const S) can be compared > with == and <, and therefore can be used with this function. > > But if such asymmetry is no longer allowed, maybe the library function > is no longer usable with pathological cases like the test, and so the > test should be changed. We can't just replace the decayed_same_as > constraint with same_as because the std::strong_order customization > point still supports similar types, but we could do: > > --- a/libstdc++-v3/libsupc++/compare > +++ b/libstdc++-v3/libsupc++/compare > @@ -1057,11 +1057,11 @@ namespace std _GLIBCXX_VISIBILITY(default) > }; > > template > - concept __op_eq_lt = requires(_Tp&& __t, _Up&& __u) > + concept __op_eq_lt = same_as<_Tp, _Up> && requires(_Tp&& __t) > { > - { static_cast<_Tp&&>(__t) == static_cast<_Up&&>(__u) } > + { static_cast<_Tp&&>(__t) == static_cast<_Tp&&>(__t) } > -> convertible_to; > - { static_cast<_Tp&&>(__t) < static_cast<_Up&&>(__u) } > + { static_cast<_Tp&&>(__t) < static_cast<_Tp&&>(__t) } > -> convertible_to; > }; No wait, that's nonsense. We can still try to compare similar types, it's just that they won't be comparable unless their comparison ops have two parameters of the same type. > And then adjust the test accordingly. If those fallbacks can no longer > support mixed types, does the resolution of > https://cplusplus.github.io/LWG/issue3465 even make sense now? If E > and F must be the same type now, then E < F already implies F < E. I > think we need some library changes to sync with P2468R2. I think this bit was right though. E and F might be different types, but E < F implies F < E. Is that right?