DIP 1030--Named Arguments--Community Review Round 1 Discussion

[Walter Bright]

On 2/11/2020 7:26 AM, Jonathan Marler wrote:
> True.  I estimate around 75% of functions in general don't benefit from named 
> parameters.  So the question becomes, what do we do about parameter name 
> inconsistency in these cases for the standard libraries?  If we don't think 
> named parameters are useful for a function, will we leave them be?   If so, can 
> we come up with a criteria we can use to determine when named parameters make 
> sense?  I think this would help greatly in this transition to named parameters 
> to help avoid alot of the bikeshedding I see coming when this is enabled.

Make some PRs to improve the consistency in advance, by all means.


> For example, for math functions like the ones I mentioned, are we going to 
> normalize on "x", "y" and "z" depending on the type?

Sounds reasonable to me. But keep in mind that this will also result in 
inconsistencies. For example, points will be (x,y,z) triplets.


> And if it's a template that 
> could accept any type, what name would we use in that case?

The most generous of the specializations.


> question still stands for functions that do make sense, do you think we should 
> come up with a standard set of names to promote consistency accross the standard 
> libraries, and 3rd party libraries?

I find standard names for things, like `p` for generic pointer, and `s` for 
generic string, and `i` for generic integer, to be valuable. But blind adherence 
to such will cause trouble, because it's not practical to be entirely consistent.


>>> Will we try to fix these names before integrating support for named parameters?

I wouldn't go crazy over this, but it would be nice to do it. Also, having good 
names for parameters is a good idea anyway.


>>> If we need to change names later, what will the policy be for druntime/phobos 
>>> for making parameter name changes when inconsistencies are discovered?

Initially, we shouldn't worry about fixing it because few will be using N.P. But 
later, no, we shouldn't be changing them.


> It looks like the parameter names have been stripped out for the windows 
> functions.  Do you think we should add parameter names in those functions?  If 
> we do want to add names, do you think we should we use the hungarian notation 
> parameter names from windows, or no?

Should use the names from the official Windows documentation. Ditto for all 
other APIs.

Also, there's no rush to add parameter names to APIs that don't currently have them.