4 ms·

> 1. The Rust community is biased against the usage of "unwrap". It was supposed to make prototyping easier. It should not have been there and should not be use

by epage 8y ago

> 1. The Rust community is biased against the usage of "unwrap". It was supposed to make prototyping easier. It should not have been there and should not be used. I'm a little confused on this point you are making. You say the Rust community is biased against `unwrap` which makes it sound like you think that is wrong but then you proceed to say it shouldn't be there, making it sound like you agree. `unwrap` has legitimate uses in product code as an assertion. Normally I recommend `expect` instead so that the assertion is self-documenting but there are times where the the scope of the assumption you are making is so small, it is obvious and doesn't need a comment, for example if I partition a collection based on the result [0] [0]: https://doc.rust-lang.org/stable/rust-by-example/error/iter_result.html#collect-all-valid-values-and-failures-with-partition https://doc.rust-lang.org/stable/rust-by-example/error/iter_... > . If the function fail, the program should handle the failure. By design, a failure should not result on setting a "default value". That's not an error but more like an "option". From the function's perspective, it errored, but from your perspective, it failed and you want to fallback to a default value. Yes, someone could express this instead as an `Option` or a `Result<Option, _>` - Sometimes you just don't need that extra boiler plate - Sometimes you want to provide context for why something failed in case the user considers it an error as well. You can't express that with `Option`.

csomar 8y ago
> I'm a little confused on this point you are making. You say the Rust community is biased against `unwrap` which makes it sound like you think that is wrong but then you proceed to say it shouldn't be there, making it sound like you agree. Nope. I think unwrap shouldn't be used without understanding the error handling capabilities of Rust. It also shouldn't be used for deployed software. The problem is that most people introduced to Rust would like to see something working now and Rust has higher barrier to entry than most mainstream languages. They'll likely keep the habit. > From the function's perspective, it errored, but from your perspective, it failed and you want to fallback to a default value. That's not my point. My point is that a failed function should not return a "default value". A default value is not a failure but rather a design decision. Should the function fail, it returns an error.
- burntsushi 8y ago
  > It also shouldn't be used for deployed software. This is equivalent to saying that `&vector[i]` shouldn't be used in deployed software, since it's just syntactic sugar for `vector.get(i).unwrap()`. It's also equivalent to saying that `assert!(...)` should never be used in deployed software. Or `unreachable!()`. Or any number of other things. unwrap is perfectly fine for use in production. Stating a requirement in terms of unwrap doesn't make sense outside of niche scenarios. It's too specific and not really actionable in a lot of cases. A better way to put it is that programs that surface a panic to end users of the application have a bug. If the panic is from inside of a library and not the result of documented preconditions on a function, then the library has a bug. Otherwise, the bug is in the application.

by epage 8y ago

csomar 8y ago

> I'm a little confused on this point you are making. You say the Rust community is biased against `unwrap` which makes it sound like you think that is wrong but then you proceed to say it shouldn't be there, making it sound like you agree. Nope. I think unwrap shouldn't be used without understanding the error handling capabilities of Rust. It also shouldn't be used for deployed software. The problem is that most people introduced to Rust would like to see something working now and Rust has higher barrier to entry than most mainstream languages. They'll likely keep the habit. > From the function's perspective, it errored, but from your perspective, it failed and you want to fallback to a default value. That's not my point. My point is that a failed function should not return a "default value". A default value is not a failure but rather a design decision. Should the function fail, it returns an error.

burntsushi 8y ago
> It also shouldn't be used for deployed software. This is equivalent to saying that `&vector[i]` shouldn't be used in deployed software, since it's just syntactic sugar for `vector.get(i).unwrap()`. It's also equivalent to saying that `assert!(...)` should never be used in deployed software. Or `unreachable!()`. Or any number of other things. unwrap is perfectly fine for use in production. Stating a requirement in terms of unwrap doesn't make sense outside of niche scenarios. It's too specific and not really actionable in a lot of cases. A better way to put it is that programs that surface a panic to end users of the application have a bug. If the panic is from inside of a library and not the result of documented preconditions on a function, then the library has a bug. Otherwise, the bug is in the application.