>I would be very interested if someone could come up with a proposal that
>would not break the following (currently perfectly legal) code:
>
>#include <iostream>
>void g() {
>     void f(int burt, int bart, int bob)
>     f(3, 4, 5);
>}
>void h() {
>     void f(int bart, int burt, int bill)
>     f(4, 6, 7);
>}
>void f(int fred, int joe, int harry) {
>     cout << "total = " << (fred+joe+harry) << "\n";
>}

Surely that's not a problem, as most of the specifications I've seen are
a backwards-compatible syntax. So the above would work, but could
be rewritten:

    void f(int fred: f, int joe: j, int harry: h) {
        // ...
    }

g() and h() would declare and call f() like this:

    void g() {
        void f(int fred: burt, int joe: bart, int harry: bob);
        f(fred: 3, joe: 4, harry: 5);
    }

    void h() {
        void f(int fred: bart, int joe: burt, int harry: bill);
        f(fred: 4, joe: 6, harry: 7);
    }

The tag-names must be the same but the formal parameter names are
ignored in declarations.

--
Neil
---
[ 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                             ]

Mark Rodgers wrote:
>
> In discussing this, don't forget that C++ has a "one definition" rule but
> not a "one declaration" rule.
>
> I would be very interested if someone could come up with a proposal that
> would not break the following (currently perfectly legal) code:
>
> #include <iostream>
> void g() {
>      void f(int burt, int bart, int bob)
>      f(3, 4, 5);
> }
> void h() {
>      void f(int bart, int burt, int bill)
>      f(4, 6, 7);
> }
> void f(int fred, int joe, int harry) {
>      cout << "total = " << (fred+joe+harry) << "\n";
> }

Sure. Only allow the use of named parameters if all declarations plus the
definition specify the same parameter names in the same order. As long as this
is the case, a caller could either leave off the parameter names by specifying
the parameters in the same order, or use parameter names for all parameters in
which case they could be in any order. If a subsequent declaration was
encountered that differed from an earlier one, from that point on in the
compilation unit, callers would be prohibited from using named parameters.

This means that the above could be modified as:

#include <iostream>
void g() {
     void f(int burt, int bart, int bob);
     f(bob: 5, bart: 4, burt: 3); // can used named parameters here
}
void h() {
     void f(int bart, int burt, int bill);
     f(4, 6, 7); // can't use named parameters here
}
void f(int fred, int joe, int harry) {
     cout << "total = " << (fred+joe+harry) << "\n";
}

--

Ciao,
Paul
---
[ 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                             ]

David R Tribble wrote:
>
> In <3469DFF3.DC97F246@informatik.tu-chemnitz.de>,
> Tobias Neubert <Tobias.Neubert@Informatik.TU-Chemnitz.DE> wrote:
> > Per Erik Stendahl wrote:
> > > Sometimes I really miss "named parameters" (I am not
> > > sure of the correct name for this feature).
> >
> > Roland Hartinger has already mentioned this in the past. The correct
> > name is 'Keyword arguments'.  His proposal was close to technical
> > perfect. But "the extensions group reached a consensus that the
> > proposal was close to redundant, would cause compatiblity problems with
> > existing C++ code, and would encourage programming styles that ought
> > not to be encouraged." as you can read in Bjarne Stroustrups book "The
> > Design and Evolution of C++" (1985). He explains the reasons in detail
> > starting page 153 to page 156.
> >
> > However, I agree with you that including this would be very nice.
>
> Stroustrup's arguments essentially boil down to:
>
> 1. An argument must have the same name in a function declaration as in
> the function definition.  (Some organizations recommend a style with
> "long, informative" names in headers and "short, convenient" names in the
> definitions, so this is a problem for them.)

I wonder if this is a problem. The declaration and the definition could
have
different names I think. For example:

void f(int me, double you);
void f(int a, double b) { /* ... */ }

// Forget the syntax problems, ok? :)
f(me = 34, you = 1.0)   becomes f(34, 1.0)
and f(you = 3.14, me = 0) becomes f(0, 3.14)

I don't see a problem with this.

I do see a problem with the following though:

void f(int me, int you);  // Decl 1
void f(int you, int me);  // Decl 2
void f(int a, int b) { /* ... */ }

I don't know if you're allowed to have different names in different
declarations (if you don't there's no problem?) but if you do
then f(me = something, you = something) becomes ambigous.

