[std-proposals] Named parameters

[z***@gmail.com]

Hello C++-ers,



I’d like to propose named parameter functionality for C++.



I see that there have been previous attempts to add named parameter functionality to C++ but led to syntactic ambiguities.



However, I think/hope I’ve come up with something that might work, namely PARAMETER LABELS:



int max(left: int, right: int); // declaration

int max(left: int left, right: int right); // OK

int max(p1: int, p2: int); // ERROR -labels must match

int max(int p1, p2: int p2); // ERROR -missing left label



int max(left: int l, right: int r) {

return l > r? l: r;

}



int foo(int p1, intp2) {


 max(left: p1, right: p2); // OK


 max(right: p1, left: p2); // OK


 max(p1, right: p2); // ERROR -missing label


 max(p1, p2); // ERROR -no labels

}



I couldn’t find anything like this on the internets.



Another question to consider is whether we should allow right-most labels to be missing:



int min(args: int arg1, int arg2, int arg3);




min(args: 1, 2, 3); // OK


min(1, args: 2, 3); // ERROR – non-labeled arguments must not preced labeled ones



In other words, a label may be omitted for those parameters for which a default value may also be specified. I’m not sure about the soundness of this, but thought I’d put it out there.



--Zem

[m***@gmail.com]

https://groups.google.com/a/isocpp.org/d/msg/std-proposals/wz0a7NrwnGQ/iBpN8pYMFQAJ

Post by z***@gmail.com
Hello C++-ers,
I’d like to propose named parameter functionality for C++.
I see that there have been previous attempts to add named parameter
functionality to C++ but led to syntactic ambiguities.
However, I think/hope I’ve come up with something that might work, namely
int max(left: int, right: int); // declaration
int max(left: int left, right: int right); // OK
int max(p1: int, p2: int); // ERROR -labels must match
int max(int p1, p2: int p2); // ERROR -missing left label
int max(left: int l, right: int r) {
return l > r? l: r;
}
int foo(int p1, intp2) {

 max(left: p1, right: p2); // OK

 max(right: p1, left: p2); // OK

 max(p1, right: p2); // ERROR -missing label

 max(p1, p2); // ERROR -no labels
}
I couldn’t find anything like this on the internets.
int min(args: int arg1, int arg2, int arg3);

min(args: 1, 2, 3); // OK

min(1, args: 2, 3); // ERROR – non-labeled arguments must not preced
labeled ones
In other words, a label may be omitted for those parameters for which a
default value may also be specified. I’m not sure about the soundness of
this, but thought I’d put it out there.
--Zem

[z***@gmail.com]

Ok, something along those lines. Is this being formally investigated?



From: ***@gmail.com <***@gmail.com>
Sent: Monday, October 29, 2018 11:14 AM
To: ISO C++ Standard - Future Proposals <std-***@isocpp.org>
Cc: ***@gmail.com
Subject: Re: [std-proposals] Named parameters



https://groups.google.com/a/isocpp.org/d/msg/std-proposals/wz0a7NrwnGQ/iBpN8pYMFQAJ





On Monday, October 29, 2018 at 7:50:26 PM UTC+2, ***@gmail.com <mailto:***@gmail.com> wrote:

Hello C++-ers,



I’d like to propose named parameter functionality for C++.



I see that there have been previous attempts to add named parameter functionality to C++ but led to syntactic ambiguities.



However, I think/hope I’ve come up with something that might work, namely PARAMETER LABELS:



int max(left: int, right: int); // declaration

int max(left: int left, right: int right); // OK

int max(p1: int, p2: int); // ERROR -labels must match

int max(int p1, p2: int p2); // ERROR -missing left label



int max(left: int l, right: int r) {

return l > r? l: r;

}



int foo(int p1, intp2) {


 max(left: p1, right: p2); // OK


 max(right: p1, left: p2); // OK


 max(p1, right: p2); // ERROR -missing label


 max(p1, p2); // ERROR -no labels

}



I couldn’t find anything like this on the internets.



Another question to consider is whether we should allow right-most labels to be missing:



int min(args: int arg1, int arg2, int arg3);




min(args: 1, 2, 3); // OK


min(1, args: 2, 3); // ERROR – non-labeled arguments must not preced labeled ones



In other words, a label may be omitted for those parameters for which a default value may also be specified. I’m not sure about the soundness of this, but thought I’d put it out there.



--Zem

[Barry Revzin]

Post by z***@gmail.com
Hello C++-ers,
I’d like to propose named parameter functionality for C++.
I see that there have been previous attempts to add named parameter
functionality to C++ but led to syntactic ambiguities.
However, I think/hope I’ve come up with something that might work, namely
int max(left: int, right: int); // declaration
int max(left: int left, right: int right); // OK
int max(p1: int, p2: int); // ERROR -labels must match
int max(int p1, p2: int p2); // ERROR -missing left label
int max(left: int l, right: int r) {
return l > r? l: r;
}
int foo(int p1, intp2) {

 max(left: p1, right: p2); // OK

 max(right: p1, left: p2); // OK

 max(p1, right: p2); // ERROR -missing label

 max(p1, p2); // ERROR -no labels
}
I couldn’t find anything like this on the internets.
int min(args: int arg1, int arg2, int arg3);

min(args: 1, 2, 3); // OK

min(1, args: 2, 3); // ERROR – non-labeled arguments must not preced
labeled ones
In other words, a label may be omitted for those parameters for which a
default value may also be specified. I’m not sure about the soundness of
this, but thought I’d put it out there.
--Zem

See: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0671r2.html

[Henry Miller]

There have been many, all died because of opposition to the idea. You
have a syntax, but you need to convince people that there isn't a
better way.
Strong types are generally preferred. Why not

max(left_t left, right_t right)

This does everything you wanted, plus as a user I can use my own names.
void fub() {
left_t foo(99);
right_t bar(getFuzzSize);
max(bar, foo) ;
}

The above passes code review, the variable names are meaningful in
context. Convert to named papamarers and it compiles. However as written
it won't compile because there is a real error.
For any proposal to be accepted you need to convince a lot of people
that the above objection is balanced by the greater good. Once you have
that we can bikeshed on syntax, there are many ideas.
--
Henry Miller

Post by z***@gmail.com
Hello C++-ers,
I’d like to propose named parameter functionality for C++.
I see that there have been previous attempts to add named parameter
functionality to C++ but led to syntactic ambiguities.>
However, I think/hope I’ve come up with something that might work,
namely PARAMETER LABELS:>
int max(left: int, right: int); // declaration
int max(left: int left, right: int right); // OK
int max(p1: int, p2: int); // ERROR -labels must match> int max(int p1, p2: int p2); // ERROR -missing left label>
int max(left: int l, right: int r) {
return l > r? l: r;
}
int foo(int p1, intp2) {

 max(left: p1, right: p2); // OK

 max(right: p1, left: p2); // OK

 max(p1, right: p2); // ERROR -missing label

 max(p1, p2); // ERROR -no labels
}
I couldn’t find anything like this on the internets.
Another question to consider is whether we should allow right-most
labels to be missing:>
int min(args: int arg1, int arg2, int arg3);

min(args: 1, 2, 3); // OK

min(1, args: 2, 3); // ERROR – non-labeled arguments must not
preced labeled ones>
In other words, a label may be omitted for those parameters for which
a default value may also be specified. I’m not sure about the
soundness of this, but thought I’d put it out there.>
--Zem
--
You received this message because you are subscribed to the Google
Groups "ISO C++ Standard - Future Proposals" group.> To unsubscribe from this group and stop receiving emails from it,
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/00c801d46faf%24dc525450%2494f6fcf0%24%40gmail.com[1].

Links:

1. https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/00c801d46faf%24dc525450%2494f6fcf0%24%40gmail.com?utm_medium=email&utm_source=footer

[Hyman Rosen]

There have been many, all died because of opposition to the idea. You have
a syntax, but you need to convince people that there isn't a better way.
Strong types are generally preferred.

Please don't passive voice into implying that everyone agrees with this.
I very much disagree. I want named parameters in the style of Ada.

Why not
max(left_t left, right_t right)

This does everything you wanted, plus as a user I can use my own names.
void fub() {
left_t foo(99);
right_t bar(getFuzzSize);
max(bar, foo) ;
}
The above passes code review, the variable names are meaningful in
context. Convert to named papamarers and it compiles. However as written it
won't compile because there is a real error.

I don't even understand this, much less want it. One of the purposes of
named parameters
is to make argument associations visible at the call site. This doesn't do
that at all.

[Henry Miller]

The idea is controversial. Many people want names parameters for various
reasons. Many others oppose them for various reasons.

On Mon, Oct 29, 2018 at 3:02 PM Henry Miller

Post by Henry Miller
There have been many, all died because of opposition to the idea. You
have a syntax, but you need to convince people that there isn't a
better way.>> Strong types are generally preferred.

Please don't passive voice into implying that everyone agrees
with this.> I very much disagree. I want named parameters in the style of Ada.

Post by Henry Miller
Why not
max(left_t left, right_t right)
This does everything you wanted, plus as a user I can use my
own names.>>
void fub() {
left_t foo(99);
right_t bar(getFuzzSize);
max(bar, foo) ;
}
The above passes code review, the variable names are meaningful in
context. Convert to named papamarers and it compiles. However as
written it won't compile because there is a real error.>

