On Thu, Aug 20, 2026 at 8:31 PM Yehuda Bernáth <yehudamber_at_[hidden]> wrote:

> Thanks. Just a few comments regarding the suggested resolution:
>
> 1. The first change is in 6.7 [basic.link], not 6.8 [basic.memobj].
>
> This appears to be already fixed.

>
> 1. 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?)
>
> I agree with the idea that they should be 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*
>>
>

-- 
*Brian Bi*