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

[Atila Neves]

On Sunday, 9 June 2019 at 13:39:34 UTC, aliak wrote:
> On Sunday, 9 June 2019 at 11:54:25 UTC, Atila Neves wrote:
>> 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.
>
> I'm curious what the dev process is here? You write a function, 
> start filling in it's parameters and you get it wrong. Ok, so 
> you check the docs right?

Most times the compiler complains.

> And then you fill in the arguments while looking at the docs 
> right? Or?

I fix the call based on the compiler error. I may or may not look 
at the function declaration.

> Also do you think you'll have a similar experience with 
> reorderable named parameters where instead of the position it 
> is now the name of the argument?

The hypothetical isn't needed, I already program that way when I 
can:

https://github.com/atilaneves/kwargs

Telling the compiler which argument matches each parameter with a 
type name or variable name seems, to me, to be a minor 
distinction. They're both symbols.

> And then on top of that, if we allow non-named parameters to 
> mix with named parameters, then what does reordering give you?

I thought I already covered that with my std.process.execute 
example. Right now I have to do this:

auto myExecute(string[] args, string workDir) {
     import std.process: Config, execute;

     const string[string] env;
     const config = Config.none;
     size_t maxOutput = size_t.max;

     return execute(args, env, config, maxOutput, workDir);
}

When really I just want to:

import std.process: execute;
execute(args, WorkDir("~/foo/bar")); // or workdir: "~/foo/bar", 
or whatever

I've typed the former more times than I can count, despite never 
having cared about changing the default values of the 
intermediate arguments.