In article 770995943@gm.dev.com, george@gm.dev.com (George Mitchell) writes:
>
>What I've always hoped to see is to specify arguments by the name of
>the formal parameters, viz.:
>
>extern "C" char *strcpy (char *to, char *from);
>
>....
> (void) strcpy (from: charPtr1, to: charPtr2);
>....
>
>(Although I didn't use default arguments here, you can see how they
>would fit into this scheme.)

This has been proposed several times to the C++ Committee, and rejected
each time.

One problem is that the parameter names in prototypes don't have
to agree with the names in the function nor with the names in
other prototypes. E.g., This:
 void foo(int a, int b);
 void foo(int b, int a);
 void foo(int arg1, int arg2) { ... }
is legal in C and C++, and represents two prototypes and a
definition of one function 'foo', all of which may appear in
the same compilation unit. If you disallow this rule, you forbid
what many consider a good programming style, and break many
existing programs. Not the above, naturally, but this:

 foo.h
 =====
 void allocate(int min_number_of_fizzbins, int max_number_of_fizzbins);

 foo.c
 =====
 void allocate(int min, int max)
 {
  ...
 }

That is, long names in headers for self-documentation, short names in
the function so expressions fit on one line.

If we keep this existing rule, what do you do with
 foo(a=3, b=4)
Is 'a' the first or second argument?

Next, the interaction with overloading is severe. Consider this:

 void bar(int    a=0,   double b=1.0); // two overloaded functions
 void bar(double b=2.0, int    a=3);
 ...
 bar(b=4.0); // call bar, use the default for 'a'

Now, is this bar(0, 4.0) or bar(4.0, 3)?

(BTW, you can't use '=' in the calling expression as I have shown,
since it conflicts with existing rules for expressions which
allow assignment as part of a general expression. So a new token
such as ':=' would have to be used, but that is a side issue.)

You can make up all kinds of special rules to handle all the special
cases, but in the end it was judged that the extra complexity, and
the increased opportunity for ambiguous function calls, was not
repaid by enough extra utility.

Remember, you can get the effect of default values for parameters by
writing additional overloaded versions of functions, or by using
a trick I showed in an earlier article. So very little expressive
power is actually achieved for the added complexity.
---
Steve Clamage, stephen.clamage@eng.sun.com