On Thu, Jul 11, 2019 at 2:20 PM Nathan Sidwell <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_[hidden]
> Subscription: http://lists.isocpp.org/mailman/listinfo.cgi/modules
> Link to this post: http://lists.isocpp.org/modules/2019/07/0522.php
>