DIP 1019--Named Arguments Lite--Final Review

Jonathan M Davis newsgroup.d at jmdavisprog.com
Sat Aug 24 01:09:48 UTC 2019


On Friday, August 23, 2019 10:47:14 AM MDT H. S. Teoh via Digitalmars-d 
wrote:
> On Fri, Aug 23, 2019 at 04:19:51PM +0000, Dennis via Digitalmars-d wrote:
> > On Friday, 23 August 2019 at 15:01:20 UTC, Andrei Alexandrescu wrote:
> > > Large parameter lists of which most have reasonable defaults is a
> > > marquee use case of named arguments. A proposal that works itself
> > > out of that opportunity cannot and should not be acceptable.
>
> Exactly the same objections I have against this DIP.  OT1H it's trying
> to get named arguments into the language, but OTOH it takes out what I
> would consider to be two of the most important reasons to *have* named
> arguments: skipping default parameters, and out-of-order argument
> passing.  Therefore, it essentially nullifies its own raison d'etre.
>
> > I'm personally not a fan of those argument lists the size of the Magna
> > Cartas like you see in Python libraries:
> > https://matplotlib.org/3.1.1/api/_as_gen/matplotlib.lines.Line2D.html#ma
> > tplotlib.lines.Line2D I don't see it as a loss that this DIP doesn't
> > enable those in D. If your function takes more than 6 arguments you
> > should really consider creating a struct with configuration data.
>
> [...]
>
> But this DIP neither enables nor disables inordinately long parameter
> lists: the language already allows them!  The only thing worse than an
> overly-long parameter list is one in which you cannot (easily) tell which
> argument corresponds with which parameter, and that's something this DIP
> would fix (by letting you name the arguments so that they are
> self-documenting).  So your argument doesn't really detract from this
> DIP.
>
> Furthermore, if this DIP hadn't shot itself in its own foot by not
> allowing out-of-order argument passing and skipping default parameters,
> then it would have actually made overly-long parameter lists actually
> *acceptable*, in the sense that the function could just supply default
> values for most of the parameters, and the caller can just name and pass
> the few arguments that it wants to be different from the defaults, and
> the rest don't have to be explicitly specified.

Personally, I'm against named arguments in general. They make the parameter
names part of the API, which adds another set of names that you have to get
right up front and which will be bike-shedded to death. The _only_ use case
IMHO where they add any real value is when you have a long parameter list
where most of the parameters having default arguments. Such functions are
usually a bad design, so I'm fine with not having named arguments in the
language to make such designs seem more reasonable. If your parameter list
is long enough that it doesn't work to go by the order of the arguments,
then you already have a problem. But if we're going to add named arguments,
then IMHO, the rare case where it actually makes sense to have a lot of
parameters with default arguments is what named arguments are there to
solve. So, if the DIP can't solve that, then IMHO, it's just making the
language worse to no benefit.

- Jonathan M Davis





More information about the Digitalmars-d mailing list