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

2024-11-11

2541. Linkage specifications, module purview, and module attachment

The interaction between linkage specifications (9.11 [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.9.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.9.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.9.2 [intro.multithread], 33.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..