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

[Timon Gehr]

On 07.06.19 05:10, Jonathan Marler wrote:
> 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.
> ...

Reductio ad absurdum is not per se a straw man fallacy, even if you 
disagree with/misunderstand the reasoning/definitions/values that lead 
to the ridiculous conclusion.

>>>> 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?
I don't particularly care, because there are other ways to restrict your 
public interface. Anyway, there are other pertinent points. As I said 
before, the analogy to _private_ fields actually does not have a lot of 
merit. You don't make your fields private just to be able to rename 
them, but to be able to completely reorganize your implementation, 
removing some private fields and adding other ones. A key reason why you 
don't want to have private members accessible is because you might break 
some internal invariant. With parameters, there is no such concern, 
because they need to be accessible by definition, they are part of the 
interface. Your subsystems _need_ to be coupled at interfaces, you just 
want the interfaces to be small. More automated checking for consistency 
at interfaces is actually good. Checking for consistency of parameter 
and argument names might occasionally break compilation of code in 
superficial ways that are easily dealt with by changing the characters 
in some identifier, but it does not actually lead to the disadvantages 
you get with a poorly encapsulated system.

Also consider that a library author can always note in the documentation 
that parameter names are not guaranteed to be stable, and that hence it 
is on the user of the library to trade off better type checking against 
fewer compilation errors when updating the library. Note that a 
compilation failure is actually the best kind of failure you can get 
when updating library versions.