[std-proposals] Function Parameter of Struct Type -> Named Parameters

[Andrew Tomazos]

It seems to me that a function that takes a struct combined with C++20
designated initializers gets us very close to named parameters:

struct FooParameters {
int bar;
float baz;
};
float foo(FooParameters params) {
return (params.bar + 3) * params.baz;
}
int main() {
foo({bar: 4, baz: 3.2});
}

If we added some syntactic sugar that...
1. Removed the need to give the parameter struct type a name
2. Introduced the parameter struct members into the function definition
scope.

...we would get pretty close:

float foo(struct { int bar; float baz }) {
return (bar + 3) * baz;
}
int main() {
foo({bar: 4, baz:3.2});
}

I'd need to take a look to see if it is ambiguous, but I think we can drop
the struct keyword from the above:

float foo({int bar; float baz}) {
return (bar + 3) * baz;
}
int main() {
foo({bar: 4, baz:3.2});
}

This would be equivalent to:

struct __A { int bar; float baz };
float foo(__A __a) {
auto&& [bar,baz] = __a;
return (bar + 3) * baz;
}
int main() {
foo({bar: 4, baz:3.2});
}

From a teachability perspective its pretty easy to explain that "a
brace-enclosed function parameter is the body of an anonymous struct, the
members of which are introduced into the function definition scope."

This also seems easy to implement.

Thoughts? Worth pursuing?

[Magnus Fromreide]

Post by Andrew Tomazos
It seems to me that a function that takes a struct combined with C++20
struct FooParameters {
int bar;
float baz;
};
float foo(FooParameters params) {
return (params.bar + 3) * params.baz;
}
int main() {
foo({bar: 4, baz: 3.2});
}
If we added some syntactic sugar that...
1. Removed the need to give the parameter struct type a name
2. Introduced the parameter struct members into the function definition
scope.

I think this misses a lot of benefits and would propose two other rules:

1. Allow anonymous structs
Similar to anonymous unions.
This is already done by VC++ and as an extension by g++ and clang++.
2. Implicitly assume that a call to a function wants to call a function named
thus and see if some overload could fit the provieded tokens, this would
allow
void fun(enum { something, other } x);
to do the right thing as well.

/MF

[Andrew Tomazos]

Post by Magnus Fromreide

Post by Andrew Tomazos
It seems to me that a function that takes a struct combined with C++20
struct FooParameters {
int bar;
float baz;
};
float foo(FooParameters params) {
return (params.bar + 3) * params.baz;
}
int main() {
foo({bar: 4, baz: 3.2});
}
If we added some syntactic sugar that...
1. Removed the need to give the parameter struct type a name
2. Introduced the parameter struct members into the function definition
scope.

I think this misses a lot of benefits

To which benefits do you refer?

Post by Magnus Fromreide
1. Allow anonymous structs
Similar to anonymous unions.
This is already done by VC++ and as an extension by g++ and clang++.

$ cat > t.cc
void f(struct {}) {}
$ g++ t.cc
error: types may not be defined in parameter types
void f(struct {}) {}

Does this work in VC++? Whats the gcc extension called?

Post by Magnus Fromreide
2. Implicitly assume that a call to a function wants to call a function named
thus

I don't quite follow sorry. My proposal doesn't make any changes to name
lookup of a function call or overload resolution, what changes to overload
resolution are you proposing?

Post by Magnus Fromreide
and see if some overload could fit the provieded tokens, this would
allow
void fun(enum { something, other } x);
to do the right thing as well.

And what is the right thing? I'm not sure I see how this is related?

[Magnus Fromreide]

Post by Andrew Tomazos

Post by Magnus Fromreide

Post by Andrew Tomazos
It seems to me that a function that takes a struct combined with C++20
struct FooParameters {
int bar;
float baz;
};
float foo(FooParameters params) {
return (params.bar + 3) * params.baz;
}
int main() {
foo({bar: 4, baz: 3.2});
}
If we added some syntactic sugar that...
1. Removed the need to give the parameter struct type a name
2. Introduced the parameter struct members into the function definition
scope.

I think this misses a lot of benefits

To which benefits do you refer?

Post by Magnus Fromreide
1. Allow anonymous structs
Similar to anonymous unions.
This is already done by VC++ and as an extension by g++ and clang++.

