>> If a user explicitly `import`s an Importable Header, should that header necessarily break free from a dependency on the state of the preprocessor?
> The header does not depend on the preprocessor state of the TU doing
> the import. However, since the import causes a change of the state of
> the preprocessor, the dependency scanning needs to emulate the import

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.

>> 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.

>> 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.

WL

> On May 19, 2023, at 7:54 PM, Daniel Ruoso via SG15 <sg15_at_[hidden]> wrote:
>
> Em sex., 19 de mai. de 2023 às 18:02, William Linkmeyer
> <wlink10_at_[hidden]> escreveu:
>> If a user explicitly `import`s an Importable Header, should that header necessarily break free from a dependency on the state of the preprocessor?
>
> The header does not depend on the preprocessor state of the TU doing
> the import. However, since the import causes a change of the state of
> the preprocessor, the dependency scanning needs to emulate the import,
> which depends on the full list of header units as well as the local
> preprocessor arguments needed when translating the header unit.
>
> That is what creates the problem.
>
>> 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.
>
>> 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?
>
> daniel
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15