DIP 1020--Named Parameters--Community Review Round 2

[rikki cattermole]

On 11/09/2019 2:01 AM, 12345swordy wrote:
> Issues with the "@named" attribute:
> 1.This is opt-in rather then opt-out, which may causes users to beg the 
> library maintainers to update their libraries to support name attribute.

This is intended.
If you want to override the intention of the API author then we need to 
find another solution. One which I am unsure about how good it would be.

> 2. Way too much verbiage for declaring functions with named arguments.
> 3.I still think the code breakage caused by named arguments is still 
> overblown, I never encounter anyone in the C# who complains about code 
> breakage regarding named arguments.

The design C# has taken, was more restrictive and quite importantly more 
conservative than both mine and Walter's.

That may have been a key factor in it not breaking peoples code.

D is a much more complex programming language and almost all talk of 
named arguments is nonrestrictive in nature. So I disagree with the 
statement that it is overblown, because it may very well be well founded.

> Most importantly, there should be a alternative solution section 
> detailing Walter suggestion regarding named arguments. It be a total 
> waste to not mention his solution given that it has shown support from 
> other people.

Agreed.

However I am unsure how to add it to the DIP as it is technically not 
prior work (since as far as I know it did not exist before DIP 1020 was 
created).

But that is a problem for me to solve at another time.

For reference, there is an example in the DIP related to parameter lists 
length that IMHO invalidates his proposal. But that is not stated hence 
some work has to be done on it at a later point.