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

[Exil]

On Thursday, 6 June 2019 at 23:36:11 UTC, Jonathan Marler wrote:
> 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.

It's what private currently means. You are misunderstanding what 
I am saying and throwing around strawman like it applies. 
Encapsulation/private/public do not relate at all to what you are 
suggesting.

>> 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 :)

This is not encapsulation. You are conflating the two. Talk about 
strawman...

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

It is not 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.

And you are going on and on about encapsulation... I understand 
what you are saying. That is not encapsulation, and what you are 
proposing is not useful. It prevents a useful feature from being 
used, if API maintainers don't want to maintain it, then they 
don't have to. Just like everything else. But then no one will 
use their API, and/or people will complain and it will be fixed.

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

Those all sound like terrible ideas. I need an extra struct to be 
able to use named and unnamed functions? So now named parameters 
dictate the design? I can only imagine the additional problems 
this would add. A special type wrapper might be worse than an 
extra attribute.

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

It doesn't matter what percentage. That's the thing, you might 
say this section of is more important and should use named 
parameters. But I disagree, and I think this other section should 
have named parameters. But you are the library maintainer, so you 
make your choice and you chose to ignore mine. Now I use your 
library and I am restricted to which functions I can use a 
language feature on. I can't use the language feature where I 
want to because of the maintainer's opinion.

struct A {
private:
     int a;
}

  A a;
  a.a = 10; // error can't do it

void foo( int value );

foo( value: 10 ); // error not defined to use named parameters
foo( 10 ); // functionally the same

The whole idea of "encapsulating" the variable name is completely 
bonkers to me. It's a feature that is mislabeling something as 
encapsulation and is trying to shoehorn it is with statements on 
the basis that "encapsulation" can't be bad. It is when you don't 
know what it is or why it is useful.