On Fri, Aug 21, 2026 at 1:02 PM Jens Maurer via Std-Discussion <
std-discussion_at_[hidden]> wrote:

>
>
> On 8/21/26 02:30, Yehuda Bernáth via Std-Discussion 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].
>
> Fixed. https://cplusplus.github.io/CWG/issues/3220
>
> > 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?)
>
> Hm... Or we might want to restore the prior IFNDR provision.
>

It doesn't seem like a burden for implementations to just treat them as
different entities if they use strong ownership: the entities that are
attached to modules have the module name in their mangled names while
extern "C" entities have unmangled names, so they'll naturally never link
with each other.


>
> Jens
>
>
> >
> > On Fri, 21 Aug 2026 at 02:52, Brian Bi <bbi5291_at_[hidden] <mailto:
> bbi5291_at_[hidden]>> wrote:
> >
> > Thanks for pointing this out. There's now a CWG issue for it:
> https://cplusplus.github.io/CWG/issues/3220 <
> 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] <mailto: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] <mailto:
> Std-Discussion_at_[hidden]>
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion <
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion>
> >
> >
> >
> > --
> > /Brian Bi/
> >
> >
>
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>

-- 
*Brian Bi*