Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



Yes it is important to have validation for anything coming in from outside (json, the database, etc). This is done by creating a map with the valid enum values and checking at runtime. This compile time solution wouldn't have worked for validating enums sent in json anyway, it's purely a defense mechanism against library users trying to cast arbitrary values to a package type.


Accidental zero value enums are a constant plague as far as I've seen. Almost any defense is worth it.


Yeah, this is the big thing. Honestly I'm not so worried about people using pkg.fun("red") or pkg.fun(25) instead of pkg.fun(pkg.Red) if they really want to, and in some cases it's IMHO even fine (e.g. HTTP status codes, where everyone knows what 404, 500, etc. mean).

It's pkg.fun(someVar) where someVar is accidentally 0 or "" because it comes from 3 functions away.


zero-values are the root of all go problems. Lack of sum/union/algebraic types are the root if zero-values.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: