Comparison of Enumerations with base type of String?

[Jonathan M Davis via Digitalmars-d-learn]

On Sunday, August 27, 2017 22:01:52 Michael Reiland via Digitalmars-d-learn 
wrote:
> whoa, you can use a struct as a basetype for an enum?  I'm
> guessing it allows you to associate more information with the
> enum without using lookup tables and the like?  And equality is
> probably just a memberwise comparison of the struct itself?
>
> That seems interesting like an interesting idea, although I'm not
> sure if I'd ever use it.

Yeah, you can use pretty much any type as a base type for an enum - though
once you're dealing with heap-allocated objects, it gets a bit entertaining,
just like it does with enums that are manifest constants. e.g.

enum a = [1, 2, 3];

will allocate that array every time that you use the enum. I don't think
that mutable or const classes will work, but you can also use immutable
classes, which should not result in an allocation every time (since they're
immutable, they can be put in the read-only segment by the compiler like
with string literals), but using structs almost certainly makes more sense
if you really want a user-defined type.

Basically, any time you have a group of constants that you want to treat as
a group of constants, an enum can make sense, even if those constants are
structs. Java implemented enums as classes, so this enables similar
capabilities to what you could do with enums in Java. I can't remember if
I've ever used a enum with a base type of struct though. Usually, I either
need ints or strings. I've definitely used manifest constants that are
structs, but actual enums that are structs are not something that I'v
frequently found useful, much as I'm glad that it's possible.

Ultimately, enums really aren't all that different from anything else with
the same base type except that you can't take their address, they're
basically copy-pasted wherever they're used (though it's the value that's
copy-pasted, not the expression used to create the value - so you wouldn't
end up with something like a struct constructor being called), some
operations aren't legal on them which are legal on the base type (mostly
assignment from non-enums), and anything which explicitly checks that
they're an enum may treat them differently. But overall, you'll mostly get
out of an enum what you'd expect from the base type. The only caveat that I
can think of at the moment with regards to performance is that dynamic
arrays (other than strings) result in an allocation every time they're used,
which can be surprising if you're not aware of it, and that applies to
manifest constants as well as proper enums. Really, manifest constants and
proper enums are pretty much the same thing except that proper enums declare
an actual type with a known set of values, whereas a manifest constant
retains its original type. The performance implications should be the same
though. And the fact that they're so similar is part of why the enum keyword
was reused, even though that annoys some folks, since a manifest constant
isn't really an enum.

- Jonathan M Davis