On Thu, 9 Jul 2020, 15:02 Arthur O'Dwyer, <arthur.j.odwyer@gmail.com> wrote:
On Thu, Jul 9, 2020 at 9:32 AM Jake Arkinstall via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
The why is clear.

FWIW, no it's not. The OP didn't give any reason for the new syntax at all. In fact, the OP didn't even say what the new syntax is supposed to do!

I thought OP's code examples were rather clear. Though, granted, a wordy explanation would be been helpful.

What is `void f(int x, int y) {}` supposed to do differently from `void f(int x; int y) {}`

Nothing, except that x can adopt a default value in the latter. Because its a separate logical group, you have a way of telling the compiler "adopt the defaults for the remainder of this parameter group". 

or `void f(int x: int y) {}`?

Now that I do not know. Except perhaps in span selection or something. Outside of operator[] I can't see a use.

Explaining what the change does is an important part of any change request.
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.

FYI, there's already a deploy plan in motion (to the admittedly limited extent that WG21 can be said to make "deploy plans") to get multi-parameter `operator[]` overloads. The first step in the plan was committed in C++20:
The second step, targeted for C++23, is to support overloaded `operator[](int x, int y)` (or whatever parameter types) with the natural meaning and call syntax.
The goal and justification, targeted also for C++23 as far as I know, is to finally ship `mdspan`. (Which I personally think is a silly end goal, but there seem to be a lot of people looking forward to it just as a lot of people look forward to C++20's `span`.)


Thats pretty cool, and I missed that entirely so thanks for the link. Still, I think the ability to have groupings of parameters (specifically for variadics and defaults) without the indirection we'd currently use would be pretty useful in some places.