Jens Maurer <Jens.Maurer@gmx.net> writes:
> On 04/09/2018 06:29 PM, Boris Kolpackov wrote:
> > To summarize my understanding: in this proposal (but not in Modules TS)
> > all import declarations must come first, before any other declarations.
> (The Modules TS does not allow exporting macros from modules at all.)
Yes, but it doesn't require all import declarations to come at the start
of the translation unit. And import declarations in/out of module
purview have different semantics in the module interface unit. So in
my view this is just one of the artificial restrictions of the Atom
> > To me, personally, this feels like a bunch of artificial restrictions
> > to make something inherently broken kinda work.
> The subdivision of C++ translation unit text into a "module import header"
> and the rest, with different rules applied, certainly is a departure from
> current preprocessor style and C++ practice.
An even bigger departure, IMO, is having a preprocessor directive (import)
not starting with '#'.
I'm confused. Import is not a preprocessor directive?
> The question is: Would this approach address your build system concerns?
Theoretically -- yes. Practically -- hard to say since all the implications
will only become apparent once you start implementing it. But I think it's
pretty clear this will be a complex beast.
Of the top of my head I see two immediate issues:
1. The module dependency extraction will have to be supported by the
compilers since the semantics will have to be something like:
"Preprocess the import region and stop (we have to stop since
continuing preprocessing requires BMIs). Then parse the import
declarations and return the set of imported module names."
In fact, I don't even know if this can be implemented. Consider
import foo; // Exports FOO.
# error foo
How does the compiler know where the import region ends? The first
non-import declaration won't work as this example shows (we are
using the exported macro FOO which means we need the BMI). Something
hackish like "first non-import declaration or first mentioning of
an exported macro"? But then how do we know FOO is an exported
macro without loading the BMI?
In contrast, for Modules TS we were able to implement this with
zero support from the compilers since we could simply preprocess
the entire translation unit and then shallow-parse module-related
2. If one wants to provide proper (as in, part of the main build
phase) support for auto-generated headers (and we do in build2),
then we will need to extract header dependencies twice, first
time for the import region only and the second time for the
entire translation unit. Here is an example that illustrates
#include "config.h" // Auto-generated, defines TARGET_*.
So, again, we will need support from the compiler for this
(something like -M -fonly-for-import-region).
Also, it is not clear why we need to endure all this complexity. The
C++ community (our target audience) is pretty clear it doesn't want
modules dragged into the preprocessor (here is one example but
there are threads like this every time modules are discussed).
I'd question whether a reddit thread is speaking for the C++ community. There is a lot of legacy code that we want to be able to take into the future (including standard libraries), and for that I believe we need an incremental path forward that gives the build time savings without requiring a complete redesign of all code.
ourselves definitely don't need it either. So perhaps the compromise
could be to make macro exporting optional, for example, via the #import
directive (for macro-exporting modules) and the import declaration (for
the rest of us) with the former expanded into the latter (by the
Here is the whole thread:
Or see this fairly representative (and thoughtful) comment for TL;DR:
Tooling mailing list