On 8/18/2011 9:54 AM, Daniel Kr   gler wrote:
>
>>  2) Inheriting from another enum would be quite useful. For example:
>>  enum class Widget {button, combobox, listview};
>>  enum class SuperWidget : Widget {iconview}
>
>  The current state would not disallow such an extension in the future,
>  so what is the problem?

I don't think it'll be a good idea to make the two coexist together:
enum class SuperWidget : Widget {iconview} // derived
enum class SuperWidget : unsigned int {iconview} // subtyping

>>  3) Redefining the underlying type could be easily done with:
>>  enum class Val { unsigned long E1, E2, E3, E4 };
>>
>>  This is much more neat and is similar to a declaration of multiple
>>  instances:
>>  const unsigned long E1, E2, E3, E4;
>
>  I don't consider this alternative as superior as the current state. To
>  me it looks, as if Ei (i=1-4) are data members of Val. It would imply
>  to me that I could write
>
>  enum class Val { unsigned long E1; unsigned long E2; unsigned long E3,
>  unsigned long E4; };
>
>  Does that mean that we could also use different underlying types for
>  individual enumerator values?

Only one declaration would be allowed.  A semicolon could even be accepted:
enum class Val { unsigned long E1, E2, E3, E4; };


Regards,
-Phil


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

On 8/16/2011 8:28 PM, Phil Bouchard wrote:
>
>  Hi,
>
>  Is it too late to change the strongly type enum? I have a proposal
>  that is much cleaner than what is on its way.

Considering that the Standard just got approved, yeah, I'd guess it's
probably too late.  [grin]



>  Right now we have:
>  enum class Val: unsigned long { E1, E2, E3, E4 };
>
>  Comments:
>  1) This design is bad because the ':' sign is reserved for inheritance.
>
>  2) Inheriting from another enum would be quite useful. For example:
>  enum class Widget {button, combobox, listview};
>  enum class SuperWidget : Widget {iconview}
>
>  This way iconview would be equal to 3, not 0.
>
>  3) Redefining the underlying type could be easily done with:
>  enum class Val { unsigned long E1, E2, E3, E4 };
>
>  This is much more neat and is similar to a declaration of multiple
>  instances:
>  const unsigned long E1, E2, E3, E4;

An interesting proposal.


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

Pete Becker<pete@versatilecoding.com>  wrote in news:2011081706332351646-
pete@versatilecodingcom:

>
>  On 2011-08-16 21:28:17 +0000, Phil Bouchard said:
>>  1) This design is bad because the ':' sign is reserved for inheritance.
>
>  Really? Where does the standard say that it's "reserved"?<g>
>
>  It's currently used to indicate inheritance, to separate two
>  expressions in a ternary operator, and to mark the size of a bitfield.

You are forgetting goto labels!

Cheers
Paavo


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

On 8/18/2011 9:51 AM, Pete Becker wrote:
>  On 2011-08-16 21:28:17 +0000, Phil Bouchard said:
>>  Right now we have:
>>  enum class Val: unsigned long { E1, E2, E3, E4 };
>>
>>  Comments:
>>  1) This design is bad because the ':' sign is reserved for inheritance.
>
>  Really? Where does the standard say that it's "reserved"?<g>
>
>  It's currently used to indicate inheritance, to separate two
>  expressions in a ternary operator, and to mark the size of a bitfield.

..and to designate a symbol as a label (for use in goto), right?  Or has
it been removed from the Standard?

V
--
I do not respond to top-posted replies, please don't ask


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

On 2011-08-16 20:28, Phil Bouchard wrote:
>
>  Is it too late to change the strongly type enum?  I have a proposal
>  that is much cleaner than what is on its way.

I'm afraid it is too late to change anything for C++0x.
But you can certainly propose something for the next standard.

>  Right now we have:
>  enum class Val: unsigned long { E1, E2, E3, E4 };
>
>  Comments:
>  1) This design is bad because the ':' sign is reserved for inheritance.

The ':' sign had not been reserved for inheritance. Labels (including
case labels) use it, bit field declarations use it, ctor-initializers
use it, the ternary operator (?:) use it, and so on.

Furthermore, extending the meaning of a lexical element is common
as the language evolves.

