That’s just someone that doesn’t know why people say things, so just made it up.
Enums outside of rust are indeed bad (I would correct it to enums in every language I know that is not rust, since maybe some other do the same thing as rust). But it’s not because the tagged union thing.
The problem of enums in other languages is that they do not make for a distinct type. They are just integers in a name. Or at least that is the case for C and Java enums. Python and JavaScript do not even have enums, which is even worse.
When enums are just integers, you don’t know if a variable of the type of the enum is actually one of the variants of the enum. If you assume that, you can easily get into undefined behavior/crash territory quite fast.
When making a library in C, for example, if one of your functions has an enum as a parameter, one of the first things you have to do is check if that parameter is actually in the range of the enum. Since you don’t control the caller to your function. These checks don’t belong in code at runtime, they belong to compile time, as you’re just validating the type of a variable.
In rust, switch/match statements need to cover every single enum variant (of course, you can also have default paths to not cover every case) your code just won’t compile if you don’t. Which means that when you add a new variant to an old enum, you don’t have to go hunting every match statement to see if it affects your new change. That is a tedious and error-prone task if done manually, while it is pretty simple for the compiler.
Of course, now that these differences are established, the tagged union thing comes in and makes rust ones better. The reason other language enums are bad is because they’re named integers, the reason rust’s are good is because they are tagged unions, completing the algebraic type system.
PHP enums can be backed by integers or strings but are distinctly typed and any signature that types them will be fatal even if the value matches that of a backed enum.
The problem of enums in other languages is that they do not make for a distinct type. They are just integers in a name. Or at least that is the case for C and Java enums. Python and JavaScript do not even have enums, which is even worse.
Strongly typed enums is hardly unique to Rust.
C++ has had them for a long time, for example: Using a plain integer type where an enum is expected has been prohibited since at least C++98. You can still use an enum in the place of an int, unless you use scoped enums (C++11 or later), which also require an explicit cast to convert from enum to the underlying type.
And Python has had some form of enum since since 3.4: https://docs.python.org/3/library/enum.html. It’s not a language level feature, but that probably wouldn’t make much of a difference, and it’s as type safe as anything else in the language. But you will get a error when using type-hints, if you pass the wrong type to a function expecting an enum:
from enum import Enum
classMyEnum(Enum):
A = 1
B = 2deffoo(_: MyEnum): ...
foo(1) # error: Argument 1 to "foo" has incompatible type "int"; expected "MyEnum" [arg-type]
The problem of enums in other languages is that they do not make for a distinct type. They are just integers in a name. Or at least that is the case for C and Java enums.
That’s just someone that doesn’t know why people say things, so just made it up.
Enums outside of rust are indeed bad (I would correct it to enums in every language I know that is not rust, since maybe some other do the same thing as rust). But it’s not because the tagged union thing.
The problem of enums in other languages is that they do not make for a distinct type. They are just integers in a name. Or at least that is the case for C
and Java enums. Python and JavaScript do not even have enums, which is even worse.When enums are just integers, you don’t know if a variable of the type of the enum is actually one of the variants of the enum. If you assume that, you can easily get into undefined behavior/crash territory quite fast.
When making a library in C, for example, if one of your functions has an enum as a parameter, one of the first things you have to do is check if that parameter is actually in the range of the enum. Since you don’t control the caller to your function. These checks don’t belong in code at runtime, they belong to compile time, as you’re just validating the type of a variable.
In rust, switch/match statements need to cover every single enum variant (of course, you can also have default paths to not cover every case) your code just won’t compile if you don’t. Which means that when you add a new variant to an old enum, you don’t have to go hunting every match statement to see if it affects your new change. That is a tedious and error-prone task if done manually, while it is pretty simple for the compiler.
Of course, now that these differences are established, the tagged union thing comes in and makes rust ones better. The reason other language enums are bad is because they’re named integers, the reason rust’s are good is because they are tagged unions, completing the algebraic type system.
PHP enums can be backed by integers or strings but are distinctly typed and any signature that types them will be fatal even if the value matches that of a backed enum.
Strongly typed enums is hardly unique to Rust.
C++ has had them for a long time, for example: Using a plain integer type where an enum is expected has been prohibited since at least C++98. You can still use an enum in the place of an int, unless you use scoped enums (C++11 or later), which also require an explicit cast to convert from enum to the underlying type.
And Python has had some form of enum since since 3.4: https://docs.python.org/3/library/enum.html. It’s not a language level feature, but that probably wouldn’t make much of a difference, and it’s as type safe as anything else in the language. But you will get a error when using type-hints, if you pass the wrong type to a function expecting an enum:
from enum import Enum class MyEnum(Enum): A = 1 B = 2 def foo(_: MyEnum): ... foo(1) # error: Argument 1 to "foo" has incompatible type "int"; expected "MyEnum" [arg-type]This is not the case for Java enums.
Yeah, my bad. Long time I don’t use java and miss remembered. Apparently proper java enums exist since 2004.