Dave Harris <brangdon@cix.co.uk> wrote:

> Qualified enum members.
[snip example]
> The semantics are similar to:

>    namespace HAlign {
>        enum Type { left, center, right, end, begin=left };
>    }
>    using namespace HAlign;

> except that we don't need a separate name for the namespace and the enum.
> Alas, I don't think it is feasible to just say that enums are namespaces.

Seeing this amid the discussion makes me wonder just how different enums are
from other 'composite' types like structs/classes. What would be the
differences between the following?

enum original{ first, second=2, third, last=third };

struct later{
  static unsigned const first = 0;
  static unsigned const second = 2;
  static unsigned const third = 3;
  static unsigned const last = third;
};

Things I can say straight away (about to rush off!) is:
- no default 'increase' in values (eg. first,third values specified)
- need for qualification on members (IMO a good thing, but breaks
                                                            back-compat.)
- possibility to hide the values of the enum options via initialisation in
  a source file
- -> not forcing the 'enum' to be effectively-inline?

The reason I say this is simply that if these are sufficiently 'overlapping',
then I could conceive of some system such as:

typedef composite{public} struct;
typedef composite{private} class;
typedef composite{public,static,unsigned,const} enum;

Of course I've not included enough, since I've not looked at how the above
differ at all. But hopefully it is fairly clear what I mean: specifying the
default type (incl. access) of composite members.

Such a system would allow something similar to:

typedef composite{public,unsealed} namespace;   // Hmmm. Dylan-esque?
typedef template<typename T>composite{public,static} trait;

Well, it would save some excessive typing ;) Oh, and (in principle) allow
the system to be more internally consistent?

Thoughts?

--
Neil

---
[ 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.research.att.com/~austern/csc/faq.html                ]