Yeah, one of the recognized strengths of C++ is that it doesn't leave all
of the legacy code behind, generally speaking. One of the reasons I don'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.

It's easy to design on a clean slate. It's harder to make that design
useful by making it fit in with the existing ecosystem. It's harder still
to make the design also deployable without requiring a wholly new project
before it can be used productively.

On Wed, Apr 11, 2018 at 4:21 AM Manuel Klimek <klimek_at_[hidden]> wrote:

> On Wed, Apr 11, 2018 at 7:31 AM Boris Kolpackov <boris_at_[hidden]>
> wrote:
>
>> Jens Maurer <Jens.Maurer_at_[hidden]> 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
>> proposal.
>>
>>
>> > > 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
>> this example:
>>
>> import foo; // Exports FOO.
>>
>> #ifndef FOO
>> # error foo
>> #endif
>>
>> 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
>> declarations.
>>
>> 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
>> the problem:
>>
>> #include "config.h" // Auto-generated, defines TARGET_*.
>>
>> #ifdef TARGET_WINDOWS
>> import support.windows;
>> #else
>> import support.unix;
>> #endif
>>
>> 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[1] 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.
>
>
>> We
>> 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
>> preprocessor)?
>>
>> [1]
>>
>> Here is the whole thread:
>>
>>
>> https://www.reddit.com/r/cpp/comments/854mu9/2018_jacksonville_iso_c_committee_reddit_trip/dvuqz0d/
>>
>> Or see this fairly representative (and thoughtful) comment for TL;DR:
>>
>>
>> https://www.reddit.com/r/cpp/comments/854mu9/2018_jacksonville_iso_c_committee_reddit_trip/dvuy0i2/
>>
>>
>> Boris
>> _______________________________________________
>> Tooling mailing list
>> Tooling_at_[hidden]
>> http://www.open-std.org/mailman/listinfo/tooling
>>
> _______________________________________________
> Tooling mailing list
> Tooling_at_[hidden]
> http://www.open-std.org/mailman/listinfo/tooling
>