expect_err for Result. #38982
expect_err for Result. #38982
Conversation
|
r? @aturon (rust_highfive has picked a reviewer for you, use r? to override) |
clarfonthey
force-pushed
the
expect_err
branch
from
495a9fa to
66c7ab7
Compare
apasel422
added
the
T-libs-api
clarfonthey
force-pushed
the
expect_err
branch
from
66c7ab7 to
8c9ba49
Compare
|
cc @rust-lang/libs This fits conventions and makes sense to me! Before we land, we'll need to open a tracking issue and tag the stability attribute with it. |
|
I like it! |
| /// | ||
| /// Basic usage: | ||
| /// | ||
| /// ```{.should_panic} |
There was a problem hiding this comment.
It's archaic but equivalent to just should_panic.
There was a problem hiding this comment.
TBH I've wondered why you use this instead of just #![should_panic]. I just copied it from expect's docs.
|
If the general consensus is to merge, I can create a tracking issue and tag it in the PR. |
|
@clarcharr Let's do it! |
clarfonthey
force-pushed
the
expect_err
branch
from
8c9ba49 to
e520b77
Compare
|
@aturon It is done! |
|
@bors: r+ Thanks for the PR! |
|
📌 Commit e520b77 has been approved by |
expect_err for Result. This adds an `expect_err` method to `Result`. Considering how `unwrap_err` already exists, this seems to make sense. Inconsistency noted in Manishearth/rust-clippy#1435.
|
☀️ Test successful - status-appveyor, status-travis |
This adds an
expect_errmethod toResult. Considering howunwrap_erralready exists, this seems to make sense. Inconsistency noted in Manishearth/rust-clippy#1435.