Date: Mon, 13 Mar 2023 13:20:09 -0400
On Mon, Mar 13, 2023 at 1:16 PM Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> On Mon, Mar 13, 2023 at 11:47 AM Andrey Semashev via Std-Proposals
> <std-proposals_at_[hidden]> 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
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
std-proposals_at_[hidden]> wrote:
> On Mon, Mar 13, 2023 at 11:47 AM Andrey Semashev via Std-Proposals
> <std-proposals_at_[hidden]> 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
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
-- *Brian Bi*
Received on 2023-03-13 17:20:50