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.
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.