I don't even understand this, much less want it. One of the purposes
of named parameters> is to make argument associations visible at the call site. This
doesn't do that at all.
--
You received this message because you are subscribed to the Google
Groups "ISO C++ Standard - Future Proposals" group.> To unsubscribe from this group and stop receiving emails from it,
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZrptw44O%2Brzt8GePh36Fih8xr-0eqctJ-rvYOJrJHB4g%40mail.gmail.com[1].

Links:

1. https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZrptw44O%2Brzt8GePh36Fih8xr-0eqctJ-rvYOJrJHB4g%40mail.gmail.com?utm_medium=email&utm_source=footer

[Izzy Coding]

I would love to see named parameters at some point.
My point of view is from a library writing one where, with named parameters, I could reduce my line count by almost half.
This is where I provide a major “working” function and then several wrapper methods that allow for the different flavours of calling.
From a build perspective the wrapping methods are likely inclined, but if my observation is correct (which it is probably not; could be missing a build flag or something), there is still lots of linking to be done at compile time.

If however, I could define (my opinion would be using an attribute for the parameters as this is really only a compiler hook rather than a language feature) a method like so:

`public: int MyFunc(int one, int two = 0, [Named] int three = 0, [Named]...);`

Notice though that it would only be allowed on optional parameters and, like optional parameters, it must be defined for all subsequent parameters. Otherwise the program should be ill-formed.

This would allow me to have a clean codebase without all the wrappers (after all if my method decides to support another type then another zillion wrappers are required).
Also when using my library (assuming it’s not statically linked), users only have 1 method to link against for each “unit-of-work” provided by my library.

Of course, I am not one with the standard so there are probably lots of things I am missing to make my life easier.

[David Brown]

Post by Henry Miller
There have been many, all died because of opposition to the idea. You
have a syntax, but you need to convince people that there isn't a better
way.
Strong types are generally preferred.

No, they are not generally preferred. At the moment, they are all we've
got.

Strong types certainly have their uses, and their advantages over other
solutions. They also have their disadvantages.

A great many people want a simple, clean and optional method of naming
parameters. It could be nothing more than a compile-time check, but it
needs a convenient syntax. More advanced requirements - re-ordering
parameters, forcing the use of names, etc., gets more controversial.

Parameter naming is not an alternative to strong types, nor are strong
types an alternative to parameter naming - they are complements.

Post by Henry Miller
Why not
max(left_t left, right_t right)
This does everything you wanted, plus as a user I can use my own names.

It most certainly does not do what /I/ want.

Post by Henry Miller
void fub() {
left_t foo(99);
right_t bar(getFuzzSize);
max(bar, foo) ;
}

This separates the declarations from the call site, spoiling the point
completely. Better would be:

max(right_t(getFussSize), left_t(99));

(Giving the same compile-time error.)

But let us be more realistic. Suppose "max" is in the namespace
"stuff". Types "left_t" and "right_t" are specific to the function
"max" here, and should be in a nested namespace "max_params" so that
they are independent from "left_t" and "right_t" for other functions.
That gives us:

stuff::max(
stuff::max_params::right_t(getFussSize),
stuff::max_params::left_t(99)
);

Compare that to a named parameter solution of :

stuff::max(right: getFussSize, left: 99);

There is simply no contest.

If there is to be a sane use of strong types as a way of implementing
named parameters, we need two things.

First, we need a "function parameter scope" for lookups, so that within
function parameters the identifier lookup starts with a scope for
function. This should also include scopes related to the parameters (if
a function takes an enum parameter, you should be able to use enum
constants of that type directly without giving the scope details).

This gets us to a call:

stuff::max(right_t(getFussSize), left_t(99));

Secondly, we need syntactic sugar so that when declaring stuff::max, we
don't need to define the parameter types and scopes manually.


mvh.,

David

Post by Henry Miller
The above passes code review, the variable names are meaningful in
context. Convert to named papamarers and it compiles. However as written
it won't compile because there is a real error.
For any proposal to be accepted you need to convince a lot of people
that the above objection is balanced by the greater good. Once you have
that we can bikeshed on syntax, there are many ideas.
--
Henry Miller

Post by z***@gmail.com
Hello C++-ers,
I’d like to propose named parameter functionality for C++.
I see that there have been previous attempts to add named parameter
functionality to C++ but led to syntactic ambiguities.
However, I think/hope I’ve come up with something that might work,
int max(left: int, right: int); // declaration
int max(left: int left, right: int right); // OK
int max(p1: int, p2: int); // ERROR -labels must match
int max(int p1, p2: int p2); // ERROR -missing left label
int max(left: int l, right: int r) {
return l > r? l: r;
}
int foo(int p1, intp2) {
… max(left: p1, right: p2); // OK
… max(right: p1, left: p2); // OK
… max(p1, right: p2); // ERROR -missing label
… max(p1, p2); // ERROR -no labels
}
I couldn’t find anything like this on the internets.
int min(args: int arg1, int arg2, int arg3);
…min(args: 1, 2, 3); // OK
…min(1, args: 2, 3); // ERROR – non-labeled arguments must not
preced labeled ones
In other words, a label may be omitted for those parameters for which
a default value may also be specified. I’m not sure about the
soundness of this, but thought I’d put it out there.
--Zem

[Hyman Rosen]

Post by David Brown
A great many people want a simple, clean and optional method of naming
parameters. It could be nothing more than a compile-time check, but it
needs a convenient syntax. More advanced requirements - re-ordering
parameters, forcing the use of names, etc., gets more controversial.

Ada-style named parameters have call expressions contain 0 or more
positional
arguments followed by 0 or more named argument associations. The named
arguments are used in overload matching, and they are reordered as needed.
(Ada overloads by return type, so that also affects overload resolution in
concert
with the other factors.)
/* 1 */ void f(int a = 0, int b = 0);
/* 2 */ void f(int c = 0);
f(1, 2); // calls #1
f(a => 1); // calls #1 f(1, 0)
f(b => 2); // calls #1 f(0, 2)
f(c => 3); // calls #2
f(4); // ambiguous

C++ has unnamed parameters and allows multiple declarations of the same
function
using different parameter names, so Ada style doesn't carry over exactly.
A reasonable
and simple-to-specify rule is that a parameter name may be used in a named
association
if the name is used for only one parameter in all declarations of the same
function.

There don't need to be any additional requirements for parameters to have
default values.
void aim(double radius, double inclination, double azimuth);
aim(azimuth => 30_deg, inclination => 70_deg, radius => 5_mi);

This style of named parameters does not need any ABI changes. It operates
strictly
within the compiler. C++ currently leaves order of evaluation of function
arguments
unspecified, so reordering based on named association does not introduce
any new
opportunities for ambiguity.

I believe that there should be no syntax to opt in or opt out of named
argument
association (short of not naming parameters).

[Henry Miller]

Post by David Brown

Post by Henry Miller
There have been many, all died because of opposition to the idea. You
have a syntax, but you need to convince people that there isn't a better
way.
Strong types are generally preferred.

No, they are not generally preferred. At the moment, they are all we've
got.
Strong types certainly have their uses, and their advantages over other
solutions. They also have their disadvantages.

I haven't actually surveyed the committee, but I think that my statement stands. There is a great desire that if the code compiles it is correct.

Max(left: varShouldBeRight, right: varShouldBeLeft);

