[015a]

`iota` is maybe the only language feature of Go that I would actually support removing. Obviously, they never will because it would be a breaking change. Its just so vestigial. There's literally no reason to use it, and a very big reason why you shouldn't: The encoded value can change any time you re-compile your program, so you can't actually use it for anything where the value of the enum leaves the process that instantiated it (e.g. marshaling to JSON and sending over the wire). That's a terribly poor characteristic for a feature in a "systems" (emphasis on plural) programming language to have, one would think.

[neilalexander]

> The encoded value can change any time you re-compile your program, so you can't actually use it for anything where the value of the enum leaves the process that instantiated it

This is not true, iota is stable in its ordering. https://go.dev/ref/spec#Iota

[mattrick]

I think they may be referring to if someone accidentally changes the ordering, either by inserting a new variant between two existing ones or by shuffling the order of the existing variants the value can change and cause problems.

[beautron]

Yes, but even with that interpretation, they claimed something much stronger:

> The encoded value can change any time you re-compile your program

Any value (not just enums) can change any time you re-compile your program, if some programmer goes in and messes it up.

The real, much softer criticism would be that Go requires its programmer's to understand the potential consequences of inserting or shuffling enum values (where iota is involved). It's a much weaker case against iota than what they stated.

[015a]

Ok, fair, yes what I meant is really that 'iota' is capable of introducing action-at-a-distance, albeit in uncommon situations, because new, preceding iota declarations within a const block change the values of subsequent iotas. This wouldn't happen every time you re-compile your program; I meant that more as a shorthand for "potentially can happen when your program changes"; and I can understand why that shorthand is confusing, because a much more poorly designed implementation of iota could actually, conceivably, change the iota values on every re-compile (in much the same way Go randomizes map iteration order, for example); and this is not what Go does.

[thiht]

Agree, iota is terrible. I think I encountered exactly one time where iota was a good fit for what I wanted to do (an internal representation of some kind, so whether the value changes in the future was irrelevant), but even then it was just needlessly opaque compared to just assigning values.

Real enumerations/discriminated unions is the one thing I consistently wish for in the Go annual surveys

[gembeMx]

Why iota show you a knuckle sandwich