Am 19.05.2023 um 07:41 schrieb Jens Maurer via SG15:
 - This should also go to the Modules Study Group.

 - "Include the Local Preprocessor Arguments for those as an input to the dependency
scanning process"

I don't think that's accurate.  Header units are specified, I believe, intentionally
such that the preprocessor state from the importing site has no effect on the
contents of the header unit.


The term "Local Preprocessor Argument" doesn't refer to the preprocessor state at the point of import of a header unit. It refers to the preprocessor state at the start of translating the header unit TU which might be different to the preprocessor state at the start of translating the TU that nominates the import of said header unit.


On 18/05/2023 22.46, Daniel Ruoso via SG15 wrote:

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:

SG15 mailing list
SG15 mailing list

PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5