This will compile, but is wrong. In a real program where the variables come from someplace and are used in multiple locations it is much more likely that either it fails to compile, or at least someone catches the error in review. Haskell has a reputation of if it compiles it is right. It would be nice to have the same reputation without the downsides of haskell (which are subjective so let's not argue about them)

Post by David Brown
A great many people want a simple, clean and optional method of naming
parameters. It could be nothing more than a compile-time check, but it
needs a convenient syntax. More advanced requirements - re-ordering
parameters, forcing the use of names, etc., gets more controversial.

Yes, but why? If you can get the same benefit from something else that might be better.

Post by David Brown
Parameter naming is not an alternative to strong types, nor are strong
types an alternative to parameter naming - they are complements.

Post by Henry Miller
Why not
max(left_t left, right_t right)
This does everything you wanted, plus as a user I can use my own names.

It most certainly does not do what /I/ want.

Post by Henry Miller
void fub() {
left_t foo(99);
right_t bar(getFuzzSize);
max(bar, foo) ;
}

This separates the declarations from the call site, spoiling the point
max(right_t(getFussSize), left_t(99));

I figured that was obvious, but it fails to show the power of types vs parameters: types follow to other contexts in a often useful way that named parameters do not.

Post by David Brown
(Giving the same compile-time error.)
But let us be more realistic. Suppose "max" is in the namespace
"stuff". Types "left_t" and "right_t" are specific to the function
"max" here, and should be in a nested namespace "max_params" so that
they are independent from "left_t" and "right_t" for other functions.
stuff::max(
stuff::max_params::right_t(getFussSize),
stuff::max_params::left_t(99)
);

Should be stuff::right_t. That max takes this isn't a factor. The very name max implies there is a min which should use the same types. Most likely stuff is a larger name space with lots of functions that take or return left_t and/or right_t. They are conceptually the same type and it would make the library hard to use if they were not the same type all the way through.

Post by David Brown
stuff::max(right: getFussSize, left: 99);
There is simply no contest.

A simple using can bring right_t into the current scope and solve that. Now we have the same thing as below.

Post by David Brown
If there is to be a sane use of strong types as a way of implementing
named parameters, we need two things.
First, we need a "function parameter scope" for lookups, so that within
function parameters the identifier lookup starts with a scope for
function. This should also include scopes related to the parameters (if
a function takes an enum parameter, you should be able to use enum
constants of that type directly without giving the scope details).
stuff::max(right_t(getFussSize), left_t(99));

A proposal to make function call parameters follow different type resolution rules from the outside scope probably is a good idea. There are some tricky areas in some of the details that need to be worked out, but it seems realistic. I'm not thinking about it, but I see the use.

Post by David Brown
Secondly, we need syntactic sugar so that when declaring stuff::max, we
don't need to define the parameter types and scopes manually.

That is the downside to strong types in current c++. They require something ugly (very subjective, some people are happy with their way of overcoming the problem some are not)

[Magnus Fromreide]

Post by Henry Miller

Post by David Brown
But let us be more realistic. Suppose "max" is in the namespace
"stuff". Types "left_t" and "right_t" are specific to the function
"max" here, and should be in a nested namespace "max_params" so that
they are independent from "left_t" and "right_t" for other functions.
stuff::max(
stuff::max_params::right_t(getFussSize),
stuff::max_params::left_t(99)
);

Should be stuff::right_t. That max takes this isn't a factor. The very name
max implies there is a min which should use the same types. Most likely stuff
is a larger name space with lots of functions that take or return left_t
and/or right_t. They are conceptually the same type and it would make the
library hard to use if they were not the same type all the way through.

Post by David Brown
stuff::max(right: getFussSize, left: 99);
There is simply no contest.

A simple using can bring right_t into the current scope and solve that. Now
we have the same thing as below.

Here you are willfully ignoring the problem - you have to assume that there is
an unrelated "results" namespace that also contain a right_t that is needed
in this scope and you can't have both stuff::right_t and results::right_t
known as right_t.

(For the record I think this is where the usefulness of this simple
example breaks down - max is most certainly a function that shouldn't
have named arguments since they all are interchangeable anyway)

Post by Henry Miller

Post by David Brown
If there is to be a sane use of strong types as a way of implementing
named parameters, we need two things.
First, we need a "function parameter scope" for lookups, so that within
function parameters the identifier lookup starts with a scope for
function. This should also include scopes related to the parameters (if
a function takes an enum parameter, you should be able to use enum
constants of that type directly without giving the scope details).
stuff::max(right_t(getFussSize), left_t(99));

A proposal to make function call parameters follow different type resolution
rules from the outside scope probably is a good idea. There are some tricky
areas in some of the details that need to be worked out, but it seems
realistic. I'm not thinking about it, but I see the use.

I agree and I see that proposal as more important than named parameters and
as independent of them.

/MF

[David Brown]

<snip>

Post by Magnus Fromreide

Post by Henry Miller

Post by David Brown
If there is to be a sane use of strong types as a way of implementing
named parameters, we need two things.
First, we need a "function parameter scope" for lookups, so that within
function parameters the identifier lookup starts with a scope for
function. This should also include scopes related to the parameters (if
a function takes an enum parameter, you should be able to use enum
constants of that type directly without giving the scope details).
stuff::max(right_t(getFussSize), left_t(99));

A proposal to make function call parameters follow different type resolution
rules from the outside scope probably is a good idea. There are some tricky
areas in some of the details that need to be worked out, but it seems
realistic. I'm not thinking about it, but I see the use.

I agree and I see that proposal as more important than named parameters and
as independent of them.

I don't know if I agree that this is more important than named
parameters, but it is certainly of independent importance and use. (And
if a simpler named parameter solution is made, then it would be entirely
independent.)

I want to be able to have something like this:

namespace picture {
enum class Colour { red, blue, green };
void setBackground(Colour c);
}

void foo(void) {
picture::setBackground(green);
}

The easier it is to use stronger types, the more they will be used, and
more bugs will be caught at compile time.

[David Brown]

Post by Henry Miller

Post by David Brown

Post by Henry Miller
There have been many, all died because of opposition to the idea.
You have a syntax, but you need to convince people that there
isn't a better way.
Strong types are generally preferred.

No, they are not generally preferred. At the moment, they are all
we've got.
Strong types certainly have their uses, and their advantages over
other solutions. They also have their disadvantages.

I haven't actually surveyed the committee, but I think that my
statement stands.

I haven't seen anything from the committee either. But even if they
have a firm opinion, there is a long way from that to claiming that one
method is "generally preferred". The fact that these threads are
brought up here again and again, and that there are multiple proposals
flying around, shows that there is a great interest in getting named
parameters in place and that strong types - or strong types alone - is
/not/ the generally preferred. We /have/ strong types today in C++ - it
is very, very far from good enough for named parameters.

Post by Henry Miller
There is a great desire that if the code compiles
it is correct.

On that, I think we all agree!

Post by Henry Miller
Max(left: varShouldBeRight, right: varShouldBeLeft);
This will compile, but is wrong.

That claim makes no sense. Since the syntax does not exist today, it is
a matter of how it is implemented. Getting the parameter order wrong
will either be a compile-time error, or will be accepted with parameter
re-ordering - the jury is still out on which is the best. Silently
compiling the incorrect code is not suggested by anyone - that is what
we have today, and what we are trying to get away from!

Given the declaration:

max(int left, int right);

and the call:

max(right: 12, left: 20);

then there are two acceptable options. One is a compile-time error.
The second is to treat the call exactly as if it had been written:

max(left: 20, right: 12);


Everything else is bike-shedding. People disagree on the syntax for the
declaration, or if the parameter information should be part of the
mangled name of the function, or if it should be possible to have
different names for the "named parameters" and the "formal parameter" in
the declaration or definition of the function. Some people want to
complicate matters with using names to overload functions, others want
to keep it simpler.


The fact is that most other good, modern programming languages have
named parameters. They can make the code clearer, and reduce errors.
It can be done in a simple, optional manner that will suffice for the
great majority of cases. And it is a frustrating thing to see people
arguing about the number of angels that can dance on the head of this
pin, instead of just making the clear and obvious solution that people
can use today.

Post by Henry Miller
In a real program where the
variables come from someplace and are used in multiple locations it
is much more likely that either it fails to compile, or at least
someone catches the error in review. Haskell has a reputation of if
it compiles it is right. It would be nice to have the same reputation
without the downsides of haskell (which are subjective so let's not
argue about them)

Ada has that reputation too - and it manages named parameters in a
simple manner without strong types.

You talk about "real programs". In "real programs", people are not
going to go out of their way to make strong types for parameters except
in a few extreme cases. When you try to make a solution that requires
extra effort on the part of programmers, people will not use it! Make
it simple, make it optional, make it work with today's code, and it will
be used.

Post by Henry Miller

Post by David Brown
A great many people want a simple, clean and optional method of
naming parameters. It could be nothing more than a compile-time
check, but it needs a convenient syntax. More advanced
requirements - re-ordering parameters, forcing the use of names,
etc., gets more controversial.

Yes, but why? If you can get the same benefit from something else that might be better.

"Better" for this means simpler to use, with clear syntax and little
extra effort.

Let those that want strong typing use that - there are cases where it is
a good idea, it works today (with lots of boilerplate and ugly code),
and no one is taking it away.

And for the majority of cases, use a simple system.

Post by Henry Miller

Post by David Brown
Parameter naming is not an alternative to strong types, nor are
strong types an alternative to parameter naming - they are
complements.

Post by Henry Miller
Why not
max(left_t left, right_t right)
This does everything you wanted, plus as a user I can use my own names.

It most certainly does not do what /I/ want.

Post by Henry Miller
void fub() { left_t foo(99); right_t bar(getFuzzSize); max(bar,
foo) ; }

This separates the declarations from the call site, spoiling the
max(right_t(getFussSize), left_t(99));

I figured that was obvious, but it fails to show the power of types
vs parameters: types follow to other contexts in a often useful way
that named parameters do not.

I don't care.

Really, I don't.

What I care about is being able to make a function call in a manner the
same as today, with the /option/ of being able to include the parameter
names in some way as self-documentation for the code and as an extra
check that I have got the order right.

Post by Henry Miller

Post by David Brown
(Giving the same compile-time error.)
But let us be more realistic. Suppose "max" is in the namespace
"stuff". Types "left_t" and "right_t" are specific to the
function "max" here, and should be in a nested namespace
"max_params" so that they are independent from "left_t" and
stuff::max( stuff::max_params::right_t(getFussSize),
stuff::max_params::left_t(99) );

Should be stuff::right_t.

No, it should not.

"max" is a silly example here, as are "right" and "left".

A better example would be:

guilib::drawbox(int x1, int y1, int x2, int y2);

Are you telling me you think "x1_t", "x2_t", "y1_t" and "y2_t" should
all be types within the "guilib" namespace? Are you telling me that
there should a type within the "guilib" namespace for each of the
parameters for each of the hundred functions in that namespace? Are you
telling me that the "x2_t" type for parameter "x2" in the "drawbox" call
should be the same as the type for parameter "x2" in the "beziercurve"
call where it means a subtly different thing? What about in the
"sheartransform" call in which "x2" is now a floating point type rather
than an integer type?

Post by Henry Miller
That max takes this isn't a factor. The
very name max implies there is a min which should use the same types.
Most likely stuff is a larger name space with lots of functions that
take or return left_t and/or right_t. They are conceptually the same
type and it would make the library hard to use if they were not the
same type all the way through.

You are talking about a different thing entirely.

You are not talking about using strong types for parameter naming - you
are talking about using strong types in programming in general.

Strong types are, of course, a good idea. (The C++ language today makes
it too difficult to make them - it takes too much manual coding. Some
standardised libraries for the purpose would be a good idea, but maybe
it should wait until metaclasses are in place.)

But strong types of the sort you are describing are /not/ an alternative
to named parameters - they are a complement.

So for the "guilib::drawbox" example, it would be better to have type
such as "guilib::pixel_coordinate_t", used for the parameters in
"drawbox". (Perhaps this should be split into horizontal and vertical
types, or combined as a point type - that's a minor detail.)

But that does not help in the slightest to get the parameter order
correct. It helps distinguish between a two-point style "drawbox" and a
point plus height/width style "drawbox". But it does not help avoid
mistakes such as "drawbox(x1, x2, y1, y2)".

To do that using strong types, you need a new strong type for each
parameter. For each parameter, in each function call. This is doable,
but would need the kind of changes I proposed in order to be manageable.

Post by Henry Miller

Post by David Brown
stuff::max(right: getFussSize, left: 99);
There is simply no contest.

A simple using can bring right_t into the current scope and solve
that. Now we have the same thing as below.

I don't want to have to add "using" clauses for every parameter of every
function call. Such extra code makes the program harder to read, which
is always a bad thing.

But I /do/ want to be able to add parameter names to every parameter of
every function call, if I feel it makes the code clearer or safer.

Post by Henry Miller

Post by David Brown
If there is to be a sane use of strong types as a way of
implementing named parameters, we need two things.
First, we need a "function parameter scope" for lookups, so that
within function parameters the identifier lookup starts with a
scope for function. This should also include scopes related to the
parameters (if a function takes an enum parameter, you should be
able to use enum constants of that type directly without giving the
scope details).
stuff::max(right_t(getFussSize), left_t(99));

A proposal to make function call parameters follow different type
resolution rules from the outside scope probably is a good idea.
There are some tricky areas in some of the details that need to be
worked out, but it seems realistic. I'm not thinking about it, but I
see the use.

I am confident that there would be tricky areas - there are /always/
tricky areas :-) But I am also confident that it could make code
simpler to write and simpler to read.

Post by Henry Miller

Post by David Brown
Secondly, we need syntactic sugar so that when declaring
stuff::max, we don't need to define the parameter types and scopes
manually.

That is the downside to strong types in current c++. They require
something ugly (very subjective, some people are happy with their way
of overcoming the problem some are not)

Yes.

As I mentioned above, I think it might be best to wait until metaclasses
are in place before "solving" this one. I suspect that metaclasses
could be used to give a much neater solution, both from the users'
viewpoint and from the implementers (it would just be a new standard
header or module, rather than changes to the core language), and it
would be a shame to standardise on one method when a better one is
around the corner.

[Henry Miller]

I think that for the most part we under each other's point of view. If you write a proposal you need to be prepared to address this one. My purpose was in part to "play Devils advocate" to make sure that you have considered the alternatives.

I'm working on collecting all of the arguments on both sides, with the idea that the committee should have a position on where we want to go.

Just some minor things to correct below.

Post by David Brown

Post by Henry Miller

Post by David Brown

Post by Henry Miller
There have been many, all died because of opposition to the idea.
You have a syntax, but you need to convince people that there
isn't a better way.
Strong types are generally preferred.

No, they are not generally preferred. At the moment, they are all
we've got.
Strong types certainly have their uses, and their advantages over
other solutions. They also have their disadvantages.

I haven't actually surveyed the committee, but I think that my
statement stands.

I haven't seen anything from the committee either. But even if they
have a firm opinion, there is a long way from that to claiming that one
method is "generally preferred". The fact that these threads are
brought up here again and again, and that there are multiple proposals
flying around, shows that there is a great interest in getting named
parameters in place and that strong types - or strong types alone - is
/not/ the generally preferred. We /have/ strong types today in C++ - it
is very, very far from good enough for named parameters.

Post by Henry Miller
There is a great desire that if the code compiles
it is correct.

On that, I think we all agree!

Post by Henry Miller
Max(left: varShouldBeRight, right: varShouldBeLeft);
This will compile, but is wrong.

That claim makes no sense. Since the syntax does not exist today, it is
a matter of how it is implemented. Getting the parameter order wrong
will either be a compile-time error, or will be accepted with parameter
re-ordering - the jury is still out on which is the best. Silently
compiling the incorrect code is not suggested by anyone - that is what
we have today, and what we are trying to get away from!

What I'm saying is that if your larger function has variables for left and right you can pass the wrong ones in with a named type.

Post by David Brown
max(int left, int right);
max(right: 12, left: 20);
then there are two acceptable options. One is a compile-time error.
max(left: 20, right: 12) ;

There is another option: the user meant

max(left: 12, right: 20);

Of course when you put a number right in the call like that you have little chance of correcting it. However if you are passing variables that are initialized elsewhere, if you have strong types the entire code flow is more likely to force the right types.

Post by David Brown
Everything else is bike-shedding. People disagree on the syntax for the
declaration, or if the parameter information should be part of the
mangled name of the function, or if it should be possible to have
different names for the "named parameters" and the "formal parameter" in
the declaration or definition of the function. Some people want to
complicate matters with using names to overload functions, others want
to keep it simpler.

True, but I belive that some of those are compelling things that cannot be done without named parameters, while named parameters alone is not compelling.

Post by David Brown
The fact is that most other good, modern programming languages have
named parameters. They can make the code clearer, and reduce errors.
It can be done in a simple, optional manner that will suffice for the
great majority of cases. And it is a frustrating thing to see people
arguing about the number of angels that can dance on the head of this
pin, instead of just making the clear and obvious solution that people
can use today.

Yes, but if there are other ways to obtain the same end and those other ways produce some other gain that is "better", we should prefer the other ways.

Post by David Brown

Post by Henry Miller
In a real program where the
variables come from someplace and are used in multiple locations it
is much more likely that either it fails to compile, or at least
someone catches the error in review. Haskell has a reputation of if
it compiles it is right. It would be nice to have the same reputation
without the downsides of haskell (which are subjective so let's not
argue about them)

Ada has that reputation too - and it manages named parameters in a
simple manner without strong types.
You talk about "real programs". In "real programs", people are not
going to go out of their way to make strong types for parameters except
in a few extreme cases. When you try to make a solution that requires
extra effort on the part of programmers, people will not use it! Make
it simple, make it optional, make it work with today's code, and it will
be used.

Post by Henry Miller

Post by David Brown
A great many people want a simple, clean and optional method of
naming parameters. It could be nothing more than a compile-time
check, but it needs a convenient syntax. More advanced
requirements - re-ordering parameters, forcing the use of names,
etc., gets more controversial.

Yes, but why? If you can get the same benefit from something else that might be better.

"Better" for this means simpler to use, with clear syntax and little
extra effort.
Let those that want strong typing use that - there are cases where it is
a good idea, it works today (with lots of boilerplate and ugly code),
and no one is taking it away.
And for the majority of cases, use a simple system.

Post by Henry Miller

Post by David Brown
Parameter naming is not an alternative to strong types, nor are
strong types an alternative to parameter naming - they are
complements.

Post by Henry Miller
Why not
max(left_t left, right_t right)
This does everything you wanted, plus as a user I can use my own names.

It most certainly does not do what /I/ want.

Post by Henry Miller
void fub() { left_t foo(99); right_t bar(getFuzzSize); max(bar,
foo) ; }

This separates the declarations from the call site, spoiling the
max(right_t(getFussSize), left_t(99));

I figured that was obvious, but it fails to show the power of types
vs parameters: types follow to other contexts in a often useful way
that named parameters do not.

I don't care.
Really, I don't.
What I care about is being able to make a function call in a manner the
same as today, with the /option/ of being able to include the parameter
names in some way as self-documentation for the code and as an extra
check that I have got the order right.

Post by Henry Miller

Post by David Brown
(Giving the same compile-time error.)
But let us be more realistic. Suppose "max" is in the namespace
"stuff". Types "left_t" and "right_t" are specific to the
function "max" here, and should be in a nested namespace
"max_params" so that they are independent from "left_t" and
stuff::max( stuff::max_params::right_t(getFussSize),
stuff::max_params::left_t(99) );

Should be stuff::right_t.

No, it should not.
"max" is a silly example here, as are "right" and "left".
guilib::drawbox(int x1, int y1, int x2, int y2);
Are you telling me you think "x1_t", "x2_t", "y1_t" and "y2_t" should
all be types within the "guilib" namespace? Are you telling me that
there should a type within the "guilib" namespace for each of the
parameters for each of the hundred functions in that namespace? Are you
telling me that the "x2_t" type for parameter "x2" in the "drawbox" call
should be the same as the type for parameter "x2" in the "beziercurve"
call where it means a subtly different thing? What about in the
"sheartransform" call in which "x2" is now a floating point type rather
than an integer type?

Post by Henry Miller
That max takes this isn't a factor. The
very name max implies there is a min which should use the same types.
Most likely stuff is a larger name space with lots of functions that
take or return left_t and/or right_t. They are conceptually the same
type and it would make the library hard to use if they were not the
same type all the way through.

You are talking about a different thing entirely.
You are not talking about using strong types for parameter naming - you
are talking about using strong types in programming in general.
Strong types are, of course, a good idea. (The C++ language today makes
it too difficult to make them - it takes too much manual coding. Some
standardised libraries for the purpose would be a good idea, but maybe
it should wait until metaclasses are in place.)
But strong types of the sort you are describing are /not/ an alternative
to named parameters - they are a complement.
So for the "guilib::drawbox" example, it would be better to have type
such as "guilib::pixel_coordinate_t", used for the parameters in
"drawbox". (Perhaps this should be split into horizontal and vertical
types, or combined as a point type - that's a minor detail.)
But that does not help in the slightest to get the parameter order
correct. It helps distinguish between a two-point style "drawbox" and a
point plus height/width style "drawbox". But it does not help avoid
mistakes such as "drawbox(x1, x2, y1, y2)".
To do that using strong types, you need a new strong type for each
parameter. For each parameter, in each function call. This is doable,
but would need the kind of changes I proposed in order to be manageable.

Post by Henry Miller

Post by David Brown
stuff::max(right: getFussSize, left: 99);
There is simply no contest.

A simple using can bring right_t into the current scope and solve
that. Now we have the same thing as below.

I don't want to have to add "using" clauses for every parameter of every
function call. Such extra code makes the program harder to read, which
is always a bad thing.
But I /do/ want to be able to add parameter names to every parameter of
every function call, if I feel it makes the code clearer or safer.

Post by Henry Miller

Post by David Brown
If there is to be a sane use of strong types as a way of
implementing named parameters, we need two things.
First, we need a "function parameter scope" for lookups, so that
within function parameters the identifier lookup starts with a
scope for function. This should also include scopes related to the
parameters (if a function takes an enum parameter, you should be
able to use enum constants of that type directly without giving the
scope details).
stuff::max(right_t(getFussSize), left_t(99));

A proposal to make function call parameters follow different type
resolution rules from the outside scope probably is a good idea.
There are some tricky areas in some of the details that need to be
worked out, but it seems realistic. I'm not thinking about it, but I
see the use.

I am confident that there would be tricky areas - there are /always/
tricky areas :-) But I am also confident that it could make code
simpler to write and simpler to read.

Post by Henry Miller

Post by David Brown
Secondly, we need syntactic sugar so that when declaring
stuff::max, we don't need to define the parameter types and scopes
manually.

That is the downside to strong types in current c++. They require
something ugly (very subjective, some people are happy with their way
of overcoming the problem some are not)

Yes.
As I mentioned above, I think it might be best to wait until metaclasses
are in place before "solving" this one. I suspect that metaclasses
could be used to give a much neater solution, both from the users'
viewpoint and from the implementers (it would just be a new standard
header or module, rather than changes to the core language), and it
would be a shame to standardise on one method when a better one is
around the corner.
--
You received this message because you are subscribed to the Google
Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/prbrqm%24p6o%241%40blaine.gmane.org.

[David Brown]

Post by Henry Miller
I think that for the most part we under each other's point of view.

Did you mean "understand" here? Yes, I think so.

Post by Henry Miller
If you write a proposal you need to be prepared to address this one.
My purpose was in part to "play Devils advocate" to make sure that
you have considered the alternatives.

Fair enough - Devil's advocates are essential.

Post by Henry Miller
I'm working on collecting all of the arguments on both sides, with
the idea that the committee should have a position on where we want
to go.
Just some minor things to correct below.

I've made a few comments to your comments, and snipped a bit for brevity.

Post by Henry Miller

Post by David Brown

Post by Henry Miller
There is a great desire that if the code compiles it is correct.

On that, I think we all agree!

(I just left that in because it is important :-) )

