It is (of course) a feature that forward declarations can not hold documentation.

One reason is that documentation for one entity should not be scattered over
several files. After all it is in-code documentation, too. And when reading the
code, the natural place to look for a documentation is at the entities
definition, not at one of possibly many forward declarations.

As the entities in unotype.hxx are defined nowhere else, I'd suggest to just
define them empty:

struct Xyz {};

Then documentation will be generated.

That does not convince me.  Think about a case where there is a declaration of
an entity in a file that is processed by autodoc, while the definition of the
entity is in another file that is not processed by autodoc.  If you want to
avoid documentation on "forward declarations," you might change autodoc so that
it ignores documentation for the declaration of an entity if and only if autodoc
comes across either more than one declarations of that entity that has
documentation, or a definition of that entity that has documentation, or both.

> where there is a declaration of
> an entity in a file that is processed by autodoc, while the definition of the
> entity is in another file that is not processed by autodoc.

In this case one processes the file with the definition.

However, I suggest to stay with the actual use case. It is good programming
practice to keep things simple, standard and unmistakable. Having undefined
structs looks strange at least. 

If one wants to do something real with the template, they are parameters to, I
am not even sure, if it is correct to leave them undefined, when the template is
instantiated. What is the C++-standard paragraph allowing this? And even (as I
assume) if you made sure, this is correct - can we be absolutely sure that in no
future use case those structs may need a definition anyway? 
Besides, if one defines those structs as empty, one can even avoid half of the
comment (the part that they are not defined and why).

Looking at all that, what is the reason to leave these struct undefined?

<quote>In this case one processes the file with the definition.</quote>
Huh?  We only process headers and not implementation files.

<quote>Having undefined structs looks strange at least.</quote>
That might be your personal opinion.  However, the idea of information hiding is
well established, even in C++ circles.  The current implementation of autodoc
does not take this into account (it equally fails to work for cases where the
class definition is hidden in an implementation file and for cases where there
is no class definition at all).

<quote>What is the C++-standard paragraph allowing this?</quote>
14.3.1/2

<quote>Looking at all that, what is the reason to leave these struct
undefined?</quote>
There is no reason to have them defined.

> Huh?  We only process headers and not implementation files.

Autodoc processes any given file as long as it contains valid C++ declarations.
The parameter -f <filename> parses files regardless of extension.

<quote>Looking at all that, what is the reason to leave these struct
undefined?</quote>
> There is no reason to have them defined.

That IMO is not enough. 
This is no defect, but a feature request. The feature to comment forward
declarations is undesirable in Autodoc as it invites to spread documentation
over several places.

In the concrete case there was no disadvantage given of defining the structs
empty. But advantages can be given: It is easier to for maintainers to recognize
the construct with one look. Also it is more robust in case of future changes
that may need a definition of these types.

Last not least: The effort to define those structs is 5 minutes. The effort to
implement the (also IMO undesirable) feature, is several hours.

So, if there are no new reasons, I'd suggest to not do this.

Interfaces indeed use to have the need to document incomplete types in
interfaces without uncovering the type's definition. So reopened.

retarget