Hello SG15,

Sadly the Friday meeting time is not one I can make usually, so email for now…

---
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.
The first idea that occurred would be to have them start with “module;” which matches the logical behaviour (the entire content is in the GMF).  However, since we already have compiler diagnostics about ‘module;’ without a following ‘module XXX;’ that would presumably not work easily now.
Suppose we chose to require that they start with “header-unit;”?
it is 
 * simple,
 * unlikely to clash with any other keyword intent
 * not an invasive source change 
 * fast to parse for build systems and compilers alike.
Given an expectation that the user has to identify importable header units somehow, doing it in the source seems to me to be the neatest solution.
what did I miss?
Iain
P.S I was considering making this an NB comment - but feedback would be welcome.