Em sáb., 20 de mai. de 2023 às 10:49, William Linkmeyer
<wlink10_at_[hidden]> escreveu:
> I’m confused. In this example:
>
> ```
> #define HASH_TYPE int
> #include “some_c_style_hash_map.h” // Dependent on the HASH_TYPE definition
> #include “some_c_style_hash_map.h” // Might do nothing if include guards are present; dependent on the line above
> // …
> ```
>
> Isn’t the header influenced by the state of the preprocessor? I may be confused about where the state change occurs, and in which TU.

Not if the compiler has been instructed that
`"some_c_style_hash_map.h"` is an importable header.

This is the case today with Clang Header Modules. It is considered a
"user error" if a header that depends on the state of the preprocessor
at the time of inclusion is annotated that way.

The specification allows for the compiler to replace an `#include` by
its equivalent `import`.

> >> Should these imported headers be subject to different rules of use than included headers, such that the concerns your paper raises about the state of the preprocessor be addressed?
> > If importing a header didn't change the state of the preprocessor,
> > then we'd be able to use the same logic we use for named modules.
> Yes. I’m wondering if a restriction on Importable Headers such that the preprocessor isn’t affected by them is viable.

While I can see the benefit of that approach, however, that would be a
significant change from where the spec is now, and I don't know if
"importable headers cannot define macros" would be something that
would be particularly useful, specially considering how easy it is to
wrap a header in a named module (fairly easy to automate as well).

> >> A space free from the state of the preprocessor may also give Epochs(1) some space to breath.
> >> Independent of whether IS wording needs to be changed, is this a viable route?
> >> (1) https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1881r0.html
> > I am not entirely sure what you mean by that. Would you mind clarifying?
> I believe a blocker for Epochs were how they would play with textual inclusions. If each Importable Header didn’t change the state of the preprocessor, or were more restricted than textual source inclusions, I could imagine the second Epoch propose an elimination of textual inclusions altogether with a good chance of adoption in current project architectures with some work.

That may be true, or not. But I want to defer those kinds of
discussions until we resolve the questions of importable headers from
the tooling perspective.