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

Jonathan Marler johnnymarler at gmail.com
Thu Jun 6 22:26:15 UTC 2019


On Thursday, 6 June 2019 at 21:46:14 UTC, Jonathan M Davis wrote:
> On Thursday, June 6, 2019 1:50:09 PM MDT FeepingCreature via 
> Digitalmars-d wrote:
>> On Thursday, 6 June 2019 at 19:17:38 UTC, Jonathan Marler 
>> wrote:
>> > There's a big issue with this DIP.  It immediately allows 
>> > any function call to increase coupling with the 
>> > corresponding function definition with no way to disable it.
>>
>> I just want to explicitly note that increasing coupling 
>> between the call site and the function definition is the 
>> entire point of named parameters.
>
> Which is precisely why I really hope that no named parameter 
> DIP is ever accepted. It means that suddenly the parameter 
> names are part of the API, meaning that there's yet another 
> point where you have to worry about breaking user code and 
> another point where you have to worry about naming things 
> really well and where people will then bikeshed names. E.G. 
> right now, there is zero attempt in Phobos to name all range 
> parameters the same, and there's no need to, but if named 
> parameters become a thing (especially without requiring that 
> the function be annotated to allow them), then suddenly, we 
> have naming problems all over the place when we didn't before, 
> because the naming isn't consistent.

Exactly.

>
> IMHO, named parameters are rarely useful with well-written 
> code. They're primarily of benefit when you have a lot of 
> function parameters, which is bad design. And they're a 
> particularly odd design choice in a language where you're 
> allowed to have interface files that don't even have to provide 
> parameter names let alone make them match the ones in the .d 
> file.

I mostly agree.  Though I estimate they are sometimes useful even 
with a well-written interface, but, it is more rare.  Hence why I 
think an "opt-in" version would work well.  Just add "public" to 
the parameters you want to expose the names of.  Same semantics 
as fields of classes and structs.  Default to private, add 
"public" if you want the caller to see the name.

void foo(T t, public bool log);

foo(t, log: true);

>
> But I suppose that there isn't much point in my expressing how 
> much I hate DIPs like this in review threads, since such 
> threads are really just for helping to improve the DIP, not 
> vote it down. The decision on that is solely up to Walter and 
> Andrei (or Atila now, I guess).
>

But I'm sure they read these threads when reviewing.


More information about the Digitalmars-d mailing list