Date: Sun, 21 May 2023 18:38:38 -0400
Em dom., 21 de mai. de 2023 às 05:22, Boris Kolpackov
<boris_at_[hidden]> escreveu:
> 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.
Yes, and no. The "canonical" interpretation should still be the same
as of source inclusion, but we would open the space for the
optimization that already exists in both Clang and MSVC.
> 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.
But yeah, I can see the immediate solution may be to just walk back
the specification of Importable Headers as it exists today and go back
to the modules working group (hopefully working more closely with
tooling) to get to a design that takes from the experiences in
implementations that already exist and specify something that could be
more easily implementable. I don't have the answer to that right now.
The existing implementation experience has a lot of caveats on what
makes a good candidate for an importable header, and it is the
responsibility of the user to do that correctly. I don't know how to
make the spec in such a way where this is not the case and at the same
time that it can be implemented in every environment where C++ is used
today.
daniel
<boris_at_[hidden]> escreveu:
> 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.
Yes, and no. The "canonical" interpretation should still be the same
as of source inclusion, but we would open the space for the
optimization that already exists in both Clang and MSVC.
> 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.
But yeah, I can see the immediate solution may be to just walk back
the specification of Importable Headers as it exists today and go back
to the modules working group (hopefully working more closely with
tooling) to get to a design that takes from the experiences in
implementations that already exist and specify something that could be
more easily implementable. I don't have the answer to that right now.
The existing implementation experience has a lot of caveats on what
makes a good candidate for an importable header, and it is the
responsibility of the user to do that correctly. I don't know how to
make the spec in such a way where this is not the case and at the same
time that it can be implemented in every environment where C++ is used
today.
daniel
Received on 2023-05-21 22:38:50