"Tom   s" wrote:
> Anyone know if they're considering adding "explicit enum" to the language?
> I've read about such a proposal a few times. The essence of it is that when
> you write:
>
> explicit enum Colour { red, green, blue };
>
> "red", "green" and "blue" aren't in the same scope as "Colour"; you've to
> qualify them:
>
> int main()
> {
>     int k = red; /* Error */
>
>     int k = Colour::red;
> }
>
>
> I think it would be a brilliant addition.

Then you may be disappointed to find out that the "strongly typed
enums" proposal apparently being considered by the Committee bears
almost no semblance to the above description. For one, an enum class
would not convert implicity to an integral type; therefore neither line
of code in main() would be correct. Second, while an enumerated value
can be qualified with the name of its enum - it does not have to be.
Therefore both "Color::red" and "red" could be used in a program -
except where the use of the unqualified name would be ambiguous.

There are several other significant improvements put forth in the
proposal which can be found at this address:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1579.pdf

Greg


---
[ 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                      ]

Tom   s wrote:
> Anyone know if they're considering adding "explicit enum" to the language?
> I've read about such a proposal a few times. The essence of it is that when
> you write:
>
> explicit enum Colour { red, green, blue };
>
> "red", "green" and "blue" aren't in the same scope as "Colour"; you've to
> qualify them:
>
> int main()
> {
>     int k = red; /* Error */
>     int k = Colour::red;
> }

It might be better to adapt recently added Java 5 enums for C++, see
http://java.sun.com/j2se/1.5.0/docs/guide/language/enums.html

For example, you Colour might look like this:

  struct enum Color { red, green, blue };

  void f()
  {
    int k = Color::red;
  }

Note that I would propose "struct enum" or "class enum" instead of
"explicit enum" syntax.

In addition, it should be possible to support non-trivial constructors:

  struct enum Color {
    red = 0xFF0000,   // constructed by Color(int)
    green(0x00FF00),  // constructed by Color(int)
    blue(0, 0, 0xFF); // constructed by Color(int, int, int)

  private:
    const int value;

  public:
    Color(int value) : value(value) {}
    Color(int r, int g, int b) : value((r << 16) | (g << 8) | b)) {}

    operator int() { return value; }
  };

Moreover, there should be constant-specific methods (implemented as by
derived classes):

  struct enum Color {
    red   = 0xFF0000 { const char* name() { return "red" } },
    green = 0x00FF00 { const char* name() { return "green" } },
    blue  = 0x0000FF { const char* name() { return "blue" } };
  };

  void f()
  {
    cout << Color::red.name() << endl; // prints "red"
  }

In particular, the constant-specific name() method should be declared
implicitly, it is the most desired feature.

The implementation of this syntax is trivial.

--
Andrei Polushin


---
[ 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                      ]

"Tom   s" wrote:
> Anyone know if they're considering adding "explicit enum" to the language?
> I've read about such a proposal a few times. The essence of it is that when
> you write:
>
> explicit enum Colour { red, green, blue };
>
> "red", "green" and "blue" aren't in the same scope as "Colour"; you've to
> qualify them:
>
> int main()
> {
>     int k = red; /* Error */
>
>     int k = Colour::red;
> }
>
>
> I think it would be a brilliant addition.
>
It would be good too to have some really strongly typed enums.
There has been proposals by competent people (Herb Sutter for example).

http://open-std.org/jtc1/sc22/wg21/docs/papers/2004/N1719.pdf

You can search for other proposals here:
http://www.research.att.com/~bs/papers.html

However I think that this proposal has been rejected and that no new
proposals are accepted for C++0x. Thus it means that it will not be
added to C++0x.

> Anyone know if they're considering adding "explicit enum" to the language?
So they have been considering adding such enums... But at this time,
"they" are not currently considering adding them.


---
[ 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                      ]

In article <1149125448.729894.224970@h76g2000cwa.googlegroups.com>, Greg
Herlihy <greghe@pacbell.net> writes
>There are several other significant improvements put forth in the
>proposal which can be found at this address:
>
>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1579.pdf

That is an old paper and much more is under consideration because WG21
tries to avoid taking proposals in isolation. The proposals wrt strong
typedefs (see papers by Walter Brown from Fermilab) have a considerable
overlap with Miller's proposals for strong enums. One thing we are
considering is whether we need both and if so, how much of the strong
enum proposals should be retained.

--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ 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                      ]

In article <1149108905.713440.286090@u72g2000cwu.googlegroups.com>,
SuperKoko <tabkannaz@yahoo.fr> writes
>It would be good too to have some really strongly typed enums.
>There has been proposals by competent people (Herb Sutter for example).
>
>http://open-std.org/jtc1/sc22/wg21/docs/papers/2004/N1719.pdf
>
>You can search for other proposals here:
>http://www.research.att.com/~bs/papers.html
>
>However I think that this proposal has been rejected and that no new
>proposals are accepted for C++0x. Thus it means that it will not be
>added to C++0x.

You are mistaken, the paper above is one of the base papers for work in
this area, but as I wrote in another post, WG21 does not deal with this
kind of issue on a piecemeal basis.

--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ 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                      ]

Anyone know if they're considering adding "explicit enum" to the language=
?=20
I've read about such a proposal a few times. The essence of it is that wh=
en=20
you write:

explicit enum Colour { red, green, blue };

"red", "green" and "blue" aren't in the same scope as "Colour"; you've to=
=20
qualify them:

int main()
{
    int k =3D red; /* Error */

    int k =3D Colour::red;
}


I think it would be a brilliant addition.


-Tom=E1s

---
[ 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                      ]