On Tue, 23 Aug 2022 at 02:36, Patrick Palka via Libstdc++
<libstd...@gcc.gnu.org> 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<const _T1>,
> + __is_nothrow_swappable<const _T2>>::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<typename _T1, typename _T2>
> + requires is_swappable<const _T1>::value && is_swappable<const _T2>::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<const _Elements>...>::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<const _T1>,
> + __is_nothrow_swappable<const _T2>>::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.
