4 ms·
Isn't unwrap(x) just match x { Some(v) => return v None => die painfully } ? If so, the None is still handled. Dying painfully is an
by strbean 7y ago
Isn't unwrap(x) just
match x {
Some(v) => return v
None => die painfully
}
?
If so, the None is still handled. Dying painfully is an escape hatch out of the type system in any language that lets you do it.
- deleted 7y ago[deleted]
- reificator 7y agoI was responding to the following post: > The key difference is that in your second example you can just forget about the else branch, while in Rust you must explicitly handle the None case, otherwise it won't compile. Do you really think that `unwrap()` is meaningfully different from "forget[ting] about the else branch"? Does it require you to "explicitly handle the None case"? My goal here was not to get mired in semantic arguments that ignore the context of the discussion. It was merely to highlight that Rust lets you assume that things won't be null the same as any other language, and that the important difference is that rust lets you be clear about what can and cannot be null.
- strbean 7y agoI get the thrust of your argument (that the expressiveness of the type system is what matters here), and it makes sense to me. I'm not sure I agree with this though: > Do you really think that `unwrap()` is meaningfully different from "forget[ting] about the else branch"? Does it require you to "explicitly handle the None case"? I haven't used Rust, so but digging up the source shows unwrap is indeed just a `match` that panics on None. The fact that "you can put thing inside a function and call that function" doesn't mean you "don't have to explicitly do thing". We end up with a pretty useless standard for "explicitly doing thing" if putting thing in a function doesn't count.