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