I've always understood importable headers as something that cannot be fully
automated
and requires such headers to be flagged manually, requiring either a list
of importable headers to be maintained
or an other way to provide that information (ie, that was the whole reason
for https://wg21.link/p1905r0

I don't think there was ever a desire for importable headers to offer a
0-cost migration, but a pretty cheap
migration, i.e., by flagging these files manually.

The "not affected by the preprocessor state" applies to a cohesive build
unit so they may still be required to be rebuilt across projects (different
set of global flags)
or per library. And certainly environments as all headers may be affected
by the global processor state, which does include any macro defined in
system headers.

I do agree that, given we need to maintain a list of importable headers,
and given that includes can be translated to import, it is not clear why
a specific grammar exists. That grammar blesses any header as importable,
which users may not fully realize, and which may lead to headers affected
by the preprocessor state to be imported.
But at the same time, very few headers are affected by the preprocessor
state (and I agree that this cannot be computed).


I think the paper would benefit from stating more clearly what the problem
is, it was a bit difficult for me to read between the lines.


Thanks!

On Thu, May 18, 2023 at 10: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
>