Named Arguments Status Update

[Richard (Rikki) Andrew Cattermole]

On 05/01/2024 10:48 PM, Dennis wrote:
> ## Empty tuple value
> Currently, the named argument y with an empty tuple will collapse into 
> nothing, and `(1, 2)` will be assigned to `(x, y)`.
> - Should this be an error?
> - Should this assign `1` to `y`?

I would error on two fronts:

1. The alias sequence was empty
2. Too many arguments for parameters

Clearly something was amiss when the programmer wrote it.

> ## Overloading by name
> Should the compiler, after finding a matching overload, retry all other 
> overloads without named arguments to prevent this? Or should it 
> instantiate it the `x` variant because it saw it first, and then refuse 
> to instantiate `y` because the mangle has been seen before?

This seems like something that should have already been checked.

But if not I suppose the smelly but correct solution is yes, try without 
named arguments using the parameter list found thanks to with named 
arguments.

Otherwise can it not be continued checking? One iteration of checks, 
rather than 2. With only 1 allowed to match.

> ## Tuple parameters
> Is the first parameter named `x`, `z`, both?
> Note: making the declaration of `h()` an error would be a breaking change.

I would go with z. As it is an aggregate.

So the current behavior is correct.

Otherwise it seems more surprise heavy than is required.

> ## Forwarding?

We currently do not support forwarding of any argument names.

The only method we have is for alias template parameters and 
``__traits(identifier, param)``.

Language is lacking, until that is resolved named arguments shouldn't be 
trying to shoehorn it in. It needs a DIP if we want it.