[PATCH] libstdc++: Work around C++20 tuple<tuple<any>> constraint recursion [PR116440]

[Patrick Palka]

On Thu, 13 Mar 2025, Ville Voutilainen wrote:

> On Thu, 13 Mar 2025 at 23:16, Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
> >
> > On Thu, 13 Mar 2025 at 23:03, Patrick Palka <ppalka@redhat.com> wrote:
> > > +      // Defined as a template to work around PR libstdc++/116440.
> > > +      template<class...>
> > > +       constexpr explicit(!__convertible<const _Elements&...>())
> > > +       tuple(const _Elements&... __elements)
> >
> > I don't understand how a constructor template declared like this can
> > ever be called. The template parameter pack
> > can't be provided or deduced, and can't have a default. So we're
> > effectively making this signature always lose
> > overload resolution to the one that takes a pack of _UElements&&.
> >
> > Which may be fine. I can't head-compile a test that would fail in that
> > case. If any of the incoming argument isn't one
> > of _Elements, that constructor wins overload resolution anyway. If the
> > incoming arguments are exactly _Elements, that
> > constructor does the same thing as this one. I think.
> 
> Oh, never mind. The pack is just deduced as an empty pack.

Yep that's my understanding, though I don't know where in the standard
this is specified, a quick Ctrl+F is failing me.

I can use template<int = 0> or template<typename = void> if that's
preferred :)