Post by Henry Miller

Post by David Brown

Post by Henry Miller
Max(left: varShouldBeRight, right: varShouldBeLeft);
This will compile, but is wrong.

That claim makes no sense. Since the syntax does not exist today,
it is a matter of how it is implemented. Getting the parameter
order wrong will either be a compile-time error, or will be
accepted with parameter re-ordering - the jury is still out on
which is the best. Silently compiling the incorrect code is not
suggested by anyone - that is what we have today, and what we are
trying to get away from!

What I'm saying is that if your larger function has variables for
left and right you can pass the wrong ones in with a named type.

Does this mean the same as your next example comment?

Post by Henry Miller

Post by David Brown
max(int left, int right);
max(right: 12, left: 20);
then there are two acceptable options. One is a compile-time
error. The second is to treat the call exactly as if it had been
max(left: 20, right: 12) ;

There is another option: the user meant
max(left: 12, right: 20);
Of course when you put a number right in the call like that you have
little chance of correcting it.

No language change will prevent /all/ errors. We can only aim to reduce
some of them.

Post by Henry Miller
However if you are passing variables
that are initialized elsewhere, if you have strong types the entire
code flow is more likely to force the right types.

True, but it also leads to a proliferation of types that makes things
awkward.

I have nothing against strong typing, I am looking for convenient and
simple ways to eliminate a large class of possible mistakes and improve
the self-documentation of code. To do that, the solution needs to be
simple and optional - something that can be easily used in parts of code
without affecting existing parts, and something that does not involve
significant extra effort or code lines.

