On 04/09/2018 06:29 PM, Boris Kolpackov wrote:
> Tom Honermann <tom_at_[hidden]> writes:
>
>> No, that would not be possible. The "Another take on Modules" proposal
>> [1] explicitly guards against this; see section 3.3 (Preprocessor impact).
>
> Thanks for the pointer.
>
> To summarize my understanding: in this proposal (but not in Modules TS)

(The Modules TS does not allow exporting macros from modules at all.)

> all import declarations must come first, before any other declarations.

Yes.

> Then the proposal "disables" expansion of exported macros in this
> import region. The build system can then discover the import set by
> somehow only preprocessing this import region and stopping (it still
> has to preprocess since the use of non-module-exported macros and,

That's my understanding.

> presumably, #include's in this region is valid).

Only if those #includes contain nothing but "import"s (if valid at all),
I'd guess.
 
> 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.

The question is: Would this approach address your build system concerns?

Jens