Paul Eggert wrote:
> C23 introduced the longstanding C++ convention that a function
> parameter’s identifier can be omitted, meaning that the parameter
> is unnamed. This is clearer than [[maybe_unused]], as it means
> the parameter is definitely (not maybe) unused. When applicable,
> prefer this new macro to _GL_ATTRIBUTE_MAYBE_UNUSED.
Tastes obviously differ. But I find the _GL_ATTRIBUTE_MAYBE_UNUSED
style better and simpler.
C23 also introduced the C++ convention of adding [[__maybe_unused__]]
before a function parameter.
The meaning is the same:
- The parameter is part of the interface (typically defined through
a function pointer type).
- In this function definition it can be omitted.
- But the reader of the code should still be aware what the meaning
of this parameter is.
IMO we don't need two ways to avoid the compiler warning here. One is
sufficient, and that was _GL_ATTRIBUTE_MAYBE_UNUSED.
Do we need the compiler to verify that the parameter is really unused?
No, we don't. Even if the code is later refactored in such a way that
the parameter gets used, there is no damage. It would be like a comment
that no longer applies.
I think this is a case of the C++ sickness, where the programming language
offers several nearly identical ways to do the same thing, that programmers
disagree on which is "better". Thus leading to unproductive discussions
among programmer teams. It is bad that the ISO C23 committee has carried
over this sickness from C++ to C.
It would be better if we banned the omitted parameter name, and _GL_UNNAMED
with it, from our coding style. One way to do a certain thing is sufficient.
Bruno
