On Tue, Jun 7, 2022 at 4:28 PM Daniel Ruoso <daniel_at_[hidden]> wrote:

> Em ter., 7 de jun. de 2022 às 10:22, Mathias Stearn via SG15
> <sg15_at_[hidden]> escreveu:
> > Don't we already have an extremely portable format for that
> > "metadata"? If you make a directory with all of the header paths
> > you want to remap and have them contain a single
> > `import named.module;` line, and inject that directory to the
> > front of your include paths, this should work out of the box
> > for all compilers. Why do we need a new metadata format for this?
>
> That is not sufficient, unfortunately. If we want to allow the
> compiler to silently replace an `#include <foo.h>` with `import
> <foo.h>`, it's important that the behavior remains the same.
>

You are describing something else. Daniella was specifically talking about
replacing an #include with an import of a *named module* not a header unit.
I assume this would only happen when it is explicitly requested by a
developer because they know that they don't actually want any macros to
leak out of the #include lines.

But also it is important that it *isn't* required for the behavior to
remain the same when an #include is turned into an import. Part of the
point of header units is that they are not affected by the preprocessor
state of the importer. If <some_header> is an importable header, then it
is completely legal and expected to get different behavior in the following
code depending on whether the #include becomes an import:

#define NDEBUG
#include <some_header>

I still regret that we added the weasel words to
http://eel.is/c++draft/cpp.include#7 to stop guaranteeing that #includes of
importable headers would become headers. In the "good old days" if the
developer indicated that some header was "importable" then it would be
guaranteed to always be imported. Once that facility was lost, I think a
lot of the power of header units went away with it so they are now mostly
just a build optimization rather than something that could be used for code
organization purposes.


>
> Importing a named module does not result in a `#define` done in the
> header to be made available in the scope after the importation. While
> doing `import <foo.h>` does.
>
> Therefore providing the compiler with the list of header units needs
> to happen even before the dependency scanning.
>
> daniel
>