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

[Jonathan M Davis]

On Wednesday, February 19, 2020 8:31:00 AM MST Yuxuan Shui via Digitalmars-d 
wrote:
> On Friday, 7 February 2020 at 03:33:26 UTC, Jonathan M Davis
>
> wrote:
> > 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.
>
> Named parameters are not just for when there are too many
> parameters.
>
> Easy example:
>
>      dup2(a, b);
>
> vs
>
>      dup2(src: a, dst: b);

Named arguments are completely unnecessary in such a situation. The list of
arguments is short enough that it's trivial to know which is which and what
they're for. Having the parameter names listed at the call site is just
unnecessary cruft, and having named arguments in the language opens up the
whole issue of whether the names src and dst were the best names for dup2.
Just like there's often too much arguing over what a function should be
named, you then have arguing over what the function's parameters should be
named and whether they're consistent with other functions, which isn't an
issue right now. Right now, if the programmer maintaining dup2 wants to
change the parameter names as part of working on the function's
implementation, doing so is not a problem, whereas with named arguments, it
would break code. Personally, I don't think that named arguments provide
much value, and I _really_ don't want parameters to become part of the API.
We have enough bikeshedding over names as it is and don't need to introduce
yet more ways that changing libraries can break existing code.
Unfortunately, given Walter's current position on this, I'm likely going to
have to deal with named arguments and the problems that they bring, but I
really don't have much good to say about them, and I do not look forward to
having to deal with them in the least.

- Jonathan M Davis