On Wed, 10 Jul 2019 at 22:13, Tom Honermann <tom_at_[hidden]> wrote:
>
> On 7/10/19 3:11 PM, Ville Voutilainen wrote:
> > On Wed, 10 Jul 2019 at 22:09, Ville Voutilainen
> > <ville.voutilainen_at_[hidden]> wrote:
> >> On Wed, 10 Jul 2019 at 22:06, Tom Honermann <tom_at_[hidden]> wrote:
> >>
> >>> You are implying that the include translation is mandatory. Is that your argument?
> >>>
> >>> Yes. The wording in [cpp.include]p7 seems fairly clear regarding that.
> >> Not at all. "If the header identified by the header-name denotes an
> >> importable header" is implementation-defined. The set
> >> of importable headers is allowed to be whatever the implementation
> >> decides, including an empty set. The library specification
> >> might change that for some library headers, but in general, it doesn't
> >> seem to me that include translation is mandatory
> >> for #include. If you import a header, it must be importable, but
> >> #including it doesn't require that, based on what the spec says.
> > ..however, having said all that, it doesn't seem to me that you can
> > get to the problematic situation with a well-formed program,
> > either, because if the header isn't importable, importing it violates
> > a shall-requirement and is thus ill-formed, in Core-speak.
> > And if you can import it, #including it will also import it. Pardon
> > the possible confusion caused by the earlier.
>
> Exactly.

In other words, the response to "is your argument that include
translation is mandatory?" is "No." :)
Include translation is not mandatory, but since the problematic
situation arises with a combination
of an #include and an import, it can never arise if the header in
question is not importable, and if it
is importable, there's no problem. :P