On Thu, Feb 12, 2026 at 9:04 PM Ville Voutilainen <
[email protected]> wrote:

> On Thu, 12 Feb 2026 at 21:52, Jonathan Wakely <[email protected]> wrote:
> >
> > This is similar to the r16-3536-g0bb0d1d2880d56 change for std::pair, so
> > that CTAD ignores the tuple(const Types&...) constructor and only uses
> > the tuple(Types...) -> tuple<Types...> deduction guide. This ensures
> > that the deduced type comes from the decayed argument types.
> >
> > libstdc++-v3/ChangeLog:
> >
> >         PR libstdc++/121771
> >         * include/std/tuple (tuple::tuple(const Elements&...)): Use
> >         type_identity_t to prevent constructor being used for CTAD.
> >         (tuple::tuple(allocator_arg_t, const A&, const Elements&...)):
> >         Likewise.
> >         * testsuite/20_util/tuple/cons/121771.cc: New test.
> > ---
> >
> > Tested aarch64-linux.
>
> FWIW, LGTM.
>
OK to merge it now, but I believe this is bug in GCC and we should open an
issue for it.
The  generated deduction guides are equivalent to:
template<typename... Args>
void foo(const Args&...);
template<typename... Args>
void foo(Args...);

And for such overload, the call foo(bar) where bar is function is ambiguous
(https://godbolt.org/z/f96Mb5E1n), so they should get disambiguated by:
https://eel.is/c++draft/over.match#best.general-2.11
> F1 is generated from a *deduction-guide*
<https://eel.is/c++draft/temp.deduct.guide#nt:deduction-guide> ([over.match.
class.deduct] <https://eel.is/c++draft/over.match#class.deduct>) and F2 is
not, or, if not that,

Reply via email to