Pretty please: Named arguments

[dsimcha]

On 2/28/2011 8:48 PM, Andrei Alexandrescu wrote:
> On 2/28/11 6:03 PM, Jonathan M Davis wrote:
>> The more I think about this, the more I'm against the idea of named
>> arguments.
>
> I think you have been blessed to work with only small, clean APIs.
> Certain domains definitely promote large argument lists. Though the
> designs could certainly be refactored to e.g. group parameters into
> separate objects, it's overkill to do that. I'm afraid sheer experience
> is showing that your counterarguments are not based.
>
> Andrei
>

Agreed.  I don't know how many times, when designing an API, I've 
considered making something  configurable and instead just hard coded it 
to avoid bloating things with yet another regular (must be passed 
in-order) function argument or (if I put the options in a struct) yet 
another type.  Besides, using structs to hold options requires 
boilerplate for the user of the library.  What would you rather write?

A:

Options options;
options.someOption = someValue;
fun(mandatoryArg1, mandatoryArg2, options);

B:

fun(mandatoryArg1, mandatoryArg2, someOption = someValue);

The beauty of named arguments with defaults is that they allow you to 
make things configurable with as little boilerplate code as possible for 
the library writer and as little boilerplate as possible for the user in 
the case where such configurability isn't needed.