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

[Jonathan Marler]

On Thursday, 6 June 2019 at 22:26:57 UTC, Adam D. Ruppe wrote:
> On Thursday, 6 June 2019 at 22:19:46 UTC, Jonathan Marler wrote:
>> If they need to change them
>
> Why would they need to change the name of a function argument 
> anyway?

Seems like a silly question doesn't it?  Have you ever changed 
the name of an argument in a library?

Have you ever changed the name of private field in a 
struct/class?  What you're saying is that functions should not 
have any privacy/encapsulation when it comes to parameters names. 
  Do you also think structs and classes should not have the 
private modifier?

>
> Note that the name is already exposed in the documentation too, 
> as well as by existing reflection (I, among others, have 
> written named param libraries already, for example).
>
>> I'd guess around 15% of all functions would use them
>
> I'd probably not use it myself so I'm meh on having it in the 
> language... but I don't think the breakage is a big deal. You 
> can just not use it in your code and be protected against 
> arbitrary changes.

Again...do you also apply this same argument to having private 
fields in structs/classes?

>
> Though if the name changes, it might indicate a change in 
> meaning of the param too, so maybe breakage is a good thing.

So in that case, you would make the parameter "public" so you 
could expose a change in semantics.  I'm not saying we shouldn't 
have named arguments, I'm saying it should be "opt-in".