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

[bachmeier]

On Sunday, 31 March 2019 at 12:33:56 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community 
> Review for DIP 1020, "Named Parameters":

While I generally do not like the idea of named parameters for 
function calls, I will limit my feedback here to one part of the 
proposal:

> Arguments matching named parameters must be named arguments, 
> i.e. they must use the name:value syntax. Named arguments must 
> be passed to a function in the same order as the named 
> parameters with which they match appear in the parameter list, 
> but may be passed in any order relative to unnamed arguments. 
> Given the prototype:
>
> void func(int a, int b, <bool o>);
>
> The function call func(1, 2, o:true) is the same as func(1, 
> o:true, 2) or func(o:true, 1, 2).

It is unclear what we would gain from allowing this, and at the 
same time, it would make it extremely difficult for new users to 
the language to read code. Reordering unnamed parameters is a 
recipe for disaster. In some cases, the second argument is x, in 
some cases it is y, and in yet other cases, it is z. Was there 
are mistake when writing this:

> Named arguments must be passed to a function in the same order 
> as the named parameters with which they match appear in the 
> parameter list, but may be passed in any order relative to 
> unnamed arguments.

It makes sense to allow named arguments to appear out of order, 
but unnamed parameters should always have to appear in the same 
order as they are declared.

It would really help to have an extensive set of examples 
demonstrating large benefits to implementation of this proposal. 
It is not a good idea to assume that everyone is familiar with 
all the details of named arguments, the various arguments for and 
against, or the alternatives that achieve the same thing. Ideally 
there should be something that named arguments provide that 
cannot reasonably be accomplished any other way.