Private enum members + Descent

[Denis Koroskin]

On Sun, 25 Oct 2009 02:22:51 +0300, Michel Fortin  
<michel.fortin at michelf.com> wrote:

> On 2009-10-24 18:45:10 -0400, Justin Johansson <no at spam.com> said:
>
>> Let me try again.  You have a set of N things which are represented by
>> an enum definition.  There is some subset of this set containing M
>> things (so M < N) which represents the things meaningful in a public
>> sense.  The remaining Q=N-M members of the whole set are only meaningful
>> to some internal processing so this subset containing Q members are
>> designated private.  I'm trying to think about this problem in an  
>> abstract
>> way; sometimes giving concrete examples like Color colors (pun intended)
>> the abstract problem.
>
> Sounds like you want enum inheritance: one enum being a superset of  
> another.  :-)
>
>

It was previously proposed, but it was rejected because it works  
"backwards": downcasting is allowed while upcasting is prohibited.

Consider the following example (taken from DMD):

enum Token
{
     colon,
     semicolon,
     eof,
     // ...
     max,
}

enum AsmToken : Token // "extend" an existing enum
{
     dword, // = Token.max + 1 implicitly
     even,
     far,
     naked,
     near,
     ptr,
     qword,
     seg,
     word,
}

Now this is very useful, and less error prone than manual enum values  
management. Less jump to the usage:

AsmToken tok1 = Token.colon; // fine
Token tok2 = AsmToken.dword; // error

The two lines above are exact opposite of class/interface inheritance  
behavior:

class Token {}
class AsmToken : Token {}

AsmToken tok1 = new Token(); // error
Token tok2 = new AsmToken(); // fine

which makes sense but confusing for novices.

IIRC, Walter rejected the feature for exactly this reason.