Named Arguments Status Update

[Dom DiSc]

On Friday, 5 January 2024 at 09:48:53 UTC, Dennis wrote:
> ## Empty tuple value
>
> ```D
> alias AliasSeq(T...) = T;
>
> int f(int x, int y) { return 0; }
>
> int v = f(y: AliasSeq!(), 1, 2);
> ```
>
> Currently, the named argument y with an empty tuple will 
> collapse into nothing, and `(1, 2)` will be assigned to `(x, 
> y)`.

I think this is correct.
But I would strongly recommend not to use named arguments on a 
tuple, as the name will be assigned only to the first element of 
the tuple (if any) and everything beyond will depend on the tuple 
length - making it hard to find out to which parameters they go.
This contradict the whole purpose of named arguments: to make 
clear to which parameter a value goes.

>
> ## Overloading by name
>
> With named arguments, you can disambiguate an overload with 
> identical types by name:
> ```D
> string f(T)(T x) { return "x"; }
> string f(T)(T y) { return "y"; }
> static assert(f(x: 0) == "x");
> static assert(f(y: 0) == "y");
> ```

I call it a good thing that this doesn't work.
This kind of feature-misuse is why I'm not a fan of named 
arguents.
They are only acceptable in the most basic cases. Every more 
complex use of them is only obfuscating the code.

> ## Tuple parameters
>
> You currently can't assign a tuple parameter by name:

Why should you?
This doesn't help to make clear what value is used for what 
parameter (it's hidden behind the tuple anyway), so this is 
beside the usecase of named arguments.

> But consider that a type tuple can already have names when it 
> came from a parameter list:

Yeah. This is the place to use names, not in the call of the 
variadic args function.

> ## Forwarding?

Nope.

> ## Named value sequence?

If you didn't give something a name in the function declaration, 
why should you at the call site?

This whole thing becomes more of a burden than a feature.