Pretty please: Named arguments

[Andrei Alexandrescu]

On 2/28/11 1:32 AM, Russel Winder wrote:
> The huge downside of any named parameter approach is that you have data
> coupling between the source of the callee and the caller.  This is fine
> in a language such as Python where you distribute source and
> documentation tools so you can always find out the names of parameters,
> this is going to be a bit of a problem in languages where only the
> compiled form may be the only distributed form.  Programmers rely on
> some other form of documentation other than the source and this leads to
> error,

It's not all that bad. Walter and I discussed a couple of times adding 
such a feature. As long as the function signature in the .d or .di file 
does specify a parameter name, that can be used.

>> Potential problems:  The only problems I can foresee here are variations
>> on the situation when there are two (or more) versions of a function
>> with the same number, type, and names of parameters, but in non-matching
>> order, like this:
>>
>> void func(int a, char b);
>> void func(char b, int a);
>>
>> In such a case, the compiler should diagnose an error if named arguments
>> are employed.
>>
>> Thoughts?
>
> The Python mechanism relies on the fact that despatch is by name and not
> by signature.  Languages that dispatch by signature will have
> significantly greater problems!

A good subset of Python's approach to parameter passing sugar can be 
done without using maps or dispatch by name.


Andrei