DIP 1019--Named Arguments Lite--Community Review Round 2

[Jonathan Marler]

On Friday, 7 June 2019 at 05:18:51 UTC, FeepingCreature wrote:
> On Friday, 7 June 2019 at 03:52:24 UTC, Jonathan Marler wrote:
>> By my estimate the percentage of functions that fit any of 
>> these 3 criteria is around 15%. This isn't backed by any real 
>> data, just an estimate.  I would love to see actual data on 
>> this, if someone wants to go through some druntime/phobos 
>> modules and count how many functions would benefit from named 
>> arguments.  And my criteria list could also be incomplete, I'm 
>> sure there are other cases where named parameters could be 
>> useful.  Please let me know if you can think of any more.  And 
>> if it turns out the percentage is much higher than my 
>> estimate, then I might change my mind and say that decreasing 
>> encapsulation is worth the benefit of having named parameters 
>> "always on".
>
> D has features that are useful for a *lot* less than 15% of 
> cases. If you think named parameters are so harmful that 15% is 
> too low a rate to bring them in, then you basically dislike 
> named parameters as a feature.

I'm not sure where you got that, I never said I didn't want named 
parameters.  I do want to bring named parameters in even though I 
only think they apply to 15% of cases.  I'm just pointing out a 
reason for making them "opt-in" instead of "always on" with no 
way to disable them.

I think there are other proposals that provide the same benefits 
without the drawbacks.  Walter's proposal may be one, Timon's 
tuple proposal should be considered as well to make sure we don't 
design a feature that won't work if we decide to implement tuples.

> But this is not a disagreement on merits - the things you 
> dislike *are* the things that I like about named parameters. I 
> think we have to separate "I don't like these parts of this 
> feature" and "I think these parts don't *work*".

I think there are pros and cons to exposing all parameters names 
to all callers.  The big con is that it adds extra coupling 
between every function and caller that in the majority of cases 
is not beneficial (at least by my estimate, having data will show 
whether or not it is actually the majority).  But there are 
benefits to enabling named parameters for all functions such as 
allowing the feature to be used without changing libraries, and 
it's backwards compatible.  I can see the pros and the cons, I'm 
just pointing out the con, but I can see where you're coming from 
if you think the pros outweigh the con.  What some people on this 
thread are saying is that the CON doesn't exist, so I'm focusing 
on explaining why it does exist which probably makes it sound 
like I don't want the feature at all.

>
> The very notion of "Named Arguments Lite" is in my opinion the 
> consequence of trying to appeal to people who just don't find 
> named arguments appealing.
>
> I think we need to separate "problems with named arguments" and 
> "problems with this DIP for named arguments" (of which there's 
> still plenty). If you think that named arguments, or rather 
> opt-out named arguments, are a bad idea, there should be a 
> separate language design thread to debate that question.

Well this DIP isn't even "opt-out", at least for the function 
definition.  If I want to keep my parameters names private so 
that I can change them without breaking compatibility, I have no 
way to do it.  It's like not having a way to make fields private 
in a struct or class.  Though to be fair, exposing field names vs 
parameters names are not the same thing, but the drawback 
shouldn't be dismissed.  Instead it should be analyzed and 
weighed against everything else.

But you are right that this DIP should not be the "make or break" 
for named parameters, and I don't think anyone is saying it is.  
I'm just pointing out a flaw with this particular DIP, not with 
named arguments in general.