> A space free from the state of the preprocessor may also give Epochs(1)
some space to breath.

First, Sean Baxter has some research in the circle compiler demonstrating
that you can have the preprocessor and granular feature directives without
an issue. Of course, epochs are just structures sets of language features,
so I'm assuming it's not strictly a problem in general. I can't promise the
same ideas apply to all toolchains, though.

Second, we can't really be free of the state of the preprocessor anyway. If
nothing else, include guards depend on preprocessor state both going into a
header and coming out of it. So I suspect protections against multiple
inclusion (and more vectors for ODR bugs!) are in particular underspecified
if we want to salvage header imports somehow. I'm not convinced it's worth
figuring it out at this point, but I'm willing to listen to ideas,
especially if they are somehow significantly less disruptive than just
powering through adoption of named modules.

Bret

On Fri, May 19, 2023, 18:02 William Linkmeyer via SG15 <
sg15_at_[hidden]> wrote:

> If a user explicitly `import`s an Importable Header, should that header
> necessarily break free from a dependency on the state of the preprocessor?
>
> 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?
>
> 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
>
> WL
>
> On May 18, 2023, at 4:46 PM, Daniel Ruoso via SG15 <sg15_at_[hidden]>
> wrote:
>
> Hello,
>
> After lots of discussions and trying to find solutions on how to make
> Importable Headers work, I have come to the unfortunate conclusion
> that they are not implementable in a way that would be acceptable in
> all environments where C++ is used.
>
> Moreover, I believe the goals that were set for the specification of
> Importable Headers can be achieved in a much simpler way, without
> introducing the special semantics that those provide.
>
> In other words, we can make the standard allow the optimizations
> achieved by Explicit Clang Header Modules as well as the early
> adoption reports from MSVC, while at the same time maintaining the
> semantics of source inclusion as the "canonical" behavior for when a
> given environment cannot make use of those optimizations.
>
> This revision of the paper does not include wording changes yet, as I
> want to build consensus on this prior to going through the effort of
> figuring out what wording needs changing.
>
> See the paper at: https://wg21.link/P2898R0
>
> daniel
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>