<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Apr 11, 2018 at 7:31 AM Boris Kolpackov <<a href="mailto:boris@codesynthesis.com">boris@codesynthesis.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Jens Maurer <<a href="mailto:Jens.Maurer@gmx.net" target="_blank">Jens.Maurer@gmx.net</a>> writes:<br>
<br>
> On 04/09/2018 06:29 PM, Boris Kolpackov wrote:<br>
><br>
> > To summarize my understanding: in this proposal (but not in Modules TS)<br>
> > all import declarations must come first, before any other declarations.<br>
><br>
> (The Modules TS does not allow exporting macros from modules at all.)<br>
<br>
Yes, but it doesn't require all import declarations to come at the start<br>
of the translation unit. And import declarations in/out of module<br>
purview have different semantics in the module interface unit. So in<br>
my view this is just one of the artificial restrictions of the Atom<br>
proposal.<br>
<br>
<br>
> > To me, personally, this feels like a bunch of artificial restrictions<br>
> > to make something inherently broken kinda work.<br>
><br>
> The subdivision of C++ translation unit text into a "module import header"<br>
> and the rest, with different rules applied, certainly is a departure from<br>
> current preprocessor style and C++ practice.<br>
<br>
An even bigger departure, IMO, is having a preprocessor directive (import)<br>
not starting with '#'.<br></blockquote><div><br></div><div>I'm confused. Import is not a preprocessor directive?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> The question is: Would this approach address your build system concerns?<br>
<br>
Theoretically -- yes. Practically -- hard to say since all the implications<br>
will only become apparent once you start implementing it. But I think it's<br>
pretty clear this will be a complex beast.<br>
<br>
Of the top of my head I see two immediate issues:<br>
<br>
1. The module dependency extraction will have to be supported by the<br>
compilers since the semantics will have to be something like:<br>
<br>
"Preprocess the import region and stop (we have to stop since<br>
continuing preprocessing requires BMIs). Then parse the import<br>
declarations and return the set of imported module names."<br>
<br>
In fact, I don't even know if this can be implemented. Consider<br>
this example:<br>
<br>
import foo; // Exports FOO.<br>
<br>
#ifndef FOO<br>
# error foo<br>
#endif<br>
<br>
How does the compiler know where the import region ends? The first<br>
non-import declaration won't work as this example shows (we are<br>
using the exported macro FOO which means we need the BMI). Something<br>
hackish like "first non-import declaration or first mentioning of<br>
an exported macro"? But then how do we know FOO is an exported<br>
macro without loading the BMI?<br>
<br>
In contrast, for Modules TS we were able to implement this with<br>
zero support from the compilers since we could simply preprocess<br>
the entire translation unit and then shallow-parse module-related<br>
declarations.<br>
<br>
2. If one wants to provide proper (as in, part of the main build<br>
phase) support for auto-generated headers (and we do in build2),<br>
then we will need to extract header dependencies twice, first<br>
time for the import region only and the second time for the<br>
entire translation unit. Here is an example that illustrates<br>
the problem:<br>
<br>
#include "config.h" // Auto-generated, defines TARGET_*.<br>
<br>
#ifdef TARGET_WINDOWS<br>
import support.windows;<br>
#else<br>
import support.unix;<br>
#endif<br>
<br>
So, again, we will need support from the compiler for this<br>
(something like -M -fonly-for-import-region).<br>
<br>
<br>
Also, it is not clear why we need to endure all this complexity. The<br>
C++ community (our target audience) is pretty clear it doesn't want<br>
modules dragged into the preprocessor (here is one example[1] but<br>
there are threads like this every time modules are discussed).</blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> We<br>
ourselves definitely don't need it either. So perhaps the compromise<br>
could be to make macro exporting optional, for example, via the #import<br>
directive (for macro-exporting modules) and the import declaration (for<br>
the rest of us) with the former expanded into the latter (by the<br>
preprocessor)?<br>
<br>
[1]<br>
<br>
Here is the whole thread:<br>
<br>
<a href="https://www.reddit.com/r/cpp/comments/854mu9/2018_jacksonville_iso_c_committee_reddit_trip/dvuqz0d/" rel="noreferrer" target="_blank">https://www.reddit.com/r/cpp/comments/854mu9/2018_jacksonville_iso_c_committee_reddit_trip/dvuqz0d/</a><br>
<br>
Or see this fairly representative (and thoughtful) comment for TL;DR:<br>
<br>
<a href="https://www.reddit.com/r/cpp/comments/854mu9/2018_jacksonville_iso_c_committee_reddit_trip/dvuy0i2/" rel="noreferrer" target="_blank">https://www.reddit.com/r/cpp/comments/854mu9/2018_jacksonville_iso_c_committee_reddit_trip/dvuy0i2/</a><br>
<br>
<br>
Boris<br>
_______________________________________________<br>
Tooling mailing list<br>
<a href="mailto:Tooling@isocpp.open-std.org" target="_blank">Tooling@isocpp.open-std.org</a><br>
<a href="http://www.open-std.org/mailman/listinfo/tooling" rel="noreferrer" target="_blank">http://www.open-std.org/mailman/listinfo/tooling</a><br>
</blockquote></div></div>