Closed gjvnq closed 5 years ago
While I like the idea, what would const Test = iota
be? iota
should always be an untyped integer constant. Perhaps a different name would be more fitting.
If the type is not specified it becomes a number just like today.
I agree that a sperate name would be better, maybe siota
(s
meaning string) or str_iota
or string iota
(with a space)
I think the last option (string iota
) is better because it does not risk backward compatibility problems. (What if someone has a variable named siota
or str_iota
)
Why declare enum values as strings? Generally, you just need the values to be unique and simple, so integers are fine. If you need to represent them as strings, you can use https://godoc.org/golang.org/x/tools/cmd/stringer.
Because printing strings is easier than ints. I don't need a conversion function or a mapping table to print my errors and understand them.
This is precisely what String()
methods are for, which is what stringer produces. fmt.Println(someEnumValue)
will work out of the box with stringer, just like any %s
or %v
formatting.
I think the last option (string iota) is better because it does not risk backward compatibility problems. (What if someone has a variable named siota or str_iota)
Making a new predeclared identifier doesn't introduce backward compatibility problems. iota
is a predeclared identifier (rather than a keyword). Also, iota
is used already in other programming languages to signify a number which increases with each variable declared, I wouldn't use iota
to signify this too, nor would I use striota
or siota
or whatever else. I think it should have its own, independent identifier.
@mvdan is also right that code generation with the stringer command already takes care of this.
I would have sometimes liked a feature such like this, but more often than not, I wouldn't want the string to match my constant name exactly. Worse, if one changes a constant's name, for instance when changing whether a constant is exported or not, the string would change, too, which seems not a desirable feature.
It also seems a bit unfortunate to "reuse" iota
for this purpose: iota
right now has a very simple definition: it's the (untyped integer) index of the constant declaration (specification, to be exact) starting at the const
keyword. Giving it an extra meaning here adds complexity to the language for a relatively minor convenience.
But most importantly, we do have the stringer
command as pointed out by @mvdan, which specifically addresses this problem. For a typical use with plenty of constants that need string names, see for instance $GOROOT/src/cmd/compile/internal/syntax/tokens.go
. Specifically, the -linecomment
gives you extra flexibility in the choice of string representation.
I'm not in favor of this proposal.
it seems to me that the most natural way to do it would be to allow
const (
MONDAY = string(iota)
TUESDAY
WEDNESDAY
THURSDAY
FRIDAY
SATURDAY
SUNDAY
)
which keeps iota unchanged and adds the cast. This compiles now and gives FRIDAY == "\x04", what is new is making the meaning of string in this context be "itoa".
Thanks, but we already have the stringer tool, and that seems like the right tool for this job.
Problem
We can write code like this:
But not like this:
Proposal
Make
iota
return strings with the same value as the const name.Example, this:
Is equal to this:
Why?
Simple, it makes writing code that use such enums easier, less boring and less error prone.
One good example is writing code that deals with errors:
Compatibility
Current Golang, gives this error when trying to compile code like the one proposed:
cannot convert 1 (type untyped number) to type string
As such I don't think that any old code will become incompatible.