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

[Exil]

On Thursday, 6 June 2019 at 22:35:31 UTC, Jonathan Marler wrote:
> On Thursday, 6 June 2019 at 20:25:32 UTC, Exil wrote:
>> On Thursday, 6 June 2019 at 20:10:06 UTC, Jonathan Marler 
>> wrote:
>>> Far to high of a cost just to allow some cases to be more 
>>> readable.  However, if you make it opt-in, then you don't 
>>> have to pay that cost for EVERY function, you only increase 
>>> coupling in the cases that make sense.
>>
>> Making it optional makes it useless. Name the programming 
>> languages that implement named parameters this way, and I'll 
>> give a giant list of ones that don't. You can make this exact 
>> argument for basically structs and everything else.
>
> Yes I am making the same argument as for structs/classes.  
> Structs and classes can "opt-in" and "opt-out" to exposing 
> their fields.  Saying that all function parameter names should 
> be exposed and coupled to the caller is like saying we 
> shouldn't have private fields in structs and classes.

That doesn't make any sense. To make a function parameter 
"private" that would mean the user wouldn't be able to pass in a 
value to it. They are already public, they just need a name now.

Why aren't you proposing this instead then ?

    void foo(private int a, public int b) { }

Cause it doesn't make sense, not one wants to deal with that 
address complexity because it provides zero benefit. The only 
benefit you get from having names be optional is that library 
maintainers can screw over their user base if they want to use 
the feature or not. This does not solve anything by making it 
optional. Every issue you can have with it not being optional is 
already a problem today with existing features, and there's no 
solution to it a side from governing people that use D.

>> When you use a library you are at the mercy of it's owner. 
>> I've seen some people maintain an API that just literally 
>> changed the style so basically every single line that used 
>> that API now had to be updated.
>
> Even more reason not expose all the parameter names of all the 
> functions in their library.  If the library owner changes any 
> of their parameters names, they have broken compatibility with 
> their library. This increases the opportunity for breakage 
> dramatically.  That's the power and benefit of encapsulation, 
> being able to change the internals without breaking your 
> external facing API.

That power is entirely depending on the person writing it. If the 
maintainer wants to keep backwards compatibility with named 
arguments it is very easy to do so. This is NOT encapsulation, 
you can still access parameters. Making it optional won't make 
maintainers be good maintainers, it will just make the users 
suffer and avoid the feature for its uselessness.

>> There's already enough attributes, we shouldn't be adding more 
>> needlessly. I don't think this is a good enough reason to.
>
> I didn't say we should add an attribute.  You're now 
> demonstrating the "straw man fallacy" 
> (https://en.wikipedia.org/wiki/Straw_man).

What the, this isn't even the main argument and your pulling that 
card? Come on now. I would be interested in hearing how you will 
mark one function as optional and another as not optional though. 
Someone suggested @named, I have yet to hear anything better from 
you.