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

[Joseph Rushton Wakeling]

I would broadly second Jonathan's remarks above:
https://forum.dlang.org/post/mailman.7211.1551233866.29801.digitalmars-d@puremagic.com

... but a few thoughts in my own words.

First, I think my core objection to this proposal is that 
ultimately, it's a cosmetic change to language syntax that does 
not make any meaningful improvement to the kinds of programs one 
can write, or to the compiler's ability to prove their safety and 
correctness -- even allowing that it's opt-in, implementing 
support is going to be finnicky and intrusive, and risks nasty 
impacts on stuff that affects _all_ programs (e.g. name mangling).

If we consider the languages where named arguments are a feature, 
virtually all of them are scripting (or scriptable) languages 
where it's common to use them via a REPL, and the use-case is for 
functions that have a lot of parameters, where in the typical 
use-case the caller only wants to specify the ones that are 
non-default.

In a scripting language, it's convenient to allow the user to 
just make the one function call.  But in a systems programming 
language it's both straightforward and arguably better 
self-documenting to do something like:

```
struct Config
{
     // default values for everything
     int alpha = 23;
     double beta = 0.25;
     int gamma = 6;
     double delta = 1.5;
     // ...
     int omega = 99;
}

double foo (Config config)
{
     with(config) {
         // implementation
     }
}
```

and then one can call with e.g.:

```
Config config = { beta: 6.5, omega: 101 };
auto result = foo(config);
```

As others have already pointed out, it needs only some small 
improvements to the struct declaration mechanisms to allow us to 
do something like:

```
foo({ beta: 6.5, omega: 101 });
```

... without even needing to declare a separate Config instance.  
This sort of approach will work naturally with UFCS:

```
double bar (int a, Config config) { ... }

x.bar({ delta: 9.125, gamma: 7});
```

... so one therefore has the effect of named parameters without 
any real change to the language syntax or behaviour.

On the question of "protecting against silent breakage in cases 
when a function's parameters are repurposed and renamed": this 
seems a very narrow protection compared to all the ways in which 
one can introduce breaking change into a function.  And by 
contrast it blocks something that can be very useful, which is 
renaming a function parameter to better illustrate its meaning, 
_without_ changing its purpose.

Specific feedback on a few points:

* `Completeness`: note that this approach of "all named or none" 
is
   in contrast with various languages' approach to named 
parameters,
   where it's common to have some initial obligatory parameters 
plus
   the option to set extra config variables.  Think Python, e.g. in
   this usage from the `pandas` data science library:

       dates = pd.date_range('20190227', periods=6)

   This should be noted as a contrast with what is being proposed
   in the current DIP.  (The struct-based approach outlined above
   may allow something closer to this, albeit imperfectly.)

* in the `Overloading and name mangling` section it would be good
   to have contrasting examples of what happens when parameter 
names
   are identical but types are different, e.g.:

       int add(int a, int b) {...}
       double add(double a, double b) {...}

   ... and a clear description of how template functions and 
methods
   will be impacted, e.g. `T add(T)(T a, T b)`.

* `Alternatives` should be updated to note the struct-based 
approach
   described above and by others, which does not need any specific
   support beyond perhaps improvements proposed in the DIP 
currently
   being drafted at
   
https://github.com/wilzbach/DIPs/blob/b1283b455b635d7dcbc2c871d2aa47cc67190059/DIPs/DIP1xxx-sw.md

In summary:

* despite being opt-in only, the proposal still seems an 
intrusive change
   for limited practical benefit

* suggestions by others that named parameters should be opt-out 
would make
   it even more intrusive, and impose a massive unasked-for 
maintenance
   burden on existing library maintainers

* some small improvements to struct initialization would make it 
possible
   to get a syntax and behaviour very close to that wanted, while 
keeping
   entirely within existing idiomatic language syntax and style

Hope that helps!