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 E7A6E3858D39 for ; Mon, 7 Nov 2022 21:56:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E7A6E3858D39 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=1667858197; 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=wHfBwExbGhVgVNEM6NZpshAdnN/RrPGRXPHY3jTbArg=; b=Etg+radnld5MIq0VW6ydle3m+CM3oAJePNOe9PVelyA/fXbHSKNHZtNf6X6rZM/XK1JebC djCX7Xp+meylh1SHm6HPq+DsSrKhYP+IBzPc+lWiod2kIPHnLjDnxiKUmC05g+epnKIEET a2iT9jvF8FqfQ/kWauMMIkPGr2Th4AE= Received: from mail-ej1-f70.google.com (mail-ej1-f70.google.com [209.85.218.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-632-rnFLS_jMMu-M13en1pZ9Hg-1; Mon, 07 Nov 2022 16:56:36 -0500 X-MC-Unique: rnFLS_jMMu-M13en1pZ9Hg-1 Received: by mail-ej1-f70.google.com with SMTP id jg27-20020a170907971b00b007ad9892f5f6so7124572ejc.7 for ; Mon, 07 Nov 2022 13:56:36 -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=wHfBwExbGhVgVNEM6NZpshAdnN/RrPGRXPHY3jTbArg=; b=aSC6p2sTnMf1PTS59BQ15eolO1zvg5n7q6kopnq4chMnNNkmmnTTpvYARn/Iw4hdaY /lPS7QZG6RqnGSXda1Ez86KIwZYfuqyMSJg9oioWMdCBtFRoD3ON3wFSy3dCcUlUUHf2 myXJbd0HzC1HUITHxQmKLW7IwHI5jg65+4XnBjbZiVv/koHp66G+rEhplWNyf4dlD6Fq T+Mbms9MpW0QLDlkjUDmGwm5ytbPWF0qGyQ2I6PvIbcqObuJbBDDnbK1hr1xqs1Kgg8C prihFzwPXecMGmZkSJjkCCgJFHflRmDKGwPGlPnNHZlO9Fqpq+HvkZH3DMSBXEGustBp abKw== X-Gm-Message-State: ACrzQf2OrFLlx8QPOQ1yKR4MXA6hUkt/k6IFkxt6WY7rX5y0hg+Fozhh swgUQSuZjlxoyUEBWK2oCHLj7fs3mrcJcG3X/v2auxZAmnhaZgglbJ4o8Nri/Fo0hu2tAoziFQc O50mcv+pWzrhw89BzWFrK6I9JovSpJypeFg== X-Received: by 2002:a05:6402:50d4:b0:461:e349:56b2 with SMTP id h20-20020a05640250d400b00461e34956b2mr53531561edb.17.1667858195275; Mon, 07 Nov 2022 13:56:35 -0800 (PST) X-Google-Smtp-Source: AMsMyM7YtUfro3f0d2G+HJdGbHYM55lxg/LuB0ZR94yUk+nXuCoFIgw717rF490tpdQDxkK1ydiNLGKr3ULwyKoQLDo= X-Received: by 2002:a05:6402:50d4:b0:461:e349:56b2 with SMTP id h20-20020a05640250d400b00461e34956b2mr53531547edb.17.1667858195045; Mon, 07 Nov 2022 13:56:35 -0800 (PST) MIME-Version: 1.0 References: <20221107205752.2735464-1-jason@redhat.com> In-Reply-To: <20221107205752.2735464-1-jason@redhat.com> From: Jonathan Wakely Date: Mon, 7 Nov 2022 21:56:24 +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.5 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 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; }; 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.