>
>  2) Inheriting from another enum would be quite useful.  For example:
>  enum class Widget {button, combobox, listview};
>  enum class SuperWidget : Widget {iconview}
>
>  This way iconview would be equal to 3, not 0.

When class D inherits from class B, any D object can be regarded as a
B object; e.g. you can pass a D object to a function like f(B&).
Therefore, D is a subtype of B, i.e. D<: B.

When enum class SW "inherits" from enum class W, a SW object cannot be
regarded as a W object, but the converse holds: i.e. not SW<: W, but
W<: SW. In this regard, using the term "inheritance" for extending enum
classes as such may be confusing.

But this could be useful, still. I can even imagine something like this:

     enum class WindowOptions : unsigned short { A, B, C };
     enum class AdvancedWindowOptions : WindowOptions { D, E };

whose implications in full I'm not sure of yet.

>
>  3) Redefining the underlying type could be easily done with:
>  enum class Val { unsigned long E1, E2, E3, E4 };
>
>  This is much more neat and is similar to a declaration of multiple instances:
>  const unsigned long E1, E2, E3, E4;

It looks similar to a simple-declaration, but its syntax must be
something entirely different. You can neither put a semicolon at
the end of the list of the enumerators, nor use different types
for different enumerators.
I think this is a case where a syntax that is too similar but not the
same can be more confusing than a syntax that looks different enough.
We might face questions like '"int i1, i2;" is equivalent to "int i1;
int i2;" but why isn't it the case inside an enum?'

Anyway, this is a matter of taste, after all.

--
Seungbeom Kim


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

On 8/18/2011 9:53 AM, Alain Ketterlin wrote:
>
>>  2) Inheriting from another enum would be quite useful.  For example:
>>  enum class Widget {button, combobox, listview};
>>  enum class SuperWidget : Widget {iconview}
>
>  This contradicts with the meaning of sub-typing, which is restriction,
>  and which you use here as augmentation. Assigning a value of type
>  SuperWidget to a variable of type Widget would be forbidden, if I
>  understand your example correctly. The exact opposite of what happens
>  between a sub-class and its base-class.

Exactly.

>>  3) Redefining the underlying type could be easily done with:
>>  enum class Val { unsigned long E1, E2, E3, E4 };
>>
>>  This is much more neat and is similar to a declaration of multiple instances:
>>  const unsigned long E1, E2, E3, E4;
>
>  In my opinion, this looks much like a list of members. I know, unions do
>  this already, but there's "class" in the type declaration here.

That's what it is, a list of constant members:
const unsigned long E1 = 0, E2 = 1, E3 = 2, E4 = 3;


-Phil


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

On 8/18/2011 9:52 AM, Marcel M   ller wrote:
>
>> 3) Redefining the underlying type could be easily done with:
>> enum class Val { unsigned long E1, E2, E3, E4 };
>
> This implies that the type is specific to each enum constant. It isn't. IMO
>
> enum class Val: unsigned long
>
> is fine. Val is an unsigned long, but it cannot be implicitly
> converted because it is a private base.

(Sorry for the delay but my posts get more than 24 hours to appear).

BTW I just realized that what I was proposing could make use of bitfields also:
enum class Val { unsigned long E1, E2, E3, E4 : 4 };

This way it could be used as such:
struct A
{
       Val v1, v2;
};

Thus:
sizeof(A) would be equal to 8


-Phil


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

On 18/08/2011 14:51, Pete Becker wrote:
>
>  On 2011-08-16 21:28:17 +0000, Phil Bouchard said:
>
>>  Hi,
>>
>>  Is it too late to change the strongly type enum?
>
>  Yes, C++11 has been unanimously approved. It will be an official
>  standard in a few weeks.
>
>  No, work is just starting on the next version of the C++ standard.
>
>>  I have a proposal
>>  that is much cleaner than what is on its way.
>>
>>  Right now we have:
>>  enum class Val: unsigned long { E1, E2, E3, E4 };
>>
>>  Comments:
>>  1) This design is bad because the ':' sign is reserved for inheritance.
>
>  Really? Where does the standard say that it's "reserved"?<g>
>
>  It's currently used to indicate inheritance, to separate two
>  expressions in a ternary operator, and to mark the size of a bitfield.
>

and for a case in a switch statement, and for a label (long time since I
used one of those but I tend to not use goto :)


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

