Tuple Parameters

[Walter Bright]

On 1/5/2024 1:48 AM, Dennis wrote:
> ## Tuple parameters
> 
> You currently can't assign a tuple parameter by name:
> ```D
> alias AliasSeq(T...) = T;
> 
> int f(AliasSeq!(int, int) x) { return 0; }
> // This will expand to:
> // int f(int __param_0, int __param_1) { return 0; }
> // So this fails:
> int v = f(x: 1, 2);
> ```

It should fail, unless the AliasSeq has exactly one (unnamed) member, when it is 
clear what should happen.


> I can change it so it expands to
> ```D
> int f(int x, int __param_1)
> ```

We shouldn't be inventing new behavior without a valuable use case. Corner cases 
like this should just be an error. That leaves us open to making it work if a 
valuable use case emerges, rather than discovering we are stuck with wrong behavior.


> But consider that a type tuple can already have names when it came from a 
> parameter list:
> 
> ```D
> int f(int x, int y) { return 0; }
> 
> static if (is(typeof(f) T == __parameters)) {}
> pragma(msg, T); // (int x, int y)
> int g(T) {return 0;}
> static assert(g(x: 3, y: 5) == 0); // Currently works
> 
> int h(T z) {return 0;}
> static assert(h(z: 3, 5) == 0); // Fails, should this work?
> ```
> 
> Is the first parameter named `x`, `z`, both?
> Note: making the declaration of `h()` an error would be a breaking change.

Trying to rename a parameter when the tuple element already has a parameter name 
should be an error.

In general, questionable corner cases should be treated as errors until a 
compelling use case for them is found.