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

[Timon Gehr]

On 07.06.19 01:36, 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,

No, he's just not arguing against the aspect of your idea that you think 
he is. You are the one setting up the straw man.

> please look that one up.  Understand what I'm saying before you respond.
> ...

That's a pretty hard constraint to satisfy, considering that you are not 
making any sense.

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

His point was that hiding argument names is not "encapsulation". You are 
arguing against a straw man. Note that mentioning fallacies by name is 
actually rarely useful.

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

Well, let's look at the facts:

- Parameter names are already exposed, and changing parameter names can 
already break third-party code:
https://dlang.org/phobos/std_traits.html#ParameterIdentifierTuple

No "encapsulation" for you. (Whatever that's supposed to mean.)

- It is possible to not name parameters (an alternative way is to use 
*.di files):

import std.traits;
int add(int, int){
     return _param_0+_param_1;
}
void main(){
     assert(add(1,2)==3);
}

I guess that's what you would call "encapsulation".

I.e., if you want to not expose any parameter names, you have the means 
to do so. Let's call those two ways to declare parameters public and 
private. What named arguments allow you to do is to actually refer to 
the public parameters by name.

If we had structs with public and private fields, there was no field 
access (e.f) syntax and you could only access public fields by index, 
would you also argue that this is a good thing, even if there was 
already a __trait to get the index of a field from its name and vice-versa?