Title
Codify the strong ownership for modules
Status
ready
Section
6.7 [basic.link]
Submitter
FR

Created on 2025-07-25.00:00:00 last changed 1 week ago

Messages

Date: 2026-03-26.13:49:04

Proposed resolution (approved by CWG 2026-03-26):

  1. Change in 6.7 [basic.link] paragraph 8 as follows:

    Two declarations of entities declare the same entity if, considering declarations of unnamed types to introduce their names for linkage purposes, if any (9.2.4 [dcl.typedef], 9.8.1 [dcl.enum]), they correspond (6.4.1 [basic.scope.scope]), have the same target scope that is not a function or template parameter scope, neither is a name-independent declaration, and either
    • they appear in the same translation unit, or
    • they both declare type aliases or namespace aliases that have the same underlying entity, or
    • they both declare names with module or external linkage and are attached to the same module, or.
    • they both declare names with external linkage.
    [Note 3: There are other circumstances in which declarations declare the same entity (9.12 [dcl.link], 13.6 [temp.type], 13.7.6 [temp.spec.partial]). —end note]
  2. Change in 6.7 [basic.link] paragraph 10 as follows:

    [ Note: If two declarations of an entity correspond but are attached to different modules, the program is ill-formed; no diagnostic is required if neither is reachable from one precedes the other (6.4.1 [basic.scope.scope]) -- end note ] . [Example 2:
      "decls.h":
        int f();  // #1, attached to the global module
        int g();  // #2, attached to the global module
    
      Module interface of M:
    
      module;
      #include "decls.h"
      export module M;
      export using ::f;  // OK, does not declare an entity, exports #1
      int g();           // error: matches corresponds to #2, but attached to M
      export int h();    // #3
      export int k();    // #4
    
      Other translation unit:
    
      import M;
      static int h();    // error: matches conflicts with #3
      int k();           // error: matches conflicts with #4 
    
Date: 2025-07-25.00:00:00
N5028 comment US 17-030
N5028 comment FR 003-031

All C++ implementations have converged on "strong ownership" of modules, with none planning to implement "weak ownership". This disposition no longer serves any purpose other than removing certainty.

History
Date User Action Args
2026-03-26 13:37:53adminsetmessages: + msg8522
2025-07-25 00:00:00admincreate