On 7/10/19 2:45 PM, Corentin wrote:
> A TU that include a header and then import it should be ill-formed.
> Otherwise we would inevitably run into the set of issues you describe.
>
> A pragma (or other syntax) would be one way for the compiler to know
> the header is importable and would therefore enable:
>
> #include <foo>
> import <foo>;
>
> to work as expected.
> I'm very much in favor of a solution that is in the source code rather
> that in the build system / compiler flags

My understanding and reading of the wording indicates that this is not
an issue. The above is treated as if it were written:

import <foo>;
import <foo>;

This of course depends on the implementation knowing which headers are
importable. That is already specified as implementation defined
([module.import]p5
<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fmodule.import%235&data=02%7C01%7Cgdr%40microsoft.com%7Ce1d9e7eedab84332db4308d7055eec54%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636983777563207334&sdata=WwjHx%2FXWe7kf6M5xVLmysV0qIgvxUCR3Ck2A9zKrBd8%3D&reserved=0>).
We haven't talked much about this in SG15. Clang modules handles this
via module map files. I think the SG15 TR should specify a similar
mechanism.

Tom.

>
> On Wed, 10 Jul 2019 at 19:23, Gabriel Dos Reis via Modules
> <modules_at_[hidden] <mailto:modules_at_[hidden]>> wrote:
>
>
>
> > On Jul 10, 2019, at 10:18 AM, Tom Honermann <tom_at_[hidden]
> <mailto:tom_at_[hidden]>> wrote:
> >
> >> On 7/10/19 1:00 PM, Gabriel Dos Reis via Modules wrote:
> >>
> >>> On Jul 10, 2019, at 6:27 AM, Bryce Adelstein Lelbach aka wash
> <brycelelbach_at_[hidden] <mailto:brycelelbach_at_[hidden]>> wrote:
> >>>
> >>> On Wed, Jul 10, 2019 at 2:48 AM Gabriel Dos Reis via SG15
> >>> <sg15_at_[hidden] <mailto:sg15_at_[hidden]>> wrote:
> >>>> Also, we should note that import and #include of the same
> file can lead to unexpected results, so we need both
> clarifications and recommendations there for users.
> >>> Why should this lead to unexpected results?
> >>>
> >>> Suppose I have:
> >>>
> >>> #include <foo>
> >>> import <foo>;
> >> To illustrate the concern, let me further add that the header
> <foo> has include guard and all that.
> >>
> >> The #include copy-n-pastes the content of foo in the current
> translation - including of course any definitions. The import
> makes available any declaration/definition from the translation
> unit of foo. The program ends up with multiple definitions (at
> link time at least).
> >
> > This doesn't sound correct to me.
> >
> > For <foo> to be importable at all implies, to me, that the
> implementation must be aware (somehow) that <foo> designates an
> importable header. In other words, in this scenario, no
> copy-n-paste inclusion occurs.
> >
> > [module.import]p5
> (https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fmodule.import%235&amp;data=02%7C01%7Cgdr%40microsoft.com%7C627c2e697d3246f69cd008d7055aaa49%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636983759279843021&amp;sdata=KNmreH81AE1GNzLjcAEgzCneqRsmQy%2BhWsuAdwN64qU%3D&amp;reserved=0):
> >
> > ... An importable header is a member of an
> implementation-defined set of headers ...
>
> Please expand on how it doesn’t sound correct. All I said follows
> exactly the spec.
>
>
> >
> > Tom.
> >
> >
> _______________________________________________
> Modules mailing list
> Modules_at_[hidden] <mailto:Modules_at_[hidden]>
> Subscription: http://lists.isocpp.org/mailman/listinfo.cgi/modules
> Link to this post: http://lists.isocpp.org/modules/2019/07/0483.php
>