This is an analyzer that will catch this: https://github.com/nishanths/exhaustive

I believe it's in golangci-lint.

>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.

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

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.

I hope Go will eventually get sum types but I hope they're better than Rust's where each variant is its own type.

At some point I think it's worth asking who are we trying to stop and why.

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.

It's the game of the mouse and the cat :-D We can change the package color like this :

  package color

  type Color interface {
    void()
  }

  type color struct {
    v string
  }

  func (c color) void() {}
  func (c color) String() string {
    return c.v
  }

  var (
    Red   color = color{"red"}
    Green color = color{"green"}
    Blue  color = color{"blue"}
  )

    func fn(c color.Color) {
     switch c {
     case color.Red, color.Green, color.Blue:
      log.Printf("c=%#+v -- OK", c)
     default:
      log.Printf("c=%#+v -- should not be possible", c)
     }
    }
    
    func main() {
     var c color.Color
     fn(c)
    }    

    c=<nil> -- should not be possible

You're not changing the underlying value of `color.Red`, you're changing the variable (in other words, `PrintColor(color.Red)` will still print `red`). If that's the point you're intending to make, then couldn't you make it more easily with this?:

    c := color.Red
    c = Color("orange")
    PrintColor(c)

    cannot convert "orange" (untyped string constant) to type Color

i appreciate this counter-example; thanks. i was hoping there was a way to get real enums in go.

In this example, *cptr is a color by contract. A Color is a type alias of a string. *cptr is a string. Interfaces match.

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.

What overhead is there at runtime?

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).

    var foo interface{ A | B }

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

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.

Ins't it still possible to construct the zero value for Color ? Like how bytes.Buffer does it 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.