12 ms·

Compile-time safety for enumerations in Go

66 points by varankinv 3y ago

jchw 3y ago
I dunno if I'd consider having a dummy method on an interface as "elegant", but it does work. A trade-off of keeping the language very simple, for sure. What I really wish Go had was sum types, Rust style. That'd cover enumerations and more.
- jjice 3y ago
  I go back and forth on this. On one hand, I _love_ Rust/ML style sum types. They're such a fantastic feature. On the other hand, I wonder how much use they'd get in a language like Go. If it's introduced, would it radically change the way some problems get solved? Is it that different than an traditional enum (which Go also skirts around)? Pattern matching and exhaustive checks are massive benefits of them though. I guess I'm just oddly conflicted here. I do think that long term, sum types are going to become more prevalent. I'm excited to see it, I'm just interested in how that adoption occurs in existing languages without them.
  - jchw 3y ago
    If I had sum types in Go, I'd use them for state machines and enumerations mostly. I can't see a huge downside; I'm sure some software has little use for it, but it's useful enough for data modelling that protobuf has the sort-of similar oneof primitive. Hmm. On that note, maybe it would be better than nothing to do some kind of code generation here...
  - jerf 3y ago
    I think the answer to your "back and forth" is probably laid out in: https://jerf.org/iri/post/2960/ https://jerf.org/iri/post/2960/ Sum types are useful, even very useful in the right place, but I do think there's a lot of people who use them a couple of times, probably in one of those "right places" and then mistakenly label them in their mind as "better". Just, universally, Platonically "better". They aren't in fact "better"; they're a tool. Sometimes they're the right tool for the job, but much, much more often, they're just a tool that works, and so do several other tools. People who get too excited about sum types need to be sure they square their understanding of how useful they are with the fact that the vast majority of programs are written without them.
    - jchw 3y ago
      This article seems almost entirely concerned with code organization, but in my case I basically never do functional programming and am only concerned about data modelling and data structures. In an adjacent, comment I do acknowledge one point (probably not all software really needs sum types) but I still feel as though languages without sum types are missing an important data and state modelling tool. Trying to take something like a state machine and jam it into interfaces or polymorphism kind of sucks; you lose exhaustiveness checking obviously, but also it enforces a lot of constraints about control flow and data. In Go parlance, if each of my states has a method with its receiver set to the state type, then I can only access that data, so for example I'd need to pass something in or out to handle state transitions. Not ideal IMO. I feel this pain basically any time I hand-write lexical scanners/parsers in Go or even C++.
      - masklinn 3y ago
        > I still feel as though languages without sum types are missing an important data and state modelling tool. That's because they are. jerf subtly shifts the point to one they can criticise, but it does not change the basic fact that sum types are a critical tool which is just... missing. There's probably no tool which can't be misused, even the humble boolean, that's not an issue with the tool, and pointing that out is at best irrelevant. It does not change the fact of the matter: you're missing a critical axis of composition. It's like saying screwdrivers are useful but you can misuse them to hammer nails as if that justified trying to screw with a hammer.
        jerf 3y ago
        Where I'd disagree is that they are a tool, not a critical tool, and they aren't missing from Go, they are simply not the preferred choice. You can cover 75% of the use cases with this approach. It is not 100% of the use cases. But there isn't a language where you can cover 100% of the use cases with 100% effectiveness, which is why we don't have and never will have The One True Language. Moreover, Go seems to attract this sort of criticism as if Go is Uniquely Broken and it's nirvana in all the other languages... but I've used enough of them to know better. Sum types are great, until you hit the branch of the expression problem where you really need the other side, and if you're in a language that favors them, you're going to get the same 75% experience, just mirror imaged.
  - Zach_the_Lizard 3y ago
    Sum types with pattern matching would likely take the place of (foo, error) in a lot of codebases. This is especially true in cases where a function returns a collection of results where each result is independent from other results and a result can succeed or fail. For instance, a batch report generator that is called every $INTERVAL might return a ([]Report metadata, error) today, but each report could have succeeded or failed without impacting the others. The output is emailed to $SOMEONE to let them know the reports ran and information about each. In today's world, the "error" could be a special error type that capture failures on a per report basis. The ReportMetadata type could also have an Error field, but one is not forced to check either. Sum types could force checking for error on a per report basis, increasing the odds something is done with the error.
