How so? Consider for example a device driver interface that uses a
struct of function pointers (a pretty common case). All divers use the
same struct, but not all divers require all of the parameters that are
passed. Having the parameter unnamed clearly documents that it is unused.
After this and Alain's posts, I have changed my mind. You are of course
correct that in cases where functions have to fit a particular type, you
can easily get parameters that have no function and would be best left
True, but it is ugly. What possible harm could unnamed parameters cause?
In the case where a function has a parameter but the current
implementation does not use it, I think it is best to name it and mark
it as unused (either by something like the gcc attribute, if that is
portable enough for the code, or by (void) x). That makes it clear that
the parameter is reserved for a purpose.
In the case where a function has extra parameters just to make it fit a
common signature, then unnamed parameters would seem better, as you are
then saying that these parameters are not really part of the function.
Unnamed parameters are quite common in C++, probably more common than
cases where they would be useful in C. While the potential uses aren't
a common in C, the feature would still be a useful, cost free, addition.
We already pay the "cost" of unnamed parameters - they are legal in
function declarations, letting people write unhelpful declarations (like
"extern int foo(int, int)"). So yes, it would be a free feature with at
least some good uses.