Date: Thu, 9 Jul 2020 15:28:45 +0100
On Thu, 9 Jul 2020, 15:02 Arthur O'Dwyer, <arthur.j.odwyer_at_[hidden]> wrote:
> On Thu, Jul 9, 2020 at 9:32 AM Jake Arkinstall via Std-Proposals <
> std-proposals_at_[hidden]> 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:
> http://eel.is/c++draft/depr.comma.subscript
> 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`.)
>
> –Arthur
>
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.
>
> On Thu, Jul 9, 2020 at 9:32 AM Jake Arkinstall via Std-Proposals <
> std-proposals_at_[hidden]> 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:
> http://eel.is/c++draft/depr.comma.subscript
> 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`.)
>
> –Arthur
>
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.
>
Received on 2020-07-09 09:32:11