C++ Logo

sg15

Advanced search

Re: P2898R0: Importable Headers are Not Universally Implementable

From: Daniel Ruoso <daniel_at_[hidden]>
Date: Fri, 19 May 2023 19:54:45 -0400
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

Received on 2023-05-19 23:54:57