DIP 1030--Named Arguments--Community Review Round 1 Discussion

[Steven Schveighoffer]

On 2/8/20 5:04 AM, Timon Gehr wrote:
> On 07.02.20 16:28, Steven Schveighoffer wrote:
>>>
>>> It does add the syntax, and I would argue it is not ideal if this 
>>> fails to pass semantic analysis.
>>
>> Yes, it's valid syntax, but shouldn't pass semantic -- you named 
>> arguments that aren't present (AliasSeq does not have parameters named 
>> a b or c).
>> ...
> 
> So you are arguing that e.g., std.typecons.Proxy should fail to work 
> with named arguments?

Technically, it doesn't today, so it's not a break. But it is a good 
point. opDispatch in general will fail to support named parameters 
without a ton of extra mixins and boilerplate (potentially, you could 
have opDispatch specify all parameters and names).

> 
>> But the DIP isn't 100% clear that named variadics cannot receive 
>> NamedParameter items. It says extra parameters match the "trailing ... 
>> of variadic parameter lists and Identifiers are not allowed". Not all 
>> variadic functions have a trailing ... without a name. I would think 
>> AliasSeq!(TList: 1, 2, 3) should be valid.
> 
> Why is that more useful than support for forwarding?

Not more useful, but unambiguous.

For example, what does AliasSeq!(TList: 1) mean? Did you mean to assign 
a 1 to the template parameter already named TList, or did you mean to 
submit a parameter named TList?

Should this then fail to compile or pass?
void foo(int a);
alias params = AliasSeq!(TList: 1);
foo(params); // does this mean foo(1) or foo(TList: 1)?

Potentially, we could specify with some syntax that a parameter could 
consume all named arguments not already tagged, and that name wouldn't 
matter. An interesting artifact of this, is that we could potentially 
eliminate std.typecons.Tuple.

But I feel this would be an additional proposal on top of named 
parameters, even though it's related.

-Steve