Hi Tom,
 Thanks for your explanation. Your words are self-contained. But I can't see it from [module.import]p5. I don't feel the semantics are stated clearly. If it is the intention, I strongly feel we need to reword it.
 Besides the wording, given this is the intention we wanted, it makes me feel header units become less usable.
> Yes, such patterns are fairly common. Headers that behave like bar.h should not be nominated as importable (and would ideally be diagnosed by implementations at import time as QoI).
 I interpreted this line into "some common headers can't be importable headers". This makes me feel worse since I thought the meaning of the definition of `header units` is to exclude some corner cases like:
```
// half.h
class A {
// another-half.h
};
// use.cpp
#include "half.h"
#include "another-half.h"
```
 And the general headers were meant to be importable although we doesn't define it well-formed in the standard. But given your interpretation, the usage of header units become less usable.

---
> I think it is possible to diagnose an attempted import of a non-importable header algorithmically by recording in the BMI the macros that would have contributed to different preprocessor translation if set differently and comparing those to the macro state of the preprocessor at import time. I don't know if it would be reasonable to require implementations to do so though.
 This sounds like a good idea.
Thanks,
Chuanqi
------------------------------------------------------------------
From:Tom Honermann <tom_at_honermann.net>
Send Time:2023 May 24 (Wed.) 03:48
To:Chuanqi <chuanqi.xcq_at_[hidden]>; Boris Kolpackov <boris_at_[hidden]>; Tom Honermann via SG15 <sg15_at_[hidden]>
Subject:Re: [SG15] Questions about wording and design intention for header units and ideas
On 5/21/23 9:48 PM, 许传奇(夜灯) wrote:
Hi Boris,
> The standard is pretty clear that an imported header does not "see"
any macros defined by the importer.
This is surprising to me. Where is the corresponding wording? I just searched 
the context and didn't find the wording. And if it is true, it implies that the following
transition is invalid, isn't it?
 I think the most applicable wording is [module.import]p5 <http://eel.is/c++draft/module.import#5 >. It defines how a header unit is constructed and, since it doesn't specify that the state of the preprocessor at the point of import is involved, that presumably means that it isn't. A note that contrasts that behavior with source file inclusion could be helpful.
```
// foo.h
#define FOO_H
// bar.h
#ifdef FOO_H
...
#else 
...
#endif
// user.orig.cpp
#include "foo.h"
#include "bar.h"
// user.cpp
import "foo.h";
import "bar.h";
```
Now we can't assume `user.cpp` isn't the same with `user.orig.cpp`. It is surprising since such patterns are
pretty common in practice. And I'm worrying that we'll meet problems if this is true.
 Yes, such patterns are fairly common. Headers that behave like bar.h should not be nominated as importable (and would ideally be diagnosed by implementations at import time as QoI). I don't know if we have wording that addresses this.
> I think these concerns should be addressed by SG15. An implementation dependent configuration file like you suggest is one way forward. Another would be for SG15 to specify a #pragma directive or magic comment (similar to the "-*- coding: <encoding name> -*-" comment that some editors recognize as an indication of source code character encoding; e.g. a "// importable-header" comment; I'm not suggesting this is a good idea).
I remember Iain had a similar idea. But this was rejected due to the intention of header units is to adopt module-like things easily without a touch to the existing code. But such ideas break such assumption. So maybe we can't decide if a header is importable header by changing its source code.
I think it is possible to diagnose an attempted import of a non-importable header algorithmically by recording in the BMI the macros that would have contributed to different preprocessor translation if set differently and comparing those to the macro state of the preprocessor at import time. I don't know if it would be reasonable to require implementations to do so though.
Tom.
Thanks,
Chuanqi
------------------------------------------------------------------
From:Boris Kolpackov <boris_at_[hidden]> <mailto:boris_at_[hidden] >
Send Time:2023 May 21 (Sun.) 16:56
To:Tom Honermann via SG15 <sg15_at_[hidden]> <mailto:sg15_at_[hidden] >
Cc:Chuanqi <chuanqi.xcq_at_[hidden]nc.com> <mailto:chuanqi.xcq_at_[hidden] >; Tom Honermann <tom_at_[hidden]> <mailto:tom_at_[hidden] >
Subject:Re: [SG15] Questions about wording and design intention for header units and ideas
 Just one to point out that the assumption in the motivating example
 (that started this discussion) is incorrect:
 > On 5/17/23 2:16 AM, "许传奇(夜灯)" <chuanqi.xcq_at_[hidden]> <mailto:chuanqi.xcq_at_[hidden] > wrote:
 >
 > > First, the motivation example:
 > > 
 > > ```
 > > // a.cpp
 > > import "foo.h";
 > > 
 > > // b.cpp
 > > #define M 43
 > > import "foo.h"
 > > ```
 > > 
 > > The question is, for build systems, how can they know if they should
 > > use the same BMI for these 2 imports. Since **currently** the build
 > > systems don't have a **good** method to know whether a macro is
 > > interesting to a specific file.
 The standard is pretty clear that an imported header does not "see"
 any macros defined by the importer.