> 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]

On Mon, Sep 12, 2022 at 10:32 AM Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Sun, Sep 11, 2022 at 7:31 PM Zopolis0 via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > Got it, thanks. I've adjusted the draft to reflect this.
> >
> > In regards to the motivation and scope, I am also working on that, but
> this draft is only for getting your feedback on the modifications to the
> wording of the standard changes and similar.
>
> There's two problems with that. The first is that looking at the
> wording is unhelpful if it isn't clear what the feature is supposed to
> actually *do*. Standard wording is like programming; you can't
> effectively write a program to solve a problem if you can't even
> explain the problem in a normal, human language. And you certainly
> cannot debug someone else's program if they haven't explained what the
> program is supposed to accomplish. The same goes here: until it's
> clear what the wording is meant to *do*, having wording is just not
> helpful.
>
> Second, wording is secondary in the initial analysis. Most proposals
> don't have standard wording in their first version, as the purpose of
> that version is to establish that the feature is desired and the
> proposed shape of the feature is a good one. Similar to programming,
> it's useless to get into the details of debugging a program if you
> have yet to determine if the program actually does something that you
> want to do.
>
> Carts and horses work best in the traditional order.
>
> As to the wording itself, it's still very much in the domain of "you
> know what I mean, right?" This is the totality of your "wording":
>
> > A module-declaration with a namespace-name has behaviour equal to a
> module containing a namespace-definition with a namespace-body enclosing
> all exported functions.
>
> Standard wording needs to be *precise* and *specific*; this lacks both
> precision and specificity. For example, modules don't "contain"
> things; declarations and definitions reside in the purview of a
> module. Also, modules don't export "functions"; they export *names*.
> Do you really intend for this feature to only apply to functions?
>
> 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?
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>