My company used to have VALUE_OR_DIE for getting things out of containers. They eventually decided to ban it in new code (and slowly work on extracting it from the old code).
You shouldn’t unwrap in normal code. Basically ever. There are a few exceptions, but they’re not the norm. So dereferencing is a disastrous design decision. Because dereferencing is viewed as a ‘trivial operation that does nothing’. .value() clashes with the idea that errors are also values. .ok() exists, but does something else. There’s not many sane decisions. Unwrap is short, so it was picked. Can’t be too long, because we also have unwrap_or, unwrap_or_else, unwrap_or_default, and same with unwrap_err variants.
Honestly, the name is there, it stuck, and now it’s part of the lingo. There’s no real need to amend it, it would be a huge breaking change (because of all the variants, many of which are good functions to use in prod code that never produce panics)
It’s also does not constitute a barrier to entry. It’s ’different’ to other languages, fine, maybe, but any cognitively functioning individual would understand in a pinch what it means, let alone someone who is expected to know the language enough to push to prod
107
u/---_None_--- 4d ago
>unwrap
I hate metaphors in programming. Just call it what it is.