Re: [PATCH 1/3] libstdc++: Separate construct/convertibility tests for std::tuple

[Jonathan Wakely <jwakely@redhat.com>]

On Tue, 23 Aug 2022 at 02:35, Patrick Palka via Libstdc++
<libstdc++@gcc.gnu.org> wrote:
>
> P2321R2 adds new conditionally explicit constructors to std::tuple which
> we'll concisely implement in a subsequent patch using explicit(bool), like
> in our C++20 std::pair implementation.  But before we can do that, this
> patch first adds members to _TupleConstraints that test for constructibility
> and convertibility separately; we'll use the first in the new constructors'
> constraints, and the second in their explicit specifier.
>
> In passing, this patch also redefines the existing predicates
> __is_ex/implicitly_constructible in terms of these new members.  This
> seems to reduce compile time and memory usage by about 10% for large

Nice.

> tuples when using the relevant constructors constrained by
> _Explicit/_ImplicitCtor (since we no longer have to redundantly expand
> and process is_constructible<_Types, _UTypes>... twice for each pair of
> such constructors).  In order to retain maximal short circuiting, do
> this only when constexpr if is available.

Would we get similar benefits for C++11 and C++14 by doing:

       return __and_<__and_<is_constructible<_Types, _UTypes>...>,
                     __and_<is_convertible<_UTypes, _Types>...>
                     >::value;

This is slightly more work in total, but if we have __and_<A,B> and
__and_<A,__not_<B>> then the A and B instantiations will be cached and
can be reused.


> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?

Yes, thanks.