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

[aliak]

On Monday, 10 February 2020 at 19:38:34 UTC, Manu wrote:
> On Thu, Feb 6, 2020 at 7:34 PM Jonathan M Davis via 
> Digitalmars-d <digitalmars-d at puremagic.com> wrote:
>>
>> On Wednesday, February 5, 2020 11:08:59 PM MST Mike Parker via 
>> Digitalmars-d wrote:
>> > [...]
>>
>> Well, I'll say again that I don't like the idea of having 
>> named arguments in the language, because it makes the 
>> parameter names part of the API, resulting in yet more 
>> bikeshedding and yet another thing that can't be changed 
>> without breaking existing code. Once in a while, named 
>> arguments may be useful, but for the most part, they're useful 
>> because a function has way too many parameters, in which case, 
>> the function should have been designed differently.
>>
>> Unfortunately, since it's Walter who created the DIP, and a 
>> number of people do like the idea of named arguments, I expect 
>> that some form of this will make it in, but I still think that 
>> it's a bad idea.
>>
>> - Jonathan M Davis
>
> I don't have any horse in this race... but I do just want to 
> echo that
> I don't understand this feature at all.
> I don't know what it's for. I've never felt I wanted named 
> arguments
> personally, and Jonathan's criticism feels very real to me.
>
> Here's a thought, which I haven't considered how it interacts 
> with this DIP deeply, but it should be on the table:
>
> I do an immense amount of generative meta; generate wrappers, 
> shims,
> bindings etc, which wrap existing functions.
> When the parameter names become part of the API, it means any 
> such
> meta must pay extra attention to properly mirror the parameter 
> names,
> and it must also carefully mirror the default args from the 
> function
> it's wrapping.
> While most of my code takes care to do this anyway, there are 
> cases
> where it's unnecessary and inconvenient. Some tasks can be 
> completed
> with a tool like:
>
>   ReturnType!originalFunction wrapper(alias
> originalFunction)(Parameters!originalFunction args)
>   {
>     // special sauce...
>     return originalFunction(args);
>   }

Before the DIP you'd call that like:

wrapper(1, 2, 3);

After the DIP you'd call that like:

wrapper(1, 2, 3);

Or are you saying meta must mirror parameter names as well? If so 
why? You can't do the default args today anyway, and I'm not sure 
if it's ever been a problem?

I do agree that having something like 
ParametersWithNamesAndDefaultArgs is infeasible. Not only from a 
technical point of view but maintenance, programming burden, and 
migratory.