On 8/18/2011 9:52 AM, Marcel M   ller wrote:
>
>> 3) Redefining the underlying type could be easily done with:
>> enum class Val { unsigned long E1, E2, E3, E4 };
>
> This implies that the type is specific to each enum constant. It isn't. IMO
>
> enum class Val: unsigned long
>
> is fine. Val is an unsigned long, but it cannot be implicitly
> converted because it is a private base.

I made a mistake in my previous post.  What I meant was:

BTW I just realized that what I was proposing could make use of bitfields also:
enum class Val { unsigned long E1, E2, E3, E4 : 2 };

This way it could be used as such:
struct A
{
   Val v1, v2, v3, v4;
};

Thus:
sizeof(A) would be equal to 1


-Phil


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

On 8/24/2011 5:06 PM, Seungbeom Kim wrote:
>
>  It looks similar to a simple-declaration, but its syntax must be
>  something entirely different. You can neither put a semicolon at
>  the end of the list of the enumerators, nor use different types
>  for different enumerators.
>  I think this is a case where a syntax that is too similar but not the
>  same can be more confusing than a syntax that looks different enough.
>  We might face questions like '"int i1, i2;" is equivalent to "int i1;
>  int i2;" but why isn't it the case inside an enum?'
>
>  Anyway, this is a matter of taste, after all.

If we would like to make it type oriented then:
- ':' could subtype when
   - the following type is fundamental
   - the following type is a class
- ':' would inherit when
   - the following type is of enum class

For example:
   class Style
   {
     Style operator ++ (int) { /*...*/ }
   };
   enum class WindowFrame : Style { A, B, C }; // subtype

   enum class WindowOptions : unsigned short : 4 { A, B, C }; // subtype
   enum class AdvancedWindowOptions : WindowOptions { D, E }; // derive


-Phil


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

Am 24.08.2011 23:06, schrieb Phil Bouchard:
>  On 8/18/2011 9:54 AM, Daniel Kr   gler wrote:
>>
>>>  2) Inheriting from another enum would be quite useful. For example:
>>>  enum class Widget {button, combobox, listview};
>>>  enum class SuperWidget : Widget {iconview}
>>
>>  The current state would not disallow such an extension in the future,
>>  so what is the problem?
>
>  I don't think it'll be a good idea to make the two coexist together:
>  enum class SuperWidget : Widget {iconview} // derived
>  enum class SuperWidget : unsigned int {iconview} // subtyping

I'm missing the rationale for your dislike. Widget is still a type that
has an integral type as underlying type, so what is the drastic
difference, if you extend scoped enums to allow for extending another
enum? We have no enumeration values in integral types, so we have we
don't have an observable difference. If you want to define that
SuperWidget contains the enumeration values of Widget, this is simply a
definition problem.

>>>  3) Redefining the underlying type could be easily done with:
>>>  enum class Val { unsigned long E1, E2, E3, E4 };
>>>
>>>  This is much more neat and is similar to a declaration of multiple
>>>  instances:
>>>  const unsigned long E1, E2, E3, E4;
>>
>>  I don't consider this alternative as superior as the current state. To
>>  me it looks, as if Ei (i=1-4) are data members of Val. It would imply
>>  to me that I could write
>>
>>  enum class Val { unsigned long E1; unsigned long E2; unsigned long E3,
>>  unsigned long E4; };
>>
>>  Does that mean that we could also use different underlying types for
>>  individual enumerator values?
>
>  Only one declaration would be allowed. A semicolon could even be accepted:
>  enum class Val { unsigned long E1, E2, E3, E4; };

You are starting now a design which comes way too late, C++11 has left
the house. We can proceed discussing this here, but I must say, I'm
failing to see the advantages. The current specification is now part of
an International Standard and I could not find any arguments in this
thread that demonstrate the defect of the current specification.

Greetings from Bremen,

- Daniel Kr   gler



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

On 8/24/2011 5:52 PM, Francis Glassborow wrote:
>
>  and for a case in a switch statement, and for a label (long time since I
>  used one of those but I tend to not use goto :)

Bison generates source code having gotos...


-Phil


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

