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