Daniel Ruoso via SG15 <sg15_at_[hidden]> writes:

> 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.

>From the paper:

> However, [...] we currently don’t have an acceptable approach for their
> implementation that fits into all cases where C++ can be used. This
> could lead to a bifurcation of the C++ Ecosystem, which is a profoundly
> undesirable outcome [...]

And:

> The most significant outcome of this alternative approach is that the
> semantics of source inclusion are still the canonical behavior, and
> instead we would give permission to implementations to do something
> different in cases where it would be advantageous to do so, allowing
> the implementations to define their own caveats for that optimization.

This reads circular to me: you say that some places where C++ is used
not being able to support importable headers is "bifurcation" that is
"profoundly undesirable" but your recommendation is to essentially
bifurcate the semantics of importable headers by making it
implementation-specific and full of caveats.

I think the semantics of importable headers should be specified by
the standard and be portable or we should just drop importable headers
altogether. Anything implementation-specific is just re-inventing
precompiled headers.