On Fri, 24 May 2002 08:39:12 GMT, Paul Mensonides wrote in
<F_dH8.14250$cQ3.705@sccrnsc01>:

> It isn't just compatibility with C anymore.  Now it is also compatibility with
> C++ itself.  As far as non-injecting enums are concerned, they are completely
> unnecessary:
>
> struct scope {
>     enum type { A, B, C };
> };
>
> scope::type
>
> scope::A
> scope::B
> scope::C

That has the problem of also keeping the enum name out of the
surrounding scope.  Something like this is better:

    struct scope
    {
        enum type { A, B, C };
    };
    using scope::type;

but very unwieldy.  I couldn't even create a macro to save the typing
because C++ does not support vararg macros.

Also it mandates using 2 different names for the type and the scope.
I would like it better to use:

    type::A
    type::B
    type::C

Unfortunately it does not work with an enclosing struct (because of a
conflict with the auto-generated default ctor [1]) and a namespace
cannot be used instead (namespaces cannot be declared in inner blocks).

Maybe a similar syntax for the proposed "strong typedefs" can be used in
this case as well.

*****
[1] Pet peeve #314: 'struct' should not have been extended to include
classes.  It should have been reserved to POD types.


Best regards,
Alex.

--
To email me, replace "myrealbox" with "alexoren".
Sorry for the inconvenience.  Blame the spammers.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Steve Clamage:
> Changing language semantics breaks programs and incurs large costs
> for developers of major applications. (If you change a line of code,
> you have to re-certify the application.)
>
> If it also reduces compatibility with C, the proposed feature ought
> to have a huge benefit to offset the large costs.

Not quite sure what you mean by "re-certify". I assume
you mean retest.

I would hope serious developers of serious applications
would retest their applications after any compiler
upgrade, regardless of the language standardization
committee's and compiler vendor's backwards
compatibility claims.

So let's not exaggerate. Once you upgrade, you retest
anyway. Each small change you need to make takes
a relatively small time to make. Only if you have a very
large number of small changes will it be accurate to
say that you have incurred a large cost. Until support
for C++98 on your platform(s) dies out completely,
the cost will be entirely optional. If you are prepared
to continue on current platforms without vendor support,
you never have to pay anything.

I suspect there will be a number of choices ahead for
those involved in C++ standardization: to add a otherwise
desirable new feature or to break existing code. I hope
the committee will not be overly swayed by those
conservative voices who basically wish to use C++98
forever anyway. We shall see.

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"Garry Lancaster" <glancaster@ntlworld.com> wrote in message
news:xKKI8.1417$C72.83607@newsfep1-win.server.ntli.net...
> Steve Clamage:
> > Changing language semantics breaks programs and incurs large costs
> > for developers of major applications. (If you change a line of code,
> > you have to re-certify the application.)
> >
> > If it also reduces compatibility with C, the proposed feature ought
> > to have a huge benefit to offset the large costs.
>
> Not quite sure what you mean by "re-certify". I assume
> you mean retest.

There are certain industries in which all software has to be "certified" by
an external body before it can be used. If you change _any part_ of the
software, you have to redo the certification procedure (lots of documented
tests and formal analysis), which as well as time consuming, is often costly
(you have to pay the certifying body).

> I would hope serious developers of serious applications
> would retest their applications after any compiler
> upgrade, regardless of the language standardization
> committee's and compiler vendor's backwards
> compatibility claims.

True, in general. I believe that some of the aforementioned industries have
a list of "certified compilers". If you change between them, you only have
to do a minimal recertification of your software. If the new version is
certified to be backwards compatible, you can get away with this. If it is
not (i.e. there is a change to semantics of existing code) you have to do a
full recertification.

> So let's not exaggerate. Once you upgrade, you retest
> anyway. Each small change you need to make takes
> a relatively small time to make. Only if you have a very
> large number of small changes will it be accurate to
> say that you have incurred a large cost. Until support
> for C++98 on your platform(s) dies out completely,
> the cost will be entirely optional. If you are prepared
> to continue on current platforms without vendor support,
> you never have to pay anything.