- jerf 3y ago
  If you are satisfied with a dummy method on an interface, you can continue by adding more types to that interface. Color is not a great example, so: type Vehicle interface { isVehicle() } type Car struct {} func (c Car) isVehicle() {} type Van struct {} func (v Van) isVehicle() {} func VehicleType(vehicle Vehicle) { switch v := vehicle.(type) { case Car: fmt.Println("car") case Van: fmt.Println("van") default: fmt.Println("unknown vehicle") } This covers most, but not all, of the bases, in that you don't get exhaustiveness checking at compile time, unless you adjoin a linter to your compile process: https://github.com/BurntSushi/go-sumtype https://github.com/BurntSushi/go-sumtype
  - jchw 3y ago
    Yeah, I've done that before. It's not really elegant in my opinion, but OTOH, it's basically the best you can do. Oh well.
- fsdjkflsjfsoij 3y ago
  I hope Go will eventually get sum types but I hope they're better than Rust's where each variant is its own type.
  - LatticeAnimal 3y ago
    How is this mess better than Rust's enums? A Rust enum + match statement results in really easy to read and clean code.
    - fsdjkflsjfsoij 3y ago
      For a trivial example, let's say I have some message type that has multiple variants with differing fields: enum Message { Action1(String, Option<Mode>), Action2(String), } Action1 and Action2 are variants not types and I cannot make functions that take an Action1 or an Action2 as a parameter. To get around this people will often make each enum variant just a container for some struct with the same name but that's more verbose and matching becomes slightly uglier. Code like this is fairly common: struct Action1(String, Option<Mode>); struct Action2(String); enum Message { Action1(Action1), Action2(Action2), } Ideally I'd like to be able to succinctly say something like: type A = B | C and have A be dependent on B and C but have both B and C be completely independent types.
      - LatticeAnimal 3y ago
        That is a pretty compelling point... I ran into this less than an hour ago and was slightly frustrated. Though, I still like the flexibility of adding additional fields to `Action1`. In golang I end up with fields that are conditionally populated based on the state of an Enum which is less than ideal and leads to lots of error checking (though this is relatively rare). It doesn't have to be one or the other though. A bit more polishing on the Rust-style enums (perhaps in a different language) could lead to pretty ergonomic code.
  - sapiogram 3y ago
    > Rust's where each variant is its own type. Is this... right? You can't use enum variants as types in function signatures, variable declarations, etc.
davidkunz 3y ago
> Go’s type system allows preventing both issues in a rather elegant way. Proper enums would be elegant, not this.
- masklinn 3y ago
  Some way to define a closed set of values anyway. It doesn't even need to be classic-style sum types, for instance as support for generics Go introduced support for union types (I don't think they have a name?) e.g. type Foo interface { A | B | C } and the interface type is the union of those type-sets. Such interfaces can not currently be used outside of type constraints, but if that is relaxed, and type switches are updated to support and enforce exhaustive matching (and understand such sealed / nominative interfaces), you've got all the bits you need. You'd need to newtype variants to add payloads of similar underlying type e.g. `int | int`, but that's not a huge imposition, and the variants being types themselves is often convenient so it's a 50:50 tradeoff compared to classic sum type (where constructors disambiguate all variants but are not themselves types).
  - foldr 3y ago
    Agreed. A slight wart is that default initialization would require either boxing or a somewhat arbitrary decision about which variant should be the default. So if you have e.g. var foo interface{ A | B } then foo either has to be boxed (so the default value is a nil interface) or unboxed and arbitrarily initialized as an A or a B.
    - masklinn 3y ago
      To me it would make sense that this be implemented as a normal interface at least initially, it would reuse all the existing bits of the language as is. Note that whether an interface boxes depends on escaping. I don't see how unboxing would have to be "arbitrarily initialized as an A or a B" either. Even with a novel bespoke implementation you still need a discriminant between the two nested. You could keep a nil default by reserving the zero discriminant for that purpose.
hqudsi 3y ago
I sometimes do this but idk if I would consider it 'elegant' The other 'gotcha' is that in switch statements the compiler can't tell whether you enumerated on all your cases as there is no true enum type so it's not uncommon to have a catch all default case that either returns an error or panics and hope you can catch it during tests if you missed a case. I just wish go had proper sum types.
- orbz 3y ago
  This is an analyzer that will catch this: https://github.com/nishanths/exhaustive https://github.com/nishanths/exhaustive I believe it's in golangci-lint.