On 8/24/2011 5:06 PM, Seungbeom Kim wrote:
>
>  It looks similar to a simple-declaration, but its syntax must be
>  something entirely different. You can neither put a semicolon at
>  the end of the list of the enumerators, nor use different types
>  for different enumerators.
>  I think this is a case where a syntax that is too similar but not the
>  same can be more confusing than a syntax that looks different enough.
>  We might face questions like '"int i1, i2;" is equivalent to "int i1;
>  int i2;" but why isn't it the case inside an enum?'
>
>  Anyway, this is a matter of taste, after all.

I think if inheritance is eventually supported then it would be very
confusing having the ':' stand for both subtyping and inheritance.
   enum class WindowOptions : unsigned short { A, B, C };
   enum class AdvancedWindowOptions : WindowOptions { D, E };

On the other hand if bitfields are supported as well, is the following
what we want?
   enum class WindowOptions : unsigned short : 2 { A, B, C }; // ?
   enum class AdvancedWindowOptions : WindowOptions { D, E };

Here we have ':' with 3 different meanings.

The following parses just like a real declaration:
   enum class WindowOptions { unsigned short A : 2, B : 2, C : 2 };


-Phil


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

On 8/24/2011 5:06 PM, Seungbeom Kim wrote:
>
>  It looks similar to a simple-declaration, but its syntax must be
>  something entirely different. You can neither put a semicolon at
>  the end of the list of the enumerators, nor use different types
>  for different enumerators.
>  I think this is a case where a syntax that is too similar but not the
>  same can be more confusing than a syntax that looks different enough.
>  We might face questions like '"int i1, i2;" is equivalent to "int i1;
>  int i2;" but why isn't it the case inside an enum?'
>
>  Anyway, this is a matter of taste, after all.

Actually perhaps the following is acceptable after all:
   enum class WindowOptions : unsigned short : 2 { A, B, C }; // ?
   enum class AdvancedWindowOptions : WindowOptions { D, E };

I think it makes more sense than what I previously suggested.


-Phil


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

Daniel Kr   gler<daniel.kruegler@googlemail.com>  Wrote:

>  Am 24.08.2011 23:06, schrieb Phil Bouchard:
>  >   On 8/18/2011 9:54 AM, Daniel Kr   gler wrote:
>  >>
>  >>>   2) Inheriting from another enum would be quite useful. For
>  example:
>  >>>   enum class Widget {button, combobox, listview};
>  >>>   enum class SuperWidget : Widget {iconview}
>  >>
>  >>   The current state would not disallow such an extension in the
>  future,
>  >>   so what is the problem?
>  >
>  >   I don't think it'll be a good idea to make the two coexist
>  together:
>  >   enum class SuperWidget : Widget {iconview} // derived
>  >   enum class SuperWidget : unsigned int {iconview} // subtyping
>
>  I'm missing the rationale for your dislike. Widget is still a type that
>  has an integral type as underlying type, so what is the drastic
>  difference, if you extend scoped enums to allow for extending
>  another enum? We have no enumeration values in integral types, so
>  we have we don't have an observable difference. If you want to
>  define that SuperWidget contains the enumeration values of
>  Widget, this is simply a definition problem.

The dislike probably comes from how an enum is typically viewed.
To my knowledge, an enum is typically viewed as an integer with a limited
set of possible values (that some/most of those values also have a symbolic
name is incidental). A scoped enum gives you the added value of being able
to specify the underlying storage.

With this view the interpretation of the declarations would be:
  enum class Widget : unsigned int { list_view, box, button }; /* RESTRICT a
storage cell of size unsigned int to store only the specified values */
  enum class SuperWidget : Widget { iconview }; /* EXTEND? the allowed values
to include iconview */

OTOH, you seem to view a (scoped) enum as its base-type with some of the
values given a symbolic name:

  enum class Widget : unsigned int { list_view, box, button }; /* Can store
all values of an unsigned int, with three of them given a specific,
symbolic, name */
  enum class SuperWidget : Widget { iconview }; /* Extend the list of
symbolic names to include iconview */

>
>  Greetings from Bremen,
>
>  - Daniel Kr   gler

Bart v Ingen Schenau


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

Am 26.08.2011 04:51, schrieb Bart van Ingen Schenau:
>

[..]

> The dislike probably comes from how an enum is typically viewed.

Maybe.

