On 05/10/16 22:24, Florian Weimer wrote:
> * David Brown:
>
>> Far and away the best solution would be for C++ to support named
>> parameters or named arguments:
>>
>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4172.htm>
>>
>> Then you could write:
>>
>> foo(1, 2, bar_p: true);
>>
>> You could also write
>>
>> foo(y: 2, bar_p: true, x: 1)
>>
>> and get the same call.
>>
>> It is always much better if you can put something in code rather than a
>> comment.
>
> True, but I don't think this is possible because function argument
> names are explicitly *not* part of the API today (and are often
> mangled in public header files, if they are included at all).
Why is that? I have always felt that you should have all the required
information to use a function in its declaration in the header - you
should not have to look up the definition unless you want to know /how/
it works. And in order to know how to use a function, you need to know
what the parameters are - when that can be communicated through their
name, there is no need to clutter the file with extra comments.
But it sounds like there was an active decision not to include argument
names in header declarations in gcc code - and I am curious to know the
basis for that.
>
> Something analogous to std::initializer_list, but for C99 designated
> initializer syntax might be more acceptible. So in your example:
>
> foo({.y = 2, .bar_p = true, .x = 1})
Are you thinking here of making foo a function that takes a single
struct argument, or as a general method for named parameters as an
alternative syntax to "foo(y: 2, bar_p: true, x: 1)" ? Personally, I
would prefer to drop the brackets "foo(.y = 2, .bar_p = true, .x = 1)" -
I think that would be nicer than either the N4172 syntax or the syntax
with brackets. I had merely suggested the N4172 choice of a colon
syntax because it is a lot more likely that a proper C++ feature
proposal gets implemented than a suggestion in a mailing list post!
But unless it is realistic that gcc will get named parameter support in
C and/or C++ (either as an extension, or due to a future C or C++
language standard), then a discussion about these details is just
bikeshedding.
>
> The advantage is that functions supporting this invocation style would
> have to be marked explicitly in the sources, so there would not be an
> accidental source code dependency on a non-portable aspect of system
> header files.
>
I suppose that even if gcc were to support named parameters or other
great new features, you couldn't use those features in the source code
for gcc without causing a chicken-and-egg problem.
