* Maybe my standardese-fu is wrong here, but since I see no provision for the implementation defined set of importable headers to change within a TU, I would expect its membership to remain constant, at least within a TU.

There is no ground for such an expectation. Implementation-defined only means that the implementation has to tell you what is importable header. There is no requirement that such a set is fixed. The implementation can very say that an importable header is one that it is told via the very syntax ‘import <x>;’ or one that it can successfully translate.

From: Mathias Stearn <redbeard0531+isocpp_at_[hidden]>
Sent: Thursday, July 11, 2019 5:34 AM
To: Ben Boeckel via Modules <modules_at_[hidden]>
Cc: Bryce Adelstein Lelbach aka wash <brycelelbach_at_gmail.com>; Gabriel Dos Reis <gdr_at_[hidden]>; Tom Honermann <tom_at_[hidden]>; sg15_at_[hidden]
Subject: Re: [isocpp-modules] [SG15] Determining identity like #pragma once



On Thu, Jul 11, 2019 at 2:20 PM Nathan Sidwell <nathan_at_[hidden]<mailto:nathan_at_[hidden]>> wrote:
On 7/10/19 5:58 PM, Bryce Adelstein Lelbach aka wash wrote:
> Hrm.
>
> My current understanding is that if you import <x>, then it is an
> importable header (otherwise your program is ill-formed), and thus
> because it is an importable header, any #include <x>s must be
> translated to imports.

There seems to be disagreement as to the implications of:
   import <x>;
1) the programmer is stating that <x> /is/ an importable header, or
2) the programmer is presuming it is (and would like to be told otherwise).

Alternatively, can the source being compiled change the set of
importable headers, or is that set exclusively determined by other means?

#1 has the time-travel issue of
   #include <x>
   import <x>;

#2 has the issue of creating an oracle somewhere (we already have that
issue wrt include translation)

As the set of importable header units is implementation defined, I don't
think the std distinguishes between these two implications.

Maybe my standardese-fu is wrong here, but since I see no provision for the implementation defined set of importable headers to change within a TU, I would expect its membership to remain constant, at least within a TU. So if we want "importable" to mean "imported" (plus std headers?) then that would probably require a pre-scan to see which modules are imported, before doing actual translation. This doesn't actually seem like a huge change from status quo (with modules in the working draft) because most build systems will end up doing a pre-scan anyway to determine named module imports to get a correctly ordered build DAG.

If it is possible for the implementation defined set to vary within a TU, are only insertions allowed, or are removals also allowed? That would essentially mean that each #include and import may operate with a different implementation defined set, rather than there only being one.


[cpp.include]/7
If the header identified by the header-name denotes an importable header
(10.3), the preprocessing directive is instead replaced by the
preprocessing-tokens ....

There's no 'maybe' in there, so it seems to me that include translation
must occur.

There's no requirement that the set of importable headers must be the
same for all TUs in a program.

nathan

--
Nathan Sidwell
_______________________________________________
Modules mailing list
Modules_at_lists.isocpp.org<mailto:Modules_at_[hidden]>
Subscription: http://lists.isocpp.org/mailman/listinfo.cgi/modules<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fmodules&data=02%7C01%7Cgdr%40microsoft.com%7C465e51670a3b491a07f008d705fc16ec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636984452795229889&sdata=%2FauivYjySauphgPrj1JSL8TFCFZlIl7OGzSgFw2rBCI%3D&reserved=0>
Link to this post: http://lists.isocpp.org/modules/2019/07/0522.php<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fmodules%2F2019%2F07%2F0522.php&data=02%7C01%7Cgdr%40microsoft.com%7C465e51670a3b491a07f008d705fc16ec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636984452795229889&sdata=H3ot2njGvtIcAYPmVpMPwCScFl0mzi404LCCwcEReJw%3D&reserved=0>