| > What is missing in the first case that wouldn't allow you to perform such static analysis? Type information. The only type info the compiler has is "integer". > It has a keyword to identify initialization of an enumerated set (iota), That's not a type. > it has an associated type (E) It still only has the one piece of type information, namely "integer". > and it has rules for defining the remaining items in the enumerated set That's not type information > That's all C gives you. No. C enums have additional information, namely, which other integers that type is compatible with. The compiler can tell the difference between `enum daysOfWeek` and `enum monthsOfYear`. Go doesn't store this difference - `Monday` is no different in type than `January`. > Warnings are not fatal. Maybe, but the warning tells you that they types are not compatible. The fact that the compiler tells you that the types are not compatible means that the compiler knows that the types are not compatible, which means that the compiler regards each of those types as separate types. Of course you can redirect the warning to /dev/null with a flag, but that doesn't make the fact that the compiler considers them to be different types go away. Whether you like it or not, C compilers can tell the difference between `Monday` and `January` enums. Go can't tell the difference between `Monday` and `January` constants. How can it? |
Nobody said it was. Reaching already? As before, enums are not a type, they are a numbering mechanism. Literally. There is an associated type in which to hold the numbers, but that's not the enum itself. This is true in both C and Go, along with every other language with enums under the sun.
> The compiler can tell the difference between `enum daysOfWeek` and `enum monthsOfYear`.
Sure, just as in Go:
> Go doesn't store this difference - `Monday` is no different in type than `January`.Are you, perhaps, mixing up Go with Javascript?
> How can it?
By, uh, using its type system...? A novel concept, I know.