pon., 20 lip 2020 o 20:23 codusnocturnus via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> Having the code-bloat associated with defining and naming a struct, as well as pulling in std::optional all over the place to get the equivalent of named parameters is objectively terrible (I think you even questioned the viability), and, subjectively, it looks awful at the call site, too.
>
And both are needed, function arguments names do not exist in C++,
this means you cannot overload on them, and to change this you will
need split all C++ environment to old and new that support it and have
different name mangling. Structs fix this as all needed functionality
is already available to make it work.

And for optional is not needed there, it could be replaced by current
solution for optional parameters: predefined value:
https://godbolt.org/z/h1Wb4K

```

struct draw_args
{
    int parameter = 10;
    int mode = -1;
};
struct draw_args2
{
    double parameter = 5.;
    int z = -1;
};

extern void do_draw(int p);

void draw(const draw_args args)
{
    if (args.mode == 1)
        do_draw(-1);
    else
        do_draw(args.parameter);
}
void draw(const draw_args2 args)
{
    if (args.z == 1)
        do_draw(-1);
    else
        do_draw(args.parameter);
}

void test()
{
    draw({.parameter = 10, .mode = 1});
    draw({.parameter = 10, .z = 1});
    draw({.z = 10});
}
```


Right now only drawback I see is that you need use at least one unique
name to allow compiler to choose correct overload but on other hand
this is good feature as you will never mistake what call you use.

> It's one thing to jump through hoops on the called side of an API, but forcing the calling side into contrived patterns to achieve what is commonly available in modern languages just seems rude.
>
> Straight-up named parameter calling (not looking for any variadic nonsense à la *args/**kwargs) would make function overloading and default parameters as useable in C++ as they were intended to be. These are features that distinguish C++ from C, but today (on this very thread) we have notable language experts actively campaigning against their use!
>

If it was that easy, it would have been added a long time ago.

> Thanks,
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Monday, July 20, 2020 7:43 AM, Richard Hodges via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
>
>
> On Mon, 20 Jul 2020 at 18:03, codusnocturnus via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> This would be great - just remove the braces, and the .’s, and the struct.
>
>
> At this point it becomes an argument over syntax, rather than functional outcomes.
>
> I think what the designated initialiser demo shows is that the language is capable of accommodating this idea.
>
> I suspect the bigger argument will be over whether it should, given the additional overhead of passing carrying unnecessary optionals into a function whether it needs them or not.
>
> I think it's common to think, "language X has a nice way of expressing Y - why don't we do that too?"
>
> I can be guilty of that just like anyone else.
>
> But in the end, if a language gives you a way to express intent, one might wonder whether it's worth expending effort in making syntax nicer for niche use cases in favour of providing more utility or fixing design bugs.
>
>
>
>>
>>
>>
>> Sent from ProtonMail Mobile
>>
>>
>> On Mon, Jul 20, 2020 at 2:10 AM, Richard Hodges via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>>
>>>
>>> Its possible something like this already exists in the latest versions of C++ but if so I am not aware of it
>>
>>
>> As of C++20, one could use designated initialisers to achieve this.
>>
>> Whether it's a good idea in C++ is another matter.
>>
>> https://godbolt.org/z/cd8szq
>>
>>
>>