<div dir="ltr">Yeah, one of the recognized strengths of C++ is that it doesn&#39;t leave all of the legacy code behind, generally speaking. One of the reasons I don&#39;t participate in design and evolution discussions on reddit is that the crowd there seems pretty one-sided on the question of what to do with legacy.<div><br></div><div>It&#39;s easy to design on a clean slate.  It&#39;s harder to make that design useful by making it fit in with the existing ecosystem. It&#39;s harder still to make the design also deployable without requiring a wholly new project before it can be used productively.</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Apr 11, 2018 at 4:21 AM Manuel Klimek &lt;<a href="mailto:klimek@google.com">klimek@google.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Apr 11, 2018 at 7:31 AM Boris Kolpackov &lt;<a href="mailto:boris@codesynthesis.com" target="_blank">boris@codesynthesis.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Jens Maurer &lt;<a href="mailto:Jens.Maurer@gmx.net" target="_blank">Jens.Maurer@gmx.net</a>&gt; writes:<br>
<br>
&gt; On 04/09/2018 06:29 PM, Boris Kolpackov wrote:<br>
&gt;<br>
&gt; &gt; To summarize my understanding: in this proposal (but not in Modules TS)<br>
&gt; &gt; all import declarations must come first, before any other declarations.<br>
&gt;<br>
&gt; (The Modules TS does not allow exporting macros from modules at all.)<br>
<br>
Yes, but it doesn&#39;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>
&gt; &gt; To me, personally, this feels like a bunch of artificial restrictions<br>
&gt; &gt; to make something inherently broken kinda work.<br>
&gt;<br>
&gt; The subdivision of C++ translation unit text into a &quot;module import header&quot;<br>
&gt; and the rest, with different rules applied, certainly is a departure from<br>
&gt; current preprocessor style and C++ practice.<br>
<br>
An even bigger departure, IMO, is having a preprocessor directive (import)<br>
not starting with &#39;#&#39;.<br></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>I&#39;m confused. Import is not a preprocessor directive?</div></div></div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
&gt; 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&#39;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>
   &quot;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.&quot;<br>
<br>
   In fact, I don&#39;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&#39;t work as this example shows (we are<br>
   using the exported macro FOO which means we need the BMI). Something<br>
   hackish like &quot;first non-import declaration or first mentioning of<br>
   an exported macro&quot;? 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 &quot;config.h&quot; // 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&#39;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></div><div dir="ltr"><div class="gmail_quote"><div>I&#39;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><div dir="ltr"><div class="gmail_quote"><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&#39;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>
_______________________________________________<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>