Em qui., 12 de mai. de 2022 às 16:06, Michael Spencer via SG15
<sg15_at_[hidden]> escreveu:
> In general I think we'll still need explicit lists of importable headers,
> but implicitly assuming `import <header.h>` makes the header
> importable and doing include translation will work in practice
> as the above code should be incredibly rare.

My current take is that we need to accept that Implementations are not
required to automatically make the header unit importation possible
for any file that could be otherwise included.

In fact, the standard has examples of "importable header" and
"non-importable header", and they are indistinguishable from their
content alone. Therefore I contend the specification *expects* an
explicit definition of what are the importable headers to live outside
the language itself.

The specification even goes as far as saying (15.3.7):

"If the header identified by the header-name denotes an importable
header (10.3), it is implementation-defined whether the #include
preprocessing directive is instead replaced by an import directive
(15.5) of the form import header-name ; new-line:"

The only way I can read this is that it's allowed for an
implementation to ignore the preprocessor state up to that point and
just import the header unit that was independently parsed. This is a
significant change in behavior, but it seems to me to have been a very
intentional one.

Specifically, I understand that statement to mean "any importable
header may be unaffected by the state of the preprocessor up to the
include directive". In other words: "if I tell you foo.h is
importable, you are free to optimize away the source inclusion, even
if the source inclusion would have resulted in a different parsing of
foo.h due to preprocessor state".

daniel