If you stick to one compiler release on one platform, you only have to
retest/recertify if you actually change anything, agreed. If you change
compilers you may need to make minor changes to the code, and retest and
recertify.

> I suspect there will be a number of choices ahead for
> those involved in C++ standardization: to add a otherwise
> desirable new feature or to break existing code. I hope
> the committee will not be overly swayed by those
> conservative voices who basically wish to use C++98
> forever anyway. We shall see.

If changing compilers is costly, I expect some people will stay with C++98
as implemented by their current compiler, complete with deficiencies and
bugs.

The big issue that I see is where you have old certified libraries written
with an existing compiler. Provided your new compiler doesn't affect the
semantics of existing code, and maintains binary compatibility, you can use
thes old libraries with new code written for your new compiler. If the
semantics of existing code are changed in the new version, then the exposed
interface of the libraries might have different semantics in the library and
in the new code, violating the ODR (e.g. adding compiler-generated virtual
destructors). This means you cannot use the new compiler unless you can
rebuild, retest and recertify the existing libraries.

Therefore, changes that break existing code might prevent people from using
C++0x where they might have used it otherwise.

I don't know how many people fall into this category, but their voice needs
to be heard. However, I agree that this needs to be weighed against the
possible utility of the new feature that will break their code --- if
something is obviously beneficial to a large number of people then the fact
that a minority is inconvenienced is largely irrelevant. OTOH, if only a
minority benefit, this needs to be weighed more carefully against the
minority who are inconvenienced.

Anthony
--
Anthony Williams
Software Engineer, Nortel Networks Optical Components Ltd
The opinions expressed in this message are not necessarily those of my
employer


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

On Fri, 24 May 2002 16:54:23 GMT, Hyman Rosen <hyrosen@mail.com>
wrote:

>xleobx@qmailcomq.com wrote:
>>> enum X { alpha, beta, gamma };
>>  X greek(beta); // well-formed
>>
>>> struct X { enum eX { alpha, beta, gamma }; };
>>  X greek(X::beta); // ill-formed
>
>X::eX greek(X::beta); // well-formed

Why to hack "struct" for namespace issue ? we have "namespace" keyword
ready for this. :-)

I usually use :

namespace Greek { enum type { alpha, beta, gamma }; };

Greek::type greek(Greek::beta); //well-formed

this way we can also inject enum in a controlled scope when wanted:

void some_function(Greek::type param)
{
    using namespace Greek;
    switch (param)
    {
    case alpha:
    case beta:
    ....
    };
}

Not a big improvement, but better than nothing ;-)


Also worth knowing in this context is this tecnique i learned a few
years ago on comp.lang.c++.moderated (from Dave Harris if i remember
correctly)

namespace EnumUtils
{
    template <typename E>
    inline E& operator++(E& e)
    {
        return e = E(e+1);
    }
    //other template operations potentially useful for enums...
};

//we want operator++ for Greek
namespace Greek
{
    enum type { alpha, beta, gamma };
    using EnumUtils::operator++;
};

//we do not want operator++ for Color
namespace Color {  enum type { red, green, blue }; };

int main()
{
 Greek::type greek = Greek::alpha;
 Color::type color = Color::red;

 ++greek; //ok, as wanted
 ++color; //compile time error, as wanted
}

If i understand correctly the proposed non-injecting enums, this
tecnique is not easily applicable to them, so maybe it is better to
use namespaces instead of "enhancing" the language this way...

Regards,
Natale Fietta

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"Steve Clamage" <clamage@eng.sun.com> wrote in message
news:Pine.SOL.4.33.0205231123130.2272-100000@taumet...
> I'm told that all the code in K&R2 is valid C++, for example.

K&R2 consistently omits the return type from 'main'.  Surely this
is not valid C++?


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

xleobx@qmailcomq.com wrote:
>> enum X { alpha, beta, gamma };
>  X greek(beta); // well-formed
>
>> struct X { enum eX { alpha, beta, gamma }; };
>  X greek(X::beta); // ill-formed

