I can kinda see some use cases for this, but I think the current syntax is
a bit confusing and not so easy to reason about. And since it is fairly
easy to get around this sorts of limitation by using wrappers for the
separate packs, you must provide a syntax and usage that is so much simpler
that it is worth the effort (for both compilermakers and developers using
the feature to learn it).

My 2 cents.

// Robin

On Sat, Nov 16, 2024, 19:03 mauro russo via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
> > So your idea of better c++ which is intended to be LESS confusing than C
> (and I find it to be the opposite ironically)
> > is to add yet more confusion to the mix by overloading existing
> keywords? Why not try inventing some new keywords instead?
>
> Not sure why you state like this.
>
> 'auto' would still keep the meaning of deducing as for classic templates.
> I don't see any overloading, but a new context where to use.
> At the moment, it's just a floating proposal, aimed at exploiting multiple
> parameter packs.
>
> Of course, some more elaboration is needed, for example to understand
> whether
> partial specialization is manageable, with eventual limits, exactly as the
> fact that
> in case of multiple packs, then the syntax auto..[N] will be a must in
> template-ids
> in order to allow non-first packs to be useful. But, absence of auto..[N]
> would still
> be valid, leading the first pack to grab everything.
>
> An obstacle may be about considering or not the 'defaulted' behaviour
> something
> bad as default parameter values for functions,
> based on what I have read on the posts mentioned at the begin of this
> thread.
> On the other hand, at the moment I have no clue for such bad perspective
> from the
> community about defaulted deduction, but my knowledge of past discussions
> is limited.
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>