The "Correct" Way to do Golang Enums

Being overly pedantic with types can achieve more robust enums… but probably not…

Wed Jul 20 2022

What is a type?

Let's start by answering this basic question abstractly: A type, is just a set of values. More specifically, the set of all values that have that type. For example:

Another concept that will be important later is the cardinality of a type. The cardinality can simply be thought of as the number of values of that type. Cardinality is mathematically notated with the | symbol. For example:

There are theoretically an infinite number of values of type int so we say that the cardinality is undefined (note that practically of course there are only finitely many 32/64-bit integers, but we'll keep things abstract for now).

Combining types

There are certain ways we can combine and perform “operations” on types as well and we can define some interesting inductive cardinality rules for them:

Let's go through these examples:

• |*T| = |T| + 1, Any value of type *T is either nil, or a pointer to a value of type T, hence the cardinality of *T is one more than T . e.g: |bool| = |{(true, false)}| = 2 and|*bool| = |{(nil, ptr(true), ptr(false))}| = 3 = |bool| + 1 (note that I'm not using any official Golang syntax here)
• |struct{ T, U }| = |T| * |U|, any value of type struct{ T, U } is a combination of 2 values of type T and U respectively, so the number of different values of this type is just every possible choice of these 2. e.g.: |struct {bool, bool}| = |{{ false, false }, { false, true }, { true, false }, { true, true }}| = 4 = 2 * 2 = |bool| * |bool|
• |[n]T| = |T|^n, the syntax [n]T here is meant to denote an array of fixed length n of values of type T. This example is very similar to the example above: |[2]bool| = | {([false, false], [false, true], [true, false], [true, true])}| = 4 = 2 ^ 2 = |bool| ^ 2

Enums in Golang

Let's go back to Golang to remind ourselves of how enums are traditionally done:

So we would typically declare a new type that wraps something iterable such as int or uint and use the iota operator to easily declare a load of constant values of this type.

This practically works and for most Go code it's probably fine. Let's dig in a bit more though and investigate the cardinality of this type:

We can easily see that if we define type A B then |A| = |B| since for every value b of type B we have a corresponding value A(b)of type A(and to be mathematically thorough we could also assert that for every value a of type A we have a corresponding value B(a)of type B )

So, for our enum example above this means: |Level| = |uint|. Which would mean we have an infinite number of possible levels. (Ok, it's technically mathematically incorrect to write this since |uint| is undefined, but the simple analogy of |uint| = +infinity holds here). More practically speaking, this means anywhere in our Go code a programmer could write Level(456) and it would pass type check even though this isn't really a valid Level.

Enum types

Let's leave the world of Golang to quickly go over what enum types really are and what their cardinality is.

An enum is a user defined type that has a fixed number of finite values with an empty constructor. Here are 2 examples:

So whenever we write enum types, we should aim to make the cardinality of the type exactly equal to the number of possible values we want it to have. e.g. for our Level enum, we should aim for a type with only 3 possible values.

Back to Golang

So, we've seen the shortfall of defining Golang enums like type Level uint. Can we do better? Is there another type that matches our desired cardinality?

Disclaimer: ok, this is where it gets a bit pedantic! This probably isn't a good way to define enums in real Go code, but it has a satisfying “theoretical correctness” to it.

It turns out, there is such a type: *bool. We know from earlier that|*bool| = |bool| + 1 = 2 + 1 = 3. This is the cardinality we desire for our 3 different levels! We can now define type Level *bool and now we have |Level| = |*bool| = 3.

This neat trick comes from 2 rules we saw above. I'll restate them here:

We can use these to construct a type of any desired finite cardinality.

In our Level example, the three enum values would be:

We can assign these values however we wish, the order is unimportant.

Let's also revisit something we said earlier:

More practically speaking, this means anywhere in our Go code a programmer could write Level(456) and it would pass type check even though this isn't really a validLevel.

We've now solved this problem, because any value that isn't one of the three defined enum values of type Level won't pass the type checker and thus won't compile!

Here's a more verbose example of defining days of the week:

It gets pretty impractical for bigger enums!

Some technicalities

The astute Go programmers amongst you will already have spotted that I've cut some corners in the examples above. You can't actually define constant pointers in Golang. So practically the Level example would have to be implemented as something like:

where the enum values are actually obtained from function calls rather than constant values.

We would also now need to define a custom definition of equality for ourLevel since in this example LevelHigh() != LevelHigh() // true.

Edit (added 01/08/22): Just wanted to add an additional section to this article to mention a great point that Tamas Bunth mentioned. All credit to him for this idea:

Our choice of bool as the base type was completely arbitrary and only chosen since it is a relatively small type of cardinality 2. Tamas pointed out that the type struct actually has cardinality 1 so this would serve as a much better base type since it allows us to have enums of cardinality 1.

So the Level example becomes: type Level **struct and can be defined: