DIP: Named Arguments

[WalterBright]

No description provided.

[adamdruppe]

I wouldn't want to hold this up with my request, but I just wanna through out one idea that might be useful to me in some case: instead of banning identifiers on a variadic, actually use them to make an anonymous struct.

For example, given:

void foo(T...)(T args) {}

foo(a: 0, b: "zero");

Instead of issuing an error, that actually generates something like this:

struct _anonymous {
   int a;
   string b;
}

foo(_anonymous(0, "zero"));

and thus args[0] is actually an instance of this generated type, holding all the named parameters that matched the variadic.

A practical application of this would be library tuples with named members, or syntax sugar for creating dynamic (e.g. json) objects,or some cases of like database query DSLs.

I don't actually wanna sidetrack y'all too much, just throwing out this as something to consider as potential in changing this rule (or something).

[CyberShadow]

So basically Python's kwargs?

I'm not against the idea in principle but I think it needs to be opt-in for the callee, otherwise, if a parameter is removed, the error messages are going to be very confusing. (Also that would put it out of scope for this DIP.)

[adamdruppe]

yeah, basically. I am inclined to agree on being opt-in too.

[skoppe]

I like the feature. Another option would be named tuples foo((a: 0, b: "zero")).

[schveiguy]

I agree with @CyberShadow, the DIP as-is provides zero burden on the implementor, they don't have to change anything in any functions, it's just how you can call them is more pleasant.

The sort of change you are proposing would open up existing implementations to a lot of problems (and probably is a breaking change). I get the point of it, but probably not doable. Note that this would also cause problems with template instantiation, since separate calls for the same types would now be different instantiations, depending on the names used in the call.

However, template parameters might provide a mechanism for this. For example, you already have code like this:

template IKnowYourName(T...)
{
   pragma(msg, __traits(identifier, T[0]));
}

int x;
alias n = IKnowYourName!x; // prints "x"
alias n2 = IKnowYourName!(blah: 0); // could also work, even with existing code

[atilaneves]

I guess this is a typo? Otherwise I don't understand the semicolon or why i can have a default value with t requiring one.

[WalterBright]

fixed

[schveiguy]

There should be something in there discussing lambdas and function types in general. I’m assuming that parameter names don’t affect the type but the type declaration that is used will dictate the parameter names recognized?

[schveiguy]

Replacing

[schveiguy]

This is based

[WalterBright]

ok

[schveiguy]

If it does not match

[schveiguy]

NamedArgument , ArgumentList

right?

[WalterBright]

right

[schveiguy]

Existing grammar has this as AssignExpression, not Argument.

https://dlang.org/spec/grammar.html#ArgumentList

[WalterBright]

yes

[WalterBright]

the type declaration that is used will dictate the parameter names recognized?

That's right. I amended the DIP to reflect this.