Post by Henry Miller

Post by David Brown
Everything else is bike-shedding. People disagree on the syntax
for the declaration, or if the parameter information should be part
of the mangled name of the function, or if it should be possible to
have different names for the "named parameters" and the "formal
parameter" in the declaration or definition of the function. Some
people want to complicate matters with using names to overload
functions, others want to keep it simpler.

True, but I belive that some of those are compelling things that
cannot be done without named parameters, while named parameters alone
is not compelling.

Named parameters makes it easier to write correct code, and harder to
write incorrect code, with the code being clearer to read and maintain,
compatible with existing code, and with very little extra effort when
writing it. To me, that is /absolutely/ compelling.

The other possibilities, such as using parameter names to overload
functions, are very minor. Yes, it would be nice to have a "Complex"
class take two floating point numbers, and have a convenient way of
distinguishing between x/y and r/theta parameters. But such use-cases
are rare, and they can be handled in other ways - tag types, and strong
types for parameters.

Common usage must be made as simple as possible, even if that means less
common usage is harder.

Post by Henry Miller

Post by David Brown
The fact is that most other good, modern programming languages
have named parameters. They can make the code clearer, and reduce
errors. It can be done in a simple, optional manner that will
suffice for the great majority of cases. And it is a frustrating
thing to see people arguing about the number of angels that can
dance on the head of this pin, instead of just making the clear and
obvious solution that people can use today.

Yes, but if there are other ways to obtain the same end and those
other ways produce some other gain that is "better", we should prefer
the other ways.

I agree with your principle, but I think we disagree about how "better"
is defined here.

[m***@gmail.com]

c++20 already has designated initializers which can do most of what is
needed from named arguments. About the only thing you could ask for is an
option to require people to set all the arguments if you really care about
that.
The following code compiles in clang with -std=c++2a

struct FnArgs
{
bool optionA = false;
bool optionB = false;
bool optionC = false;
};
void Fn(int requiredArg, FnArgs optionalArgs){}

int main()
{
// Setting all args by position:
Fn(0, {false, true, false});

// Setting all args with names:
Fn(0, {.optionA=false, .optionB=true, .optionC=false});

// Setting one named argument:
Fn(0, {.optionB=true});

// Setting no optional args:
Fn(0, {});

return 0;
}

[Hyman Rosen]

Post by m***@gmail.com
About the only thing you could ask for

I could ask for named argument association participating in overload
resolution,
which this does not give me. I could also ask to not have to change
function
definitions and declarations to be able to use named associations.

[Jake Arkinstall]

What I like about this solution is that it makes a named-parameter API the
writer's choice, and people can easily create wrappers if they want to use
named parameters with a library that doesn't use them.

The primary reason I want to push for it to be chosen by the library
authors, rather than users, is because there are many legacy libraries with
*horrible* parameter naming conventions, and suddenly they're going to have
to change to thinking about carefully considering the names of parameters
in the same way that they would currently consider the names for methods.
It gives them time to plan their interfaces with the named parameter scheme
in mind - otherwise they would end up stuck with names they didn't really
think about, and changing them would be breaking.

Sure, it's not the biggest issue in the world, and I do have little
sympathy for people who don't write self-documenting interfaces, but I *do*
have sympathy for people who will have to use APIs with silly typos in
parameter names, and for the people who will have to keep replying to repo
issues reminding users that fixing a typo would be a breaking change.

On 31 Oct 2018 21:45, <***@gmail.com> wrote:

c++20 already has designated initializers which can do most of what is
needed from named arguments. About the only thing you could ask for is an
option to require people to set all the arguments if you really care about
that.
The following code compiles in clang with -std=c++2a

struct FnArgs
{
bool optionA = false;
bool optionB = false;
bool optionC = false;
};
void Fn(int requiredArg, FnArgs optionalArgs){}

