Language:

• This would be a fully backward-compatible language change.

Seems problematic to me: https://play.golang.org/p/c0BE0M_WYI

@cznic how so? iota is a predeclared identifier, and you're replacing it with a constant. iota wouldn't work in that case with constants, either: https://play.golang.org/p/d2TVAZ1AU9

I know it's the same as with constant, it's just now double the surface. So questions also like "Why do my var-enums not work?" will be coming. I don't think adding the feature is worth complicating the language.
(A tiny addition to the complexity, sure, but non zero and they sum up.)

@cznic It's arguably less complexity in the language because now the same syntax and mechanism can be used for constants and variables. The question you're afraid might be coming up would have surfaced already now as it's quite common to have sequences of grouped constant declarations. iota is special in the language, like true and false, etc. You're in hot waters if you redeclare predeclared constants.

Unrelated: The reason I brought this issue up in the first place is that it might be another stepping stone towards addressing the desire for "enums" by some. Making it easier to declare groups of variables, perhaps together with a mechanism to enumerate over them might be a more Go-like approach than the the more heavy-weight enum support that is found in other languages.

This would be useful for stuff like type Exported { unexported int } where you want the identity but to hide the "numberness" of the value from the outside world

The main problem I have with this is that these are indeed variables, not constants, with the associated possibility of modification, and the lack of possibility for optimisation. That's a whole other can of worms though, of course.

@rogpeppe that's valid but the orthogonal concept of creating immutable values could handle that.

Wouldn't this be unnecessary if we allowed non-{string, numeric} constants?

@faiface Probably, but that is not a simple change.

type foo struct {
  n int
  s string
}
var (
  a = foo{n: iota, s: "a"}
  b = foo{s: "b"}
)

Does b.n == 1? It seems like that's what one would want but also that that's not how it would work.

@jimmyfrasche b.n would be zero, of course. The initialization expression for b is present, so it is used. There's no iota in there.

This would be a fully backward-compatible language change.

Technically not fully. This code would now fail to compile: https://play.golang.org/p/GIz4UoSAKrD (Today the -iota expression evaluates to 0; but this proposal would change it to -1, which isn't representable as uint.)

But I think it's reasonable to assume no one writes obscure code like that except me when I'm coming up with contrived language spec test cases (e.g., #15550).