Go is boring, and that’s fantastic

Re:Go is boring, and that’s fantastic by orisho on Thursday July 02, 2020 @05:45PM (#23718432)

You would never initialize an enum like that, since you would use one of the enumerated values instead. That is, after all, the reason behind defining an enum in the first place. When could you end up with an enum that has an invalid value? When you get the value during runtime and typecast from an int. In that case, though, you should obviously have a runtime check that verifies the value is legal.

Your example case is something that I can't think of a reason to do. It isn't a case where you would need to be careful and knowledgeable to avoid it - there's just no reason to do it. You would use On and Off instead of defining a variable with this type.

[ Parent | on HN ]

Re:Go is boring, and that’s fantastic by bbatha on Sunday July 05, 2020 @01:37PM (#23740372)

This happens all of the time for enums in structs especially during (de)serialization and returning a zero value and an error. func DeserializeState(raw []byte) (State, error) { type Foo struct { State state `json:"state"` Data map[string]string `json:"data"` } f := Foo{} err := json.Unmarshal(&foo, raw) if err != nil { return ???, err }

   }
   s := DeserializeState([]byte(`{"data": {"key": "value"}}`)
   fmt.Println(s) // prints 0 oops

[ Parent | on HN ]

Re:Go is boring, and that’s fantastic by simon_o on Friday July 03, 2020 @07:49AM (#23723182)

> It isn't a case where you would need to be careful and knowledgeable to avoid it - there's just no reason to do it.

Then why does it compile?

[ Parent | on HN ]