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 4F4CC3858D37 for ; Tue, 23 Aug 2022 12:03:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4F4CC3858D37 Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-19-zAphPTzkMx-1Mvygbryc-A-1; Tue, 23 Aug 2022 08:03:46 -0400 X-MC-Unique: zAphPTzkMx-1Mvygbryc-A-1 Received: by mail-qv1-f71.google.com with SMTP id n9-20020a0cfbc9000000b00496bb293f1fso6905862qvp.1 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=S7iPDoxkb7wkB25ndGHbNY1QC21P5zlZQ6zsf7KDkSCoX1CctGaxVTiD31jT7UmZlc CxE7ras2E44V1w0c/3Trq+Y/X0ULZPGLDTiFpT5sywFcThprqVaNywrz05v6mYutOv18 zuqaN9CQioAFJ5rTBZ7TYtrgqHkKpTyyimD2+/l1Deeg416kQJ0CQ1qVIoFCFLnWPZbW nsUW6bq3VRFKkH+UDRt6AmvYmxYX0mgSzQErP3/IbnWsqlXl8UkNF7MfSPBbSTu+Qq2y 9pv7tGD4mXNBetCVHw3bwlDm8ctUqmGj0cmmeHuWEZI9Gv3oSIFTrPoJD4vdQT20tJoW Y3UA== X-Gm-Message-State: ACgBeo24UK1iKGU9X3xYGP5KVAe+ABHvDf0H9swbaJ7dZz54d4RYF/lz uKp45BvJASLC5IieX3w8KF8QDIuaQNl02w39tk7/qrZMg6y2bh1txLh6DbyHD6dW5peEfRFhrWo f0O1EXHmIYJ3vd1RNMNtDFJTBhKPan59xFA== X-Received: by 2002:a05:620a:2728:b0:6ba:e857:9375 with SMTP id b40-20020a05620a272800b006bae8579375mr15287790qkp.728.1661256226228; 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.8 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=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2022 12:03:49 -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.