This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Named parameters

On 16/03/15 17:34, Marc Glisse wrote:
> 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.

I'm glad I asked here first!

Another poster has told me that the C++ committee rejected the idea -
even though Mozilla's proposal was for C++ and slightly different
syntax, the same justification for rejection would apply to my suggested

> 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.

Certainly for the simplified version (where re-ordering is not allowed,
and code generation is not affected), it should be a relatively small
task.  However, for the way I work, I use multiple different gcc
versions and builds for different embedded targets - keeping separate
forks would not be feasible.  The only point of working on this in a
fork would be with the aim of integrating it into mainline gcc - and it
sounds like that is not going to happen.

A possibility would be to use a MELT plugin - that would be a little
more flexible.

>> 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);
> }

That has two main disadvantages.  First, because the argument is in a
struct, it is going to be harder or impossible for the compiler to
generate equally good code (for some of my uses, the difference between
passing arguments in registers and passing as a struct on the stack is
very significant).  And secondly, it would require a wrapper macro for
each function, rather than merely a prototype with parameter names
(which are typically already there in existing code).  But it is
certainly a possibility for functions with particularly large numbers of

> 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.

I'd be happy with that - I like to keep my prototypes consistent.  But I
know that some people are more flexible.

>> 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.

We've discussed it a little in comp.lang.c already, and of those who
expressed an opinion, most were positive to the idea.  But c.l.c. is for
people who /use/ compilers - this mailing list has people who /write/
compilers, and who understand how changes to the language are made - it
has thus been very useful to me to hear your viewpoint.

Obviously your reply was not the answer I had hoped for (which would be
"Great idea! We'll put it in the next version" :-) ), but it makes
sense, and helps me understand the gcc developers' position on such
things, as well as the C (and C++) committees' positions.  If Mozilla
can't persuade the C++ committee, then I'll just have to hope that
someone even bigger and more influential likes the idea!

So thank you for taking the time to reply,


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]