Just to double check my understanding: are you talking about raw pointers (i.e. void*) being common in C++ and not in Rust? You're right that I was using ADT a bit loosely; to be honest the main value add for me has been the first class data-holding enums/sum types. C++ has std::variant, but the syntax support in Rust feels nicer.
You can't trust pointers have a value, or that the value is valid, you can't trust that your enums have a value inside their interval, or in fact you can't trust that any value from any type is inside its interval at all.
You also can't really trust that your values have the correct size.
We choose some of those to ignore, otherwise we wouldn't be able to program at all, but C++ gives you no guarantees at all about anything. The point is that if you do a parsing run in C++ and encode your value, you will still get many of the above problems because of bugs in your code.
If you don't set the underlying type, assigning a value that doesn't match an enumerator via `static_cast` is undefined behavior. See https://en.cppreference.com/w/cpp/language/enum . (Doing weird pointer casting things is also undefined behavior per the strict aliasing rule, though, come to think of it, I'm not sure whether memcpying an out-of-range value into an enum through the "reinterpret_cast to `char*`" loophole is undefined behavior.)
> If the underlying type is not fixed and the source value is out of range, the behavior is undefined.
Note the fine print about the meaning of ”out of range”:
> (The source value, as converted to the enumeration's underlying type if floating-point, is in range if it would fit in the smallest bit field large enough to hold all enumerators of the target enumeration.)
So this is not undefined:
enum E { A = 0, B = 1, C = 2 };
E valid = static_cast<E>(3);Choosing one just makes a difference because code has problems.