Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Enums in Go

dizzy.zone

Post reply on HN
Print view View original

11–20 of 57 posts

Re: Enums in Go

#11

Post by tialaramex »

CraigJPerry wrote: post #5
ramon156 wrote: post #4

Earlier quoted context omitted.

This might be a very simple and ignorant thought, but I'd be fine if they completely worked the same as Rust's enum's. [if let] is such a powerful feature, along with match arms.

That’s not an enumeration like the parent and grandparent are discussing (think of a collection of consts), that’s a tagged union you’re talking about. Confusing because rust used the name enum in their syntax for this (Haskell calls it data - well, Haskell uses data in their syntax for both product and sum types).

What we're discussing here is always an actual sum type though, it's just a question of whether you're interested in half-assing it, and Rust is not.

There are people who want C's "surprise it's actually just an integer" which lets them use C's enums as bit flags, and that I agree isn't just a sum type, but the fact that Rust will let you sum things which aren't units isn't that this is "really" a tagged union, that's a possible implementation detail but not the core idea.

This is not C++ std::variant which really is just a tagged union. Option isn't a tagged union, it's "just" much nicer sugar for C's signed integer type. Option isn't a tagged union it's sugar for a fat pointer which can be null. And so on.

Re: Enums in Go

#12

Post by akira2501 »

Use a slice of strings?

    type Color int
    const (
        Red Color = iota
        Green
        Blue
    )

    var Colors = []string{ "Red", "Green", "Blue" }
Now (Colors[Red] == "Red") and (slices.Index(Colors, "Green") == Green).

Re: Enums in Go

#13

Post by dgb23 »

I recently wrote a little tokenizer in Go.

The data structure for a token that makes most intuitive sense to me is a tagged union.

So I defined an „const iota“-style enum. Stuck it into a struct that has the appropriate fields to cover all the cases and it was fine.

Having some syntax sugar for tagged unions would be nice. Having exhaustiveness checks if you switch over them, could be useful in some cases.

But that’s not where my mental energy went at all.

Reading the bytes (runes) efficiently and correctly into the data structure however is the part that needs focus. Once the data is in shape, I‘m not „worried“ at all anymore. Sure a bit of extra support is nice, but also kind of superficial.

Also going further, dispatching on them is again never the tricky part. It’s handling the cases correctly and efficiently that has my focus.

In Clojure, a common thing is to write multimethods that dispatch on (namespaced) keywords. Similar in spirit and structure, but each method might now reside in a different namespace or not even be written by you. But I have never worried about exhaustive matching or similar. What’s in the method bodies is the important part.

Re: Enums in Go

#14

Post by barnabee »

I’ve found the enumer [0] library does the job of generating usable helpers without too much pain or any obvious downsides. The ability to generate JSON [un]marshallers is particularly handy.

Still, the lack of enums and enum/sum types remains by far my biggest gripe about Go.

[0] https://github.com/dmarkham/enumer

Re: Enums in Go

#15

Post by slekker »

akira2501 wrote: post #12

Use a slice of strings? type Color int const ( Red Color = iota Green Blue ) var Colors = []string{ "Red", "Green", "Blue" } Now (Colors[Red] == "Red") and (slices.Index(Colors, "Green") == Green).

You could do the same with a map[Color]struct{} and the lookup would be "if _, ok := Colors[Green]; ok {"

Re: Enums in Go

#16

Post by JyB »

akira2501 wrote: post #12

Use a slice of strings? type Color int const ( Red Color = iota Green Blue ) var Colors = []string{ "Red", "Green", "Blue" } Now (Colors[Red] == "Red") and (slices.Index(Colors, "Green") == Green).

Compile-time safety is not achieved which is the point.

Re: Enums in Go

#18

Post by weavie »

The problem isn't so much the lack of enums, it's more that there is no way to do exhaustive pattern matching at compile time. I have seen production systems go down because someone added a variant to an 'enum' but failed to handle that new variant everywhere.

Re: Enums in Go

#19

Post by witx »

I can't take this language seriously. No enums, letter cases defining if something is "public" or "private", generics as an after-thought. To name just a few

Re: Enums in Go

#20

Post by JetSetIlly »

daghamm wrote: post #8

I'm implementing a somewhat complex software in both Go and Rust. The Rust version is bith shorter and more readable - and probably more efficient - thanks to Rust enums and Rust error handling. I don't understand why golang doesn't copy Rust here. The error handling in particular could be a very simple change. I am not a huge fan of go:generate and similar projects. They add a level of unknown that goes against the…

> I am not a huge fan of go:generate and similar projects. They add a level of unknown that goes against the core Golang design values.

I'm not sure I would agree with that. go:generate is a core part of Go since v1.4 and the enum generators are the kind of thing that was intended. https://go.dev/blog/generate

That said, enums would be a welcome improvement to the language. But even then, I think go:generate has a place.

Post reply on HN