## Scope and safety This tutorial shows some of the safety features of Better Enums: scope, how to control conversions, and the lack of a default constructor. $internal_toc ### Scope You have probably noticed by now that Better Enums are scoped: when you declare #include #include ENUM(Channel, int, Red = 1, Green, Blue) you don't get names such as `Red` in the global namespace. Instead, you get `Channel`, and `Red` is accessible as `Channel::Red`. This is no big deal in $cxx11, which has `enum class`. In $cxx98, however, this typically requires effort. Better Enums brings scope uniformly to both variants. So, despite the above declaration, you can safely declare ENUM(Node, char, Red, Black) and everything will work as expected. int main() { assert((+Channel::Red)._to_integral() != (+Node::Red)._to_integral()); ### Implicit conversion A major complaint in $cxx98 is that `enums` are implicitly convertible to integers. Unfortunately, that is also true of Better Enums, and I haven't found a way to forbid the conversions and still have switch case checking. Better Enums can be made as safe as `enum class` in $cxx11, however. If your compiler supports `enum class` and you define `BETTER_ENUMS_STRICT_CONVERSION` before including `enum.h`, the following code will not compile: ~~~comment Channel channel = Channel::Red; int n = channel; ~~~ The reason this is not enabled by default is explained in the reference page on [strict conversions](${prefix}OptInFeatures.html#StrictConversions). ### Default constructor Better Enums don't have a default constructor, for three reasons. - Better Enums is a library that can't know what your application would like the default value to be for each enum, or whether you even want one. - I chose not to leave the default value undefined, because the idea is to encourage the convention that whenever a Better Enum exists, it has a valid value. This is borrowed from typed functional programming. - Better Enums is still under development, and this option is the most future-proof. So, if you uncomment this code, the file won't compile: ~~~comment Channel channel; ~~~ This may be too strict, and I may relax it in the future. In the meantime, the solution sketched in the [special values demo](${prefix}demo/SpecialValues.html) can replace default constructors for some purposes, and in a more flexible way. I may eventually have the default constructor calling a template function like the one in that demo. --- return 0; } %% description = Type safety features and limitations.