The why is clear. It's a way of forming groupings of parameters, which
currently isn't possible without bringing structs into the equation. This
opens up some decent possibilities: Defaults can apply to the group (rather
than having to put them at the end of the call), parameter packs can be
logically separated in a way they currently cannot, and so we can pass
multiple parameters to operator[] without interfering with the comma
operator. All lovely things. I'm for it.

It presents a very clean method of solving some long standing niggles with
the language, and does so in a way that (as far as I can see) does not
interfere with any existing valid syntax. In fact, it's clean enough that
it is even being used as a scoping tool for if statements, so the syntax
does carry some favour in related areas.

As a language change, and a reasonably big one at that, I can't imagine it
even being considered until c++26 at the very earliest. It's also going to
need a very convincing writeup. None of those should ever, ever detract you
from doing it, though.

I recall, some time ago, a proposal (or at least a discussion of a
potential proposal) for bringing template parameters into the function
parameter set, and with the same syntax. I cannot find it at the moment,
but I believe it is on the old mailing list somewhere, I think around the
2017-2018 mark. I'll see if I can dig it up - there might be some merit to
merging the two. IIRC I was against it at the time, but who knows - the two
may complement each other.


On Thu, 9 Jul 2020, 10:56 Magnus Fromreide via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> On Thu, Jul 09, 2020 at 10:32:03AM +0200, Filippo Casarin via
> Std-Proposals wrote:
> > I would like to allow colons and semicolons to appear in function
> > parameters
>
> Why?
> What is your use case?
> What does C++ as a language stand to gain from this change?
>
> The kneejerk reaction to any proposal with no rationale is generally
> 'Over my dead body' so you really have to make an argument for why the
> change should happen.
>
> There is also the time factor, even if your change is agreed upon by
> everybody as the best thing ever you won't see it in compilers for
> 4-6 years so if the change is because you need it NOW then this is the
> wrong path.
>
> /MF
>
> > >
> > Example:
> >
> > > void foo(int a, int b; int c);
> > > foo(0, 4; 3);
> >
> >
> > void foo(int a=0; int b);
> > > foo(/* default vaue for a */ ; 43);
> > >
> >
> >
> > > template <class... Args1; class... Args2>
> >
> > void foo(Args1&&... args1; Args2&&... args2);
> > >
> >
> > I would also like this to extend this to the operator[]
> >
> > Example:
> >
> > > template <class T>
> > > struct matrix {
> > > T &operator[](size_t i, size_t j);
> > > };
> > >
> >
> >
> > > template <class T, size_t N>
> > > struct array {
> > > std::span<T> operator[](size_t i : size_t j);
> > > };
> > >
>
> > --
> > Std-Proposals mailing list
> > Std-Proposals_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>