Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
griesemer opened this issue Aug 16, 2017 · 11 comments

Comments

@griesemer
Copy link
Contributor

commented Aug 16, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Aug 16, 2017

Language:

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

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

@mvdan

This comment has been minimized.

Copy link
Member

commented Aug 16, 2017

@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

This comment has been minimized.

Copy link
Contributor

commented Aug 16, 2017

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

This comment has been minimized.

Copy link
Contributor Author

commented Aug 16, 2017

@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 comment has been minimized.

Copy link
Member

commented Aug 16, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Aug 16, 2017

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

This comment has been minimized.

Copy link
Member

commented Aug 16, 2017

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

@faiface

This comment has been minimized.

Copy link

commented Aug 18, 2017

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

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Aug 18, 2017

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

@jimmyfrasche

This comment has been minimized.

Copy link
Member

commented May 29, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented May 29, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
8 participants
You can’t perform that action at this time.