Am 17.12.2022 um 00:10 schrieb Jens Maurer via Core:

On 16/12/2022 18.58, Gabriel Dos Reis via Core wrote:
In the SG15 telecon this morning, the issue of whether a named modules can bring in macros via re-exported header units was discussed.

The issue is that the current specification of module-import-declaration: 10.3/7 <>


When a /module-import-declaration/ <> imports a translation unit T, it also imports all translation units imported by exported /module-import-declaration/ <>/s/ in T; such translation units are said to be /exported/ <,exported> by T. <> Additionally, when a /module-import-declaration/ <> in a module unit of some module M imports another module unit U of M, it also imports all translation units imported by non-exported /module-import-declaration/ <>/s/ in the module unit purview of U. <>91 <> These rules can in turn lead to
the importation of yet more translation units. <>
This clearly refers to "translation units", and translation units are a phase 7 concept
per [lex.phases] p7:

"Whitespace characters separating tokens are no longer significant. Each preprocessing token is converted
into a token (5.6). The resulting tokens are syntactically and semantically analyzed and translated as a
translation unit."

At that point, macros simply don't exist anymore.

I support adding examples and notes, but I feel there is nothing normatively amiss.

places no restrictions on “it also imports all translation units imported by exported /module-import-declaration/ <>/s/ in T;”.

It was pointed out that there is a CWG issue


    [cpp.import] Example should demonstrate that module imports do not import macros · Issue #199 · cplusplus/CWG · GitHub <>
This is not a CWG issue; it's a request that a CWG issue be created,
once the chair feels like it.

I felt like it:

Please have a look whether you like my suggested resolution.

Thanks Jens for this swift action. I like it.


Core mailing list
Link to this post:

PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5