| > It does. No. > By definition, an enum is simply a set of named values That is not the definition of "an enum", no. "an enum" does not imply a complete absence of any sort of type safety. "a C-style enum" might, but that is not the distinguishing characteristic of C-style enums, the lying is, otherwise literally every language which has constants has C-style enums, including every language with sum types. > and is behaviourally the same as C. Except for all the ways in which C enums mislead users into assuming any sort of non-existent type-safety guarantees. There is a critical distinction between "C-style enum", aka a misleading pile of garbage, and "just a bunch of constants". The latter is what Go provides. > While true, that is a feature of sum types That is not correct. For instance Java enums are not sum types, but are a type-safe, closed, set of values. |
Sum types are where you expect to find type safety. Some languages call sum types enums, which I expect is where the confusion lies. Neither Go nor C have sum types.
> literally every language which has constants has C-style enums
I think that ultimately that's a fair assertion, but one might argue that the definition does imply some kind of defined set. Both C and Go define syntax for characterizing enums in an established set which the machine can determine where the set boundaries lie. A language with only constants relies on human interpretation of what defines the set.
> For instance Java enums are not sum types, but are a type-safe, closed, set of values.
That's a sum type, also known as a tagged union. Neither Go nor C has those, as has been established multiple times now.