This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 119e. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.

2026-05-01

2541. Linkage specifications, module purview, and module attachment

The interaction between linkage specifications (9.12 [dcl.link]) and named or global module purview and attachment (10.1 [module.unit]) is confusing. The addition of linkage declarations attaching their contents to the global module is not fully integrated into the wording and examples would also help.

• Module purview and attachment are not necessarily the same. This is never explicitly mentioned.
• 10.1 [module.unit] paragraph 7 explicitly calls out replaceable allocation and deallocation functions as being (implicitly) attached to the global module. This is unnecessary.
• 6.10.3.1 [basic.start.main] paragraph 1 specifies that there shall be a main function in the global namespace, but only in paragraph 3 do we specify that not attaching it to the global module is ill-formed.

Suggested resolution:

1. Change 6.10.3.1 [basic.start.main] paragraph 1 as follows:

   A program shall contain exactly one function called main that belongs to the global scope and is attached to the global module. Executing a program starts a main thread of execution (6.10.2 [intro.multithread], 32.4 [thread.threads]) in which the main function is invoked. It is implementation-defined whether a program in a freestanding environment is required to define a main function.

2. Change 10.1 [module.unit] bullet 7.2 as follows:

   • ...
   • Otherwise, if the declaration
     • is a replaceable global allocation or deallocation function (17.6.3.2 [new.delete.single], 17.6.3.3 [new.delete.array]), or
     • is a namespace-definition with external linkage, or
     • appears within a linkage-specification,
     it is attached to the global module.
   • Otherwise, ...

3. Add an example at the end of 10.1 [module.unit] paragraph 7:

   [ Example:

     // Translation unit #1
     export module Foo;
     void f();              // module linkage, attached to named module Foo
     extern "C++" {
       export void g();     // nameable by importers
       void h();            // nameable in Foo's purview
     }
   

   Both g and h have external linkage, are attached to the global module, and can thus also be redeclared in other translation units:

     // Legacy header "foo.h"
     extern "C++" void g();
   
     // Legacy header "foo-internal.h"
     extern "C++" void h();
   

   -- end example ]

   A module-declaration that contains neither...

4. Change in 10.2 [module.interface] paragraph 6 as follows:

   A redeclaration of an entity X is implicitly exported if X was introduced by an exported declaration; otherwise it shall not be exported unless it has external linkage..

Additional notes (May, 2026)

The first suggested change is semantically wrong, because it is selective, not restrictive. The second change was implemented by issue 2597. The fourth change is not motivated by the issue write-up.