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).  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@lists.isocpp.org> wrote:

> On Jul 10, 2019, at 10:18 AM, Tom Honermann <tom@honermann.net> 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@gmail.com> wrote:
>>>
>>> On Wed, Jul 10, 2019 at 2:48 AM Gabriel Dos Reis via SG15
>>> <sg15@lists.isocpp.org> 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@lists.isocpp.org
Subscription: http://lists.isocpp.org/mailman/listinfo.cgi/modules
Link to this post: http://lists.isocpp.org/modules/2019/07/0483.php