DIP 1030--Named Arguments--Community Review Round 1 Discussion

[Paolo Invernizzi]

On Saturday, 8 February 2020 at 03:57:56 UTC, Walter Bright wrote:
> On 2/6/2020 7:33 PM, Jonathan M Davis wrote:
>> Well, I'll say again that I don't like the idea of having 
>> named arguments in
>> the language, because it makes the parameter names part of the 
>> API,
>> resulting in yet more bikeshedding and yet another thing that 
>> can't be
>> changed without breaking existing code. Once in a while, named 
>> arguments may
>> be useful, but for the most part, they're useful because a 
>> function has way
>> too many parameters, in which case, the function should have 
>> been designed
>> differently.
>> 
>> Unfortunately, since it's Walter who created the DIP, and a 
>> number of people
>> do like the idea of named arguments, I expect that some form 
>> of this will
>> make it in, but I still think that it's a bad idea.
>
> I appreciate your thoughts on this. But I like the feature even 
> if all it does is make the "Flag" template obsolete:
>
>   https://dlang.org/library/std/typecons/flag.html
>
> So instead of:
>
>   foo(Yes.caseSensitive)
>
> we'd write:
>
>   foo(caseSensitive : true)
>
> There's no overhead or cognitive load of an extra type, and it 
> doesn't look stupid.

Honestly, I like the Flag template ...

I think Jonathan have nailed the point:. In my little, I've a PR 
waiting for months as it breaks a possible derived class of 
Phobos Socket, as none is marking methods 'final' when it's not 
intended to be part of the API. And that remember me that, once 
alone a time, you and Andrei agreed that turning the default to 
'final' from 'virtual' was the correct thing to do, specifically 
for the above point: the default should encourage the writing of 
a "minimalist" API boundary.

Now, I'm all with Jonathan on that, having the parameters name 
part of the API is just going in the wrong direction related to 
the above: we are enlarging the possibility of code breakage. Do 
we want to go further down that road?