On Mon, Mar 13, 2023 at 1:16 PM Jason McKesson via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
On Mon, Mar 13, 2023 at 11:47 AM Andrey Semashev via Std-Proposals
<std-proposals@lists.isocpp.org> wrote:
> On 3/13/23 18:14, Thiago Macieira via Std-Proposals wrote:
> > On Monday, 13 March 2023 05:00:13 PDT Andrey Semashev via Std-Proposals wrote:
> >> It would seem not fundamentally different from other
> >> contexts, like within a function body
> >
> > Because they are fundamentally different.
> Could you clarify in what way?

Declarations do very different things when they are in a class vs. not
in a class. The declaration `void foo();` declares a function... or a
*member* function. These are very different entities, one which
affects the very type that the expression `&foo` will generate.

`using name;` behaves differently as well. Outside of a class, that
will... do nothing actually, since `name` already has to be accessible
without qualification at that scope to work. By contrast, inside a
class, it means that any base class `name`s will be available as part
of the derived class with unqualified lookup. If `name` is not a
member of a base class, you get a compile error.

So yes, in C++, "in a class" is a fundamentally different thing from
"not in a class".

In any case, this is one of those cases where I feel like liberal use
of modules will basically make the problem go away. The main reason to
want to put `using namespace` in a class is just to keep the scope
from leaking out everywhere. With modules, they're restricted to a
particular TU, and importing that module will not import the `using
namespace` declaration.

So this feature would be increasingly less useful going forward.

And yet, you can have multiple classes in a module, and perhaps one of them will want to `using namespace X` and another will want to `using namespace Y` and putting both of those using-directives at namespace scope would cause conflicts.

Anyway, I suspect the reason why you can't have using-directives (or using-declarations naming anything other than a member of a base class) in class scope has to do with not wanting to create new unforeseen issues with name lookup; that said, I don't think there's any fundamental reason why it can't be done. The main question for the author of a proposal such as this is: given that we've lived without this feature since 1998, why do we need it badly enough now to be worth spending committee time on?
Std-Proposals mailing list

Brian Bi