I suggest that when an alias for an enum is created in a
different scope, whether with "typedef" or "using", all of
the enum members should also be aliased in that
(different) scope. This would make the following legal.

namespace Foo
{
enum A { a1, a2 };
enum B { b1, b2 };
}

namespace Bar
{
using Foo::A;
typedef Foo::B B2;
}

Bar::A a = Bar::a1;
Bar::B2 b = Bar::b1;

I'd suggest the implicit aliasing of an enum member be
blocked by a conflicting declaration in the aliasing scope,
or when there would be a multiple implicit aliases for
the member from different enums aliased in a scope.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

wkaras@yahoo.com ha scritto:
> I suggest that when an alias for an enum is created in a
> different scope, whether with "typedef" or "using", all of
> the enum members should also be aliased in that
> (different) scope. This would make the following legal.
>
> namespace Foo
> {
> enum A { a1, a2 };
> enum B { b1, b2 };
> }
>
> namespace Bar
> {
> using Foo::A;
> typedef Foo::B B2;
> }
>
> Bar::A a = Bar::a1;
> Bar::B2 b = Bar::b1;
>
> I'd suggest the implicit aliasing of an enum member be
> blocked by a conflicting declaration in the aliasing scope,
> or when there would be a multiple implicit aliases for
> the member from different enums aliased in a scope.

I can't see how the rule you suggest (blocking aliasing because of a
conflicting declaration) can be implemented in a reasonable way.
Consider this case:

--- int.h
externt int Value;

--- enum.h
namespace Enum
{
 enum MyEnum { Value };
}

--- good.cpp
#include "int.h"
#include "value.h"
using Enum::MyEnum; // ::Value blocks Enum::Value from being aliased

int e = Value;      // uses ::Value

--- bad.cpp
#include "value.h"
using Enum::MyEnum; // Enum::Value is aliased
#include "int.h"    // Ummm...

int e = Value;      // which Value now?

This program is well formed in the current C++ standard and uses
::Value. For backward compatibility reasons, languages changes should
not break existing code or alter its behaviour, so the new rule should
also use ::Value (in particular it can't select Enum::Value because the
behaviour would silently change and can't give an ambiguity error
because it would break valid code).

However, if you let the rule selects ::Value either because we are now
violating ODR. If we let this pass we could have a bigger problem:

#include "value.h"
using Enum::MyEnum; // Enum::Value is aliased

int f = Value;      // uses Enum::Value

#include "int.h"    // silently changes meaning of Value!

int e = Value;      // uses ::Value!?

I think this situation is not tolerable.

So "enhancing" a syntax that is currently valid is not an option. A
possible to have this kind of feature is to invent a completely new
syntax, so to avoid any risk of backward incompatibility. The most
obvious such syntax is:

  using enum Enum::MyEnum;

which would be interpreted as:

  using Enum::Value; // all members of the Enum::MyEnum enum listed here

with all pros and cons of that. Notice that only the names of the values
are aliased and not the name of the enum itself. This is intentional.
This choice is motivated by the fact that there are case where you might
actually want to alias the names of the value only. Moreover this
behaviour is more consistent with the one of the using namespace
directive, which has similar syntax. If you want to alias both the enum
*and* its values then you can have it easily by writing both lines:

  using Enum::MyEnum;
  using enum Enum::MyEnum;

Do anybody knows if something like this has already been proposed? If
not, is there any interest about it?

Ganesh

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]