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

Steven Schveighoffer schveiguy at gmail.com
Mon Feb 10 18:27:49 UTC 2020


On 2/6/20 10:33 PM, Jonathan M Davis wrote:
> Once in a while, named arguments may
> be useful, but for the most part, they're useful because a function has way
> too many parameters, in which case, the function should have been designed
> differently.

I find this assertion lacking evidence.

How does one design a constructor that initializes all the fields of a 
type without including all the parameters to initialize that type? If 
you reduce the number of parameters, what do you do with the data not 
specified? I suppose you can just have a minimal constructor and then 
just expect the user to set all the pieces up, but what if you need to 
use it in an expression? How do you decide which pieces are "important" 
enough to initialize first, and which ones get initialized later? What 
if the parameters are initializing things that can only be initialized 
in the constructor (e.g. immutable data).

I focus on constructors because structs ALREADY support named parameters 
in this instance (when there is a lack of constructor), and we haven't 
seen the problems you are asserting.

I can imagine with this DIP instead of 15 different constructors for all 
the different ways you want to construct said type (yes, I've seen this 
kind of stuff), you have one that has default arguments for all of the 
optional pieces (or maybe you split them up with ones that can be 
safe/pure and ones that can't, etc). And then the call interface is much 
better looking and self-explanatory. And I like that you can pick which 
way you want to call it, even for individual parameters.

-Steve


More information about the Digitalmars-d mailing list