Tuples a first class feature, manu's new unary operator and named arguments

[Timon Gehr]

On 08.05.20 22:38, 12345swordy wrote:
> As I am working on the "Tuples first class feature" dip (will uploaded 
> first draft soon), I noticed that if we would allow this in D:
> 
> fun((int x = 10, int y = 1, int z = 2)...);
> 
> Could this be used as a replacement for named arguments?

No, too ugly. Anyway, there should not be a difference in features for 
tuples and multiple function arguments. In mathematics, those are the 
same thing. (I.e. each function has one parameter, which may be a 
tuple.) Ideally, built-in tuples and multiple function arguments should 
interact in a way that is consistent with this principle.

> It would 
> address the readability problem certainly. However it doesn't address 
> the default argument values that certain functions have. I.E.
> 
> void sub(int x, int y = -1, int z) { ... }
> 
> if that were the case why not allow tuples such that
> 
> sub((int x = 0, int z = 0)...) = sub(0, -1, 0)
> 
> It will attempted to map tuple variables to function argument based on 
> the named values. Then I realize that it will ran into the same issue 
> with name arguments by default as that when the function arguments name 
> been changed it will break users code, so no dice there.
> ...

That's true even now, so this is not a strong argument. The problem is 
that existing names are inconsistent because naming is hard and the 
authors were not aware that function names are part of the public API. 
Attributing this situation to named arguments is simply a mistake.

> Any thoughts on this? Right now, my dip is nothing more than much needed 
> syntax sugar for tuples.
> 
> -Alex

I don't see why you would start a new DIP instead of forking mine, but 
in any case, syntax for a named argument tuple should be (x: 0, z: 0), 
not (int x = 0, int z = 0).