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

[Jonathan Marler]

On Saturday, 8 June 2019 at 18:05:43 UTC, Jonathan Marler wrote:
> On Thursday, 6 June 2019 at 20:04:15 UTC, Walter Bright wrote:
>>     [...]
>
> Unlike the other cases, this one seems particularly surprising.
>
>>     [...]
>
> This is another re-ordering case, which makes my brain have to 
> strain for a second.
>
>> [...]
>
> 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?
>
> Allowing re-ordering seems to cause surprising results, such as 
> the ones I noted above, and also causes a new decision to made, 
> namely, which order should arguments be evaluated in (which you 
> noted).  It also means that in order to understand what 
> overload you are calling, you need to check EVERY argument 
> before you can determine this.  If you don't allow re-ordering, 
> you can rule out overloads sooner as you only need to check 
> whether the next named argument matches the next named 
> parameter.  To demonstrate, in the above example, if I saw
>
>>     [...]
>
> I can immediately rule out overload B since parameter `s` must 
> always come before `t`.  I don't have to check the rest of the 
> arguments to see if there is a "s: ...", and then make sure to 
> remember that it does as I move through the rest of the 
> parameters.  The amount of memory a human will need to track 
> while evaluating which overload is taken as the number of 
> parameters grows will be unmanageable if re-ordering is 
> allowed.  And, usually the most useful cases for this are the 
> ones where there are alot of parameters.

By the way, I think your proposal is basically DIP 1019 except 
allowing default arguments to be skipped and allowing re-ordering.

But again, I maintain that re-ordering seems to be add more 
confusion than it does value.

Reordering isn't a problem with struct initialization as there's 
no such thing as struct initialization overloading :)