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

[Johannes Loher]

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.

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

6. Another possible interaction the DIP does not mention at all is
implicit istanciation of template functions. Without giving it too much
tought, 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.