int main()
{
// Setting all args by position:
Fn(0, {false, true, false});

// Setting all args with names:
Fn(0, {.optionA=false, .optionB=true, .optionC=false});

// Setting one named argument:
Fn(0, {.optionB=true});

// Setting no optional args:
Fn(0, {});

return 0;
}
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/caa51caf-2bf6-4720-8d4d-3dbe610eadb2%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/caa51caf-2bf6-4720-8d4d-3dbe610eadb2%40isocpp.org?utm_medium=email&utm_source=footer>
.

[m***@gmail.com]

I feel very strongly about that too.
Automatically making argument names a part of the function lookup would
mean I wouldn't be able to easily fix any typos or style issues or anything
in parameter names without potentially breaking calling code. It would mean
I couldn't delete parameter names for things no longer needed or even
rename them 'unused'.
It would make it much harder to make things clearer unless you got
everything perfect the first time.
I do not get everything perfect the first time.


On these two points by Hyman:
"I could ask for named argument association participating in overload
resolution,
which this does not give me. I could also ask to not have to change
function
definitions and declarations to be able to use named associations."

While I disagree that they would be good for the language, if you wanted
them I'd suggest asking for anonymous structs to be implicitly created for
each function, and then have the overload rules look for structs that could
be created from the initialiser list.

By that I mean having:
void Fn(int arg1, int arg2, int arg3);
void Fn(int arg4, int arg5, int arg6);

and writing
Fn({.arg2 = 4});

would cause it to call the top function as 'arg2' only exists in the top
one meaning you get overload resolution.
Writing Fn({}); would be an ambiguous call in this case.

Again, I don't think it's a good change, but if you want automatic named
arguments for overload resolution it's perhaps a relatively minimal change.

Post by Jake Arkinstall
What I like about this solution is that it makes a named-parameter API the
writer's choice, and people can easily create wrappers if they want to use
named parameters with a library that doesn't use them.
The primary reason I want to push for it to be chosen by the library
authors, rather than users, is because there are many legacy libraries with
*horrible* parameter naming conventions, and suddenly they're going to have
to change to thinking about carefully considering the names of parameters
in the same way that they would currently consider the names for methods.
It gives them time to plan their interfaces with the named parameter scheme
in mind - otherwise they would end up stuck with names they didn't really
think about, and changing them would be breaking.
Sure, it's not the biggest issue in the world, and I do have little
sympathy for people who don't write self-documenting interfaces, but I *do*
have sympathy for people who will have to use APIs with silly typos in
parameter names, and for the people who will have to keep replying to repo
issues reminding users that fixing a typo would be a breaking change.
c++20 already has designated initializers which can do most of what is
needed from named arguments. About the only thing you could ask for is an
option to require people to set all the arguments if you really care about
that.
The following code compiles in clang with -std=c++2a
struct FnArgs
{
bool optionA = false;
bool optionB = false;
bool optionC = false;
};
void Fn(int requiredArg, FnArgs optionalArgs){}
int main()
{
Fn(0, {false, true, false});
Fn(0, {.optionA=false, .optionB=true, .optionC=false});
Fn(0, {.optionB=true});
Fn(0, {});
return 0;
}
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/caa51caf-2bf6-4720-8d4d-3dbe610eadb2%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/caa51caf-2bf6-4720-8d4d-3dbe610eadb2%40isocpp.org?utm_medium=email&utm_source=footer>
.

[Hyman Rosen]

I wouldn't be able to easily fix any typos or style issues or anything in
parameter names without potentially breaking calling code.

It would mean I couldn't delete parameter names for things no longer needed

or even rename them 'unused'.
It would make it much harder to make things clearer unless you got
everything perfect the first time.

It's no different than for any other publicly visible names.
You have to get function names, type names, and enumeration literals right.
You can't change them once they're out in the wild without breaking user
code.
So parameter names get to join the club. No big deal.

I'd suggest asking for anonymous structs to be implicitly created for each

function,

and then have the overload rules look for structs that could be created

from the initialiser list.

What does this get me that plain named argument association doesn't?

[Magnus Fromreide]

Post by Hyman Rosen

I wouldn't be able to easily fix any typos or style issues or anything in
parameter names without potentially breaking calling code.

It would mean I couldn't delete parameter names for things no longer needed

or even rename them 'unused'.
It would make it much harder to make things clearer unless you got
everything perfect the first time.

It's no different than for any other publicly visible names.
You have to get function names, type names, and enumeration literals right.
You can't change them once they're out in the wild without breaking user
code.
So parameter names get to join the club. No big deal.

This is where we disagree - i think it is a big deal since it will set in
stone something that up til now was only an implementation detail with no
warning.

/MF

[David Brown]

Post by Jake Arkinstall
What I like about this solution is that it makes a named-parameter API
the writer's choice, and people can easily create wrappers if they want
to use named parameters with a library that doesn't use them.

Interesting. One of the things I don't like about this syntax is that
it makes it the API writer's choice, and people have to create wrappers
to use it with existing code.

(I also don't like the ugly separation of the parameters from rest of
the function declaration - it's a step back towards K&R C functions. I
don't like the need to define an extra name for the parameters, I don't
like the inefficiency involved in dealing with a struct instead of
individual parameters, and I don't like the extra code needed in the
function definition.)

Designated initialisers have existed in C for decades, but are rarely
used for named parameters. Why would anyone think they would be popular
as a named parameter solution in C++?

Post by Jake Arkinstall
The primary reason I want to push for it to be chosen by the library
authors, rather than users, is because there are many legacy libraries
with *horrible* parameter naming conventions, and suddenly they're going
to have to change to thinking about carefully considering the names of
parameters in the same way that they would currently consider the names
for methods. It gives them time to plan their interfaces with the named
parameter scheme in mind - otherwise they would end up stuck with names
they didn't really think about, and changing them would be breaking.

Make the parameter names part of the /declaration/, not the function
definition.

The function can be defined as :

void foo(int __a, int __b, int __c) { .... }