- RetpolineDrama 3y ago
  >I just wish go had proper sum types. It's by far my favorite feature of Swift. Enums + Payloads + switches are incredibly simple yet so effective. You can make a simple state object, isolate it with an actor, then stream it anywhere with Combine (or now Observability). You'll get full compiler safety too, forcing any new state to be handled everywhere. You can even stack that with _generic_ payloads that conform to protocols, and if you're feel brave you can make those payloads equable completions for _typed returns_. for example (I hate formatting on here, but I'll give it a shot) // A user state enum that conforms to loggable. // The state is generic, any object T that conforms to "Partner" protocol can be a partner enum UserState<T: Partner>: Loggable { // Your states case loggedOut(error: String?) case loggingIn(email: Email) // Email type is a string that's been validated case loggedIn(authToken: String, user: User, partner: T) case loggingOut(exampleBlock: (String) -> Bool) // You can embed a callback here // Utility Functions /// Is the user logged in? func isLoggedIn() -> Bool { switch self { case .loggedOut, .loggingIn: return false case .loggedIn: return true } } /// Loggable conformance func logText() -> String { // switch that converts state into something that's safe for your logging service } } In the above, any subscriber that gets a UserState object can switch on it, and for example if you're logged in you 100% get the auth token, user, etc. It's impossible to be logged in without those in-context. It might look something like this in your UI: /// Called by a subscriber that's hooked in to the state stream func onUserStateChanged(newState: UserState) { switch newState { case let .loggedOut: // Impossible? Error UI case let .loggingIn, .loggingOut: // loading UI case let .loggedIn(authToken: _, user: user, parner: partner): // set some text "hello \(user.userName)" // display an image: \(MyRemoteLoader.url(url: partner.primaryLogoURL)) // Button to website: Button(url: partner.homePageURL) } } add a new state later? The compiler will error in the 500 places in your codebase you didn't handle the new case with one build command.
atombender 3y ago
The main downside to this approach is that you'll still have to deal with the zero value, which for interfaces is going to be nil.
- Groxx 3y ago
  While I agree nils are a problem with this: as long as they have access to the type at all, they can create zero values. E.g. var c color.Color That's a valid color whether it's a nil interface value or an empty typed string. You can return a private type to prevent this, but that also means they can't refer to it as an argument or return value anywhere outside the implementing package, which is a rather severe limit in many cases. Sometimes* I really miss constructors. *: all the time
