[boost] [Better Enums] Non-integral underlying types

Subject: [boost] [Better Enums] Non-integral underlying types
From: Anton Bachin (antonbachin_at_[hidden])
Date: 2015-06-18 15:21:24

About a week ago, I generalized Better Enums somewhat to accept non-integral
underlying types, with some conditions and restrictions. I’d like to ask for
comments/opinions/ideas on this feature. I made a little write-up on it [1], but
I will summarize here as well. The write-up is a superset of the content of this
message, so don’t read the message if you click the link :)

If you have a literal type “foo”, you can do:

    ENUM(SomeEnum, foo, A, B = 2, C = foo(…))

    SomeEnum  value = SomeEnum::A;
    switch(value) {
        case SomeEnum::A: // …
        case SomeEnum::B: // …
        case SomeEnum::C: // ...
    }

The switch above can have its cases checked for exhaustiveness by the compiler.
Also, “value” above behaves like a “container” for one value of type foo, whose
members can be accessed using operator ->. So, basically, you can have
enumerated, reasonably type-safe sets of arbitrary literal types.

The catch is that you have to provide an invertible mapping from foo into some
underlying integral type, which mapping is declared either by equipping foo with
the right constructor and conversion operator, or specializing a traits
template. I would love to make a default implementation for this mapping, but it
seems like I need to achieve the effect of a reinterpret_cast at compile time,
and I haven’t been able to do so.

[1]: http://aantron.github.io/better-enums/GeneralUnderlyingTypes.html