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