DIP 88: Simple form of named parameters
default0 via Digitalmars-d
digitalmars-d at puremagic.com
Sun Jan 24 02:14:53 PST 2016
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.
More information about the Digitalmars-d
mailing list