> To my knowledge, an enum is typically viewed as an integer with a limited
> set of possible values (that some/most of those values also have a symbol=
ic
> name is incidental).

Yes, whereby this limited set is always a limited range (7.2 p7), see
also below.

> A scoped enum gives you the added value of being able
> to specify the underlying storage.

Correct, but this description does not go far enough. When scoped enums
where proposed it turned out that the specification of an underlying
type should not be restricted to scoped enums and the concept of a
*fixed* underlying type was introduced. so we can now define e.g.

enum Ef : int {};

Ef is an *unscoped* enum with a *fixed* underlying type. But all scoped
enums have essentially a fixed underlying type. If this type is not
explicitly provided, it is int (7.2 p5+6).

> With this view the interpretation of the declarations would be:
>    enum class Widget : unsigned int { list_view, box, button }; /* RESTRI=
CT a
> storage cell of size unsigned int to store only the specified values */

Note that the set of values of any enumeration type with fixed
underlying type is equal to the set of the possible values of the
underlying type (7.2 p7), so your comment seems misleading to me,
because the possible values of Widget are essentially equal to the range

[0, std::numeric_limits<unsigned>::max()]

In other enum cases, the range of enum values is a sub-range possibly
identical to the range of the values of the underlying type.

Before the CD this was not really clear and some implementations did
have a stronger interpretation of this. One of the key issues for
clarifying the intended meaning were the following
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#128http://www.=
open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#172http://www.open-std.or=
g/jtc1/sc22/wg21/docs/cwg_defects.html#628http://www.open-std.org/jtc1/sc22=
/wg21/docs/cwg_defects.html#685http://www.open-std.org/jtc1/sc22/wg21/docs/=
cwg_defects.html#1022http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defect=
s.html#1094

>    enum class SuperWidget : Widget { iconview }; /* EXTEND? the allowed v=
alues
> to include iconview */

I don't know yet, what the meaning should be. For me one intuitive
interpretation would be that SuperWidget has two enumerators of value 0.
An alternative interpretation could be that SuperWidget::iconview has
the numeric value 3 in this example.

We also have to define the rules for the underlying type. My intuitive
understanding would be that SuperWidget still has the same underlying
type of Widget here. This makes sense, because the underlying type for
scoped enums is determined *before* the enumeration values are seen. We
could allow to change the underlying type by some other syntax, e.g.

enum class SuperWidget : Widget, unsigned long long { iconview };

I would guess that only *extending* this underlying type should be
well-formed.

Maybe different people have different preferences and the meaning must
be controllable somehow.

> OTOH, you seem to view a (scoped) enum as its base-type with some of the
> values given a symbolic name:

Is your "base-type" the underlying type? If so, I didn't want to imply
that. The underlying type just defines the "raw storage" layout. For
that reason we have in 7.2 p8:

"Two enumeration types are layout-compatible if they have the same
underlying type."

>    enum class Widget : unsigned int { list_view, box, button }; /* Can st=
ore
> all values of an unsigned int, with three of them given a specific,
> symbolic, name */

Widget has a value range of unsigned int, this is what the standard
defines.

>    enum class SuperWidget : Widget { iconview }; /* Extend the list of
> symbolic names to include iconview */

As described above, I'm not yet sure what the precise meaning should be.

HTH & Greetings from Bremen,

- Daniel Kr=FCgler





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

=?ISO-8859-15?Q?Daniel_Kr=FCgler?= <daniel.kruegler@googlemail.=
com> writes:
> >    enum class Widget : unsigned int { list_view, box, button };
> >    enum class SuperWidget : Widget { iconview };
>
> I don't know yet, what the meaning should be. For me one intuitive
> interpretation would be that SuperWidget has two enumerators of value 0.
> An alternative interpretation could be that SuperWidget::iconview has
> the numeric value 3 in this example.

Surely the latter...

That sort of usage seems very common in existing code, by doing
something like:

   enum X { a, b, X_MAX };
   enum Y { d = X_MAX + 1, e, Y_MAX };

Real inheritance seems like a natural way to sugar this up a bit.

Some other possible behavior:

* when the compiler does type checking of enum classes, consider enum
 classes related by inheritance compatible in some appropriate sense
 (e.g., an enum superclass can be assigned to an enum subclass, enum
 classes related by inheritance can be compared, etc)

