June 09, 2019
On 6/8/19 3:58 PM, Yuxuan Shui wrote:
> 
> Reordering is definitely a very important feature. However, this proposal is not going to be the last DIP about named parameters, as is stressed in the proposal itself.
> 
> Generally, I think incremental improvements should be allowed.

Sadly my vast and mostly unsuccessful experience with programming language design is that such is not to be done incrementally. Never. I will oppose a DIP that argues its utility by means of possible future DIPs. (For measure, don't forget I do not hold decision power any longer.) For named arguments, I very strongly believe that any DIP that does not allow reordering is a stillborn.
June 09, 2019
On Sunday, 9 June 2019 at 02:49:13 UTC, Jonathan Marler wrote:
> 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);

overload error, you have 7 parameters here but only 6 in the definition and no 7 parameter overload.

>
> 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.

none, it's a compilation error


June 09, 2019
On Sunday, 9 June 2019 at 02:49:13 UTC, Jonathan Marler wrote:
> 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?
>
They are in the order of declaration of the function. But here again you have 7 parameter for a function who takes only 6. But they will have a=1 b=2 c=3 (d=4)
There's no reason to evaluate it any other order as the code generation requires that the caller populates the registers/stack in the order the function expects.
June 09, 2019
niedz., 9 cze 2019 o 04:50 Jonathan Marler via Digitalmars-d <digitalmars-d@puremagic.com> napisał(a):
>
> 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.

There is simple solution for this, don't allow positional arguments after named.

June 09, 2019
On Sunday, 9 June 2019 at 07:51:18 UTC, Andrei Alexandrescu wrote:
> On 6/8/19 2:05 PM, 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?
>
> Named arguments is useful mainly so one doesn't need to remember their order in large argument lists.

When has anyone had a problem with unreorderable named arguments in functions with large argument lists?

After using languages with unreorderable and reorderable named parameters. I only see a very mild benefit of programmer laziness for reorderable, and the larger downside of reader annoyance. I've felt no downsides of unreorderable (you generally look at the documentation, and type it in param by param, or copy paste the declaration, and if you get it wrong, the compiler tells you and you fix it).
June 09, 2019
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.

Without looking at the documentation, what are the parameters of this function

blah(...)

?
June 09, 2019
On Sunday, 9 June 2019 at 11:15:39 UTC, aliak wrote:
> On Sunday, 9 June 2019 at 07:51:18 UTC, Andrei Alexandrescu wrote:
>> On 6/8/19 2:05 PM, 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?
>>
>> Named arguments is useful mainly so one doesn't need to remember their order in large argument lists.
>
> When has anyone had a problem with unreorderable named arguments in functions with large argument lists?
>
> After using languages with unreorderable and reorderable named parameters. I only see a very mild benefit of programmer laziness for reorderable, and the larger downside of reader annoyance. I've felt no downsides of unreorderable (you generally look at the documentation, and type it in param by param, or copy paste the declaration, and if you get it wrong, the compiler tells you and you fix it).

There're also some technical advantages/disadvantages to either or:

1) searchability is out the window if you allow reordering
  find "func(a:" will now not work
2) semantic overloading is out the window
  lets(int doA, int thenB int thenC)
  lets(int doA, int thenC, int thenB)

I'm not sure what technical advantages reordering brings though.

I also wonder what kind of overload resolution can be accomplished with reorderable and unreorderable, and also what kind of overload resolution is blocked with either of the two. I believe that should also be taken in to account to make a better decision here.

Maybe the DIP can address that point as well?

Cheers
- Ali
June 09, 2019
On Sunday, 9 June 2019 at 11:26:07 UTC, aliak wrote:
> On Sunday, 9 June 2019 at 11:15:39 UTC, aliak wrote:
>> [...]
>
> There're also some technical advantages/disadvantages to either or:
>
> 1) searchability is out the window if you allow reordering
>   find "func(a:" will now not work
> 2) semantic overloading is out the window
>   lets(int doA, int thenB int thenC)
>   lets(int doA, int thenC, int thenB)
>
> I'm not sure what technical advantages reordering brings though.
>
> I also wonder what kind of overload resolution can be accomplished with reorderable and unreorderable, and also what kind of overload resolution is blocked with either of the two. I believe that should also be taken in to account to make a better decision here.
>
> Maybe the DIP can address that point as well?
>
> Cheers
> - Ali

Forgot another technical advantage: evaluation of arguments. With unreorderable it's obvious. With reorderable, as Walter pointed out, what't the order (parameter-wise or argument-wise).
June 09, 2019
On Sunday, 9 June 2019 at 07:55:50 UTC, Andrei Alexandrescu wrote:
> On 6/8/19 3:58 PM, Yuxuan Shui wrote:
>> 
>> Reordering is definitely a very important feature. However, this proposal is not going to be the last DIP about named parameters, as is stressed in the proposal itself.
>> 
>> Generally, I think incremental improvements should be allowed.
>
> Sadly my vast and mostly unsuccessful experience with programming language design is that such is not to be done incrementally. Never. I will oppose a DIP that argues its utility by means of possible future DIPs. (For measure, don't forget I do not hold decision power any longer.) For named arguments, I very strongly believe that any DIP that does not allow reordering is a stillborn.

I agree. Reordering is the main motivation. I've lost count of how many times I've shaken my fist at the sky when trying to change the working directory when calling std.process.execute.
June 09, 2019
On Sunday, 9 June 2019 at 08:20:15 UTC, Piotr Duda wrote:
> niedz., 9 cze 2019 o 04:50 Jonathan Marler via Digitalmars-d <digitalmars-d@puremagic.com> napisał(a):
>> [...]
>
> There is simple solution for this, don't allow positional arguments after named.

Yeah that seems to solve most if not all of the issues I pointed out.