| > Isn't really a good workaround when lacking an enumeration type. Enumeration isn't a type, it's a numbering construct. Literally, by dictionary definition. Granted, if you use the Rust definition of enum then it is a type, but that's because it refers to what we in this thread call sum types. Rust doesn't support "true" enums at all. > The compiler can't complain when you use a value that isn't in the list of enumerations. Well, of course. But that's not a property of enums. That's a property of value constraints. If Go supported value constraints, then it could. Consider: type Temperature 0..1
const (
Hot Temperature = 0
Cold Temperature = 1
)
Then the compiler would complain. Go lacks this in general. You also cannot define, say, an Email type: type Email "{string}@{string}"
Which, indeed, is a nice feature in other languages, but outside of what enums are for. These are separate concepts, even if they can be utilized together.> Enums are a big thing I miss when writing Go, compared to when writing C. Go has enums. They are demonstrated in the earlier comment. The compiler doesn't attempt to perform any static analysis on the use of the use of the enumerated values because, due to not having value constraints, "improper" use is not a fatal state[1] and Go doesn't subscribe to warnings, but all the information you need to perform such analysis is there. You are probably already using other static analysis tools to assist your development. Go has a great set of tools in that space. Why not add an enum checker to your toolbox? [1] Just like it isn't in C. You will notice this compiles just fine: typedef enum {
Hot,
Cold
} Temperature;
void setThermostat(Temperature temperature) {
switch (temperature) {
case Hot:
printf("Hot\n");
}
}
int main() {
setThermostat(10);
}
|
No, it isn't, unlike C, in which it is. The C compiler can actually differentiate between an enum with one name and an enum with a different name.
There's no real reason the compiler vendor can't add in warnings when you pass in `myenum_one_t` instead of `myenum_two_t`. They may not be detecting it now, but it's possible to do so because nothing in the C standard says that any enum must be swappable for a different enum.
IOW, the compiler can distinguish between `myenum_one_t` and `myenum_two_t` because there is a type name for those.
Go is different: an integer is an integer, no matter what symbol it is assigned to. The compiler, now and in the future, can not distinguish between the value `10` and `MyConstValue`.
> Just like it isn't in C. You will notice this compiles just fine:
Actually, it doesn't compile "just fine". It warns you: https://www.godbolt.org/z/bn5ffbWKs
That's about as far as you can get from "compiling just fine" without getting to "doesn't compile at all".
And the reason it is able to warn you is because the compiler can detect that you're mixing one `0` value with a different `0` value. And it can detect that, while both are `0`, they're not what the programmer intended, because an enum in C carries with it type information. It's not simply an integer.
It warns you when you pass incorrect enums, even if the two enums you are mixing have identical values. See https://www.godbolt.org/z/eT861ThhE ?