* for enum classes, import all the members of the parent into the
 child, e.g.:

   enum class X : whatever { a, b };
   enum class Y : X { d, e };

 would yield X::a = 0, X::b = 1, Y::a = 0, Y::b = 1, Y::d = 2, Y::e = 3.

      [dunno about this one; maybe it's not desirable...]


-Miles

--
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]


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

Hi,

Is it too late to change the strongly type enum?  I have a proposal
that is much cleaner than what is on its way.

Right now we have:
enum class Val: unsigned long { E1, E2, E3, E4 };

Comments:
1) This design is bad because the ':' sign is reserved for inheritance.

2) Inheriting from another enum would be quite useful.  For example:
enum class Widget {button, combobox, listview};
enum class SuperWidget : Widget {iconview}

This way iconview would be equal to 3, not 0.

3) Redefining the underlying type could be easily done with:
enum class Val { unsigned long E1, E2, E3, E4 };

This is much more neat and is similar to a declaration of multiple instances:
const unsigned long E1, E2, E3, E4;


Thanks,
-Phil


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

On 2011-08-17 05:28, Phil Bouchard wrote:
>
> Hi,
>
> Is it too late to change the strongly type enum?

Yes, the ISO standard C++11 is accepted.

> I have a proposal
> that is much cleaner than what is on its way.
>
> Right now we have:
> enum class Val: unsigned long { E1, E2, E3, E4 };
>
> Comments:
> 1) This design is bad because the ':' sign is reserved for inheritance.

I disagree. First, ':' is only "reserved" for inheritance for class
types, second, even, if we look at it similar to class types I don't
consider the current state as incorrect, because we can (conceptually)
consider an enum to "derive from" an underlying type.

> 2) Inheriting from another enum would be quite useful. For example:
> enum class Widget {button, combobox, listview};
> enum class SuperWidget : Widget {iconview}

The current state would not disallow such an extension in the future,
so what is the problem?

> This way iconview would be equal to 3, not 0.

Maybe, that would depend on an actual proposal that describes the
semantics in this way.

> 3) Redefining the underlying type could be easily done with:
> enum class Val { unsigned long E1, E2, E3, E4 };
>
> This is much more neat and is similar to a declaration of multiple
> instances:
> const unsigned long E1, E2, E3, E4;

I don't consider this alternative as superior as the current state. To
me it looks, as if Ei (i=1-4) are data members of Val. It would imply
to me that I could write

enum class Val { unsigned long E1; unsigned long E2; unsigned long E3,
unsigned long E4; };

Does that mean that we could also use different underlying types for
individual enumerator values?

HTH & Greetings from Bremen,

- Daniel Kr   gler


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

On 2011-08-16 21:28:17 +0000, Phil Bouchard said:

> Hi,
>
> Is it too late to change the strongly type enum?

Yes, C++11 has been unanimously approved. It will be an official
standard in a few weeks.

No, work is just starting on the next version of the C++ standard.

>  I have a proposal
> that is much cleaner than what is on its way.
>
> Right now we have:
> enum class Val: unsigned long { E1, E2, E3, E4 };
>
> Comments:
> 1) This design is bad because the ':' sign is reserved for inheritance.

Really? Where does the standard say that it's "reserved"? <g>

It's currently used to indicate inheritance, to separate two
expressions in a ternary operator, and to mark the size of a bitfield.

>
> 2) Inheriting from another enum would be quite useful.  For example:
> enum class Widget {button, combobox, listview};
> enum class SuperWidget : Widget {iconview}
>
> This way iconview would be equal to 3, not 0.

Sure. That's not precluded by using ':' to indicate that an enum is
based on an integral type.

--
 Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)


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

Phil Bouchard <philippe@fornux.com> writes:

> Is it too late to change the strongly type enum?  I have a proposal
> that is much cleaner than what is on its way.

Too late.

> Right now we have:
> enum class Val: unsigned long { E1, E2, E3, E4 };
>
> Comments:
> 1) This design is bad because the ':' sign is reserved for inheritance.

It makes perfect sense to me. Sub-classing is restriction. You define
Val as a restriction of unsigned long to four possible values (and you
give symbolic names to these values to make sure you do not violate the
restriction). A Val "is a" unsigned long.

