Thanks. Just a few comments regarding the suggested resolution:

   1. The first change is in 6.7 [basic.link], not 6.8 [basic.memobj].
   2. What about declarations that declare the same entity because of
   [decl.link]/7? Declarations with C linkage are always attached to the
   global module (because they appear within a linkage-specification), but
   what if the other declaration is of a global scope variable which is
   attached to a named module? The proposed wording would require the program
   to be ill-formed even if neither declaration is reachable from the other.
   (Maybe we should simply allow such cases and make them different entities?)


On Fri, 21 Aug 2026 at 02:52, Brian Bi <bbi5291_at_[hidden]> wrote:

> Thanks for pointing this out. There's now a CWG issue for it:
> https://cplusplus.github.io/CWG/issues/3220
>
> On Sat, Aug 15, 2026 at 3:44 PM Yehuda Bernáth via Std-Discussion <
> std-discussion_at_[hidden]> wrote:
>
>> [basic.link]/10 <https://eel.is/c++draft/basic.link#10> states:
>>
>>> As a consequence of these rules, all declarations of an entity are
>>> attached to the same
>>> module;
>>
>>
>> How does it follow from those rules? Paragraph 8
>> <https://eel.is/c++draft/basic.link#8> gives three cases where two
>> corresponding declarations with the same target scope declare the same
>> entity:
>>
>> 1. if they appear in the same translation unit,
>> 2. if they both declare aliases to the same type or namespace, *or*
>> 3. if they both have module or external linkage *and are attached to
>> the same module.*
>>
>> So only the case 3 is explicitly restricted to declaration that are
>> attached to the same module. In case 2 this is trivially true since aliases
>> are always attached to the global module. But what about case 1? Two
>> declarations in the same translation unit can easily be attached to
>> different modules if the TU is a module unit and one of them appears in the
>> global module fragment or inside a language linkage specifier, for example:
>>
>> module M;
>> int x;
>> extern "C++" int x;
>>
>> Or:
>>
>> module;
>> void f();
>> module M;
>> void f();
>>
>> Note 5 <https://eel.is/c++draft/basic.link#note-5> tries to address such
>> cases by saying:
>>
>>> If two declarations correspond but are attached to different modules,
>>> the program is ill-formed if one precedes the other ([basic.scope.scope]
>>> <https://eel.is/c++draft/basic.scope.scope>).
>>
>> But clause [basic.scope.scope] doesn't contain any rule that makes such
>> cases ill-formed. The only relevant paragraph there is 6
>> <https://eel.is/c++draft/basic.scope.scope#6>, which states:
>>
>>> Two declarations *potentially conflict* if they correspond and cause
>>> their shared name to denote different entities ([basic.link]
>>> <https://eel.is/c++draft/basic.link>). The program is ill-formed if, in
>>> any scope, a name is bound to two declarations A and B that potentially
>>> conflict and A precedes B ([basic.lookup]
>>> <https://eel.is/c++draft/basic.lookup>), unless B is name-independent.
>>
>> But for it to apply the two declarations need to already denote different
>> entities, and it explicitly refers to [basic.link] for the definition of
>> when that occurs. So it seems like nothing in the normative wording
>> prevents declarations of an entity from being attached to different
>> modules, making the statement in [basic.link]/10
>> <https://eel.is/c++draft/basic.link#10> false and the definition that
>> follows there ambiguous.
>> --
>> Std-Discussion mailing list
>> Std-Discussion_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>>
>
>
> --
> *Brian Bi*
>