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