Remove unused parameter names in StatusArg.h

[annafilimonova1]

Part of closed #8938

[hvlad]

I have no idea how parameter name in declaration could be [un]used.
And why it should be removed.
Honestly, I prefer to name all params in declarations - it greatly helps intellisense to produce better hints.

[hvlad]

I have no idea how parameter name in declaration could be [un]used.

Oops, it is not only declarations, it contains empty bodies.
Anyway, my opinion is not changed.

[asfernandes]

I have no idea how parameter name in declaration could be [un]used.

Oops, it is not only declarations, it contains empty bodies. Anyway, my opinion is not changed.

Agreed.

[aafemt]

Unfortunately compilers disagree and produce warning for such cases. That's what [[maybe_unused]] is for.

[hvlad]

Unfortunately compilers disagree and produce warning for such cases.

What compiler and which warnings ? I see none.

[aafemt]

What compiler and which warnings ?

class Foo
{
public:
  void bar(int x) {  }
};

g++ -Wall -Wextra:

warn.cpp: In member function 'void Foo::bar(int)':
warn.cpp:4:16: warning: unused parameter 'x' [-Wunused-parameter]
   void bar(int x) {  }
            ~~~~^

You don't see them just because Firebird build system suppress too many diagnostic messages.

[hvlad]

Your case is very far from Firebird code above.
Make Foo::bar virtual and add derived class with overrided bar which really uses parameter.
Useless warnings should not distract so mush attention as in this case.

[aafemt]

Make Foo::bar virtual and add derived class with overrided bar which really uses parameter.

Result is exactly the same:

class Foo
{
public:
  virtual void bar(int x) {  }
};

class Bar: public Foo
{
  void bar(int x) override { throw x; }
};

warn.cpp: In member function 'virtual void Foo::bar(int)':
warn.cpp:4:24: warning: unused parameter 'x' [-Wunused-parameter]
   virtual void bar(int x) {  }
                    ~~~~^

Warning-less build would be much more useful than nested namespaces...

[hvlad]

Result is exactly the same:

Exactly. This is why this warning in this place is completely useless and wrong.

[AlexPeshkoff]

On 4/3/26 01:02, Vlad Khorsun wrote: *hvlad* left a comment (FirebirdSQL/firebird#8976) <#8976?email_source=notifications&email_token=AA44OUP5I7L5I7XSBD2D7TT4T3PRHA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMJYGA3TEMZUGQ22M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOS2XA4S7MNXW23LFNZ2F633QMVXF6Y3MNFRWW#issuecomment-4180723445> Result is exactly the same: Exactly. This is why this warning in this place is completely useless and wrong.

Agreed. On my mind presence of parameter names makes code better human readable and let compiler provide better error messages, specially in a case when there are many parameters.

[aafemt]

That's why [[maybe_unused]] exists: to confirm that coder intentionally didn't use the parameter and not just forget to write some important code.

[hvlad]

In short: not in this case

[aafemt]

JFYI: this attribute is not inheritable.

[hvlad]

JFYI: this attribute is not inheritable.

wow! this change everything (nope)

I have no idea why do you wrote it.

[aafemt]

When function's parameter isn't mentioned in function's body, compilers (and code analyzers) issue a warning. There are four ways to handle that:

1. Close your eyes (yours).
2. Instruct them to shut up (Firebird's).
3. Remove parameter name (pre-C++17).
4. Use [[maybe_unused]] attribute (post-C++17).

First two options are bad because warnings are your friends helping to discover bugs in code. Last two options are used case-per-case and show readers that unused parameter is the writer's intention, not mistake.

[hvlad]

You wrong again. Read this, for example.

I'm insist that:

• parameter names should not be missed in functions declarations
• [[maybe_unused]] should not be used as a garbage in functions declarations making it impossible to read.

In this case, when declaration of virtual function in very base class is combined with its empty definition, one may avoid scary stupid useless warnings by:

• decoupling declaration from definition, or
• make declaration pure virtual (when/if possible, of course).

But I didn't consider it as necessary at all.

[aafemt]

• make declaration pure virtual (when/if possible, of course).

Finally you said something that make sense.

[dyemanov]

Originally parameters were named. Names were removed by Claudio to eliminate warnings (which implies he had seen them). Then two new methods were added, again with named parameters. This PR eliminates the new warnings again (and it follows the existing practice in this file). I'm open to any arguments except those reverting us back to unnecessary warnings.

Personally, I don't like [[maybe_unused]], even if standard - but that's just me. I don't like missing names either and prefer to use commented names instead. Options suggested by Vlad are the best ones IMHO, but they require some refactoring. The question is whether we insist it to be done by students or just apply the PR and defer the refactoring to some other day.