$ cat > t.cc
void f(struct {}) {}
$ g++ t.cc
error: types may not be defined in parameter types
void f(struct {}) {}
Does this work in VC++? Whats the gcc extension called?

The parts are independent, the first part is about allowing anonymous structs
in places where structs are allowed today.

Post by Andrew Tomazos

Post by Magnus Fromreide
2. Implicitly assume that a call to a function wants to call a function named
thus

I don't quite follow sorry. My proposal doesn't make any changes to name
lookup of a function call or overload resolution, what changes to overload
resolution are you proposing?

Consider

void f(struct { int a = 0; int b; });
void f(struct { int b; int c = 0; });

Which one should each of the following call?

f({a: 1, b: 2 }):
f({b: 1, c: 2 });
f({b: 1});

Post by Andrew Tomazos

Post by Magnus Fromreide
and see if some overload could fit the provieded tokens, this would
allow
void fun(enum { something, other } x);
to do the right thing as well.

And what is the right thing? I'm not sure I see how this is related?

Look up types in the argument lsts of the possible functions.

I will readily admit that I have failed to convey the idea here.

/MF

[Jake Arkinstall]

In the case of ambiguities, the compiler can error as it currently does
with ambiguous function overloads. But given the work that would go into
making that happen, a deeper language change without the indirection
through structs might be better.

One thing I like about the struct idea is that it gives the control over
named parameters to the API author, not to the user. Another benefit I see
is that we don't need a change to function mangling, whereas function calls
with parameters of the same types but different names would require such a
change.

So I'm (tentatively) for it. But at the same time, I know that mine isn't a
popular position.

We really need a poll to find out which named parameter features (and/or
language changes) that people want, which features they don't want, and
work from there. Otherwise what we end up with is many proposals and a
different subset of people for and against each. As an example, I will
defend the notion of authors having control over whether or not their
functions can be called with named parameters until I see evidence that a
strong majority would prefer the user to have that control - at which point
the position becomes indefensible from a standards perspective.

[Hyman Rosen]

Post by Jake Arkinstall
One thing I like about the struct idea is that it gives the control over
named parameters to the API author, not to the user.

I think that's a bad idea. The API author should be supplying good
parameter names just like they supply good function names, good class
names, good
enumeration literals, and so on. Just because it does not matter now (and
that's not really true, because functions should be documented and the
documentation should be describing the parameters, so they should already
have sensible names) is no reason to allow it to continue not to matter.

Post by Jake Arkinstall
Another benefit I see is that we don't need a change to function mangling,
whereas function calls with parameters of the same types but different
names would require such a change.

No. Named arguments (in my preferred and correct Ada style) are handled by
the compiler without any ABI or mangling changes needed. You cannot
overload based only on different parameter names. Just as now, multiple
function declarations with the same function name and parameter types will
declare the same function, even if the different declarations use different
parameter names.

Overload resolution at the call site can use named argument association to
help pick a function to call, but parameter names do not generate different
functions.

[Jake Arkinstall]

Post by Hyman Rosen

Post by Jake Arkinstall
One thing I like about the struct idea is that it gives the control over
named parameters to the API author, not to the user.

I think that's a bad idea. The API author should be supplying good
parameter names just like they supply good function names, good class
names, good
enumeration literals, and so on. Just because it does not matter now (and
that's not really true, because functions should be documented and the
documentation should be describing the parameters, so they should already
have sensible names) is no reason to allow it to continue not to matter.

Post by Jake Arkinstall
Another benefit I see is that we don't need a change to function
mangling, whereas function calls with parameters of the same types but
different names would require such a change.

No. Named arguments (in my preferred and correct Ada style) are handled
by the compiler without any ABI or mangling changes needed. You cannot
overload based only on different parameter names. Just as now, multiple
function declarations with the same function name and parameter types will
declare the same function, even if the different declarations use different
parameter names.
Overload resolution at the call site can use named argument association to
help pick a function to call, but parameter names do not generate different
functions

Both of these points are nonetheless opinions. The notion of allowing
overloads of the same types with different parameter names is very much on
the table - again, we have no poll results and no consensus, so the only
thing we ever manage to obtain on these discussions is knowledge that
everyone wants something different.

[Hyman Rosen]

Post by Jake Arkinstall
Both of these points are nonetheless opinions. The notion of allowing
overloads of the same types with different parameter names is very much on
the table - again, we have no poll results and no consensus, so the only
thing we ever manage to obtain on these discussions is knowledge that
everyone wants something different.

And as exemplified by order of evaluation, we also have a history of coming
to bad decisions, some based on specious arguments.
I'm not convinced that language design by plebiscite produces the best
result (or even a good one).

[Matthew Woehlke]

Post by Hyman Rosen
Named arguments (in my preferred and correct Ada style) are handled by
the compiler without any ABI or mangling changes needed. You cannot
overload based only on different parameter names.

Let's say you have this feature implemented in such manner. How do you
make this (not) work:

int foo(int: a, int: b);
std::invoke(foo, .a=5, .c=12); // should be an error

[Hyman Rosen]

Post by Matthew Woehlke

Post by Hyman Rosen
Named arguments (in my preferred and correct Ada style) are handled by
the compiler without any ABI or mangling changes needed. You cannot
overload based only on different parameter names.

Let's say you have this feature implemented in such manner. How do you
int foo(int: a, int: b);
std::invoke(foo, .a=5, .c=12); // should be an error

I'm not sure what you're getting at here. In my version of named argument
association,
the std::invoke function would need to have at least three parameters, two
of which are
named a and b. The std::invoke call is not a function call of foo, so the
parameter names
of foo are irrelevant.

[Matthew Woehlke]

Post by Matthew Woehlke

Post by Hyman Rosen
Named arguments (in my preferred and correct Ada style) are handled by
the compiler without any ABI or mangling changes needed. You cannot
overload based only on different parameter names.

Let's say you have this feature implemented in such manner. How do you
int foo(int: a, int: b);
std::invoke(foo, .a=5, .c=12); // should be an error

In my version of named argument association, the std::invoke function
would need to have at least three parameters, two of which are named
a and b. The std::invoke call is not a function call of foo, so the
parameter names of foo are irrelevant.

Riiiight... So, what you're saying, is forwarding named arguments
doesn't work. That's a shame. It's also a feature that some people
(myself included) want.

Forwarding named arguments Just Works when names are part of the type
(e.g. P1229).

I'm not sure what you're getting at here.

Really? std::invoke (and I mean *std::invoke*; I didn't chose that by
accident) transparently forwards its arguments to some other function,
also given in the call site. On its own, it takes whatever arguments you
give it, and just passes them along.

Therefore, it seems "obvious" that I should a) be able to pass named
arguments to std::invoke, and b) that std::invoke should call the
function passed to it using those named arguments. That is:

int foo(int: a, int: b);
std::invoke(foo, .a=5, .c=12);

...should result in a compile error, because I am trying to call `foo`
with non-matching arguments. More particularly, the above should have
the exact same effect as:

foo(.a=5, .c=12);

...which I believe pretty much all of us agree should be a compile error.

I should be able to do something similar with std::apply. More
generally, if I write something like:

auto t = std::make_tuple(12, .x=7);

...then `t` should continue to "know" that its second element isn't just
an `int`, but one with the 'name' "x".

[Hyman Rosen]

Post by Andrew Tomazos

Post by Matthew Woehlke
Riiiight... So, what you're saying, is forwarding named arguments
doesn't work. That's a shame. It's also a feature that some people
(myself included) want.

I don't think that's a good thing to want, but I guess that's just me.
I also don't want "pointer to function returning int with double

parameter

named 'a' and string parameter named 's'" as part of the type system.

template <typename Func>
void foo(Func f)
{
f(.a=5);
}
void bar(int: q);
foo(&bar);
OTOH, pointers to functions with named arguments should probably
implicitly convert to pointers to functions with the same signature sans
name.

How is your std::invoke call supposed to work, anyway? Even if argument
names were part of the function type (which they should not be), how is a
named argument association supposed to pass through the std::invoke call?

...because a named argument has a different type than an unnamed
argument. See P1229. IOW, the argument type to invoke isn't `int`, it's
something like `std::arg<"x", int>`.

Are you suggesting that a named argument association is a special object
that carries the name with it, and can be passed to a function that

doesn't

have such a named parameter but can be passed along to something else

that

does?

Yes, exactly.

I think we're once again in the land of "hey, this should do that!" and I
think that's a bad way to design language features.

I don't think I can agree. If I expect a feature to work in a certain
way, and a proposed design doesn't give me that, doesn't that indicate
that maybe the design has a problem?
In my mind, it would be surprising if invoke/apply either didn't accept
named arguments at all, or effectively circumvented the protection (and
maybe other features?) that named arguments are supposed to provide.
I'd like to propose the opposite question... besides the above comment
about pointer types, and if this was implemented in a way that made it
*possible* to have named arguments in functions whose ABI does not
include the name, what objections do you have to argument names being
visible at the type system level?
--
Matthew

I think that having named argument association objects be things that
aren't just
the same as the arguments themselves, and allowing named arguments to flow
through function calls into other function calls is just a recipe for
disaster. It strikes
me as causing similar issues to operator dot, namely, when does a name
apply to
the thing itself and when does it apply to something else instead?
Furthermore,
initializer lists were implemented in the way you suggest, with strange
interpolated
class objects, and that has not led to great satisfaction.

The beautiful thing about doing named argument association the Ada way is
that
it's kept *out* of the type system. It lets you reorder arguments on
invocation, lets
you specify only those defaulted parameters that you want, and lets you
document
your function calls at the call site. You get overload resolution just to
the extent
needed by the rest of these features. And you don't have to change any ABIs.

I promise you that making it part of the type system will end in tears,
just like so
many other features of C++.

[Matthew Woehlke]

Post by Hyman Rosen
The beautiful thing about doing named argument association the Ada
way is that it's kept *out* of the type system. It lets you reorder
arguments on invocation, lets you specify only those defaulted
parameters that you want, and lets you document your function calls
at the call site.

Having names be part of the type does not preclude any of this.

I'm on the fence about reordering, though...

One of my "eventual" objectives for named arguments is to replace
designated initializers with an "as if it existed" ctor rule. I believe
this can be done with no noticeable change in existing code. However, if
we do that, and then add reordering, we are reopening a can of worms as
far as designated initializers.

My preference is to get in a feature *without* reordering, first, and
then people that want reordering can try to add it later.

Post by Hyman Rosen
And you don't have to change any ABIs.

I have a solution to that, that also allows you to add named arguments
to functions that don't already have them. You might not be able to
overload on name, though (I haven't fully thought it through, but I
think if you try to add an overload that would require named
overloading, you'll necessarily wind up with an ambiguous overload).

Post by Hyman Rosen
I promise you that making it part of the type system will end in tears,
just like so many other features of C++.

You keep saying that, but I haven't seen any *concrete* reason. Just a
lot of unspecific muttering.

[Hyman Rosen]

You keep saying that, but I haven't seen any *concrete* reason. Just a lot
of unspecific muttering.

Here are some specific mutters:

int &a();
int &b();
a() <<= b();
a() << b();
a() < b();

std::vector<int> vi{3};
std::vector<std::string> vs{3};

std::vector<int> zi{0};
std::vector<std::string> zs{0};

unsigned short u1 = 60001u;
unsigned short u2 = 59999u;
unsigned long u = u1 * u2;


For the sake of exposition, the library clauses sometimes annotate
constructors with EXPLICIT. Such a
constructor is conditionally declared as either explicit or non-explicit
(15.3.1). [ Note: This is typically
implemented by declaring two such constructors, of which at most one
participates in overload resolution.
—end note ]

[ptr.launder]

I could come up with more. It's a history of bad decisions, bad designs,
and bad object models.
Part of it is excessive cleverness and part of it is inchoate "make this
mean that" design, both of
which I find in your preferred version of named argument association.

[Matthew Woehlke]

Post by Jake Arkinstall
In the case of ambiguities, the compiler can error as it currently does
with ambiguous function overloads. But given the work that would go into
making that happen, a deeper language change without the indirection
through structs might be better.
One thing I like about the struct idea is that it gives the control over
named parameters to the API author, not to the user.

P1229 provides that.

Post by Jake Arkinstall
Another benefit I see is that we don't need a change to function
mangling, whereas function calls with parameters of the same types
but different names would require such a change.

I have an idea for 'function aliases' that would allow creating a
not-quite-overload¹ taking P1229 "strongly" named arguments that really
calls something else. (Usually, the "something else" would be the
ABI-existing version of the function that does not take "strongly" named
arguments.) The down side, however, is users can add such aliases, which
defeats your previous point. (OTOH, users can overload non-member
functions today, so you've already lost that battle. Possibly we could
limit method aliases to appearing in the class definition, which would
mitigate this to at least no worse than it is already.)

Basically, this gives you most of what everyone wants: opt-in, and the
ability to choose between name-based overloading and no ABI change.

(¹ The not-quite-overload mostly acts like an overload, except it is not
ambiguous with the signature it aliases.)

Post by Jake Arkinstall
We really need a poll to find out which named parameter features (and/or
language changes) that people want, which features they don't want, and
work from there. Otherwise what we end up with is many proposals and a
different subset of people for and against each.

I actually started writing a paper to this effect, although it remains
to be seen if I actually finish it :-). (Basically, rather than being a
full proposal, the idea is to explain various folks' positions and
suggest how we can compromise... although the latter does end up being a
semi-proposal.)