- masklinn 3y ago
  No matter how Go solves the issue (assuming it ever does), that will be part of it: unless it goes through a revolution and strips out and forgets about ubiquitous default values (which I don't think it will, C# has barely just dipped its toes into that pool) any sort of sum-type-like construct will need a default value. And I'm not sure `nil` (a clearly corrupted / missing value) is any worse than picking an actual valid value the way non-pointer types do.
euroderf 3y ago
In a more dynamic environment where you could manage values in a controlled manner, how could you validate values ? One idea is to make a DB table dedicated to enumerations and then use foreign key constraints. Define a unique namespace for each set of enumerated values, and catch foreign key constraint failures on DB writes.
kiitos 3y ago
Unfortunately not. func main() { c := color.Red cptr := (*string)(&c) *cptr = "orange" PrintColor(c) // successfully compiles, and prints "orange" }
- revoly 3y ago
  I don't think the solution is trying to cover this. If a user does type conversion then usually they know what they are doing. It's like going out of the way. The solution is to just hide a type behind an interface to be explicit about it and to avoid the error that would have gone unnoticed otherwise.
  - throwaway894345 3y ago
    The type conversion is a red herring. He's just changing the value of a variable by referencing and dereferencing a pointer. In other words, he's not using a pointer conversion to change the value of `color.Red`, he's creating a new variable `c` and assigning `color.Red` to it, and then changing the value of the variable through the pointer and type conversion. But he doesn't even need to do the pointer/type conversion stuff, he could just do `c = Color("orange")` and call it a day.
    - kiitos 3y ago
      > But he doesn't even need to do the pointer/type conversion stuff, he could just do `c = Color("orange")` and call it a day. c = Color("orange") does not compile.
      - throwaway894345 3y ago
        Ah, I misunderstood what type color.Red had. My mistake.
  - kiitos 3y ago
    The article is titled "Compile-time safety for enumerations in Go" but my example demonstrates that this is not the case.
kleton 3y ago
I use this in my projects https://github.com/abice/go-enum https://github.com/abice/go-enum
maxekman 3y ago
Here is an issue tracking a possible fix to this: https://github.com/golang/go/issues/19412 https://github.com/golang/go/issues/19412
- ncruces 3y ago
  This is a more recent proposal, and at this time more likely to get traction: https://github.com/golang/go/issues/57644 https://github.com/golang/go/issues/57644 As stated in that proposal, the interaction between what people want from “enums,” “discriminated unions,” “sum types,” (as well as “optional values” and “nil safety”) and fundamental Go tenets like zero values, make this a tough sell, which is very likely to make no one happy.
SPBS 3y ago
This is not elegant. It also has overhead. Stick with the simple `const Red Color = "red"`, you're not gaining a lot by doing all these strange type contortions in Go. Seriously consider what you are protecting against, and whether it's an imagined bogeyman. "Oh but someone may try to cast arbitrary values to my package type" Okay but who is that going to hurt? You or them? Will they get hit with errors early on in the development lifecycle if they do something silly like this? Are you actually going through all these lengths for nothing?
- ollien 3y ago
  What overhead is there at runtime?
  - kgeist 3y ago
    Casting a value to an interface forces it to be allocated on the heap.
  - Groxx 3y ago
    Interfaces are both allocations and function-call indirection, and I think they also always move their data to the heap. Which is almost always trivial except when it isn't.
- the_gipsy 3y ago
  It's stuff that just creeps in. Enum values can come from outside (json, anything non-literal). Now you have to do validation, because the bad values parse and for sure exist at some stage in your program. It's not a bogeyman.
  - Groxx 3y ago
    Accidental zero value enums are a constant plague as far as I've seen. Almost any defense is worth it.
    - arp242 3y ago
earthboundkid 3y ago
I would be interested to read bug reports from people who thought they had a complete enumeration but learned in production that their enumeration was incomplete. I've never seen it myself.
- Zach_the_Lizard 3y ago
  This is relatively common with naive int / string to enum type conversions, especially if the int or string are given as input from an RPC mechanism of some sort. This type of pattern can be used to force other developers to check if the value is garbage before calling $BUSINESS_LOGIC that uses the enum
- Someone 3y ago
  An easy way to get that is when you use a third-party library, update that to get some new feature, and get a new enum value for free, say because the html parser library started supporting a new node type or added a new error type (the latter will be rare in go because of its lack of sum types). Ideally, of course, the release notes of the library would spell out the issue, and you’d read them, but even then, making sure you fix this everywhere is way easier if the compiler refuses to compile your code if it doesn’t handle the new case.
  - earthboundkid 3y ago
    Did this actually happen to you or are you just theorizing that it could happen?
  - mappu 3y ago
    One difficulty with this is, adding a new enum value should therefore be semver-major.
- dgunay 3y ago
  At my current day job we have many, many such "enums" that slowly expand over time. I've seen many bugs from new values not being taken into account in the several places one has to remember to double check. Sometimes testing catches these, sometimes it doesn't.
the_gipsy 3y ago
You need the JSON de/encode implementation with checks. At that point you'll want code generation, and something that was never elegant is turning awful.
pjmlp 3y ago
Pascal like enumerations, yet another feature that Go missed from the 1970's.
dgb23 3y ago
Clever! But what problem does this actually solve? When I see a type alias of a string and enumerated variants then why would I pass in arbitrary strings? There are _always_ ways to break assumptions. Putting arbitrary, complex guard rails at every call site doesn’t make a program magically better. An API is primarily about affordances. We provide utility to the caller.
uluyol 3y ago
You can implement the interface from other packages through embedding type ColorWrapper struct { color.Color ... } ColorWrapper will implement color.Color. I don't know what the point would be, but another way to break the compile-time type safety.
fnfjfk 3y ago
Go doesn’t have type-safe enums in the language? That’s wild, even C compilers have this feature now (optionally), and then there’s Rust/Swift’s capabilities.
- nonethewiser 3y ago
  Welcome to Go. “Wait, Go doesnt have X?” I’m convinced its an incomplete language masquerading as a simple one.
  - dingnuts 3y ago
    Well, that's an opinion. Depending on how you define "complete," any language with fewer features than Scala might be considered incomplete Unless you mean: is it enough of a language to be useful for its intended usages? In which case my decade of paychecks would like to let you know that it is, in fact, sufficiently complete for many business needs.
    - avgcorrection 3y ago
      This is either skirting close to the Nirvana Fallacy or using unwarranted hyperbole. Enumerations aren't an advanced language feature at all and Go was released in 2010.
  - pjmlp 3y ago
    It is one of those languages that I will use if I have to, not because I want to.
- randomdata 3y ago
  They are type-safe, but they are not sum types.
- deleted 3y ago
  [deleted]
andreygrehov 3y ago
Another approach could be: package color type Color struct { val string } func (c Color) String() string { return c.val } var ( Red = Color{val: "red"} Green = Color{val: "green"} Blue = Color{val: "blue"} ) Since `val` is not exported, external packages cannot create arbitrary `Color`.
- curvilinear_m 3y ago
  Ins't it still possible to construct the zero value for Color ? Like how bytes.Buffer does it https://pkg.go.dev/bytes#Buffer https://pkg.go.dev/bytes#Buffer : the implementation is not exported but you the usage is to construct the zero value and use it. So unless Color{} is a valid enum value, this solution would not work.
nikolayasdf123 3y ago
interesting approach! but I typically use this method for type constraints. for enums I prefer just direct structs: https://github.com/nikolaydubina/go-enum-example https://github.com/nikolaydubina/go-enum-example

66 points by varankinv 3y ago

jchw 3y ago

I dunno if I'd consider having a dummy method on an interface as "elegant", but it does work. A trade-off of keeping the language very simple, for sure. What I really wish Go had was sum types, Rust style. That'd cover enumerations and more.

jjice 3y ago
I go back and forth on this. On one hand, I _love_ Rust/ML style sum types. They're such a fantastic feature. On the other hand, I wonder how much use they'd get in a language like Go. If it's introduced, would it radically change the way some problems get solved? Is it that different than an traditional enum (which Go also skirts around)? Pattern matching and exhaustive checks are massive benefits of them though. I guess I'm just oddly conflicted here. I do think that long term, sum types are going to become more prevalent. I'm excited to see it, I'm just interested in how that adoption occurs in existing languages without them.
- jchw 3y ago
  If I had sum types in Go, I'd use them for state machines and enumerations mostly. I can't see a huge downside; I'm sure some software has little use for it, but it's useful enough for data modelling that protobuf has the sort-of similar oneof primitive. Hmm. On that note, maybe it would be better than nothing to do some kind of code generation here...
- jerf 3y ago
  I think the answer to your "back and forth" is probably laid out in: https://jerf.org/iri/post/2960/ https://jerf.org/iri/post/2960/ Sum types are useful, even very useful in the right place, but I do think there's a lot of people who use them a couple of times, probably in one of those "right places" and then mistakenly label them in their mind as "better". Just, universally, Platonically "better". They aren't in fact "better"; they're a tool. Sometimes they're the right tool for the job, but much, much more often, they're just a tool that works, and so do several other tools. People who get too excited about sum types need to be sure they square their understanding of how useful they are with the fact that the vast majority of programs are written without them.
  - jchw 3y ago
    This article seems almost entirely concerned with code organization, but in my case I basically never do functional programming and am only concerned about data modelling and data structures. In an adjacent, comment I do acknowledge one point (probably not all software really needs sum types) but I still feel as though languages without sum types are missing an important data and state modelling tool. Trying to take something like a state machine and jam it into interfaces or polymorphism kind of sucks; you lose exhaustiveness checking obviously, but also it enforces a lot of constraints about control flow and data. In Go parlance, if each of my states has a method with its receiver set to the state type, then I can only access that data, so for example I'd need to pass something in or out to handle state transitions. Not ideal IMO. I feel this pain basically any time I hand-write lexical scanners/parsers in Go or even C++.
    - masklinn 3y ago
      > I still feel as though languages without sum types are missing an important data and state modelling tool. That's because they are. jerf subtly shifts the point to one they can criticise, but it does not change the basic fact that sum types are a critical tool which is just... missing. There's probably no tool which can't be misused, even the humble boolean, that's not an issue with the tool, and pointing that out is at best irrelevant. It does not change the fact of the matter: you're missing a critical axis of composition. It's like saying screwdrivers are useful but you can misuse them to hammer nails as if that justified trying to screw with a hammer.
      - jerf 3y ago
        Where I'd disagree is that they are a tool, not a critical tool, and they aren't missing from Go, they are simply not the preferred choice. You can cover 75% of the use cases with this approach. It is not 100% of the use cases. But there isn't a language where you can cover 100% of the use cases with 100% effectiveness, which is why we don't have and never will have The One True Language. Moreover, Go seems to attract this sort of criticism as if Go is Uniquely Broken and it's nirvana in all the other languages... but I've used enough of them to know better. Sum types are great, until you hit the branch of the expression problem where you really need the other side, and if you're in a language that favors them, you're going to get the same 75% experience, just mirror imaged.
- Zach_the_Lizard 3y ago
  Sum types with pattern matching would likely take the place of (foo, error) in a lot of codebases. This is especially true in cases where a function returns a collection of results where each result is independent from other results and a result can succeed or fail. For instance, a batch report generator that is called every $INTERVAL might return a ([]Report metadata, error) today, but each report could have succeeded or failed without impacting the others. The output is emailed to $SOMEONE to let them know the reports ran and information about each. In today's world, the "error" could be a special error type that capture failures on a per report basis. The ReportMetadata type could also have an Error field, but one is not forced to check either. Sum types could force checking for error on a per report basis, increasing the odds something is done with the error.
jerf 3y ago
If you are satisfied with a dummy method on an interface, you can continue by adding more types to that interface. Color is not a great example, so: type Vehicle interface { isVehicle() } type Car struct {} func (c Car) isVehicle() {} type Van struct {} func (v Van) isVehicle() {} func VehicleType(vehicle Vehicle) { switch v := vehicle.(type) { case Car: fmt.Println("car") case Van: fmt.Println("van") default: fmt.Println("unknown vehicle") } This covers most, but not all, of the bases, in that you don't get exhaustiveness checking at compile time, unless you adjoin a linter to your compile process: https://github.com/BurntSushi/go-sumtype https://github.com/BurntSushi/go-sumtype
- jchw 3y ago
  Yeah, I've done that before. It's not really elegant in my opinion, but OTOH, it's basically the best you can do. Oh well.
fsdjkflsjfsoij 3y ago
I hope Go will eventually get sum types but I hope they're better than Rust's where each variant is its own type.
- LatticeAnimal 3y ago
  How is this mess better than Rust's enums? A Rust enum + match statement results in really easy to read and clean code.
  - fsdjkflsjfsoij 3y ago
    For a trivial example, let's say I have some message type that has multiple variants with differing fields: enum Message { Action1(String, Option<Mode>), Action2(String), } Action1 and Action2 are variants not types and I cannot make functions that take an Action1 or an Action2 as a parameter. To get around this people will often make each enum variant just a container for some struct with the same name but that's more verbose and matching becomes slightly uglier. Code like this is fairly common: struct Action1(String, Option<Mode>); struct Action2(String); enum Message { Action1(Action1), Action2(Action2), } Ideally I'd like to be able to succinctly say something like: type A = B | C and have A be dependent on B and C but have both B and C be completely independent types.
    - LatticeAnimal 3y ago
      That is a pretty compelling point... I ran into this less than an hour ago and was slightly frustrated. Though, I still like the flexibility of adding additional fields to `Action1`. In golang I end up with fields that are conditionally populated based on the state of an Enum which is less than ideal and leads to lots of error checking (though this is relatively rare). It doesn't have to be one or the other though. A bit more polishing on the Rust-style enums (perhaps in a different language) could lead to pretty ergonomic code.
- sapiogram 3y ago
  > Rust's where each variant is its own type. Is this... right? You can't use enum variants as types in function signatures, variable declarations, etc.

davidkunz 3y ago

> Go’s type system allows preventing both issues in a rather elegant way. Proper enums would be elegant, not this.

masklinn 3y ago
Some way to define a closed set of values anyway. It doesn't even need to be classic-style sum types, for instance as support for generics Go introduced support for union types (I don't think they have a name?) e.g. type Foo interface { A | B | C } and the interface type is the union of those type-sets. Such interfaces can not currently be used outside of type constraints, but if that is relaxed, and type switches are updated to support and enforce exhaustive matching (and understand such sealed / nominative interfaces), you've got all the bits you need. You'd need to newtype variants to add payloads of similar underlying type e.g. `int | int`, but that's not a huge imposition, and the variants being types themselves is often convenient so it's a 50:50 tradeoff compared to classic sum type (where constructors disambiguate all variants but are not themselves types).
- foldr 3y ago
  Agreed. A slight wart is that default initialization would require either boxing or a somewhat arbitrary decision about which variant should be the default. So if you have e.g. var foo interface{ A | B } then foo either has to be boxed (so the default value is a nil interface) or unboxed and arbitrarily initialized as an A or a B.
  - masklinn 3y ago
    To me it would make sense that this be implemented as a normal interface at least initially, it would reuse all the existing bits of the language as is. Note that whether an interface boxes depends on escaping. I don't see how unboxing would have to be "arbitrarily initialized as an A or a B" either. Even with a novel bespoke implementation you still need a discriminant between the two nested. You could keep a nil default by reserving the zero discriminant for that purpose.

hqudsi 3y ago

I sometimes do this but idk if I would consider it 'elegant' The other 'gotcha' is that in switch statements the compiler can't tell whether you enumerated on all your cases as there is no true enum type so it's not uncommon to have a catch all default case that either returns an error or panics and hope you can catch it during tests if you missed a case. I just wish go had proper sum types.

orbz 3y ago
This is an analyzer that will catch this: https://github.com/nishanths/exhaustive https://github.com/nishanths/exhaustive I believe it's in golangci-lint.
RetpolineDrama 3y ago
>I just wish go had proper sum types. It's by far my favorite feature of Swift. Enums + Payloads + switches are incredibly simple yet so effective. You can make a simple state object, isolate it with an actor, then stream it anywhere with Combine (or now Observability). You'll get full compiler safety too, forcing any new state to be handled everywhere. You can even stack that with _generic_ payloads that conform to protocols, and if you're feel brave you can make those payloads equable completions for _typed returns_. for example (I hate formatting on here, but I'll give it a shot) // A user state enum that conforms to loggable. // The state is generic, any object T that conforms to "Partner" protocol can be a partner enum UserState<T: Partner>: Loggable { // Your states case loggedOut(error: String?) case loggingIn(email: Email) // Email type is a string that's been validated case loggedIn(authToken: String, user: User, partner: T) case loggingOut(exampleBlock: (String) -> Bool) // You can embed a callback here // Utility Functions /// Is the user logged in? func isLoggedIn() -> Bool { switch self { case .loggedOut, .loggingIn: return false case .loggedIn: return true } } /// Loggable conformance func logText() -> String { // switch that converts state into something that's safe for your logging service } } In the above, any subscriber that gets a UserState object can switch on it, and for example if you're logged in you 100% get the auth token, user, etc. It's impossible to be logged in without those in-context. It might look something like this in your UI: /// Called by a subscriber that's hooked in to the state stream func onUserStateChanged(newState: UserState) { switch newState { case let .loggedOut: // Impossible? Error UI case let .loggingIn, .loggingOut: // loading UI case let .loggedIn(authToken: _, user: user, parner: partner): // set some text "hello \(user.userName)" // display an image: \(MyRemoteLoader.url(url: partner.primaryLogoURL)) // Button to website: Button(url: partner.homePageURL) } } add a new state later? The compiler will error in the 500 places in your codebase you didn't handle the new case with one build command.

atombender 3y ago

The main downside to this approach is that you'll still have to deal with the zero value, which for interfaces is going to be nil.

Groxx 3y ago
While I agree nils are a problem with this: as long as they have access to the type at all, they can create zero values. E.g. var c color.Color That's a valid color whether it's a nil interface value or an empty typed string. You can return a private type to prevent this, but that also means they can't refer to it as an argument or return value anywhere outside the implementing package, which is a rather severe limit in many cases. Sometimes* I really miss constructors. *: all the time
masklinn 3y ago
No matter how Go solves the issue (assuming it ever does), that will be part of it: unless it goes through a revolution and strips out and forgets about ubiquitous default values (which I don't think it will, C# has barely just dipped its toes into that pool) any sort of sum-type-like construct will need a default value. And I'm not sure `nil` (a clearly corrupted / missing value) is any worse than picking an actual valid value the way non-pointer types do.

euroderf 3y ago

In a more dynamic environment where you could manage values in a controlled manner, how could you validate values ? One idea is to make a DB table dedicated to enumerations and then use foreign key constraints. Define a unique namespace for each set of enumerated values, and catch foreign key constraint failures on DB writes.

kiitos 3y ago

Unfortunately not. func main() { c := color.Red cptr := (*string)(&c) *cptr = "orange" PrintColor(c) // successfully compiles, and prints "orange" }

revoly 3y ago
I don't think the solution is trying to cover this. If a user does type conversion then usually they know what they are doing. It's like going out of the way. The solution is to just hide a type behind an interface to be explicit about it and to avoid the error that would have gone unnoticed otherwise.
- throwaway894345 3y ago
  The type conversion is a red herring. He's just changing the value of a variable by referencing and dereferencing a pointer. In other words, he's not using a pointer conversion to change the value of `color.Red`, he's creating a new variable `c` and assigning `color.Red` to it, and then changing the value of the variable through the pointer and type conversion. But he doesn't even need to do the pointer/type conversion stuff, he could just do `c = Color("orange")` and call it a day.
  - kiitos 3y ago
    > But he doesn't even need to do the pointer/type conversion stuff, he could just do `c = Color("orange")` and call it a day. c = Color("orange") does not compile.
    - throwaway894345 3y ago
      Ah, I misunderstood what type color.Red had. My mistake.
- kiitos 3y ago
  The article is titled "Compile-time safety for enumerations in Go" but my example demonstrates that this is not the case.

kleton 3y ago

I use this in my projects https://github.com/abice/go-enum https://github.com/abice/go-enum

maxekman 3y ago

Here is an issue tracking a possible fix to this: https://github.com/golang/go/issues/19412 https://github.com/golang/go/issues/19412

ncruces 3y ago
This is a more recent proposal, and at this time more likely to get traction: https://github.com/golang/go/issues/57644 https://github.com/golang/go/issues/57644 As stated in that proposal, the interaction between what people want from “enums,” “discriminated unions,” “sum types,” (as well as “optional values” and “nil safety”) and fundamental Go tenets like zero values, make this a tough sell, which is very likely to make no one happy.

SPBS 3y ago

This is not elegant. It also has overhead. Stick with the simple `const Red Color = "red"`, you're not gaining a lot by doing all these strange type contortions in Go. Seriously consider what you are protecting against, and whether it's an imagined bogeyman. "Oh but someone may try to cast arbitrary values to my package type" Okay but who is that going to hurt? You or them? Will they get hit with errors early on in the development lifecycle if they do something silly like this? Are you actually going through all these lengths for nothing?

ollien 3y ago
What overhead is there at runtime?
- kgeist 3y ago
  Casting a value to an interface forces it to be allocated on the heap.
- Groxx 3y ago
  Interfaces are both allocations and function-call indirection, and I think they also always move their data to the heap. Which is almost always trivial except when it isn't.
the_gipsy 3y ago
It's stuff that just creeps in. Enum values can come from outside (json, anything non-literal). Now you have to do validation, because the bad values parse and for sure exist at some stage in your program. It's not a bogeyman.
- Groxx 3y ago
  Accidental zero value enums are a constant plague as far as I've seen. Almost any defense is worth it.
  - arp242 3y ago

earthboundkid 3y ago

I would be interested to read bug reports from people who thought they had a complete enumeration but learned in production that their enumeration was incomplete. I've never seen it myself.

Zach_the_Lizard 3y ago
This is relatively common with naive int / string to enum type conversions, especially if the int or string are given as input from an RPC mechanism of some sort. This type of pattern can be used to force other developers to check if the value is garbage before calling $BUSINESS_LOGIC that uses the enum
Someone 3y ago
An easy way to get that is when you use a third-party library, update that to get some new feature, and get a new enum value for free, say because the html parser library started supporting a new node type or added a new error type (the latter will be rare in go because of its lack of sum types). Ideally, of course, the release notes of the library would spell out the issue, and you’d read them, but even then, making sure you fix this everywhere is way easier if the compiler refuses to compile your code if it doesn’t handle the new case.
- earthboundkid 3y ago
  Did this actually happen to you or are you just theorizing that it could happen?
- mappu 3y ago
  One difficulty with this is, adding a new enum value should therefore be semver-major.
dgunay 3y ago
At my current day job we have many, many such "enums" that slowly expand over time. I've seen many bugs from new values not being taken into account in the several places one has to remember to double check. Sometimes testing catches these, sometimes it doesn't.

the_gipsy 3y ago

You need the JSON de/encode implementation with checks. At that point you'll want code generation, and something that was never elegant is turning awful.

pjmlp 3y ago

Pascal like enumerations, yet another feature that Go missed from the 1970's.

dgb23 3y ago

Clever! But what problem does this actually solve? When I see a type alias of a string and enumerated variants then why would I pass in arbitrary strings? There are _always_ ways to break assumptions. Putting arbitrary, complex guard rails at every call site doesn’t make a program magically better. An API is primarily about affordances. We provide utility to the caller.

uluyol 3y ago

You can implement the interface from other packages through embedding type ColorWrapper struct { color.Color ... } ColorWrapper will implement color.Color. I don't know what the point would be, but another way to break the compile-time type safety.

fnfjfk 3y ago

Go doesn’t have type-safe enums in the language? That’s wild, even C compilers have this feature now (optionally), and then there’s Rust/Swift’s capabilities.

nonethewiser 3y ago
Welcome to Go. “Wait, Go doesnt have X?” I’m convinced its an incomplete language masquerading as a simple one.
- dingnuts 3y ago
  Well, that's an opinion. Depending on how you define "complete," any language with fewer features than Scala might be considered incomplete Unless you mean: is it enough of a language to be useful for its intended usages? In which case my decade of paychecks would like to let you know that it is, in fact, sufficiently complete for many business needs.
  - avgcorrection 3y ago
    This is either skirting close to the Nirvana Fallacy or using unwarranted hyperbole. Enumerations aren't an advanced language feature at all and Go was released in 2010.
- pjmlp 3y ago
  It is one of those languages that I will use if I have to, not because I want to.
randomdata 3y ago
They are type-safe, but they are not sum types.
deleted 3y ago
[deleted]

andreygrehov 3y ago

Another approach could be: package color type Color struct { val string } func (c Color) String() string { return c.val } var ( Red = Color{val: "red"} Green = Color{val: "green"} Blue = Color{val: "blue"} ) Since `val` is not exported, external packages cannot create arbitrary `Color`.

curvilinear_m 3y ago
Ins't it still possible to construct the zero value for Color ? Like how bytes.Buffer does it https://pkg.go.dev/bytes#Buffer https://pkg.go.dev/bytes#Buffer : the implementation is not exported but you the usage is to construct the zero value and use it. So unless Color{} is a valid enum value, this solution would not work.

nikolayasdf123 3y ago

interesting approach! but I typically use this method for type constraints. for enums I prefer just direct structs: https://github.com/nikolaydubina/go-enum-example https://github.com/nikolaydubina/go-enum-example