Hi, Thanks for the comments.
A. get rid of the leading _ un function names.
The reason I chose to add the _ is that the function names occupy the same namespace (I don’t mean the C++ keyword) as the constant names, i.e. if I had a function such as “Channel::valid()" it would conflict with a potential user-declared constant Channel::valid. I’m open to better suggestions than using underscores, though. I had an alternative implementation (which is internally almost the same), in which the ENUM macro generated type traits over an enum (or enum class, in C++11), instead of wrapping an enum in an object, as now. That is, instead of notionally generating struct Channel { enum _enumerated { … }; // Methods }; it generated enum class Channel { … }; template <> struct traits<Channel> { // Methods }; In this implementation, the methods were in their own namespace, so there was no need to use underscores. Also, there was no need to have operator+, and the interface, in general, was very uniform. However, the usage was usually much more verbose: Channel::_from_string(“Red”); vs. better_enums::traits<Channel>::from_string(“Red”); I could get some degree of type inference to happen by wrapping the traits functions in freestanding template functions, but it was still too verbose (IMO), and also threw away the advantage of a uniform and easy-to-remember interface. There might be a way to make this work nicely - I am open to suggestions. It might actually be possible to have decent syntax with traits, using some helper types to get type inference, along the lines suggested by Tony Van Eerd in an earlier message. I will look into that. However, I am working on a feature that allows the underlying type of a Better Enum to be any literal type that provides conversions to/from an integral type. It’s essentially an adapter between anything and the switch statement. That feature would not be possible with a traits approach in the form I outlined above.
B. make size a constexpr function
What would be the advantage to this? Uniformity of interface? Is there any disadvantage from this change? I generally want to move in the direction of making more things available to C++03 metaprogramming, so I am worried about making constants into functions.
C. add to_integral() (or is that done by a static cast?)
Do you mean this? http://aantron.github.io/better-enums/ApiReference.html#_to_integral I didn’t put it into the example in the README/documentation front page because it’s not much of a feature, and I’d rather save space. Do let me know if you think that’s misleading on my part.
Somthing to consider: One reaching for an enum, one very often needs a small statically sized, immutable bidirectional map. That is, the mapped strings needs not be the name of the enum constant. Key-value pair iteration may be useful and
Noted, thanks. I think this could be covered by a solution that would also take care of a use case Gavin Lambert described yesterday. I will look into it. And, thanks for the links. I did see the first one, but not the second. Best, Anton