On Monday, 15 July 2013 at 11:00:59 UTC, Dicebot wrote:
> 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))".

That might solve the partitioning problem and solve part of the hierarchical problem but won't allow submember access, e.g., colors.red.redorange. It seems like a good start though.

I imagine one could potentially build up a set of nested struct with immutable members representing the enums:

final immutable struct Colors
{
	final immutable struct Red
	{
		private immutable int _Red = 10000;
		immutable int RedOrange = 10001;
		alias _Red this; // obviously doesn't work
	}

	final immutable struct Green
	{
		immutable int Green = 20000;
	}

}

but with the glitch on the alias(Colors.Red doesn't work)... which sort of throws a kink in the solution making more than a 2-deep nest useless.

On Monday, 15 July 2013 at 13:01:05 UTC, JS wrote:
> ...

I see. No, unfortunately, I am currently not aware of a way to make symbol act as type and and value at the same time.

However it is worth noting that you use plenty of excessive attributes. Currently it is not a compiler error but makes code much harder to read and confusing. For example, "final" has no meaning for structs as they can't be inherited from anyway. Duplicating immutable is also excessive because it is transitive.

On Monday, 15 July 2013 at 13:47:10 UTC, Dicebot wrote:
> On Monday, 15 July 2013 at 13:01:05 UTC, JS wrote:
>> ...
>
> I see. No, unfortunately, I am currently not aware of a way to make symbol act as type and and value at the same time.
>
> However it is worth noting that you use plenty of excessive attributes. Currently it is not a compiler error but makes code much harder to read and confusing. For example, "final" has no meaning for structs as they can't be inherited from anyway. Duplicating immutable is also excessive because it is transitive.


Original I had it as a class. I'm not sure if it matters much between a class and a struct though?

In any case, I solved this problem by using an attribute to test instead of using isMutable. Obviously this requires adding a symbol but not a huge deal.

e.g.,

@Enum immutable struct ...

and hasAttribute(T, Enum) replaces isMutable(T).

On Monday, 15 July 2013 at 18:26:26 UTC, JS wrote:
> Original I had it as a class. I'm not sure if it matters much between a class and a struct though?

It does matter a lot. structs are value types, classes are polymorphic reference types. There is a nice summary table in docs: http://dlang.org/struct.html , please notice that "inheritance" and this "final" applies only for classes.

> In any case, I solved this problem by using an attribute to test instead of using isMutable. Obviously this requires adding a symbol but not a huge deal.
>
> e.g.,
>
> @Enum immutable struct ...
>
> and hasAttribute(T, Enum) replaces isMutable(T).

Yeah, that may work, despite being not that pretty. I personally think it is better for now chose some not-that-elegant approach in your code, at least until enums will become more robust. Currently it tries to workaround some very basic type system assumptions, which rarely ends good.

On Monday, 15 July 2013 at 19:24:27 UTC, Dicebot wrote:
> On Monday, 15 July 2013 at 18:26:26 UTC, JS wrote:
>> Original I had it as a class. I'm not sure if it matters much between a class and a struct though?
>
> It does matter a lot. structs are value types, classes are polymorphic reference types. There is a nice summary table in docs: http://dlang.org/struct.html , please notice that "inheritance" and this "final" applies only for classes.
>
um, but I'm only using the type at compile time. the immutable fields in it all result in compile time literals... the struct itself never gets used at run time... so there is no runtime difference(or shouldn't be) except maybe a little more wasted space with the class unless it is optimized out.


>> In any case, I solved this problem by using an attribute to test instead of using isMutable. Obviously this requires adding a symbol but not a huge deal.
>>
>> e.g.,
>>
>> @Enum immutable struct ...
>>
>> and hasAttribute(T, Enum) replaces isMutable(T).
>
> Yeah, that may work, despite being not that pretty. I personally think it is better for now chose some not-that-elegant approach in your code, at least until enums will become more robust. Currently it tries to workaround some very basic type system assumptions, which rarely ends good.

I really don't have 10 years to wait for enums to become more robust and hope in the way I am trying to use them.

JS:

> 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?

In Ada you can define ranged types, and there is a keyword to define their subtypes:

type Day is
   (Monday,
    Tuesday,
    Wednesday,
    Thursday,
    Friday,
    Saturday,
    Sunday);

-- Derived types, they are new incompatible with the original:
type Business_Day is new Day range Monday .. Friday;
type Weekend_Day is new Day range Saturday .. Sunday;

-- Subtypes that convert implicitly to their supertype:
subtype Business_Day is Day range Monday .. Friday;
subtype Weekend_Day is Day range Saturday .. Sunday;
subtype Dice_Throw is Integer range 1 .. 6;

The Ada compiler enforces static typing where possible, and uses dynamic tests where it can't (and the dynamic tests can be disabled with a compiler switch). So if assign a generic integer to a Dice_Throw, the Ada compiler performs a run-time test to see if it's in the correct range.

Ada code is based on similar things that avoid/catch lot of bugs.

Bye,
bearophile