Hi Iain!

Am 13.10.2022 um 10:41 schrieb Iain Sandoe via SG15:
> Once again in the course of implementation work we find ourselves noticing that Header Units are special.
>
> * The compiler cannot determine from the source that a header is an importable one.
>
> * AFAICT, the build system can figure that a source depends on a specific header, but it is also not able to determine if that header is an “importable” one (except for the sub-set that are pre-defined to be). Which means that we probably require that the user’s project defines which headers are importable. That disconnects metadata from the sources which is undesirable, if not a recipe for bugs.
>
> I expect that this has been discussed before, and I’ve missed it somehow .. but several times during my implementation work on clang, it seemed to me that this problem would go away if importable header units were required to start with a keyword.
>
> ...

You are right, I also think the Header Unit situation is a mess.

Specifying their set as implementation-defined (beyond what's mandated
by the standard text) makes them effectively non-portable. Back in 2019
I had discussions about that on the #module CppSlack channel (I wasn't a
member of WG21 at that time) with some of the implementers having
discussions there. The folks didn't like my assessment, arguing that
"importable" actually means something along the lines of '*every* header
that doesn't contain language constructs that are invalid in modules'.
As a humble user I reluctantly accepted this depiction and my own
experiences with msvc since then seem to corroborate that.

I understand the desire to improve the situation. But I also think that
mandating a keyword to introduce "importable" HUs renders their whole
existence obsolete. If you need to modify existing headers then you can
make them into full-featured named modules with barely more efforts.

This is all that I can contribute to this thread.

Dani