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@lists.isocpp.org> wrote:
On Sat, Apr 29, 2023 at 12:30 PM Barry Revzin via Std-Proposals
<std-proposals@lists.isocpp.org> wrote:
>
>
>
> On Sat, Apr 29, 2023 at 9:37 AM Jens Maurer via Std-Proposals <std-proposals@lists.isocpp.org> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals