Re: Named parameters

[Marc Glisse <marc dot glisse at inria dot fr>]

On Mon, 16 Mar 2015, David Brown wrote:

> In a discussion on comp.lang.c, the subject of "named parameters" (or
> "designated parameters") has come up again.  This is a feature that some
> of us feel would be very useful in C (and in C++).  I think it would be
> possible to include it in the language without leading to any conflicts
> with existing code - it is therefore something that could be made as a
> gcc extension, with a hope of adding it to the standards for a later C
> standards revision.
>
> I wanted to ask opinions on the mailing list as to the feasibility of
> the idea - there is little point in my cluttering up bugzilla with an
> enhancement request if the gcc developers can spot obvious flaws in the
> idea.

Filing a report in bugzilla would be quite useless: language extensions 
are now almost automatically rejected unless they come with a proposal 
that has already been favorably seen by the standardization committee.

On the other hand, implementing the feature (in your own fork) is almost a 
requirement if you intend to propose this for standardization. And it 
should not be too hard.

> Basically, the idea is this:
>
> int foo(int a, int b, int c);
>
> void bar(void) {
> 	foo(1, 2, 3);	// Normal call
> 	foo(.a = 1, .b = 2, .c = 3)	// Same as foo(1, 2, 3)
> 	foo(.c = 3, .b = 2, .a = 1)	// Same as foo(1, 2, 3)
> }

struct foo_args {
  int a, b, c;
};
void foo(struct foo_args);
#define foo(...) foo((struct foo_args){__VA_ARGS__})
void g(){
  foo(1,2,3);
  foo(.c=3,.b=2);
}

In C++ you could almost get away without the macro, calling f({1,2,3}), 
but f({.c=3}) currently gives "sorry, unimplemented". Maybe you would like 
to work on that?

> If only the first variant is allowed (with the named parameters in the
> order declared in the prototype), then this would not affect code
> generation at all - the designators could only be used for static error
> checking.
>
> If the second variant is allowed, then the parameters could be re-ordered.
>
>
> The aim of this is to make it easier and safer to call functions with a
> large number of parameters.  The syntax is chosen to match that of
> designated initialisers - that should be clearer to the programmer, and
> hopefully also make implementation easier.
>
> If there is more than one declaration of the function, then the
> designators used should follow the most recent in-scope declaration.

An error may be safer, you would at least want a warning.

> This feature could be particularly useful when combined with default
> arguments in C++, as it would allow the programmer to override later
> default arguments without specifying all earlier arguments.

C++ is always more complicated (so many features can interact in strange 
ways), I suggest you start with C.

> At the moment, I am not asking for an implementation, or even /how/ it
> might be implemented (perhaps a MELT plugin?) - I would merely like
> opinions on whether it would be a useful and practical enhancement.

This is not such a good list for that, comp.lang.c is better suited. This 
will be a good list if you have technical issues implementing the feature.

--
Marc Glisse