ENUMs for custom types in GO

Question

I am trying to generate an enum for a type I defined

type FeeStage int

From this I learned that I can use iota to create an enum based on this type

const(
     Stage1 FeeStage = iota
     Stage2 
     Stage3
)

However, manipulating the actual values of the enum is rather cumbersome and error prone

const(
     Stage1 FeeStage = iota           // 0
     Stage2          = iota + 6       // 7
     Stage3          = (iota - 3) * 5 // -5
)

Is there a way to automatically convert a list of ENUMs with custom values to a certain type. This is what I was using before but only converts the first member of the constant to the custom type.

const(
     Stage1 FeeStage = 1
     Stage2          = 2
     Stage3          = 2
)

Here is a playground with a similar result

Does this answer your question? [What is an idiomatic way of representing enums in Go?](https://stackoverflow.com/questions/14426366/what-is-an-idiomatic-way-of-representing-enums-in-go) — Michael Freidgeim, Mar 28 '21 at 12:36

Not_a_Golfer · Accepted Answer · 2016-03-29T15:54:45.410

There's no way beyond either using iota and automatic enums, or doing the most straightforward thing:

const(
     Stage1 FeeStage = 1
     Stage2 FeeStage = 2

     // or another syntax with same results
     Stage3 = FeeStage(2)
)

which IMHO is less cumbersome than doing stuff like iota + 5 which as you said is really bad.

I usually either use iota if the value is not important beyond the context of the program, or explicit typing if I need the values to be used in a protocol or something.

Though I have to say sometimes just using ints or strings is good enough, it depends on the context. See for example the http status codes in the standard library. They don't have a special type.

Or without syntax just "const Stage1 = 1; varOfTypeFeeStage = Stage1" can also work in certain circumstances. — Uvelichitel, Mar 29 '16 at 16:49

score 2 · Answer 2 · answered Mar 29 '16 at 15:50

You should maybe clarify what you're actually wanting to do with enumerated constants, but it looks like you're trying to assign arbitrary values to your custom type.

Using iota doesn't need to be cumbersome if you structure your constants and the initialization to be ordered and to follow a pattern. Effective Go has a section on this too.

You can create fairly complicated patterns for enumerated constants, which doesn't have to be error-prone and cumbersome.

icza · Answer 3 · 2016-03-29T21:59:39.227

Actually there's a way. But let's clear some things first.

In constant declarations, if the type is present, the constant will take the specified type:

const n int64 = 3 // n will be a typed constant, its type will be int64

If the type is omitted, the constant will take the type of the expression:

const x = int16(3) // x will be a typed constant, its type will be int16

If the expression is an untyped constant, the declared constant will remain untyped constant:

const i = 1 // i will be an untyped integer constant

Note that if you try to print i's type (e.g. with fmt.Printf("%T", i), you will see int, and that's because when passing a constant to a function or when assigning it to a variable, it has to be converted to an actual type, and the default type will be used (because fmt.Println() has arguments type of interface{}) - which is int for an untyped integer constant.

Within a parenthesized const declaration list the expression list may be omitted from declarations (except at the first). If the expression is missing, the previous non-empty expression will be used (textual substitution).

So when you do this:

const(
    Stage1 FeeStage = iota
    Stage2 
    Stage3
)

It means:

const (
    Stage1 FeeStage = iota
    Stage2 FeeStage = iota
    Stage3 FeeStage = iota
)

Which results in 3 new constants: Stage1, Stage2 and Stage3, all being of type FreeStage.

Your second example:

const (
    Stage1 FeeStage = iota           // 0
    Stage2          = iota + 6       // 7
    Stage3          = (iota - 3) * 5 // -5
)

Since you didn't omit the expressions, ONLY your first constant Stage1 will be a typed constant (of type FreeStage), the rest will be untyped constants! So this doesn't even qualify (doesn't comply with your requirements)!

And now to your point: you want something like this:

const(
    Stage1 FeeStage = 1
    Stage2          = 2
    Stage3          = 2
)

As stated above, if you leave out the type, Stage2 and Stage3 will be untyped constants. So type must be specified, you may take advantage of the fact that a const specification is:

ConstSpec      = IdentifierList [ [ Type ] "=" ExpressionList ] .

You may specify an identifier list:

const(
    Stage1, Stage2, Stage3 FeeStage = 1, 2, 2
)

Is this more readable? Maybe if there are a few constants only. If there are many, use Not_a_Golfer's recommendation:

const(
    Stage1 FeeStage = 1
    Stage2 FeeStage = 2
    Stage3 FeeStage = 2
)

that's a nice touch, but feels less readable to me personally - I think 2-3 consts is the limit for this being useful. and at 2-3 it's really nothing repeating the type. but it's a matter of taste. anyways, great answer! — Not_a_Golfer, Mar 29 '16 at 18:18
@Not_a_Golfer I agree. I wouldn't use it myself, I would put it in 3 lines. But it's a possibility. — icza, Mar 29 '16 at 18:26

ENUMs for custom types in GO

3 Answers3