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

[Jonathan M Davis]

On Monday, February 10, 2020 11:27:49 AM MST Steven Schveighoffer via 
Digitalmars-d wrote:
> On 2/6/20 10:33 PM, Jonathan M Davis wrote:
> > 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.
>
> I find this assertion lacking evidence.
>
> How does one design a constructor that initializes all the fields of a
> type without including all the parameters to initialize that type? If
> you reduce the number of parameters, what do you do with the data not
> specified? I suppose you can just have a minimal constructor and then
> just expect the user to set all the pieces up, but what if you need to
> use it in an expression? How do you decide which pieces are "important"
> enough to initialize first, and which ones get initialized later? What
> if the parameters are initializing things that can only be initialized
> in the constructor (e.g. immutable data).
>
> I focus on constructors because structs ALREADY support named parameters
> in this instance (when there is a lack of constructor), and we haven't
> seen the problems you are asserting.
>
> I can imagine with this DIP instead of 15 different constructors for all
> the different ways you want to construct said type (yes, I've seen this
> kind of stuff), you have one that has default arguments for all of the
> optional pieces (or maybe you split them up with ones that can be
> safe/pure and ones that can't, etc). And then the call interface is much
> better looking and self-explanatory. And I like that you can pick which
> way you want to call it, even for individual parameters.

The only time that the struct initialization equivalent of named parameters
comes into play is when you have a POD type which exposes its member
variables. Most structs don't do that, because it's usually bad practice to
expose members that way unless they're POD types, and most structs aren't
POD types. They usually encpasulate their data and have functions for
manipulating it. So, while struct initializers may exist in the language,
they're very limited in how they can be used, whereas named arguments could
be used pretty much anywhere.

I have rarely seen structs where it made sense to have a long list of
parameters to their constructors. In almost all cases, when that sort of
thing happens, it makes far more sense to group such data into multiple
structs so that the data is more organized instead of a huge blob of values
all shoved directly into a single object. And in general, if a function
parameter list is long, it's usually because the API didn't use structs to
group and encapsulate data cleanly. I have rarely seen code where I would
have considered it reasonable to have a large list of parameters to a
function. As far as I can tell, named parameters are primarily an excuse to
be able to have overly long parameter lists instead of properly organizing
data, and they encourage what I would consider to be poor programming
practices.

Regardless, my biggest problem with this DIP (and any DIP with named
arguments) is that it adds function parameter names to the API. IMHO, it
adds minimal benefit, and in return, it adds yet another set of names which
are going to be bikeshedded, and yet another thing that you can't change
without risking breaking code. If D were set up so that you normally had
function prototypes separate from the functions themselves like you do in
C/C++, I would almost certainly stop putting names on _any_ function
prototypes if named parameters were added. I don't want to have to worry
about breaking someone else's code because of a change to a parameter's
name, and IMHO, there are already far too many arguments over the names of
functions and types without adding parameter names to the list.

- Jonathan M Davis