On Wed, Sep 14, 2022 at 10:19 PM Zopolis0 via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> > So what is your intent here? Should `strob`'s implementation be able
> > to use the unqualified name `frob` to refer to `foo::frob`? Or should
> > it be able to use the unqualified name only if the definition is in
> > the interface file that exported `frob`? Or should all uses of it need
> > full qualification?
> All uses of it need full qualification. Again, exported names from a method declaration with a namespace-name have an implied namespace block wrapping them.
>
> > Is breaking ADL in these cases something that you *intend* to do?
> In brief, yes.
>
> > Do you genuinely intend for two declarations side-by-side that are
> > *visually* at the same scope to not actually be in the same scope?
>
> Yes. I see no other way to not drastically break with namespace convention and also preserve the core purpose of this proposal.

And finally, we come to the fundamental issue: why do we *want* "the
core purpose of this proposal?"

You admit that it breaks namespace convention, but you don't seem to
recognize what that really means. My version was intended to preserve
a very simple fact of C++ as it currently stands:

If two names are declared in the same scope, they're in the same
namespace and will interact with each other in predictable ways.

That is a simple rule. And you want to make it more complicated.

Why?

What do we *gain* by making a simple system more complicated? Why is
"the core purpose of this proposal" a thing worth having in the
language?

I'm particularly stuck on your bizarre design decision to require that
non-exported names not be in the same namespace as exported names. You
keep wanting this to be the case, but there seems to be no reason why
it *needs* to be. The closest thing I can see to a reason for this
notion is that if it weren't so, if they were all in the same
namespace...

We would tell you to just stick two curly braces in the file and leave
the language alone.

This entire proposal seems to exist because you don't want to put two
curly braces in your files.

My final advice to you is to not bother wasting the committee's time
with this thing. Just put the curly braces in your file and move on
with your life. Scoping is a thing, and C++ is not going to throw it
away to save you some keystrokes and indentation.