(This sort of thing is common in standard headers - you can't use a
parameter name like "width" in case someone has written "#define width
123" before including the header.)

If the last declaration visible at the call site is

void foo(int top, int bottom, int width);

then the named parameters used by the call would be "top", "bottom" and
"width".

Compilers could have a warning to check that the parameter names in a
definition match those in declarations - you'd use that on your own
code, but not for standard library headers.

And if you have a library with unhelpful parameter names, but you want
nicer ones, all you need is a header with new declarations - not wrappers.

[Jake Arkinstall]

Post by David Brown
Designated initialisers have existed in C for decades, but are rarely
used for named parameters. Why would anyone think they would be popular
as a named parameter solution in C++?

C function overloading isn't as trivial as C++ function overloading. They'd
have to manually create new functions with different names.

Make the parameter names part of the /declaration/, not the function

Post by David Brown
definition.

This doesnt solve anything. They can name the members in their definition
whatever they want (unless there are two overloads with the same
signature...), but it's the declaration that is exposed. Modifying the
declaration is a breaking change if parameter names matter.

[David Brown]

Post by David Brown
Designated initialisers have existed in C for decades, but are rarely
used for named parameters. Why would anyone think they would be popular
as a named parameter solution in C++?
C function overloading isn't as trivial as C++ function overloading.
They'd have to manually create new functions with different names.

True, but irrelevant. The main points of named parameters is to make it
easier to write correct code, harder to write incorrect code, and make
the code you write clearer, more "self-documenting" and safer in
maintenance. This applies whether functions are overloaded or not.

(Overloading based on parameter names is an additional feature some
people want - I am moving towards strongly disapproving of that idea, as
a serious hinder to making a clean and simple named parameter system.)

Post by David Brown
Make the parameter names part of the /declaration/, not the function
definition.
This doesnt solve anything. They can name the members in their
definition whatever they want (unless there are two overloads with the
same signature...), but it's the declaration that is exposed. Modifying
the declaration is a breaking change if parameter names matter.

Yes, that is correct. And it is a /good/ thing. When someone changes
the declaration from "foo(int x, int y)" to "foo(int y, int x)", I will
be /glad/ that my compilation breaks.

[Richard Hodges]

I am always amazed at the reaction by the c++ community when presented with
the idea of obviously useful language features.

C++ people seem to be unique amongst programmers in resisting progress for
the most pedantic of reasons.

Almost every other popular programming language has named parameters,
asynchronous primitives, featureful libraries, and so on.

All implemented without fuss, very short deprecation times, often there is
breakage between versions. This would be an anathema in the c++ world, and
yet we see no tantrums by java, swift, c#, javascript or python developers
because the implementation of a new feature has required them to refactor a
couple of functions in their code base. They just convert their code and
move on without fuss.

Why are c++ people so determined to argue the minutiae of every irrelevant
detail? Boost moves forward at a good pace, sometimes making logical
mistakes, sometimes rectifying them, while maintaining good backward
compatibility and great take-up and support by the dev community.

I have personally been adapting some code to the new features in ASIO -
it's frankly a pleasure to dump the old code and replace it with the new.
Anyone who has ever written an ASIO service or compound operation with
correct handler execution semantics will know *exactly* what I mean.

Apple's Swift is another example. It's been though, what, 3 iterations now,
with breakage each time? The developers love it (I would personally argue
that it's awful and just a bit better than objective-c, but who am I to
disagree with a global developer community?).

It absolutely stuns and dismays me that standard c++ cannot bring itself to
innovate at this pace.

As for named parameters - it's obviously useful. The compiler has full
visibility of the names (if any) in the declaration. There need be no ABI
breakage at all and no rearranging of argument evaluation order. Simply
match un-named arguments in order of appearance and then named arguments to
the names in the declaration. If there's a logical mismatch, e.g. an
argument has been passed in the un-named set and the named set, it's an
error. Not hard, requires nothing more than a tinkering in the compiler.
Zero breakage with old code. We literally get extra expressiveness for free.

If you want more compile-time checking than that, use custom types. While
we're at it, a std::tagged_value template would go a long way towards *helping
developers to write type-safe code* without ten thousand lines of
boilerplate template effort to cover all the corner cases inherent in this
kind of thing. Anyone who's ever written their own tagged_value (and let's
face it, who hasn't!) understands all too well how hard it is to cover the
bases. If it's this hard, it needs a language feature or at least the
standard library to do it for us. This is just painfully obvious.
Programming languages are there to allow us to express intent. C++ should
be there to allow us to express intent and get close to perfect assembler
as a result. Writing our own template boilerplate is about as productive as
writing assembly language. I stopped doing that commercially 25 years ago
(it would have been 30 years ago, but for reasons of cost I had to reverse
engineer and recycle legacy hardware).

The above (more or less) has worked for python for longer than many here
have been able to write code. No-one complains about it. Who cares about
the irrelevant details of exactly what the syntax should be at the call
site? As long as it's reasonably easy to read and type, people will get
used to it.

Fellow "close to the machine" enthusiasts, we have before us, just outside
our windows, two billion years of evidence which serves only to reinforce
the truth we all know - *In the face of new technology and challenges, you
will adapt, and adapt quickly, or you will die*.

C++ is no different. We all want perfect runtime machine code. Our
employers will not wait for us to argue about how we get it. They will
simply insist that we use something less argumentative, regardless of our
protestations that the indeterminate nature of garbage collection sucks, or
that we won't benefit from RAII. That means nothing in the business world.
Investors and business managers almost always want stuff they can sell -
fast (possible exceptions would be aerospace, but then again I know a guy
who used to write spaceship code in java - who knew?).

I speak as a business owner, who would much prefer to see c++ as the
primary language of our business, but who has been forced to accept that in
anything other than the most rarified industry, the current state of the
art is not cost-effective.

At the root of this is the failure of the language and its custodians to
adapt to the evolution of human understanding about software systems. I
strongly believe that the failure to adapt is directly attributable to the
fact that when young enthusiastic developers want to offer an improvement
to the language, they just bounce off the adamantine wall of intransigence
exhibited, in part, in mailing lists such as this one.

It's a terrible shame to waste all that talent and positive enthusiasm.

R

Post by Jake Arkinstall

Post by David Brown
Designated initialisers have existed in C for decades, but are rarely
used for named parameters. Why would anyone think they would be popular
as a named parameter solution in C++?

C function overloading isn't as trivial as C++ function overloading.
They'd have to manually create new functions with different names.
Make the parameter names part of the /declaration/, not the function

Post by David Brown
definition.

This doesnt solve anything. They can name the members in their definition
whatever they want (unless there are two overloads with the same
signature...), but it's the declaration that is exposed. Modifying the
declaration is a breaking change if parameter names matter.

Post by David Brown
--

You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNjzETCg6tgMeq2WG0yYUbSFFsfNLFsmo%3D3J-b0zPkaGA%40mail.gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNjzETCg6tgMeq2WG0yYUbSFFsfNLFsmo%3D3J-b0zPkaGA%40mail.gmail.com?utm_medium=email&utm_source=footer>
.

--
Richard Hodges
***@gmail.com
office: [phone]
home: [phone]
mobile: [phone] (this will be *expensive* outside Andorra!)
skype: madmongo
facebook: hodges.r

[Ville Voutilainen]

Apple's Swift is another example. It's been though, what, 3 iterations now, with breakage each time? The developers love it (I would personally argue that it's awful and just a bit better than objective-c, but who am I to disagree with a global developer community?).

There was fair amounts of complaints about those breakages among Swift
developers.

The above (more or less) has worked for python for longer than many here have been able to write code. No-one complains about it. Who cares about the irrelevant details of exactly what the syntax should be at the call site? As long as it's reasonably easy to read and type, people will get used to it.

Which part of it exactly worked for python? The python 2/3 split
caused heavy friction.

If you want named parameters,

1) make them be declared, not automatically nameable
2) don't make it part of the ABI
3) don't try to introduce overloading by parameter name

and you have a chance of getting most of what you want, for those who
indeed want it. Try to insist on something different,
and be prepared for getting what you have now, i.e. nothing. In case
you insist on something different, then your claim
that how to do it is obvious is, well, obviously false.

[Hyman Rosen]

On Thu, Nov 1, 2018 at 11:51 AM Ville Voutilainen <

Post by Ville Voutilainen
2) don't make it part of the ABI
3) don't try to introduce overloading by parameter name

Just wanted to mention that overloading by parameter name (Ada style)
does not mean that functions can have the same signature - they still have
to be unique. That is, you can do
void f(int a, int b = 0);
void f(int c);
and use parameter names to distinguish f(a => 0) from f(c => 0) but you
can't do
void f(int a);
void f(int b);
and have those be different functions. That's part of not changing the ABI.

[Richard Hodges]

Post by Richard Hodges
Apple's Swift is another example. It's been though, what, 3 iterations

now, with breakage each time? The developers love it (I would personally
argue that it's awful and just a bit better than objective-c, but who am I
to disagree with a global developer community?).
There was fair amounts of complaints about those breakages among Swift
developers.

Post by Richard Hodges
The above (more or less) has worked for python for longer than many here

have been able to write code. No-one complains about it. Who cares about
the irrelevant details of exactly what the syntax should be at the call
site? As long as it's reasonably easy to read and type, people will get
used to it.
Which part of it exactly worked for python? The python 2/3 split
caused heavy friction.
If you want named parameters,
1) make them be declared, not automatically nameable
2) don't make it part of the ABI
3) don't try to introduce overloading by parameter name
and you have a chance of getting most of what you want, for those who
indeed want it. Try to insist on something different,
and be prepared for getting what you have now, i.e. nothing. In case
you insist on something different, then your claim
that how to do it is obvious is, well, obviously false.

I think unfortunately you underscore my point - there is only negativity in
this response. The community (at least this part of it) wants progress,
rather than reasons why progress is not possible.

Not just with the triviality of named parameters. It is currently not
possible to express any more than the most basic intent in C++. C++
remains, after 30 years, basically an auto-optimising macro assembler. This
is not good enough to survive the rigours of the modern world.

Yes, we want low level control. And yes, we need to be able to express
intent more naturally.

There are different levels of importance of course. Being unable to name
parameters at the call site is an inconvenience. Being unable to express
asynchronous flow control in terms of logically linear code is a nail in
the coffin for c++ as a server language.

--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUa3OVbiZFYD4k4WHe%3D7hD0mFOKPLGMqcEVj109FQdhF4w%40mail.gmail.com
.

--
Richard Hodges
***@gmail.com
office: [phone]
home: [phone]
mobile: [phone] (this will be *expensive* outside Andorra!)
skype: madmongo
facebook: hodges.r

[Balog Pal]

2018. november 1., csÃŒtörtök 23:13:14 UTC+1 időpontban Richard Hodges a

Post by Richard Hodges

(...) If you want named parameters,
1) make them be declared, not automatically nameable
2) don't make it part of the ABI
3) don't try to introduce overloading by parameter name
and you have a chance of getting most of what you want, for those who
indeed want it. Try to insist on something different,
and be prepared for getting what you have now, i.e. nothing. In case
you insist on something different, then your claim
that how to do it is obvious is, well, obviously false.

I think unfortunately you underscore my point - there is only negativity
in this response. The community (at least this part of it) wants progress,
rather than reasons why progress is not possible.

Hmm. I'm almost hearing Ville saying hos usual "I'm just stating the FACT".

The negativity is only your observation. Try to read the text as it was
put: as helpful guiding. If your aim is rally related to the functionality
and its getting into C++, not just moaning or/or bashing the people who
contribute to the standard.

The idea was discussed in public a lot and even at the committee level
several times. In great detail too. It did not progress because the
concerns were not addressed by the proposers, and the verdict was that the
benefits fall short. It was not done out of sloth or malice, just through
simple technical evaluation.

Above, Ville summarized the road that lead to the dead end, and even
pointed to directions where it DOES have a fighting chance. If you did your
homework and read up all the history you'd probably arrived to similar
conclusions.

Post by Richard Hodges
Not just with the triviality of named parameters.

Well, just reading the last discussion N4172_Named_Function_Arguments
discussion
<http://wiki.edg.com/bin/view/Wg21urbana-champaign/FunctionFacilities#N4172_Named_Function_Arguments>
it is pretty far from trivial. Ant there is a lot more just following the
links from posts 2 and 3 of this topic and their references.

It is currently not possible to express any more than the most basic intent

Post by Richard Hodges
in C++. C++ remains, after 30 years, basically an auto-optimising macro
assembler. This is not good enough to survive the rigours of the modern
world.

Well, everyone is entitled to have their opinion, I know a plenty of folks
who see it a different way.

[Richard Hodges]

Post by Balog Pal
2018. november 1., csÃŒtörtök 23:13:14 UTC+1 időpontban Richard Hodges a

Post by Richard Hodges