> 2) Inheriting from another enum would be quite useful.  For example:
> enum class Widget {button, combobox, listview};
> enum class SuperWidget : Widget {iconview}

This contradicts with the meaning of sub-typing, which is restriction,
and which you use here as augmentation. Assigning a value of type
SuperWidget to a variable of type Widget would be forbidden, if I
understand your example correctly. The exact opposite of what happens
between a sub-class and its base-class.

> 3) Redefining the underlying type could be easily done with:
> enum class Val { unsigned long E1, E2, E3, E4 };
>
> This is much more neat and is similar to a declaration of multiple instances:
> const unsigned long E1, E2, E3, E4;

In my opinion, this looks much like a list of members. I know, unions do
this already, but there's "class" in the type declaration here.

-- Alain.


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

Phil Bouchard wrote:
>
> Right now we have:
> enum class Val: unsigned long { E1, E2, E3, E4 };
>
> Comments:
> 1) This design is bad because the ':' sign is reserved for inheritance.

I see no problem so far.

> 2) Inheriting from another enum would be quite useful.  For example:
> enum class Widget {button, combobox, listview};
> enum class SuperWidget : Widget {iconview}
>
> This way iconview would be equal to 3, not 0.

I had the same idea some time ago. However, poeple told me that it is
not that easy.

First of all inheriting from a type implies that slicing is possible.
But SuperWidget can't ever be safely converted to Widget, becuse
Widget can't take the value iconview. In fact it is the other way
around. Widget is Safely a SuperWidget. The covariance/contravariance
is swapped.


> 3) Redefining the underlying type could be easily done with:
> enum class Val { unsigned long E1, E2, E3, E4 };

This implies that the type is specific to each enum constant. It isn't. IMO

 enum class Val: unsigned long

is fine. Val is an unsigned long, but it cannot be implicitly
converted because it is a private base.


Marcel


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

On 8/18/2011 9:52 AM, Marcel M   ller wrote:
>
>>  3) Redefining the underlying type could be easily done with:
>>  enum class Val { unsigned long E1, E2, E3, E4 };
>
>  This implies that the type is specific to each enum constant. It isn't. IMO
>
>  enum class Val: unsigned long
>
>  is fine. Val is an unsigned long, but it cannot be implicitly
>  converted because it is a private base.

I made another mistake.  The bitfields technically should be declared as
follows:
enum class Val { unsigned long E1 : 2, E2 : 2, E3 : 2, E4 : 2 }

I'm sure the syntax could change to the following:
enum class Val { unsigned long E1, E2, E3, E4 : 2 }


-Phil


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

Phil Bouchard wrote:
>  Hi,
>
>  Is it too late to change the strongly type enum?  I have a proposal
>  that is much cleaner than what is on its way.
>

Considering that C++11 was officially approved Wednesday last week, it
seems to be too late.  :-)


http://herbsutter.com/2011/08/12/we-have-an-international-standard-c0x-is-unanimously-approved/



Bo Persson



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

On 17/08/2011 04:28, Phil Bouchard wrote:
>
>  Hi,
>
>  Is it too late to change the strongly type enum?

Far too late. The new Standard has been voted out (21 yes, 0 no)
  I have a proposal
>  that is much cleaner than what is on its way.
In your opinion.
>
>  Right now we have:
>  enum class Val: unsigned long { E1, E2, E3, E4 };
>
>  Comments:
>  1) This design is bad because the ':' sign is reserved for inheritance.

Since when? The colon (:) is used in several places in C++ that have
nothing to do with inheritance.
>
>  2) Inheriting from another enum would be quite useful. For example:
>  enum class Widget {button, combobox, listview};
>  enum class SuperWidget : Widget {iconview}
Yes, but the above use does not prevent us from doing this if we decide
it is a good idea.

>
>  This way iconview would be equal to 3, not 0.
I am not sure that that follows.
>
>  3) Redefining the underlying type could be easily done with:
>  enum class Val { unsigned long E1, E2, E3, E4 };
Yes but is that better than what we have?
>
>  This is much more neat
In your opinion.
  and is similar to a declaration of multiple
>  instances:
>  const unsigned long E1, E2, E3, E4;
>

However that is all academic because we now have the syntax that you
dislike so all you can do is learn to like it :)



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