>
> Also why isn't it sufficient to do this:


Because for one(as per your solution/suggestion) I would have to
repeat the *template-parameter-clause
*with each such specialization. Instead of this workaround(which is useful
btw) I think it is better to have a more straightforward solution as
suggested in the proposal.

On Sat, 29 Apr 2023 at 22:41, Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Sat, Apr 29, 2023 at 12:30 PM Barry Revzin via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> >
> >
> > On Sat, Apr 29, 2023 at 9:37 AM Jens Maurer via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
> >>
> >>
> >>
> >> On 29/04/2023 06.43, Anoop Rana via Std-Proposals wrote:
> >> > Attached is the proposal to allow multiple template parameter packs
> for class templates provided they can be deduced using CTAD.
> >>
> >> The "before - after" comparison should not just show "invalid";
> >> it should show for "before" the workaround that you need to take
> >> today to achieve the same result. I guess passing around several
> >> tuples might work today.
> >>
> >> Jens
> >
> >
> > Also why isn't it sufficient to do this:
> >
> > template <typename F, typename... Args>
> > struct C;
> >
> > template <typename... Param, typename Ret, typename... Args>
> > struct C<Ret(*)(Param...), Args...>
> > {
> > C(Ret (*ptrFunc)(const Param&... param), const Args&... args);
> > };
> >
> > Which is valid today?
>
> You'd need to add explicit template deduction guides in this case, as
> CTAD cannot generate them from template specializations.
>
> That being said, while it is duplicating information, it's not *that*
> painful.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>