Hacker News new | ask | show | jobs
by mieubrisse 1591 days ago
That's a fair concern: if everything is strict, then there's no option to incrementally roll out a new value. Maybe a proper enum type could always have an `Unknown` value, which would allow for the leniency while still forcing the use to think about (and handle) it at compile time?
3 comments
Gwypaas 1591 days ago
Rust supports #[non_exhaustive] attributes, forcing users to cover the generic/wildcard case even though you have already covered all existing ones. Although, I rather do versioning and a breaking change if possible. Put it on the parsing/interop level rather than deep in the code during runtime because it is very likely that your code is not correct without handling the extra case either way.

https://doc.rust-lang.org/reference/attributes/type_system.h...

link
masklinn 1591 days ago
Oooor the language can have proper type-safe enumerated types of some sort, and if you're in a domain where that's an issue you don't use them.
link
cle 1591 days ago
Go is focused on the distributed systems domain though. It's fine, even desirable, to have languages focused on particular domains, that make design decisions based on the constraints of the domain. In this domain, closed enums are footguns with costly consequences if you get it wrong.
link
farresito 1591 days ago
As someone that doesn't work in that domain, could you give a short example?
link
closeparen 1591 days ago
You push Thrift clients out into the world expecting to a certain API field to be typed according to a 3-element enum. You add a 4th element to support a new feature in a new client. If you ever accidentally serve this 4th element to an old client, it will crash on deserialization. Bonus points if the client is old enough that it's not part of your testing regime anymore.
link
cle 1591 days ago
I would be okay with an open-by-default enum type. (I think...I'm not sure I've ever encountered a language with open-by-default enums.)

I'm still not sure if it's worth it, it's idiomatic Go to "fall-through" if-branches for default cases, which is the same when checking quasi-enums. The symmetry is nice and makes it very easy to read. But I could be convinced.

link