Date: Tue, 23 Sep 2025 10:30:18 +0000
Neat, thanks.
Would you by chance happen to know if with C++26 reflection, taking a 'std::meta::info' as a template parameter and then using that in a deduction is legal? Something like this:
template<std::meta::info Container>
using deduced = decltype(
typename[: Container :](std::from_range, std::vector<int>())
);
using deduced_from_list = deduced<^^std::list>;
static_assert(std::same_as<deduced_from_list, std::list<int>>);
It would appear to work on Bloomberg's reflection fork of Clang: https://godbolt.org/z/xe84P1r7c
But that could be implemented wrong, I don't know. Looking at the standardese it would appear to me like it should be fine since it seems 'splice-type-specifier' is peppered around in the CTAD wording, but would be nice to know either way.
It would definitely be useful though. Not only to possibly circumvent this thing about template template parameters not being deducible templates, but also so you could accept a wider variety of templates, like templates that accept non-type parameters as well.
Thanks
On Tuesday, September 23rd, 2025 at 4:07 AM, Jens Maurer <jens.maurer_at_[hidden]> wrote:
>
> On 9/23/25 01:48, Keenan Horrigan wrote:
>
> > Does this conflict with the specification of 'std::ranges::to'? From my (naive) reading, the 'DEDUCE_EXPR' for when a template, such as 'std::vector', is passed to 'std::ranges::to' relies on being able to use the template template parameter 'C' as a deducible template. Or is the standard just given special blessing to have it work as if 'C' were a deducible template?
>
>
> I've posted a library issue and amended CWG3003 accordingly.
>
> Good catch!
>
> Jens
>
> > Wrote some code the other day that mimicked the 'DEDUCE_EXPR' for 'std::ranges::to', so it'd be nice to know if I should go change that now.
> >
> > On Monday, September 22nd, 2025 at 1:17 PM, Jens Maurer via Std-Discussion std-discussion_at_[hidden] wrote:
> >
> > > On 9/22/25 09:11, Ell via Std-Discussion wrote:
> > >
> > > > Consider this:
> > > >
> > > > template <class T, class U = long>
> > > > struct A { A (T, U); };
> > > >
> > > > template <class T>
> > > > using B = A<T>;
> > > >
> > > > template <template <class> class P>
> > > > P x (1, 2);
> > > >
> > > > The type of x<B> is A<int, long>, as expected. However, the type of X<A>
> > > > is A<int, int>, which is surprising. I'd expect it to either
> > > > be A<int, long>, as if P were an alias template, or to be ill formed,
> > > > since the deduced type doesn't match P.
> > >
> > > This is ill-formed; the name of a template template parameter is not
> > > a deducible template per the current rules, as clarified here:
> > >
> > > https://cplusplus.github.io/CWG/issues/3003.html
> > >
> > > If you wish to make this situation deducible, please submit a paper
> > > to EWG.
> > >
> > > Jens
> > >
> > > --
> > > Std-Discussion mailing list
> > > Std-Discussion_at_[hidden]
> > > https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
Would you by chance happen to know if with C++26 reflection, taking a 'std::meta::info' as a template parameter and then using that in a deduction is legal? Something like this:
template<std::meta::info Container>
using deduced = decltype(
typename[: Container :](std::from_range, std::vector<int>())
);
using deduced_from_list = deduced<^^std::list>;
static_assert(std::same_as<deduced_from_list, std::list<int>>);
It would appear to work on Bloomberg's reflection fork of Clang: https://godbolt.org/z/xe84P1r7c
But that could be implemented wrong, I don't know. Looking at the standardese it would appear to me like it should be fine since it seems 'splice-type-specifier' is peppered around in the CTAD wording, but would be nice to know either way.
It would definitely be useful though. Not only to possibly circumvent this thing about template template parameters not being deducible templates, but also so you could accept a wider variety of templates, like templates that accept non-type parameters as well.
Thanks
On Tuesday, September 23rd, 2025 at 4:07 AM, Jens Maurer <jens.maurer_at_[hidden]> wrote:
>
> On 9/23/25 01:48, Keenan Horrigan wrote:
>
> > Does this conflict with the specification of 'std::ranges::to'? From my (naive) reading, the 'DEDUCE_EXPR' for when a template, such as 'std::vector', is passed to 'std::ranges::to' relies on being able to use the template template parameter 'C' as a deducible template. Or is the standard just given special blessing to have it work as if 'C' were a deducible template?
>
>
> I've posted a library issue and amended CWG3003 accordingly.
>
> Good catch!
>
> Jens
>
> > Wrote some code the other day that mimicked the 'DEDUCE_EXPR' for 'std::ranges::to', so it'd be nice to know if I should go change that now.
> >
> > On Monday, September 22nd, 2025 at 1:17 PM, Jens Maurer via Std-Discussion std-discussion_at_[hidden] wrote:
> >
> > > On 9/22/25 09:11, Ell via Std-Discussion wrote:
> > >
> > > > Consider this:
> > > >
> > > > template <class T, class U = long>
> > > > struct A { A (T, U); };
> > > >
> > > > template <class T>
> > > > using B = A<T>;
> > > >
> > > > template <template <class> class P>
> > > > P x (1, 2);
> > > >
> > > > The type of x<B> is A<int, long>, as expected. However, the type of X<A>
> > > > is A<int, int>, which is surprising. I'd expect it to either
> > > > be A<int, long>, as if P were an alias template, or to be ill formed,
> > > > since the deduced type doesn't match P.
> > >
> > > This is ill-formed; the name of a template template parameter is not
> > > a deducible template per the current rules, as clarified here:
> > >
> > > https://cplusplus.github.io/CWG/issues/3003.html
> > >
> > > If you wish to make this situation deducible, please submit a paper
> > > to EWG.
> > >
> > > Jens
> > >
> > > --
> > > Std-Discussion mailing list
> > > Std-Discussion_at_[hidden]
> > > https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
Received on 2025-09-23 10:30:25