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

[Jonathan Marler]

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.

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

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