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

[Yuxuan Shui]

On Friday, 15 February 2019 at 18:04:36 UTC, Johannes Loher wrote:
> Am 15.02.19 um 13:56 schrieb Mike Parker:
>> [...]
>
> All in all, DIP 1019 looks quite interesting and also primising 
> to me. I do however see some issues with the DIP:
>
> 1. The rationale describes 2 problems that can arise when not 
> having named arguments, but it does not describe how those 
> problems could be prevented by using named arguments.
>
> 2. In the "Description" secion, the DIP says:
>
>> When the label and the corresponding parameter name mismatch, 
>> the
> compiler will generate an error of the following nature: "Named 
> argument 'foo' does not match function parameter name 'bar'."
>
> I don't really understand how the compiler should generate this 
> exact error message. How can the compiler know that the 
> argument passed with name 'foo' is supposed to match the actual 
> parameter 'bar'? I don't think this is possible if reordering 
> of named arguments is allowed (as the DIP later suggests).
>
> To clearify this, the DIP should provide code examples where 
> those mismatches occur and what errors are detected (or not 
> bother with specifying what the exact error message is, but 
> simply state that this is a compile error, but also provide 
> examples).
>
> 3. In the completeness section, I would have liked an example 
> to make this more easily understandable.
>
> 4. In the "Alternatives" section, the DIP says:
>
>> For example, in one potential library-only solution, it is 
>> necessary
> to call functions like so:
>>
>> args!(add, a=>1, b=>1);
>>
>> This has too much noise and, moreover, does not allow for the 
>> use of
> Uniform Function Call Syntax (UFCS).
>
> This clearly suggests that named arguments as proposed by the 
> DIP should work with UFCS. However, the DIP fails to explain 
> how this should actually work. At the moment, UFCS works by 
> lowering as described in the following example:
>
> ```d
> int add(int a, int b, int c) { /* ... */ }
>
> void main() {
>     1.add(2, 3); // lowered to add(1, 2, 3);
> }
> ```
>
> It is totally unclear how this should work with named arguments.

Thanks for pointing these out, they will be fixed in the next 
revision.

>
> 5. Similarly, as already mentioned by somebody else, the DIP 
> fails to explain interaction with function default arguments.

I think it is reasonable to require a prefix of the parameters 
are specified.

e.g. int fun(int a, int b = 1, int c = 2, int d = 3);

The user can specify (a), (a, b), (a, b, c) or all of the 
parameters, and the arguments can be in any order.

>
> 6. Another possible interaction the DIP does not mention at all 
> is implicit instantiation of template functions. Without giving 
> it too much thought, to me it looks like this should actually 
> work. But the DIP does not consider this at all. It should at 
> least describe whether those features are compatible or not, 
> and provide examples if they are.

I think it should just work. But I would give it some thought and 
include that in the next revision.

Thanks!