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

Jonathan Marler johnnymarler at gmail.com
Thu Jun 6 22:55:02 UTC 2019


On Thursday, 6 June 2019 at 22:38:53 UTC, Jonathan Marler wrote:
> 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".

I do see some weaknesses with the "opt-in" approach.

The first one being that once a library decides to "opt-in", 
depending on how it's done, it may break that library from being 
compile-able by older compilers.

Also if named parameters were more useful, say around 50% of all 
functions, I would probably lean towards saying that we could 
sacrifice encapsulation and just have everything opt-in by 
default.  But because I think it will be needed more rarely, 
"opt-in" seems to make sense to me to preserve encapsulation of 
parameter names.




More information about the Digitalmars-d mailing list