Excellent, thank you all! I hope this would really get fixed.

On Fri, Aug 21, 2026, 10:58 PM Jens Maurer <jens.maurer_at_[hidden]> wrote:

>
>
> On 8/21/26 21:52, Brian Bi wrote:
> >
> >
> > On Fri, Aug 21, 2026 at 1:02 PM Jens Maurer via Std-Discussion <
> std-discussion_at_[hidden] <mailto: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 <
> 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.
>
> Yeah. Applied that:
>
> https://cplusplus.github.io/CWG/issues/3220
>
> Jens
>
>
> >
> >
> > Jens
> >
> >
> > >
> > > On Fri, 21 Aug 2026 at 02:52, Brian Bi <bbi5291_at_[hidden] <mailto:
> bbi5291_at_[hidden]> <mailto: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> <
> 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]> <mailto:std-discussion_at_[hidden]
> <mailto:std-discussion_at_[hidden]>>> wrote:
> > >
> > > [basic.link]/10 <https://eel.is/c++draft/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 <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 <
> 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 <
> 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 <
> 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 <
> 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 <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 <
> 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]> <mailto: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> <
> 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] <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/
>
>