>From my perspective, "build optimization" is a better design than the previous iteration.

BTW, where named modules are found aren't along include paths; at least, not on MSVC. Furthermore, hijacking include paths by sticking stuff in front is something that we wanted to move away from because of the bugs/headaches that practice has caused.

-- Gaby

________________________________
From: SG15 <sg15-bounces_at_[hidden]> on behalf of Mathias Stearn via SG15 <sg15_at_[hidden]>
Sent: Tuesday, June 7, 2022 8:13:43 AM
To: Daniel Ruoso <daniel_at_[hidden]>
Cc: Mathias Stearn <redbeard0531+isocpp_at_[hidden]>; sg15_at_[hidden] <sg15_at_[hidden]>
Subject: Re: [SG15] "logical name" of importable headers




On Tue, Jun 7, 2022 at 4:28 PM Daniel Ruoso <daniel_at_[hidden]<mailto:daniel_at_[hidden]>> wrote:
Em ter., 7 de jun. de 2022 ās 10:22, Mathias Stearn via SG15
<sg15_at_[hidden]<mailto: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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fcpp.include%237&data=05%7C01%7Cgdr%40microsoft.com%7C827474229ccc481d4f5e08da4898584c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637902116407938672%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1NRdCLLwGBMbtWhWolNnls7FnwX6Cvx0ZK9QSPCeW1g%3D&reserved=0> 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