> 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@lists.isocpp.org> 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@lists.isocpp.org> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg15
_______________________________________________
SG15 mailing list
SG15@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg15