DOXYGEN: Create multi-arguments alias without curly braces syntax, like @param & others (tag!)?

Question

We use doxygen to document our C/C++ code in a project we've just started and we'd like to achieve the following, if possible. When creating a custom ALIAS, with multiple arguments, the syntax we'd use in our code-doc would look like:

/**
 * @myalias{param1,param2}
 */

and in our .doxy file, the definition of this ALIAS would look like:

ALIASES += myalias{2}="do something with \1 and with \2"

What we'd like instead would be to define a custom tag, that behaves like @param, which would allow us to use the following syntax when documenting our source-files:

/**
 * @myalias param1          param2
 */

and still be able to refer to param1 & param2 somehow.

I know that, for instance, the @param tag can discern between param1 & param2 as being 2 DIFFERENT entities, and it doesn't need any curly braces.

Would it be possible to define a custom tag in which we could access param1 & param2 as separate entities in our .doxy files, but by using a code-doc syntax WITHOUT the curly braces?

Thank you in advance

Answer 1

The short answer is no. After reading the doxygen documentation very carefully, there does appear to be a reasonable explanation as to why. The list of built in doxygen commands is liable to change, and you do not want to redefine all of your aliases when it does. How would you select a command versus an alias when there was a conflict? Rather than having to implement a decision, doxygen forces you to indicate which is which.

The example that is implied by the documentation is in the section on aliases with arguments. Here, the l{1} alias is defined and experimented with in detail. However, if you go to the bottom of the list of commands, it clearly states that there is a command \l that should never be used explicitly. The curly brace alias definition makes it completely unambiguous as to which one is being used.

I am not sure if this is actually a deliberate design philosophy or it just happily came together this way, but the distinction serves a useful purpose.

I am sorry to be writing this answer since I was myself hoping for the result that you are trying to achieve. Knowing the reason helps though.