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
syntax.
> 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
arguments.
>
> 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,
David
