[zer00eyz]

>> Sounds fine for a lot of cases, of course, but in a world of mixed deployment fleets working on data, you pretty much have to have a way to allow a value that is not part of your current definition, or you are basically placing a "poison pill" on your system.

I had the joy of a numeric ID (an int) getting a B added to the end of it to distinguish the product as being the "same" but sourced from another vendor... (and vendor is part of the system so this is layers of silly, but useful on the floor if there is a problem).

This is the down side of "fleets" of applications with differing degrees of type safety working in concert.

Should an enum be fixed, and its change need to be reflected in every system? Cause current go out of the box isnt that. Should it be open ended as your suggesting ... because a "new int value" can flow through the system in an "Unsafe" way depending on the permissiveness or quality of your code.

I dont like any of the answers, but I candidly dont have a lot of problems with the current enum system in go. Is it great, no. But if your validating at your borders/boundries (storage, api, etc) and being responsible I dont really give it much thought.

[taeric]

I found this lesson out the hard way by finding that a new "status" had been added to our service and blew up some of our monitoring code. Since our monitoring code was still correct for the cases that they were checking for, and had default clauses to note things that were not relevant, we were crashing purely because I had coded it to convert the incoming value into a java enum. Oops...

[Brian_K_White]

well thank you for the example anyway :)