X::eX greek(X::beta); // well-formed

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <aclcki$imq$1@cam-news1.cambridge.arm.com>, Al Grant
<tnarga@arm.REVERSE-NAME.com> writes
>"Steve Clamage" <clamage@eng.sun.com> wrote in message
>news:Pine.SOL.4.33.0205231123130.2272-100000@taumet...
>> I'm told that all the code in K&R2 is valid C++, for example.
>
>K&R2 consistently omits the return type from 'main'.  Surely this
>is not valid C++?
>
Nor, these days (since 1999) is it valid C code.

--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

> All workarounds suffer one way or another. Allowing scoped enumerators
> (I forgo non-injection) will not break anything C-wise.

I think that using namespaces with internal "type" typedefs you
can create non-injecting enums in a very flexible manner.  Here's a
short sample program compiled with Borland Builder C++ 3.0.

Derek.

------------------------------------------------------
#include <conio.h>
#include <iostream>

namespace EColor
{
    enum EColor_t { red=0, green, blue };
    typedef EColor_t type;
}

namespace ESize
{
    enum ESize_t { small=4, medium , large};
    typedef ESize_t type;
}

int main(int argc, char **argv)
{

    cout << EColor::red << endl;
    cout << ESize::small << endl;

    {
        using namespace EColor;
        type my_color(green);
        cout << my_color << endl;
    }

    {
        using namespace ESize;
        type my_size(medium);
        cout << my_size << endl;
    }

    {
        EColor::type    my_color(EColor::blue);
        ESize::ESize_t  my_size(ESize::large);
        cout << my_color << endl << my_size << endl;
    }

    {
        using namespace ESize;
        using namespace EColor;
        EColor_t       my_color(red);
        ESize::type    my_size(small);
        cout << my_color << endl << my_size << endl;
    }

    getch();
    return 0;
}
------------------------------------------------------

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Steve Clamage <clamage@eng.sun.com> wrote:
> On Tue, 21 May 2002 xleobx@qmailcomq.com wrote:

>> Currently enums are the only (potentially) named scopes that inject
>> the names declared within them into the surrounding scope at all times,
>> and there is no way to prevent it.

> Unions do the same.

Not "at all times". Named unions in global scope don't; unnamed ones must be static.

>> Making enums non-injecting by default
>> will fix this inconsistency.

> And break C compatibility.

Is this still an issue?
Not every valid C program is a valid C++ program anyway, and a fix - adding
using enum X; - is trivial.

>> In compatibility mode,
>> "using enum X;" will be implied after a declaration of enum X.

> "Compatibility mode" is a quality of implementation issue, not
> something to put in the standard, when it concerns something as basic
> as the scope of an identifier.

> Standardized compatibility libraries might be reasonable in the
> standard. Optional language semantics are not, in my view. It opens
> the door to a potentially unbounded number of C++ dialects, all
> standard-conforming.

Ok, strike "compatibility mode". It will be up to the compiler vendor to
imply "using enum X;" to simplify transition.

> If the next C standard were to change the scope of enumerators, it
> would be reasonable for C++ to do it as well, in the same way. We
> should prefer to maintain as much C compatibility as possible.

Semantical, yes; but the syntactical compatibility is long gone already, IMHO.

A weaker proposal: allow constructs enum_name::enumerator - does not hurt
and allows for better expressiveness and error-checking.

 Leo

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

> > And break C compatibility.

This is something that is REALLY annoying. This is the reason why C++ is
somehow still stuck in the 70's...



---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

You could also use an enum in a namespace, i.e.

namespace X
{
  enum { alpha, beta, gamma };
}

That way, you could either call:

 myvar = X::alpha;

or

 using namespace X;
 myvar = alpha;

Derek.

