[morelisp]

In C the enum declaration is - by idiom and also syntax - contained a single declaration. You can construct values outside those, but as a default assumption the compiler/linter has a reasonable list of values to claim "these are the enum values which need handling".

In Go the values are not in a single declaration, and not even in a single TU. The strongest hint that this is an enum and not some other kind of integral newtype is the use of `iota` on the first declaration, but `iota` is also used for other purposes.

You're technically correct that they're "behaviorally the same", but declaration structures matter a lot.

[randomdata]

> but `iota` is also used for other purposes.

According to the Go spec[1] iota exists specifically for enum generation. The closure of the enum is also defined. There is no other intended purpose. If a developer has found a new way to overload it in some new way they can equally do the same in C, so that is moot. Enums are not sum types in either language, with no expectation of behaving like sum types, there is no debate about that. They are simply enums.

[1] https://go.dev/ref/spec#Iota

[masklinn]

> According to the Go spec[1] iota exists specifically for enum generation.

This assertion is nowhere in the Go spec, not even implicitly.

`iota` is a convenience sequence generator, it is no more "specifically for enum generation" than sqlite's AUTOINCREMENT qualifier is. Or excel's cell-sequencing system.

Further demonstrating that the goal was not to replicate C enums, iota can not be advanced manually save by adding intermediate discarded case.

> If a developer has found a new way to overload it in some new way they can equally do the same in C

No, they can not, literally the second example of your link has to be written and maintained entirely by hand in C, to say nothing of the second example block.

> Enums are not sum types in either language, with no expectation of behaving like sum types, there is no debate about that. They are simply enums.

Go still does not have enums, and your generalised statements about enumerated types remain incorrect regardless of sum types.

[randomdata]

> This assertion is nowhere in the Go spec, not even implicitly.

The first line explicitly defines their use for defining enums. The only way it could be more clear would be to define enum, but that should be unnecessary given that the definition is usually well established, although certainly a couple of languages have tried to muddy those waters in recent times.

> `iota` is a convenience sequence generator

More importantly, it defines a set of values. The set is what differentiates an enumeration from a general bag of constants. C reaches for a enum keyword instead, but they achieve the same result of establishing a set.

> Go still does not have enums

It has enums. It doesn't have sum types. Yes, some languages call sum types enums, which is no doubt where your confusion lies.

[morelisp]

> The closure of the enum is also defined

No it's not, you can write totally heterogeneous types in a single const block, as well as intermix iotas and literals. iota may count the same sequence spread across multiple types. There's not even a guarantee that the type definition and the const block exist in the same TU!

> There is no other intended purpose.

It is often used to generate private context keys, for example.