On Wed, 10 Jul 2019 at 21:11, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
On Wed, 10 Jul 2019 at 22:09, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
>
> On Wed, 10 Jul 2019 at 22:06, Tom Honermann <tom@honermann.net> 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.