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.129.124]) by sourceware.org (Postfix) with ESMTPS id D2FF93858D32 for ; Tue, 23 Aug 2022 12:03:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D2FF93858D32 Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-601-EIDW5A-iNpmjs5hUPJBHOg-1; Tue, 23 Aug 2022 08:03:46 -0400 X-MC-Unique: EIDW5A-iNpmjs5hUPJBHOg-1 Received: by mail-qt1-f200.google.com with SMTP id b10-20020a05622a020a00b003437e336ca7so10420140qtx.16 for ; Tue, 23 Aug 2022 05:03:46 -0700 (PDT) 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; bh=21Khf12hGlYeiDOGRGJQoLSPxtY2/o3vsN6dKECusuc=; b=0mMfpVN3PIUI1moJ+UmXvNrjuEJiqmJu0UgGBJBnwpUNfiC72XN+LDyP4Ui7irWZFm iVbeKzK4dnRr1G97+aoQKYfwcyI+XmplgufhQfdCiV3eMtnOzkWHTzdd0vHX5fG2PJv7 GGO2yGDft5UbapQXybJYBc9Xr0t9ZPcpHfZ7ZXruewdbIhRWJGVHxTuF3YnyKI19S6qo 71bNYrXGQWXJuI1iSaXGvKQcNMA/Y9aQZnFM0vehlrMF7gVYW9aWxOcGiwQ9r4T7/koA 2EiQK7KGieZD+g3wT0CaPO3UcYM+NP4vUlLASd/pamJmzY6NRsUuwsWmgTRJI4xCN8VR R8Hw== X-Gm-Message-State: ACgBeo323goFSynAmWT2NjlwPsCVj0BGS+wrWlaaAfnZApYtN0Ah7Y/7 gveDyl31IdcdE6qmbJ8Ou+zAL+QbxbDYy9DQ4cB+FqIG0CSGQfNU5US2VDtZBgkkAFlxeRzwnnq e22VfGiNIVQ1ODjwy9NAzdPjQwC4zLek= X-Received: by 2002:a05:620a:2728:b0:6ba:e857:9375 with SMTP id b40-20020a05620a272800b006bae8579375mr15287781qkp.728.1661256226141; Tue, 23 Aug 2022 05:03:46 -0700 (PDT) X-Google-Smtp-Source: AA6agR54dlTnTlckLZLwDX5SHPgupBliSCWWwHE3DuiOOQWdvoenzZ0ENLHar43dG9MoQgAjHsnEYfGOdQqhSoChZZU= X-Received: by 2002:a05:620a:2728:b0:6ba:e857:9375 with SMTP id b40-20020a05620a272800b006bae8579375mr15287766qkp.728.1661256225922; Tue, 23 Aug 2022 05:03:45 -0700 (PDT) MIME-Version: 1.0 References: <20220823013500.1756466-1-ppalka@redhat.com> <20220823013500.1756466-2-ppalka@redhat.com> In-Reply-To: <20220823013500.1756466-2-ppalka@redhat.com> From: Jonathan Wakely Date: Tue, 23 Aug 2022 13:03:35 +0100 Message-ID: Subject: Re: [PATCH 2/3] libstdc++: Implement std::pair/tuple/misc enhancements from P2321R2 To: Patrick Palka Cc: gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_NUMSUBJECT, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2022 12:03:48 -0000 On Tue, 23 Aug 2022 at 02:36, Patrick Palka via Libstdc++ wrote: > --- a/libstdc++-v3/include/bits/stl_pair.h > +++ b/libstdc++-v3/include/bits/stl_pair.h > @@ -212,6 +212,19 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION > swap(second, __p.second); > } > > +#if __cplusplus > 202002L > + /// Swap the first members and then the second members. > + constexpr void > + swap(const pair& __p) const > + noexcept(__and_<__is_nothrow_swappable, > + __is_nothrow_swappable>::value) This could use __and_v (which is just __and_::value today, but could theoretically be optimized to use a requires expression and avoid instantiating __and_ one day). Is consistency with the C++11 overload more important? I *hope* we won't need to make many changes to these noexcept-specifiers, so the maintenance burden of using __ad_::value in one and __and_v in the other shouldn't be too high. > @@ -710,6 +792,15 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION > noexcept(noexcept(__x.swap(__y))) > { __x.swap(__y); } > > +#if __cplusplus > 202002L > + template > + requires is_swappable::value && is_swappable::value is_swappable_v instead of ::value here ... this is already using a requires-clause and so is substantially different to the old overload anyway. > + > // tuple swap > _GLIBCXX20_CONSTEXPR > void > swap(tuple& __in) > noexcept(__and_<__is_nothrow_swappable<_Elements>...>::value) > { _Inherited::_M_swap(__in); } > + > +#if __cplusplus > 202002L > + constexpr void > + swap(const tuple& __in) const > + noexcept(__and_<__is_nothrow_swappable...>::value) __and_v ? > _GLIBCXX20_CONSTEXPR > void > swap(tuple& __in) > noexcept(__and_<__is_nothrow_swappable<_T1>, > __is_nothrow_swappable<_T2>>::value) > { _Inherited::_M_swap(__in); } > + > +#if __cplusplus > 202002L > + constexpr void > + swap(const tuple& __in) const > + noexcept(__and_<__is_nothrow_swappable, > + __is_nothrow_swappable>::value) __and_v ? Thanks for doing this, those changes looked tedious to implement and test! If you agree with the suggestions to use _v variable templates, this is OK for trunk with those changes. I am willing to be persuaded to not use the variable templates if there's a good reason I've missed.