(...) If you want named parameters,
1) make them be declared, not automatically nameable
2) don't make it part of the ABI
3) don't try to introduce overloading by parameter name
and you have a chance of getting most of what you want, for those who
indeed want it. Try to insist on something different,
and be prepared for getting what you have now, i.e. nothing. In case
you insist on something different, then your claim
that how to do it is obvious is, well, obviously false.

I think unfortunately you underscore my point - there is only negativity
in this response. The community (at least this part of it) wants progress,
rather than reasons why progress is not possible.

Hmm. I'm almost hearing Ville saying hos usual "I'm just stating the FACT".
The negativity is only your observation. Try to read the text as it was
put: as helpful guiding. If your aim is rally related to the functionality
and its getting into C++, not just moaning or/or bashing the people who
contribute to the standard.
The idea was discussed in public a lot and even at the committee level
several times. In great detail too. It did not progress because the
concerns were not addressed by the proposers, and the verdict was that the
benefits fall short. It was not done out of sloth or malice, just through
simple technical evaluation.
Above, Ville summarized the road that lead to the dead end, and even
pointed to directions where it DOES have a fighting chance. If you did your
homework and read up all the history you'd probably arrived to similar
conclusions.

Post by Richard Hodges
Not just with the triviality of named parameters.

Well, just reading the last discussion N4172_Named_Function_Arguments
discussion
<http://wiki.edg.com/bin/view/Wg21urbana-champaign/FunctionFacilities#N4172_Named_Function_Arguments>
it is pretty far from trivial. Ant there is a lot more just following the
links from posts 2 and 3 of this topic and their references.
It is currently not possible to express any more than the most basic

Post by Richard Hodges
intent in C++. C++ remains, after 30 years, basically an auto-optimising
macro assembler. This is not good enough to survive the rigours of the
modern world.

Well, everyone is entitled to have their opinion, I know a plenty of folks
who see it a different way.

I think something we can agree on is that other languages are surging
forward in terms of powerful functionality, while the c++ community mumbles
about ABI breakage and backward compatibility.

These are obstacles for sure, but I have always had the impression that c++
guys were the bright ones. There are answers. We are clearly at the end of
the road in terms of modern features coupled with backward compatibility
(which we don't have anyway - auto_ptr is no more!). Those answers will
involve modifying 20 year old code if we insist on compiling it with an
ultra-modern compiler. So what?

The old generation of "it can't be done, we talked about it at a committee
meeting" are doing a disservice to the new generation of bright young
things.

If you can't do it, leave it to someone else.

Post by Balog Pal
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/46a88b60-7f08-45fb-bbad-30f5be27d28f%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/46a88b60-7f08-45fb-bbad-30f5be27d28f%40isocpp.org?utm_medium=email&utm_source=footer>
.

--
Richard Hodges
***@gmail.com
office: [phone]
home: [phone]
mobile: [phone] (this will be *expensive* outside Andorra!)
skype: madmongo
facebook: hodges.r

[Francis Grizzly Smit]

have a look at julia
https://docs.julialang.org/en/v1/manual/functions/#Keyword-Arguments-1
basically they put all their keyword args after a different symbol i.e. ;

so a named arg looks like f(arg1, arg2, ... ; namedarg1=value2,
namedarg2=value2...)

so for us that would look like

type_0 f(type_1 arg1, type_2 arg2, ....., type_n argn ; type_n1
namedarg1=value1, type_n2 namedarg2=value2, .....)

or we could invent another symbol for the divider i.e. ;| say

so we could have
T0 f(T1 a, T2 b, T3 c=val3 ;|    T4 d=val4, T5 e=val5)

and then it's called like so x = f(val1, val2 ;| e=val5_dashed)

or x = f(val1, val2, val3_dashed ;| e=val5_dashed, d=val4_dashed)

so basically we just redefine argspeclist:

argspeclist ::= normalargspeclist [ nameddivider namedspeclist ]

normalargspeclist ::= /* what it always was */

nameddivider ::= ";|"

namedspeclist ::= /* empty */ | namedspeclist ',' namedspec

namedspec ::= typespec identifier '=' value

please for give my rusty grammar spec it's been a long time

Post by z***@gmail.com
Hello C++-ers,
I’d like to propose named parameter functionality for C++.
I see that there have been previous attempts to add named parameter
functionality to C++ but led to syntactic ambiguities.
However, I think/hope I’ve come up with something that might work,
int max(left: int, right: int);         // declaration
int max(left: int left, right: int right);     // OK
int max(p1: int, p2: int);               // ERROR -labels must match
int max(int p1, p2: int p2);           // ERROR -missing left label
int max(left: int l, right: int r) {
  return l > r? l: r;
}
int foo(int p1, intp2) {
   
 max(left: p1, right: p2);    // OK
   
 max(right: p1, left: p2);     // OK
   
 max(p1, right: p2);              // ERROR -missing label
   
 max(p1, p2); // ERROR -no labels
}
I couldn’t find anything like this on the internets.
int min(args: int arg1, int arg2, int arg3);
   
min(args: 1, 2, 3);  // OK
   
min(1, args: 2, 3);  // ERROR – non-labeled arguments must not
preced labeled ones
In other words, a label may be omitted for those parameters for which
a default value may also be specified.  I’m not sure about the
soundness of this, but thought I’d put it out there.
--Zem
--
You received this message because you are subscribed to the Google
Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/00c801d46faf%24dc525450%2494f6fcf0%24%40gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/00c801d46faf%24dc525450%2494f6fcf0%24%40gmail.com?utm_medium=email&utm_source=footer>.

--
.~. In my life God comes first....
/V\ but Linux is pretty high after that :-D
/( )\ Francis (Grizzly) Smit
^^-^^ http://www.smit.id.au/

[Hyman Rosen]

have a look at julia basically they put all their keyword args after a
different symbol i.e. ;
so a named arg looks like f(arg1, arg2, ... ; namedarg1=value2,
namedarg2=value2...)

Why do we need such a thing?

[Jake Arkinstall]

Post by Hyman Rosen

have a look at julia basically they put all their keyword args after a
different symbol i.e. ;
so a named arg looks like f(arg1, arg2, ... ; namedarg1=value2,
namedarg2=value2...)

Why do we need such a thing?
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZdppJ2LovqpgJKnMnKyk64WXDf7FTj_KRgavDDcqNH1g%40mail.gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZdppJ2LovqpgJKnMnKyk64WXDf7FTj_KRgavDDcqNH1g%40mail.gmail.com?utm_medium=email&utm_source=footer>
.

Ironically my facial expression somewhat resembled the suggested syntax ;|
- I have not got much hope for the squinty frog separator. Especially when
we can rather easily distinguish which are named and which are unnamed by a
parameter-by-parameter approach, e.g. Emulating the member access operator
with (.name=value, ...). With python, for example, no unnamed parameter is
allowed after a named parameter. Its probably a sensible restriction,
though whether or not that makes sense in C++ depends on which one of the
many, many potential approaches we take.

[Francis Grizzly Smit]

I just thought that if we must have named args that we should do it in
the simplest way possible all the other suggestions, looked clunky and
kludgey, basically  using a A-Bomb to kill a mosquito, I thought just
use the time honoured trick of inventing some thing that would be a
compile-time error now to introduce the new thing that way we don't have
to change the traditional part of the argument list at all

On Fri, Nov 2, 2018 at 3:29 PM Francis Grizzly Smit
have a look at julia basically they put all their keyword args
after a different symbol i.e. ;
so a named arg looks like f(arg1, arg2, ... ; namedarg1=value2,
namedarg2=value2...)
Why do we need such a thing?
--
You received this message because you are subscribed to the Google
Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZdppJ2LovqpgJKnMnKyk64WXDf7FTj_KRgavDDcqNH1g%40mail.gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZdppJ2LovqpgJKnMnKyk64WXDf7FTj_KRgavDDcqNH1g%40mail.gmail.com?utm_medium=email&utm_source=footer>.

--
.~. In my life God comes first....
/V\ but Linux is pretty high after that :-D
/( )\ Francis (Grizzly) Smit
^^-^^ http://www.smit.id.au/

[Bengt Gustafsson]

Here is a long paper I wrote on the subject, which uses a semicolon

This proposal is based on opt-in both on the declaration and the call site
sides. Both annotations consist of a semicolon in the
parameter list. On the declaration side the semicolon separates potentially
positional from name-only parameters. On the callsite
side the semicolon separates positional from named arguments.

Any signature which does not have a semicolon works as before, only
allowing positional arguments and no parameter names in the
mangled function name. For signatures with a semicolon in the declaration
all names are significant and can be named at call sites.
All names are included in the mangled name.

At the call site arguments before the semicolon are positional and
assignment operators work like today. Arguments after the
semicolon are parsed differently, with a special <name> = <expression>
production creating named arguments. As an optional feature just a
name can be allowed, to set a bool parameter to true. Another option could
be to allow arithmetic assignment operators (+= and the
like) instead of the plain = if the parameter has a default value. This can
be useful to express things like "one more than the
default" or "double the default" without having to repeat the default
expression at the call site.

Variadic templates can allow variadic unnamed and/or named parameters.
Names can be picked up in the function body using small
extensions of the already proposed reflection system.

Perfect forwarding is a tricky issue, and this proposal shows has no
_perfect_ solution unless a special core-language operator is
introduced.