Post by Jake Arkinstall
As an example, I will defend the notion of authors having control
over whether or not their functions can be called with named
parameters until I see evidence that a strong majority would prefer
the user to have that control - at which point
the position becomes indefensible from a standards perspective.

I'm on the fence here. In an ideal world, I agree, but I worry about
users wanting to use this feature with libraries that are unmaintained
or otherwise hard to change. That said, I don't think we can stop users
from adding overloads of free functions anyway...

[Matthew Woehlke]

Post by Magnus Fromreide
Consider
void f(struct { int a = 0; int b; });
void f(struct { int b; int c = 0; });
Which one should each of the following call?
f({b: 1, c: 2 });
f({b: 1});

Somewhat OT, but... all of those will fail to compile because they are
not valid syntax.

Why aren't we using correct syntax in this discussion?

f({.a=1, .b=2}):
f({.b=1, .c=2});
f({.b=1});

[Hyman Rosen]

Post by Andrew Tomazos
It seems to me that a function that takes a struct combined with C++20

designated initializers gets us very close to named parameters

Post by Andrew Tomazos
This also seems easy to implement.
Thoughts? Worth pursuing?

I think named argument association should be sui generis, not implemented
by weird class equivalents. Doing the latter hearkens back to the days of
OO,
where everything was defined in terms of virtual functions. We should
define
the behavior we want, not try for an equivalence that may or may not have
dark
corners that don't quite match.

[Ville Voutilainen]

Post by Hyman Rosen

Post by Andrew Tomazos
It seems to me that a function that takes a struct combined with C++20
designated initializers gets us very close to named parameters
This also seems easy to implement.
Thoughts? Worth pursuing?

I think named argument association should be sui generis, not implemented
by weird class equivalents. Doing the latter hearkens back to the days of OO,
where everything was defined in terms of virtual functions. We should define
the behavior we want, not try for an equivalence that may or may not have dark
corners that don't quite match.

I don't see how an automatic struct wrapper is necessarily a good
solution to the problem, since it changes the arity
of the function. This has practical consequences; the function is no
longer callable with separate unnamed
arguments, which is a horrible loss of functionality.

[Bengt Gustafsson]

And it also misses the possibility to call different function overloads
depending on the names provided at the call site.

Post by Hyman Rosen

Post by Hyman Rosen

Post by Andrew Tomazos
It seems to me that a function that takes a struct combined with C++20
designated initializers gets us very close to named parameters
This also seems easy to implement.
Thoughts? Worth pursuing?

I think named argument association should be sui generis, not

implemented

Post by Hyman Rosen
by weird class equivalents. Doing the latter hearkens back to the days

of OO,

Post by Hyman Rosen
where everything was defined in terms of virtual functions. We should

define

Post by Hyman Rosen
the behavior we want, not try for an equivalence that may or may not

have dark

Post by Hyman Rosen
corners that don't quite match.

I don't see how an automatic struct wrapper is necessarily a good
solution to the problem, since it changes the arity
of the function. This has practical consequences; the function is no
longer callable with separate unnamed
arguments, which is a horrible loss of functionality.