> From my experience, things I think Go could really benefit from [...] Enums Obviously it already benefits from enums. type E int const ( A E

> From my experience, things I think Go could really benefit from [...] Enums Obviously it already benefits from enums. type E int const ( A E = iota B C ) Which, once you get past the superficiality of syntax, is identical to, say, what you find in C. enum E { A, B, C } Enums are just a numbering mechanism, after all. No different than hand numbering constants, but without the need to put in the manual effort. Enums kind of suck, though. Are you sure any language actually benefits from them (as compared to better alternatives)? > especially if the need for exhaustiveness checking It is true that gc doesn't make any effort to determine how the enums are used, but if it were to it would be a warning like as is seen in many C compilers. As enums are values, not a type, it's not a fault to use them "inappropriately". While it may be all fine and dandy to add such warnings to gc, the Go team has taken a hard line stance that warnings have no place in the compiler. Of course, the external analysis tools like you speak to can still be used to provide these warnings for you. All the information you need is there. But it seems what you really want is a more expressive type system – specifically sum types. Then you would be able to describe how you expect identifiers to be used without resorting to using generated number values as placeholders. Enums are just a hack to work around a limited type system anyway. If you are going to improve the type system in order to gain improved compilation constraint, you don't need enums anymore. Rust doesn't have enums and nobody has ever noticed. Hell, many are even somehow convinced it has enums – but it does not. It provides tag-only unions (with, optionally, fully tagged unions) instead. Seemingly that is what you really want in Go as well. And fair enough. It is undeniably the better solution, but at the cost of being more complex to implement.