proposal: permit iota, omission of init expressions in var declarations

[griesemer]

This was discussed very early in the language design, at the same time when we also introduced iota for constant declarations: Permit iota and the omission of initialization expressions not only in constant but also variable declarations. For instance, this would permit code like:

var (
    mercury = NewPlanet(iota + 1)
    venus
    earth
    mars
    ...
)

If my memory serves me right, we didn't pursue it at the time because there was no compelling or urgent argument in favor of it.

Such a mechanism could simplify the construction of related named objects and open the door to "enum" values that are not restricted to constant values and their respective types.

As such it may be a more elementary building block towards more complex "enums" in Go (see also the discussion in #19814).

Implementation:

• Straight-forward changes would be required in the front-end of the compiler.

Language:

• This would be a fully backward-compatible language change.
• The change is fully orthogonal to existing features and would make variable and constant declarations more symmetric (and thus the language simpler).
• No new concepts are introduced as this is essentially syntactic sugar.

[cznic]

Language:

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

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

[mvdan]

@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

[cznic]

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

[griesemer]

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

[jimmyfrasche]

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

[rogpeppe]

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.

[jimmyfrasche]

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

[faiface]

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

[ianlancetaylor]

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

[jimmyfrasche]

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.

[griesemer]

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

[mdempsky]

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