> Completely unnecessary; instead of writing
> enum X { alpha, beta, gamma };
> and longing for X::beta, just write
> struct X { enum eX { alpha, beta, gamma }; };
> and you'll have it.


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Hyman Rosen <hyrosen@mail.com> wrote:
> xleobx@qmailcomq.com wrote:
>> Currently enums are the only (potentially) named scopes that inject
>> the names declared within them into the surrounding scope at all times,
>> and there is no way to prevent it. Making enums non-injecting by default
>> will fix this inconsistency. In compatibility mode,
>> "using enum X;" will be implied after a declaration of enum X.

> Completely unnecessary; instead of writing

You do not see the whole picture.

>  enum X { alpha, beta, gamma };

 X greek(beta); // well-formed

> and longing for X::beta, just write
>  struct X { enum eX { alpha, beta, gamma }; };
> and you'll have it.

 X greek(X::beta); // ill-formed

But if written correctly (with ctors and conversion operators),
X is not an enum anymore and is not subject to enum-specific optimizations.

 Leo

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Allan W <Allan_W@my-dejanews.com> wrote:
> xleobx@qmailcomq.com wrote in message news:<WIlG8.7739$T_.182623@iad-read.news.verio.net>...
>> Currently enums are the only (potentially) named scopes that inject
>> the names declared within them into the surrounding scope at all times,
>> and there is no way to prevent it.

> Does this cause a problem? A principle of C++ is that it isn't designed
> by purists. The committee generally does NOT change the language for
> aesthetic reasons, but only to solve specific real-world problems.

enum Color { Black, Red, Green, Blue };
Color red = red_enabled ? Red : Black;
Color c(red); // Intended "Red" - no way to catch
Color c(Color::Red);  // Proposed
Color c(Color::red); // Will be ill-formed

As I wrote to Steve Clamage, making enums non-injecting may be an overkill,
and limited my proposal to scoped enumerators.

>> Making enums non-injecting by default
>> will fix this inconsistency. In compatibility mode,
>> "using enum X;" will be implied after a declaration of enum X.

> How would one enable (or disable) compatibility mode?

It will be up to the vendor. And it will not be necessary if the enumerators
are still injected but scoped ones are allowed.

 Leo

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"Steve Clamage" <clamage@eng.sun.com> wrote in message
news:Pine.SOL.4.33.0205221016230.25849-100000@taumet...
> On Tue, 21 May 2002 xleobx@qmailcomq.com wrote:
> > Making enums non-injecting by default
> > will fix this inconsistency.
>
> And break C compatibility.

The fact that enums declared in structs don't inject into the
outer scope is already an incompatibility, since they do in C.
There are several others, most obviously the lack of implicit
conversion from int to enum types.


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

On Thu, 23 May 2002 xleobx@qmailcomq.com wrote:
>
> > And break C compatibility.
>
> Is this still an issue?
> Not every valid C program is a valid C++ program anyway, ...
>
> ... but the syntactical compatibility is long gone already, IMHO.

You can write a valid C program that won't compile as C++.  But it
is easy to write the program so that it is valid as both C and C++.
I'm told that all the code in K&R2 is valid C++, for example.

It is very helpful for header files to be useable in both C and
C++ programs. If you start with the idea of writing a compatible
header, it generally suffices to add 'extern "C"' brackets guarded
by #if __cplusplus around the header.

Changing language semantics breaks programs and incurs large costs
for developers of major applications. (If you change a line of code,
you have to re-certify the application.)

If it also reduces compatibility with C, the proposed feature ought
to have a huge benefit to offset the large costs.

--
Steve Clamage, stephen.clamage@sun.com

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Derek Ross <dross@iders.ca> wrote:
> You could also use an enum in a namespace, i.e.

Only globally.

> namespace X
> {
>   enum { alpha, beta, gamma };
> }

> That way, you could either call:

>  myvar = X::alpha;

> or

>  using namespace X;
>  myvar = alpha;

All workarounds suffer one way or another. Allowing scoped enumerators
(I forgo non-injection) will not break anything C-wise.

 Leo

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

> > > And break C compatibility.
>
> This is something that is REALLY annoying. This is the reason why C++ is
> somehow still stuck in the 70's...

