DIP 1019--Named Arguments Lite--Final Review

Yuxuan Shui yshuiv7 at gmail.com
Tue Aug 27 17:01:21 UTC 2019


On Monday, 26 August 2019 at 21:48:42 UTC, Jonathan M Davis wrote:
> On Monday, August 26, 2019 8:18:21 AM MDT Kagamin via 
> Digitalmars-d wrote:
>> On Saturday, 24 August 2019 at 01:09:48 UTC, Jonathan M Davis
>>
>> wrote:
>> > Personally, I'm against named arguments in general. They 
>> > make the parameter names part of the API, which adds another 
>> > set of names that you have to get right up front and which 
>> > will be bike-shedded to death.
>>
>> Errors in function names happen too.
>
> My point is that adding named arguments results in even more 
> bikeshedding over names. We already have more than enough 
> trouble with that over function names and type names in APIs. I 
> don't want parameter names to be added to that. I don't want to 
> have to care about how good the parameter names are or have to 
> worry about breaking anyone's code when changing a parameter 
> name. And since parameter names have never actually been part 
> of the API in D, existing parameter names were not selected 
> with the idea that they would be used by anyone other than the 
> function itself. For instance, if we had named arguments, all 
> of a sudden, we'd have issues with whether range-based used 
> range, r, or some other name entirely for the range that 
> they're consuming or wrapping. Phobos is not at all consistent 
> about that - and it hasn't needed to be. If we added named 
> arguments, that sort of thing would then matter. I don't want 
> to have to deal with any of that.

I agree this _could_ be a problem. In fact, if you were there 
during the first community review, you would know I anticipated 
this objection, by adding the @named attribute.

But, OTOH, there are quite a lot of languages supporting named 
arguments, and I don't think I ever heard this become a problem 
for them.

So, yes, theoretically this is a problem; in practice, not so 
much?

>
> The _only_ use case IMHO where they add any real value is when 
> you have a long parameter list where most of the parameters 
> having default arguments.

Disagree. Oftentimes having the name clarifies a function, so the 
_reader_ doesn't have to read the document to figure out what a 
function call does (e.g.

     // width first, or height first?
     createWindow(100, 200);

     // ah
     createWindow(height: 100, width: 200);
)

Remember, code is not written just for the compiler to ingest.

>
> - Jonathan M Davis




More information about the Digitalmars-d mailing list