Passing function parameters by name

[renoX]

>> I could ask the opposite question: why should we restrict the API to 
>> the function and object name instead of using the full data that we have?
> Because it's simpler, and there's an enormous body of code (C, C++ for 
> example) which demonstrates a language can get by perfectly well without 
> it;

With hacks in the compiler such as the special case for memset I talked 
about, I don't think that it works 'perfectly well'.


> Is the extra cost worth the benefit?
> 
>> To answer your question: passing parameter by name increase the 
>> readability of the source, reduce the number of mistake when writing 
>> the code (and with a good IDE the number of character to type would be 
>> the same).
> 
> But it also means that if you change the name of a parameter in a 
> library, user code will break. Certainly, you'd need some special syntax 
> to specify which parameters are part of the API, otherwise you get 
> horribly brittle code.

Uh? Why would renaming the parameters of a function happen more 
frequently than say renaming a function?

> Overload lookup rules could become complicated.

If two function overloaded function have a different set of parameters 
name, then if you call a function passing a parameter by name then, then 
either it's a 'common' name and the normal overload rules apply either 
it's a name which appears in only one function so it's not an overload 
anymore (if you have two parameters specific to two different function, 
it's an error) ..


>>> Named arguments are potentially a disastrous feature, if completely 
>>> unrestricted. It was when COM needed to support VB's named arguments 
>>> that Windows programming really nose-dived.
>>
>> Could you explain this point? (I know nothing about COM).
> 
> <flame>
> VB allows you to call a C++ COM object by giving a list of argument 
> names (as a text array, with whatever stupid VB formats are possible) 
> together with the argument values as VB Variants. Languages like C++ 
> were supposed to support any  combination the VB programmer chose to 
> use. A massive complication of COM code, just to support sloppy practice 
> by VB programmers, and even then it was only necessary because the VB 
> interpreter was too lazy to put the parameters in the right order.
> </flame>

Interesting.

Regards,
renoX