No, Go enums are definitely separate types. Sure, technically there is also an integer (or some other base representation) hidden in there somewhere, but that's what an enumeration is. Without that you don't have an enum.
Creating new types wrapping int is not really the same thing. It's not a closed set. Presumably one could define additional overlapping constants with the same integer type elsewhere?
It has a lot to do with enums, especially if you are claiming statically typed enums. When defining a type, more often than not, we want to define the values that make up the set. For example, 'type boolean = true | false'
> we want to define the values that make up the set. For example, 'type boolean = true | false'
Sure, or, more relevant, `type monthOrdinal = 1-12` or `type email = {string}@{string}`. Any advanced type system will allow for that, of course, but Go does not. It does not even pretend to claim to be an advanced language. It has, quite explicitly, chosen to not be.
Yes, you are right that if Go had value constraints then an enum type could utilize those constraints, but, again, nothing to do with enums themselves. You are confusing unrelated features.
Actually I think you are. For example, almost all statically typed languages since Pascal do not have value constraints but support typed enums as closed sets. There's no advanced type system needed - no need to define enums as integers and then put additional constraints in the type system to try and restrict this. There is also no need to model enums as integers in the type system in order to use integers as a runtime representation.
You can't have closed enums without value constraints. Yes, some languages have been lazy and provided value constraints only for enum types.
Which is an interesting choice: Give a noose for developers to hang themselves with for every single other type other than enums – the types they are going to use most often – and not think twice, but then go full on helicopter parent when using enums – the one type that isn't particularly interesting.
It's a neat parlour trick, don't get me wrong, but I guess that's why almost all of the popular statically typed languages since Pascal (C, C++[1], Typescript[2], etc.) didn't bother with closed enums. They put their time into features that actually mattered to developers instead.
[1] Added later in life, granted.
[2] Ironically, does support value constraints except in the case of using enum.
> You can't have closed enums without value constraints
Sum types and closed enums don't need to constrain existing sets of values, they define the set of values. Again, I think you might be confusing the type system with runtime representation.
> It's a neat parlour trick, don't get me wrong,
It's a step towards sum types which are the mathematical dual of product types. Not a parlour trick at all, every modern language should have algebraic data types.
