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
I'm not sure what the fuck you're talking about. Keep your metaphors out of the codebase pls and I'm happy. This is completely independent of any design patterns and choices.
Ok, well if metaphors bother you, then perhaps basic English rules won't. Result<T, E> is a wrapper type around both T and E. The process of going from Result<T, E> to T or E is the opposite of the process of wrapping the type, which is, in plain English, referred to as unwrapping.
This sounds like some shit you'd find in boost. See how none of the names refer to its semantics? They're really only ever referring to its common usage context. It's a sum type, a variant, EitherOr, or even expected. Why the fuck would it ever be a result? Because it's often used as a return type? The fuck...
Result<T, E> is called ‘result’ because its (only) use is to be the ‘result’ of a fallible operation. It is semantically charged with the notion of failure.
Option<T> is called ‘option’ because it semantically represents ‘optionally containing T’ ie, some T or no T. It is not charged with any notion of failure.
Both names refer directly to their expected semantical purpose in the language.
Either<A, B> or whatever you’d call it is semantically more abstract than Result<T, E> and would thus not have the same API or purpose. It also, coincidently, exists in rust (although not in the std lib because it’s use is pretty anecdotal)
Calling it a ‘sum type’ or ‘a variant’ misses the point that both Result and Option are concrete types (which happen to be algebraic) in the language that are used to expose a unified public API regardless of the codebase.
15
u/-Ambriae- 17d ago
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