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

[Andrei Alexandrescu]

On 6/9/19 9:39 AM, 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? And then you fill in the arguments while looking at the docs 
> right? Or?
> 
> 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? And then on top of that, if we allow non-named parameters to 
> mix with named parameters, then what does reordering give you?

A missing straitjacket.