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

I think a complete proposal for epoch should be made with its requirements spelled out clearly and unambiguously, independently of what SG15 is or isn't doing with header units. Then, based on that information and evaluation, EWG would take the appropriate actions.

-- Gaby

-----Original Message-----
From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of William Linkmeyer via SG15
Sent: Saturday, May 20, 2023 7:50 AM
To: sg15_at_[hidden]
Cc: William Linkmeyer <wlink10_at_gmail.com>
Subject: Re: [SG15] P2898R0: Importable Headers are Not Universally Implementable

>> 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_lists.isocpp.org> 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]pp.org
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
_______________________________________________
SG15 mailing list
SG15_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/sg15