DIP 1019--Named Arguments Lite--Community Review Round 1

[Andrei Alexandrescu]

On 2/15/19 7:56 AM, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for 
> DIP 1019, "Named Arguments Lite":
> 
> https://github.com/dlang/DIPs/blob/23ef47a94e0fdd5ddc4b2f6b2f4dcfd3c1f43aa6/DIPs/DIP1019.md 

Things that I think would make this DIP stronger:

* The presence of the feature in other programming languages belongs in 
"rationale" if also the rationale pertaining to those other languages is 
present. Otherwise it's argument by majority. Normally "rationale" would 
stand on its own (possibly using examples drawn/inspired from other 
languages) and mention of other languages would go in the "related work" 
section (which presently is missing).

(@Michael we need to make "Related Work" a required section.)

* The example with "CalculateProduct(values, 7, false, null);" in the 
rationale should be completed with the best-of-the-breed solution in the 
current D language, i.e. using Flag. Currently Flag is not being 
discussed at all and it should because it is a workaround to named 
parameters (however insufficient as the proposal might argue).

* The argument with repurposing argument is weak because code that 
doesn't use named parameters would be broken anyway, which makes the 
idea of repurposing parameters bad to start with. I suggest it be 
dropped, or mentioned later as a perk of named parameters.

* "The relevance of forward declarations will become clear later." -> 
"Section xyz clarifies the relevance of forward declarations."

* "Named arguments proposed by this DIP have no effect on the ordering 
of arguments in function calls." Related work will in all likelihood 
reveal that reordering arguments in large argument lists is a key 
advantage of named arguments. Not availing ourselves of that advantage 
is a serious issue that weakens the proposal. It must explain why it is 
not possible to allow reordering of arguments (or better yet work out 
the mechanics to allow it).

* "Named arguments proposed by this DIP do not allow default parameters 
to be skipped." Not sure what "skipped" means in context; I assume it 
means some defaulted arguments would be left unspecified and other 
following them would be specified with non-default values. My 
understanding is that this is another key advantage of named arguments 
in related work - typically complex functions with large argument lists 
like CreateWindow, CreateArchive etc. would have many arguments 
defaulted to reasonable values, which then the caller can pick and 
choose which to customize. I assume a large part of what makes Python 
APIs so friendly is this ability. The DIP should explain why this is not 
desirable or achievable for the D language (or again better yet make it 
just work).

* "Variadic arguments can be labeled with the name of the variadic 
parameter and a subscript." seems to have little value if there's only 
one variadic per function and all indexes must be specified in order. 
The DIP should explain why this feature (the index can be any 
compile-time expression... right?) is useful.

* "If a function is defined with some of its parameter names omitted, 
arguments to those parameters can labeled with an empty name." The 
utility of this should be explained.

* "This seems to be the biggest concern among people who are against 
named arguments." This is vague and nonscientific and has no place in a 
DIP. Who are those (does it even matter), where are the relevant 
exchanges, how did the author arrive at the conclusion that this is the 
biggest concern. The concern should be discussed at face value and if 
appropriate rebutted soundly with an analysis of the tradeoff (I assume 
it's not "all bad" vs "all good" but more like pros and cons).

* "Allow calling the same function with a different set of parameter 
names." The advantage of this seems to be backward compatibility, but it 
endorses a technique that is questionable in the first place.

* "This DIP does not prohibit future proposals for adding parameter 
reordering, partially-specified parameter names with reordering, named 
template parameters, omission of default arguments by using named 
arguments, and other similar things." The problem here is that all of 
these (easily anticipated as desirable) weaken the DIP by their absence 
from it.