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

[Jonathan Marler]

On Friday, 7 June 2019 at 02:51:16 UTC, Timon Gehr wrote:
> 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:
>>>>> [...]
>>>>
>>>> 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.
>

He said "To make a function parameter 'private' that would mean 
the user wouldn't be able to pass in a value to it".  My idea had 
nothing to do with preventing callers from passing values to 
arguments, hence why he is straw manning me.

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

Hmmm that's a good point, I suppose they are already exposed to 
the caller.  However, I believe private fields in structs/classes 
have the same problem.  You can still access those fields with 
some fancy reflection, but I don't think that means we should get 
rid of private fields just because we can still access them 
through reflection.  Do you?