On Tue, 23 Aug 2022 at 02:35, Patrick Palka via Libstdc++
<libstd...@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.
