Martin D Kealey <martin@kcbbs.gen.nz> wrote in article
<199611072112.KAA04900@kcbbs.gen.nz>...

[on keyword function arguments]

> In article <327A513B.525B@oec.com>, Pete Becker (pbecker@oec.com) wrote:
> > There's another aspect of this that I really don't like: how does it
> > ineract with overloading? We considered a couple of proposals, and some
> > folks worked hard on this, but nobody could make it work sensibly with
> > overloading.
>
> Ok, there is a problem getting this to work because currently names
> aren't part of the function signature.  The obvious answer would
> seem to me to make them part of the signature, but in a way that doesn't
> impact on existing practice

That does seem to be the crux of it, isn't it? Not breaking existing code.
That and doing it in such a way that it doesn't encourage excessive
argument lists.

> for examples:
>
>     void Copy( Type & :dest, const Type & :src );
> or
>     void Copy( Type & =dest, const Type & =src );

or

 void foo(bar& destination: dst, const bar& source: src = bar());

where 'dst' and 'src' are optional (and possibly default to the argument
keyword). This allows continuing the practice of long names in headers with
short names in implementation files. It makes the argument keyword distinct
from the argument's name itself.

> Names would be required to match in all declarations, and it would be
> illegal to declare a function with the same list of type/name pairs in a
> different order.

> I'm not sure if mandatory names should be allowed on some parameters and
> not others, but for a first-cut at a proposal I would say "no".

Actually, I would take a cue from Lisp here. I don't remember _exactly_ how
argument keywords work in that language, but rougly I'd expect:

* calling a function with argument keywords _requires_ use of the keyword
in the call
* the order of keyworded arguments is not considered in declaring,
defining, or calling the function
* the order of non-keyworded arguments is significant, just as it is now
* keyworded and non-keyworded arguments may be mixed in any order, so long
as the non-keyworded arguments are in the correct order and all of the
keyworded arguments have their names given in calls

Given that, I think you can even deal with the overloading problem. For
overloading, you consider the set of functions which:

* have a legal conversion for the first N positional (non-keyworded)
parameters in order, where N is the number of positional arguments given in
the function call
* have a legal conversion for each named (keyworded) parameter that matches
a named parameter given in the function call

and then search for the best match among those functions.

The analogy to the current system is that instead of parameters always
matching according to their positions, some may match according to an
argument name instead. You can consider the current system a degenerate
case of this, where the first parameter is named _P0, the second _P1, and
so on through _P[N-1].

If it helps, just consider how that degerate case works given the current
rules: re-write all functions as if all positional parameters have a
keyword name _P[X], where X is the parameter number, and always match on
names instead of positions. Now if you consider the case where some of the
parameter 'names' can (must) be given explicity, you have an
argument-keyword system. I'm not sure, but I think it's important that
named parameters _must_ have the argument named in the call. That even
solves the too-long argument problem to some extent: if you're required to
name the arguments, people will be discouraged from using them except where
necessary, because C and C++ programmers hate typing more than they need
to.

I used to be strongly opposed to argument keywords, even though the idea
has merit (and is widely used in some languages). Solving the
code-breaking, overriding, and overuse problems goes a long way to making
the idea reasonable, however.

Is it possible to make official language-extension proposals for the next
version of the standard, since no more extensions are allowed in this
version? Would they at least be archived for later?
--
Bradd W. Szonye
bradds@concentric.net
http://www.concentric.net/~bradds
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]