Hi,
> Any specific suggestions here?
I feel the statements in the mail is pretty clear (maybe we need to rewrite it to make it looks like standard more):
> Header units do not depend on the preprocessor state at
the location where the "import" appears.

---
> Note that this says "implementation-defined, with a minimum supported set".
>
> So, your first go-to point to determine that set is your vendor documentation,
not the standard.
Yeah, my logic here is that both you and Tom think the header "bar.h" should not be importable without talking about specific implementation according to a paragraph in the standard. So there should be a statement in the standard to make it clear. Also, personally, "implementation-defined" is not completely equal to "we don't care what headers can be importable". For example, [module.import]/p6 (http://eel.is/c++draft/module.import#6 <http://eel.is/c++draft/module.import#6 >) says:
> A header unit shall not contain a definition of a non-inline function or variable whose name has external linkage.
So my interpretation is "although we don't define what importable header is, we still have some rules for header units."
Thanks,
Chuanqi
------------------------------------------------------------------
From:Jens Maurer <jens.maurer_at_[hidden]>
Send Time:2023 May 24 (Wed.) 17:07
To:sg15 <sg15_at_[hidden]>; Tom Honermann <tom_at_[hidden]>; Boris Kolpackov <boris_at_[hidden]>
Cc:Chuanqi <chuanqi.xcq_at_[hidden]>
Subject:Re: [SG15] Questions about wording and design intention for header units and ideas
On 24/05/2023 08.45, 许传奇(夜灯) via SG15 wrote:
> 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.
Any specific suggestions here?
Note that this says "implementation-defined, with a minimum supported set".
So, your first go-to point to determine that set is your vendor documentation,
not the standard.
Also note that header units are intended as a transitional feature, thus
giving a bit more leeway to the implementation in that area might be a
good idea.
> 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.
Header units do not depend on the preprocessor state at
the location where the "import" appears.
If that's not what you thought the feature would deliver, please
review the papers leading to the current design in the standard,
and feel free to submit a paper seeking improvements to EWG.
Jens