It isn't just compatibility with C anymore.  Now it is also compatibility with
C++ itself.  As far as non-injecting enums are concerned, they are completely
unnecessary:

struct scope {
    enum type { A, B, C };
};

scope::type

scope::A
scope::B
scope::C

Paul Mensonides

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Currently enums are the only (potentially) named scopes that inject
the names declared within them into the surrounding scope at all times,
and there is no way to prevent it. Making enums non-injecting by default
will fix this inconsistency. In compatibility mode,
"using enum X;" will be implied after a declaration of enum X.

 Leo

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

On Tue, 21 May 2002 18:35:49 UTC, xleobx@qmailcomq.com wrote: WEEKDAY

>Currently enums are the only (potentially) named scopes that inject
>the names declared within them into the surrounding scope at all times,
>and there is no way to prevent it. Making enums non-injecting by default
>will fix this inconsistency. In compatibility mode,
>"using enum X;" will be implied after a declaration of enum X.
>
[...]

 I have considered enum as defined in C a weak design.
 I think they should be made an actual type.

 enum COLOR{ RED=1, ORANGE=2, YELLOW };
 // An enum may be extended
 enum MORE_COLORS : COLOR { GREEN=4, BLUE };
 // enum values need not be unique
 enum FRUIT{ ORANGE=1, APPLE };

 MORE_COLOR mc;
 // Which enum value can be determined by context at compile time.
 // In the rare instance it cannot (templates?) write COLOR.ORANGE
 COLOR c=ORANGE;
 FRUIT f=ORANGE;
 // the type relation goes in the other direction from classes
 mc = c;
 // c = mc;  is an error
 // Conversion to integer must be explicit.
 int I = c.intValue();
 // Conversion to string is provided
 String s = c.toString();
 // string to enum conversion is provided
 f = FRUIT.parse( s );





--

Remove -zamboni to reply
All the above is hearsay and the opinion of no one in particular

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

On Tue, 21 May 2002 xleobx@qmailcomq.com wrote:

> Currently enums are the only (potentially) named scopes that inject
> the names declared within them into the surrounding scope at all times,
> and there is no way to prevent it.

Unions do the same.

> Making enums non-injecting by default
> will fix this inconsistency.

And break C compatibility.

> In compatibility mode,
> "using enum X;" will be implied after a declaration of enum X.

"Compatibility mode" is a quality of implementation issue, not
something to put in the standard, when it concerns something as basic
as the scope of an identifier.

Standardized compatibility libraries might be reasonable in the
standard. Optional language semantics are not, in my view. It opens
the door to a potentially unbounded number of C++ dialects, all
standard-conforming.

If the next C standard were to change the scope of enumerators, it
would be reasonable for C++ to do it as well, in the same way. We
should prefer to maintain as much C compatibility as possible.

--
Steve Clamage, stephen.clamage@sun.com

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

xleobx@qmailcomq.com wrote in message news:<WIlG8.7739$T_.182623@iad-read.news.verio.net>...
> Currently enums are the only (potentially) named scopes that inject
> the names declared within them into the surrounding scope at all times,
> and there is no way to prevent it.

Does this cause a problem? A principle of C++ is that it isn't designed
by purists. The committee generally does NOT change the language for
aesthetic reasons, but only to solve specific real-world problems.

> Making enums non-injecting by default
> will fix this inconsistency. In compatibility mode,
> "using enum X;" will be implied after a declaration of enum X.

How would one enable (or disable) compatibility mode?

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

xleobx@qmailcomq.com wrote:
> Currently enums are the only (potentially) named scopes that inject
> the names declared within them into the surrounding scope at all times,
> and there is no way to prevent it. Making enums non-injecting by default
> will fix this inconsistency. In compatibility mode,
> "using enum X;" will be implied after a declaration of enum X.

Completely unnecessary; instead of writing
 enum X { alpha, beta, gamma };
and longing for X::beta, just write
 struct X { enum eX { alpha, beta, gamma }; };
and you'll have it.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]