On 7/10/19 3:18 PM, Corentin wrote:
>
>
> On Wed, 10 Jul 2019 at 21:11, Ville Voutilainen
> <ville.voutilainen_at_[hidden] <mailto:ville.voutilainen_at_[hidden]>> wrote:
>
> On Wed, 10 Jul 2019 at 22:09, Ville Voutilainen
> <ville.voutilainen_at_[hidden] <mailto:ville.voutilainen_at_[hidden]>>
> wrote:
> >
> > On Wed, 10 Jul 2019 at 22:06, Tom Honermann <tom_at_[hidden]
> <mailto: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.
>
>
>
> The situation arises if the implementation assumes imported headers
> are importable (aka import <foo> implies foo is importable).
> Are we saying this is not a good implementation strategy?

I would say that such an implementation strategy is not valid given the
existing wording (and my understanding of the intent of the wording from
various discussions).

Tom.