DIP 1020--Named Parameters--Community Review Round 1

[Bastiaan Veelo]

Thank you Richard for writing the DIP.

I subscribe to Olivier's review and won't repeat those critiques. In 
addition, I have the following concerns.

1) Any DIP on named arguments nowadays should have references to all 
prior suggestions and ideas, summarize them and categorize them and 
clarify why this one is better.

2) Different subjects should have different section headings ("Overload 
resolution", "Variadic parameters", etc).

3) What is the value of the following?

 > The function call `func(1, 2, o:true)` is the same as `func(1, 
o:true, 2)` or `func(o:true, 1, 2)`.

So is this equivalent at the definition site as well: `void func(int a, 
int b, <bool o>);`, `void func(int a, <bool o>, int b);` and `void 
func(<bool o>, int a, int b);`? Being able to reorder arguments somewhat 
but not any way you like is confusing.

4) The section on overload resolution is flawed because it contains 
illegal code:

 > `void bar(int a, string b = "", int c) {}`

5) Use cases. The "Ranges" case needs to open with what the example 
looks like without the DIP, and then with the DIP, so that its value 
becomes apparent. So one of the advantages of this DIP is that fewer 
types and instantiations are needed? That is fundamental and should be 
further explained and certainly goes beyond syntax sugar or mere 
improvement of readability. What is necessary, compiler implementation 
wise, to support that?
The "Logging" case (grouping of arguments that the user typically would 
not want to bother with) has nothing to do with named arguments as users 
won't typically name those arguments.


6) About the aim of the DIP:

 > "The primary aim of this proposal is to aid in readability and the 
implementation of tooling."

I have no idea how this DIP is supposed to aid in the implementation of 
tooling. There is no further mentioning of tooling at all. What is left 
is "aid readability" which I agree would be a worthwhile improvement. 
However, in this DIP, what is gained in readability at the call site is 
smaller in value than what is lost in readability at the definition 
site, to a net loss.

The value in readability should be weighed against ordinary comments:

    `func(1, 2, o:true)`

versus

     `func(1, 2, /*o*/ true)`

Note that the comment has the added advantage that it is optional at the 
call site. This DIP should justify itself against the obvious solution 
which in my eyes is accepting `o:` in this example as a comment. It 
would be easy to accept an identifier followed by a colon in a parameter 
list as a new syntax for a comment. It would work everywhere and be 
optional. As an extra service, the compiler could check the comment 
against the function definition and issue a warning in case of a 
mismatch: "Warning: argument 3 of 'func' is not called 'o', did you mean 
'q'?" or the like. Maybe this is worth a DIP?

Bastiaan.