> 2. Once a keyword (named) argument is used, the name of that argument
> cannot be changed in the function definition without breaking code.

You explained why this is a moot argument and I agree with you, although
I consider this to be a problem with the editor (it doesn't change all
references to that name as well! (including documentation) :-).
How many "smart" editors exists "out there"?

[snip]

> Client code that uses keyword arguments actually breaks less often when
> header files are changed than code without them.  For one thing, they
> allow the argument order in function definitions to be changed; client
> code that uses keyword arguments does not have to be rewritten (it still
> has to be recompiled, but that's reasonable).  And that's one of the key
> points in favor of keyword arguments.

> Another point is that named arguments provide extra documentation, to
> both the function definition and to its invocations.  Surely this is a
> good thing, especially for functions with many (>3) arguments.

You are very right, even though I was thinking about how much more
usefulness
would come out of default parameters.

Regards,
Per Erik Stendahl
Swedish Institute of Computer Science
---
[ 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                             ]

In <3469DFF3.DC97F246@informatik.tu-chemnitz.de>,
Tobias Neubert <Tobias.Neubert@Informatik.TU-Chemnitz.DE> wrote:
> Per Erik Stendahl wrote:
> > Sometimes I really miss "named parameters" (I am not
> > sure of the correct name for this feature).
>
> Roland Hartinger has already mentioned this in the past. The correct
> name is 'Keyword arguments'.  His proposal was close to technical
> perfect. But "the extensions group reached a consensus that the
> proposal was close to redundant, would cause compatiblity problems with
> existing C++ code, and would encourage programming styles that ought
> not to be encouraged." as you can read in Bjarne Stroustrups book "The
> Design and Evolution of C++" (1985). He explains the reasons in detail
> starting page 153 to page 156.
>
> However, I agree with you that including this would be very nice.

Stroustrup's arguments essentially boil down to:

1. An argument must have the same name in a function declaration as in
the function definition.  (Some organizations recommend a style with
"long, informative" names in headers and "short, convenient" names in the
definitions, so this is a problem for them.)

2. Once a keyword (named) argument is used, the name of that argument
cannot be changed in the function definition without breaking code.

These appear reasonable at first glance.  However, on reflection, I have the
following responses:

(1) is usually not a problem if you adopt the "same name" strategy.
On the other hand, it's simple enough to allow different names in the
definition and the declaration, like C++ does today, by requiring that
the _order_ of the arguments to be the same.  This expressly disallows
a function definition from specifying a different argument (type) order
than the declaration of the function, which is probably a good idea
anyway and which is how C++ works today.  (The opposite case is arguably
convenient, but dangerous - a change to a function declaration ought to
require a change to the function definition, and the two ought to agree
in argument types and ordering.)

(2) sounds reasonable until you realize that there are already names
that can't be changed in the header files without affecting client code.
Names such as function names, class names, typedef names, names of
constants, etc.  So why not add function argument names to this list?

Client code that uses keyword arguments actually breaks less often when
header files are changed than code without them.  For one thing, they
allow the argument order in function definitions to be changed; client
code that uses keyword arguments does not have to be rewritten (it still
has to be recompiled, but that's reasonable).  And that's one of the key
points in favor of keyword arguments.

Another point is that named arguments provide extra documentation, to
both the function definition and to its invocations.  Surely this is a
good thing, especially for functions with many (>3) arguments.

Of course, adding keyword function arguments would require a sufficiently
novel syntax so that old code doesn't break.  (I haven't seen Roland
Hartinger's proposal, so I don't know what kind of compatibility problems
his syntax has.)  Maybe we could use something like the proposed syntax
for named initializers in C9X:

    void func(int size, int count);

    func([size] = 3072, [count] = 17);
    func([count] = 17, [size] = 3072);    // Identical semantics

-- david.tribble@noSPAM.central.beasys.com --
---
[ 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                             ]

In discussing this, don't forget that C++ has a "one definition" rule but
not a "one declaration" rule.

I would be very interested if someone could come up with a proposal that
would not break the following (currently perfectly legal) code:

#include <iostream>
void g() {
     void f(int burt, int bart, int bob)
     f(3, 4, 5);
}
void h() {
     void f(int bart, int burt, int bill)
     f(4, 6, 7);
}
void f(int fred, int joe, int harry) {
     cout << "total = " << (fred+joe+harry) << "\n";
}


Mark
mark.rodgers@xtra.co.nz
---
[ 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                             ]