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

[Jonathan Marler]

On Sunday, 9 June 2019 at 01:34:50 UTC, Paul Backus wrote:
> On Saturday, 8 June 2019 at 18:05:43 UTC, Jonathan Marler wrote:
>> I see value in allowing a caller to omit arguments that have 
>> default values, but what is the value in allowing the caller 
>> to reorder them?
>
> Without looking at the documentation, which of the following 
> calls would fail to compile if argument reordering was 
> forbidden?
>
> spawnProcess("/usr/bin/sort", stdout: outputFile, stdin: 
> inputFile);
> spawnProcess("/usr/bin/sort", stdin: inputFile, stdout: 
> outputFile);
>
> From a usability perspective, it's completely insane for only 
> one of these to work.

Of the top of my head stdin is first...but I don't think many 
people would know that.  It's just that I've written wrappers to 
spawnProcess so many times that it's ingrained in my head.  But I 
think whether or not I know is irrelevent to your point :)

I believe that optimizing code for the reader should take 
priority over optimizing for the writer.  The antithetical 
example is the perl language...writing it can be terse and quick 
but reading it can make your head spin.

I think your point is that when developers write code like this, 
having to put arguments in a particular order seems like an 
unnecessary burden.  I agree it's an extra burden on the writer, 
but enforcing the same order reduces the complexity of overload 
resolution and knowing how to map arguments to parameters, 
something which the "reader" needs to be able to do whenever they 
see a function call.

Consider,

foo(int a, int b, int c, int d, int e, int f);

foo(1, 2, 3, 4, 5, 6); // a=1, b=2, c=3, d=4, e=5, f=6

Now let's see it with some argument re-ordering:

foo(6, c=1, e=2, 3, b=4, e=5, a=7);

What's the values of a/b/c/d/e/f in this case? This may have made 
sense when it was written, but this is not beneficial for the 
reader.

This gets worse when you introduce the concept of 
order-of-evaluation:

int x = 0;
foo(x++, c=x++, e=x++, x++, b=x++, e=x++, a=x++);

Now what are the values of a/b/c/d/e/f?  Do you evaluate 
arguments in the order of the call, or the order of the function 
definition?

These are the problems before you get into overloading.  Now add 
that into the mix:

foo(float a, float b, float c, int   d, float e, float f);
foo(float a, float b, float c, float d, float e, int f);

foo(0, c=1, 2.0, 0.0, b=4, e=5, a=7);

...

Keep in mind that I'm not saying that by enabling re-ordering 
we're going to start having a huge mass of unreadable code like 
this.  These examples are contrived to show you how re-ordering 
can make things confusing.  But when you enable powerful things 
like this, you are adding an extra burden on the reader every 
time they see a function call.  The more rules you add, the more 
unsure you make the reader and the more rules the reader has to 
remember and evaluate in order to understand the code.  Now 
whenever they see a function call with named arguments, they're 
going to have to go through a mental checklist of rules to be 
sure which overload is actually being called and which parameters 
are receiving which arguments.

The benefit of allowing the writer to re-order arguments should 
be weighed against the burden of the reader to then understand it 
later when they do.