On 7/10/19 3:18 PM, Corentin wrote:


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.