> This means that by the time you get to your `export-declaration`,
> there must have already been a `module-declaration`, which specified
> the `module-name`.

I don't see what you mean here.
Are you saying that this is invalid:

export module foo;
//do_stuff
export void things {}

Because I use that in my code already.
What I am proposing, in short, is to make this valid

export module foo namespace bar
//do_stuff
export void things {}

I don't see how this is a significant deviation from the standard.

On Fri, Sep 9, 2022 at 12:16 AM Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Thu, Sep 8, 2022 at 6:01 AM Zopolis0 via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > > This is a claim made without any evidence that such a thing (using
> > > namespaces "without wrapping files in namespace blocks") is even
> > >*desireable* let alone something worthy of a language change.
> >
> > I'm not sure how to give "evidence" that something is desirable.
>
> There are plenty of ways.
>
> For example, you can show some example code of what you have to do
> now, then show example code of what your language feature would allow.
> You can then, in the text below, highlight what you consider to be
> deficiencies in the former which the latter resolves. And most
> importantly, you can highlight *why* you consider them to be
> deficient, what features of the status quo cause certain problems and
> what makes those things problems.
>
> The committee didn't add concepts or structured bindings or lambdas to
> the language because they had some personal dislike for the current
> ways to achieve things. They added them because the current ways to do
> them were very complicated, easy to get wrong, confusing to look at,
> and/or otherwise problematic. And they could substantiate all of those
> positions by showing what code looked like before and after the change
> and making arguments based on them.
>
> For example:
>
> ```
> auto some_tuple = func();
> std::get<2> (some_tuple).stuff;
> ```
>
> to
>
> ```
> auto [name0, name1, name2] = func();
> name2.stuff;
> ```
>
> Now, the difference seems clear, but there are particulars that can be
> highlighted. The first one has a lot of syntactic noise (`get<2>`,
> extra parens, etc) that doesn't really mean much for the programmer.
> It has the number `2`, the exact meaning of which is unclear. Yes, it
> means to get the 3rd member of the tuple, but what that member
> actually represents is unclear.
>
> By contrast, the second one has little noise, and `name2` can be
> descriptive of the meaning of the object rather than a bare number.
>
> These are arguments that one can read and agree with or disagree with.
> They're not purely personal preferences; they highlight specific flaws
> in the original.
>
> At the end of the day, simply saying that the status quo is bad is
> unhelpful. Words like "easy" or "hard", "clear" or "simple", etc are
> way too subjective. Unless the difference between the two pieces of
> code is obvious, you need something more than personal preference to
> justify why your suggestion is an improvement.
>
> > Feedback on the wording and formatting of the paper. Is that so hard?
>
> Well, the *content* of the wording is sufficiently lacking that the
> wording and formatting is largely irrelevant. It's like asking someone
> to comment on the quality of the concrete in a pile of rubble.
>
> However, if you want commentary on the particulars of the standard
> wording, it's rather like the motivation section: thin and threadbare,
> relying on a lot of "you know what I mean" rather than spelling things
> out.
>
> There are two things I would like to highlight in this regard.
>
> The first is the introduction sentence, probably the *most important*
> sentence in your proposal:
>
> > This paper proposes to allow the establishment of namespace scopes in an
> export-declaration and define a syntax for doing so.
>
> Um... what does that *mean*?
>
> I know what that means only because we've had interactions on this
> mailing list where you explain what you're trying to do. But if I had
> no idea what you're trying to do, I would have no idea what that
> entails.
>
> We already have a syntax wherein an `export-declaration` can
> "establish" a "namespace scope":
>
> ```
> export namespace my_namespace
> {
> }
> ```
>
> That is an `export-declaration` and it establishes a namespace scope.
> All names declared within that scope will be exported.
>
> My understand of what you mean for your feature to do is to shove
> every subsequent declaration into the scope of that namespace without
> putting the code in the scope of the namespace with curly braces.
>
> But that's not what your sentence describes. In standard-speak, I
> believe that what you want to do is to create a declarative region
> from that declaration to the end of the file into which all declared
> names are members of that namespace.
>
> Even if that's the intent, the introduction section isn't the place to
> say it in standard-speak. The introduction is where you describe what
> it looks like in C++ layman's terms, not in standard-speak. Your
> feature seems to be about making names a member of a namespace without
> actually putting them in a namespace declaration. So your introduction
> should probably bring that up, since that's the point of the feature.
>
> For the second, consider this key sentence:
>
> > An export-declaration containing a module-name and a namespace-name
> establishes a named module according to the module-name and establishes and
> exports a namespace-scope according to the namespace-name.
>
> It is very unclear what this does, and unclear if an
> `export-declaration` is even the right tool to use to do it.
>
> What does it mean to "establish a named module"? The word "establish"
> tends to be used around scopes, but modules aren't scoped. Do you mean
> that such an `export-declaration` means that the translation unit is a
> module unit in the module identified by `module-name`?
>
> If so, that's the job of a `module-declaration`, not an
> `export-declaration`. It is *very important* in C++ modules that the
> `module-declaration` comes early in the file. The point being that
> tools can easily tell if a file is a module unit by scanning it and
> seeing if you encounter any actual C++ before finding a
> `module-declaration` or a `global-module-fragment` section.
>
> This means that by the time you get to your `export-declaration`,
> there must have already been a `module-declaration`, which specified
> the `module-name`. So what happens if the current module unit's
> `module-name` is different from the one specified by this special
> `export-declaration`:
>
> ```
> module my_name;
>
> export different_name some_namespace;
> ```
>
> So let's assume you meant that this is part of a `module-declaration`
> instead. But every `module-declaration` of the form `export module
> module-name` is an *interface* unit, not an implementation unit. So
> you can't even use your feature in module implementation units.
>
> Also, it's not clear what it means to "export a namespace-scope".
> Currently, the standard doesn't export "scopes"; it exports names,
> which may be declared *within* a scope. So, what is the scope whose
> declarations are being exported? Does this mean that every `namespace
> X{}` scope from that point forward will export its declarations as
> though it were written as `export namespace X{}`?
>
> Lastly, from your previous thread and the comments here, I gather that
> you want to avoid putting declarations into a namespace by using
> regular C++ syntax. That is `namespace X {declarations}`. If you mean
> for all `declarations` to implicitly and automatically be part of some
> namespace, nothing in your wording causes that to happen.
> [basic.namespace.scope] establishes what names are inside of a
> namespace and what names are not. So if you intend for your feature to
> change how that works, it needs to change stuff in there.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>