[Daniel]
> My take at this point is that we should remove the `import <header>`
> format, and simplify the specification such that it is understood
> strictly as an optional optimization, which is what both Clang and
> MSVC are doing.

As you probably know, I am not a big fan of removing functionalities (from the standards) that took painstaking conversations to arrive at, with reasonable compromise.
We have to foster and operate in an environment where people are encouraged to seek solutions that work reasonably well for the larger community without fearing that once they agreed to a compromise, the next move is that they will see their parts of the compromise removed. (That has happened in the past, and I really really want us not to make it a habit.)

Yes, header units are painful to implement usefully (more so than named modules by an order of magnitude) in both the compiler and build systems, but they can be made to work (based on in-the-field experience we've accumulated at Microsoft). My team and I have been working to reach the best experience that can possibly be offered; the work is not perfect in its current state, but we will get there. We are most happy to share our learnings (e.g. as we did at CppCon 2021).

I would have strong reservations about any proposal to remove header units (not because I love them, but because of the principle I outlined above).

From my perspective, a key question is: ignoring bugs in exiting implementations (I am aware that MSVC's dependency scanner has a couple of embarrassing bugs), what else needs refinement in the existing spec? We don't have a formal definition of "modular header", and I doubt we can have one that is useful for the larger C++ community without appealing to some form of "implementation-defined".

Saying "header units are an optimization" doesn't automatically remove the onus from the user to audit and/sanitize their source code if they desire to benefit from the header unit functionality. So, even if WG21 somehow arrived at the consensus of removing header units, the underlying problem would still be there.

And finally, please don’t get me wrong: I do appreciate and value your initiatives and leadership in getting the tooling ecosystem make practical progress on this topic, in a way that offers the same experience across platforms and compilers.

-- Gaby


-----Original Message-----
From: Daniel Ruoso <daniel_at_ruoso.com>
Sent: Wednesday, May 24, 2023 6:54 AM
To: Gabriel Dos Reis <gdr_at_microsoft.com>
Cc: sg15_at_[hidden]; Tom Honermann <tom_at_honermann.net>
Subject: Re: [SG15] P2898R0: Importable Headers are Not Universally Implementable

Em qua., 24 de mai. de 2023 às 07:44, Gabriel Dos Reis
<gdr_at_[hidden]> escreveu:
> The MSVC implementation of the spec is that what #include to translate to import comes from a user specified list, either explicitly or implicitly through the provision of BMI mapping.

My take at this point is that we should remove the `import <header>`
format, and simplify the specification such that it is understood
strictly as an optional optimization, which is what both Clang and
MSVC are doing.

I agree with the sentiment that we need a well-defined behavior for
that optimization. But I'm convinced this should be optional and that
the source inclusion behavior should continue to be considered
correct, such that the code is still valid whenever the use of that
optimization is not advantageous.

daniel