Em qua., 24 de mai. de 2023 às 00:40, Corentin Jabot via SG15
<sg15_at_[hidden]> escreveu:
> But, let's entertain for a minute that the only importable headers that exist in a projet were standard library headers. We might find that this would be enough to justify the feature, and it's a more tractable problem.

It would solve the dependency-chain problem, since the build system
would be able to just pre-generate the BMIs for the standard library
headers and move on from there. However, I suspect this is not really
an appealing solution for most folks.

> Or maybe, as you say, they work great in mono repos and less so in collections of small projects playing fast and loose with ODR (which is what inconsistent flags open the door to). That again is enough to justify the feature for some project.

Right. I agree with that. However, the difference is that currently
the semantics of `import <header>` *require* the build system to
support this. Which is why I'm advocating that we need to walk back
the spec for importable headers such that it becomes clear that this
is an optimization and that source inclusion is still a valid
interpretation of the code.

> So then maybe the question is whether import as a keyword is justified, as it forces header units on projects that would rather ignore them, and maybe that's a problem?

Correct.

> Maybe having only include rewrite of a list of importable headers (which you could elect to keep empty) offers a more generally applicable migration path, than addition exposing an import grammar to users ( for importable headers)

That's the direction I'm pointing at, yes.

daniel