I suspect eventually the toolchains and/or static analysis tools would
benefit from a standard way to declare the intention that a header be
importable. I expect certain kinds of antipatterns or even bugs could be
identified that way.

But I also suspect we can circle back to that idea after we have some
significant adoption and real-world experiences.

Bret

On Wed, Jul 27, 2022, 10:17 Gabriel Dos Reis via SG15 <sg15_at_[hidden]>
wrote:

> Thank you.
>
> -- Gaby
>
> ------------------------------
> *From:* SG15 <sg15-bounces_at_[hidden]> on behalf of Daniel Ruoso
> via SG15 <sg15_at_[hidden]>
> *Sent:* Wednesday, July 27, 2022 5:36:08 AM
> *To:* sg15_at_[hidden] <sg15_at_[hidden]>
> *Cc:* Daniel Ruoso <daniel_at_[hidden]>
> *Subject:* Re: [SG15] P1905 In-Source Mechanism to Identify Importable
> Headers
>
> On Wed, Jul 27, 2022, 05:50 Corentin via SG15 <sg15_at_[hidden]>
> wrote:
>
> I think it's something we ought to explore, if only for the sake of
> ahead-of-time scanning build systems.
>
>
> I have gotten to the conclusion that it's actually a good thing that
> importable headers are indistinguishable from the source code alone.
>
> Essentially, from the build system perspective, an importable header needs
> all the same semantics that named modules do, including the need for
> additional metadata (such as preprocessor arguments) as well as the ability
> to reuse BMI files.
>
> For that reason, I think importable modules will always need to be
> explicitly identified by the build system either when they're in the same
> project, but even more when importable headers are shared with a pre-built
> library.
>
> IOW, just knowing that a header is importable is not sufficient, the same
> way that just knowing that a module interface exists is not sufficient.
>
> Daniel
>
>
>
>
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>