attach metadata to enum values ? about better-enums HOT 2 CLOSED

Hi :)

These syntaxes do look nice, but the tricky part is how to get them parsed and output something that will get parsed by the compiler, and how to keep them optional.

Currently, Better Enums takes advantage of being able to dump the ... inside BETTER_ENUM(Foo, int, ...) directly into an enum class, so enum class {...}, and, parsing only top-level commas using the preprocessor, into an array declaration in slightly modified form, so _values = [slightly_modified(...)]. From there, the compiler takes over the parsing. You can see a simplified, but fully-working sketch in this StackOverflow answer. It focuses exactly on what Better Enums does to get the compiler to parse the declarations.

Having these inner curly braces seems like it will prevent this parsing. We could probably get them treated as initializer lists for the _values array declaration, for some type that casts to integers, but I don't think they would parse at all inside an enum class. In fact, being valid syntax for enum class is going to be the limiting factor in the current Better Enums approach, I think.

I had some ideas for using some overloaded operators to associate metadata with constants. But, the only operator that can appear to the right of an enum constant inside enum class is =, and it's not actually an operator, but another piece of syntax, in that context. So, basically, I believe we can only use =. The only way we can get to use other operators inside an enum class is by asking the user to always use =, then on the right side we get an expression, and we can ask the user to write just about anything in there. But then we lose automatic value assignment... So, I'm not sure what to do in this approach.

There may be better ways of generating the enum class than just pasting in a big, opaque token string like done now. I haven't really kept up with C++17, so perhaps there is something there :)

I recall messing around with heavier preprocessor parsing, like done by Boost, but I didn't find the results satisfactory, and I don't seem to have documented why. You're welcome to experiment with it, and I'd be happy to know the results :)

from better-enums.

There is also this, about building bidirectional maps between a Better Enum and any types. Together with switch exhaustiveness checking, it should give you fully-checked compile-time maps. Not sure how good it is in practice, though.

from better-enums.