DIP 88: Simple form of named parameters

[default0 via Digitalmars-d]

On Sunday, 24 January 2016 at 02:51:43 UTC, Jonathan M Davis 
wrote:
> On Saturday, 23 January 2016 at 14:19:03 UTC, Jacob Carlborg 
> wrote:
>> This is mostly to prevent ugly hacks like Flag [1].
>>
>> http://wiki.dlang.org/DIP88
>>
>> [1] https://dlang.org/phobos/std_typecons.html#.Flag
>
> Regardless, I for one, hope that we never have named arguments. 
> It's just one more thing that's then part of the function's 
> signature that you can't change without breaking code and will 
> cause that much more bikeshedding. At least right now, 
> parameter names don't matter much, whereas if they're part of 
> the API, then they're open to all of the issues that function 
> naming has.
>
> And while I appreciate that this DIP does not make named 
> arguments the default behavior for a function, making it up to 
> the library writer whether they support named arguments or not 
> is likely to create a lot of bikeshedding and debates over 
> whether a particular function or library should support named 
> arguments. Personally, I'd never use them under any 
> circumstances.
>
> - Jonathan M Davis

So given this method:
void M(int a, int b = 1, int c = 2, int d = 3, int e = 4, int f = 
5, int g = 6, int h = 7, int i = 8)
{
}

You prefer calling it this way:
M(5, 1, 2, 3, 4, 5, 6, 7, 23);
As opposed to:
M(5, i: 23);

Or am I misunderstanding you?
Also consider that the two aren't even the same, if the library 
author decides to change some default values you will likely want 
to update the former call, but the latter can stay the same. Less 
of a maintenance burden.

Coming from C# where it's a 
free-for-all-every-argument-can-be-named implementation, I never 
once even heard someone complain or experience breakage because 
some parameter name changed, which makes me think that the 
possibility of breakage, while of course real, seems to not be an 
issue in practice. Judging from my own coding habits in C#, I 
rarely change parameter names anyways (about as rarely as I 
change method names) and I rarely use named arguments anyways 
(most functions I dealt with neither had many optional 
parameters, nor had "blind" parameters where the documentation 
would've been sincerely helpful).

Also consider that using named arguments is a decision made by 
the caller ("I want to document these parameters..." or "Ugh I 
don't want to pass 10.000 arguments to this function, SKIP!"), 
not the callee ("Will the user want to document these parameters? 
Hmm... it's possible!" or "Will the user want to skip these 
default values? Hmm there's at most three here, not sure if it's 
worthwhile...").

As for this DIP I don't know - it seems to be well-thought-out, 
albeit with a focus on ease of implementation rather than 
usefulness for a language user, so I don't really have a 
conclusive opinion on that.