On Sun, Sep 11, 2022 at 8:46 PM Zopolis0 via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> > How does this relate to other module units that comprise that module?
> > Like, if you have one module unit with a "namespace-definition" and
> > another unit within the same module without that definition, or with a
> > *different* "namespace-definition", how is that supposed to work?
>
> > What happens if you put this on a module implementation unit? After
> > all, implementation units cannot export things. So do names exist in
> > this namespace or not? If an interface unit has a
> > "namespace-definition" and exports some name, does that mean that an
> > implementation unit that defines it needs to explicitly use the
> > namespace when defining it?
>
> See the note:
> + [Note 2: Only the primary module interface unit of any given module
> + can contain a namespace-name. -- end note]

That's *not* how notes work! Notes are non-normative; the standard
would say the same thing if you took them all out. Notes like that are
for saying something in one place that is defined elsewhere, so that
readers don't have to go track down where that gets said.

You didn't mention that in text that matters, so it doesn't exist.

Furthermore, that raises more questions. A module implementation unit
that is a partition need not include the primary module interface it
is a part of. Indeed, the primary module interface unit may not have
even been *compiled* yet. So how exactly is the compiler supposed to
know what gets defined in a module unit that isn't being imported?

Equally importantly, module units are supposed to be *independent* of
one another, outside of explicit importation. And importation is not
equivalent to textual inclusion. By all rights, a build system ought
to be able to compile an interface partition without having to know
anything in the primary interface unit it is a partition of. So again,
how exactly is the compiler supposed to know about what gets defined
in the primary interface unit?