It would be nice to be able to use enums in a hierarchical way:

enum colors
{
     enum Red { RedOrange, ... }
     enum Green { GreenBlue, ...}
     enum Blue { BlueYellow, ... }
...
}

which would be the same as the flattened version,

enum colors
{
   Red, RedOrange, ..., Green, GreenBlue, ..., Blue, BlueYellow, ..., ...
}

but we could dereference such as

colors.Red.RedOrange,
colors.Blue,
colors.Green.GreenBlue,

(This isn't a great example but demonstrates what I would like to be able to do)

Is anything like this possible?

BTW, the usefulness is to group sub-enums into the same range. This would make it easy/efficient to branch over a range in the enum:

if (v in colors.Red) { v is a color in red }

instead of

if (v is color.Red || v is color.RedOrange || ...)

On Monday, 15 July 2013 at 04:27:42 UTC, JS wrote:
> BTW, the usefulness is to group sub-enums into the same range. This would make it easy/efficient to branch over a range in the enum:
>
> if (v in colors.Red) { v is a color in red }
>
> instead of
>
> if (v is color.Red || v is color.RedOrange || ...)

I guess a more intelligent structure is needed so changes in the enum do not break binaries. (although this is already somewhat of an issue with enums as changes in order requires a re-compilation)

On Monday, 15 July 2013 at 04:27:42 UTC, JS wrote:
> BTW, the usefulness is to group sub-enums into the same range. This would make it easy/efficient to branch over a range in the enum:
>
> if (v in colors.Red) { v is a color in red }
>
> instead of
>
> if (v is color.Red || v is color.RedOrange || ...)

if( v >= Red && v <= LastRed )

On Monday, 15 July 2013 at 07:37:36 UTC, Mike Parker wrote:
> On Monday, 15 July 2013 at 04:27:42 UTC, JS wrote:
>> BTW, the usefulness is to group sub-enums into the same range. This would make it easy/efficient to branch over a range in the enum:
>>
>> if (v in colors.Red) { v is a color in red }
>>
>> instead of
>>
>> if (v is color.Red || v is color.RedOrange || ...)
>
> if( v >= Red && v <= LastRed )

The problem is if a binary is already compiled and changes are made. If a red color is inserted your range has changed. Also, it requires you to keep your entries sorted properly. Also, a "LastRed" entry is needed and there is no other reason to have it.

Since an int is 4B entries, and that's way more than most will use, It think it's better to be able to have the compiler partition of the range for you and save "space" for future entries. This prevents an addition entry from screwing up everything.


e.g.,

enum colors
{
    enum Red : 1M { RedOrange, ... }
    enum Green : 2M {  ... }
    ...
}

In this case, one can have up to 1M unordered sub entries(should be plenty) and ~4.2k main entries. One could order further,


enum colors
{
    enum Red : 1M { enum RedOrange : 10k { }, ... }
    enum Green : 2M {  ... }
    ...
}

Basically the idea is to distribute the elements of enum and sub enums in such a way as to maximize space between each entry. This allows any binaries using an old version not to crash and burn. This does require an estimation of the maximum entries that will be used.

I'm particularly thinking of a messaging system where ints can be passed around with 10's of thousands of defined messages with messages grouped into common functionality(hence the inheritance aspect) and adding new messages won't ruin the communications between new and old systems.

Nested switch statements can easily and quickly pare down determination of a message(not as fast as a flattened hierarchy though).

Maybe this way?

----
final abstract class Colors
{
	enum Red { RedOrange }
	enum Green { GreenBlue}
	enum Blue { BlueYellow }
}

void main() {
	Colors.Red foo = Colors.Red.RedOrange;
	assert(foo >= Colors.Red.min && foo <= Colors.Red.max);
}
----

On Monday, 15 July 2013 at 08:20:20 UTC, Namespace wrote:
> Maybe this way?
>
> ----
> final abstract class Colors
> {
> 	enum Red { RedOrange }
> 	enum Green { GreenBlue}
> 	enum Blue { BlueYellow }
> }
>
> void main() {
> 	Colors.Red foo = Colors.Red.RedOrange;
> 	assert(foo >= Colors.Red.min && foo <= Colors.Red.max);
> }
> ----

but RedOrange and GreenBlue have the same value!

On Monday, 15 July 2013 at 10:17:08 UTC, JS wrote:
> On Monday, 15 July 2013 at 08:20:20 UTC, Namespace wrote:
>> Maybe this way?
>>
>> ----
>> final abstract class Colors
>> {
>> 	enum Red { RedOrange }
>> 	enum Green { GreenBlue}
>> 	enum Blue { BlueYellow }
>> }
>>
>> void main() {
>> 	Colors.Red foo = Colors.Red.RedOrange;
>> 	assert(foo >= Colors.Red.min && foo <= Colors.Red.max);
>> }
>> ----
>
> but RedOrange and GreenBlue have the same value!

Also, Colors.Red is not a value!

On Monday, 15 July 2013 at 10:23:22 UTC, JS wrote:
> On Monday, 15 July 2013 at 10:17:08 UTC, JS wrote:
>> On Monday, 15 July 2013 at 08:20:20 UTC, Namespace wrote:
>>> Maybe this way?
>>>
>>> ----
>>> final abstract class Colors
>>> {
>>> 	enum Red { RedOrange }
>>> 	enum Green { GreenBlue}
>>> 	enum Blue { BlueYellow }
>>> }
>>>
>>> void main() {
>>> 	Colors.Red foo = Colors.Red.RedOrange;
>>> 	assert(foo >= Colors.Red.min && foo <= Colors.Red.max);
>>> }
>>> ----
>>
>> but RedOrange and GreenBlue have the same value!
>
> Also, Colors.Red is not a value!
Then: good luck.

On Monday, 15 July 2013 at 04:24:59 UTC, JS wrote:
> ...

I think closest solution you can get is having bunch of private enum definitions and combining them into single public one via compile-time reflection. Something like "mixin(generateEnum!(Red, Green, blue))".