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

[Jonathan Marler]

On Thursday, 6 June 2019 at 23:08:56 UTC, Exil wrote:
> 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.

That's not the meaning I proposed.  I proposed that public 
exposes the "name" of the function parameter.  You're "straw 
manning" again, please look that one up.  Understand what I'm 
saying before you respond.

> Cause it doesn't make sense, not one wants to deal with that 
> address complexity because it provides zero benefit.

Encapsulation = Zero Benefit?

Well I can see we're not going to agree here :)

> 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.

Again, the benefit is Encapsulation.

>>> 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.
>

You seem to be confusing what I said.  I didn't say the 
parameters are encapsulated...that doesn't make any sense.  I'm 
talking about encapsulating the 'names' of the parameters.  I 
think once you understand the distinction you'll see you're 
response here doesn't make much sense.

>>> 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.


You just need a way to distinguish named from unnamed.  Opt-in 
and Opt out.  You could do so by putting all your named arguments 
in a struct and supporting some caller syntax to expand arguments 
into that struct.  You could use tuples, you could use a special 
type wrapper. And yes, you could use an attribute like "public", 
but you don't have too is the point.

Keep in mind that I'm not trying to say that you don't have any 
points here.  You are correct that having to opt-in means you 
have to depend on your libraries to opt-in to using named 
arguments before you can use them. That's a valid point.

I'm just weighing the pros and cons here.  I see a big con to 
enabling this by default for every function in D.  I see a small 
benefit from the feature altogether, as it's only useful for a 
small percentage of functions.  We can argue over how big/small 
those factors are, but I hope we agree that they are factors and 
that encapsulation matters and is important.  We can argue over 
the value of encapsulating parameter names, but you shouldn't 
dismiss it altogether.  A good scientist weighs all the factors 
without any bias, whether or not they agree with his/her initial 
hypothesis.  Listen to what others are saying and consider it.  
We're not at war trying to "beat" each other, we're on the same 
team trying to make D better for everyone.