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