Skip to content

Commit 77c2975

Browse files
committed
Quick draft "Result::expect" rfc
1 parent 64ccd29 commit 77c2975

File tree

1 file changed

+40
-0
lines changed

1 file changed

+40
-0
lines changed

text/0000-result-expect.md

Lines changed: 40 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,40 @@
1+
- Feature Name: `result_expect`
2+
- Start Date: 2015-05-13
3+
- RFC PR: (leave this empty)
4+
- Rust Issue: (leave this empty)
5+
6+
# Summary
7+
8+
Add an `expect` method to the Result type, bounded to `E: Debug`
9+
10+
# Motivation
11+
12+
While `Result::unwrap` exists, it does not allow annotating the panic message with the operation
13+
attempted (e.g. what file was being opened). This is at odds to 'Option' which includes both
14+
`unwrap` and `expect` (with the latter taking an arbitrary failure message).
15+
16+
# Detailed design
17+
18+
Add a new method to the same `impl` block as `Result::unwrap` that takes a `&str` message and
19+
returns `T` if the `Result` was `Ok`. If the `Result` was `Err`, it panics with both the provided
20+
message and the error value.
21+
22+
The format of the error message is left undefined in the documentation, but will most likely be
23+
the following
24+
```
25+
panic!("{}: {:?}", msg, e)
26+
```
27+
28+
# Drawbacks
29+
30+
- It involves adding a new method to a core rust type.
31+
- The panic message format is less obvious than it is with `Option::expect` (where the panic message is the message passed)
32+
33+
# Alternatives
34+
35+
- We are perfectly free to not do this.
36+
- A macro could be introduced to fill the same role (which would allow arbitrary formatting of the panic message).
37+
38+
# Unresolved questions
39+
40+
Are there any issues with the proposed format of the panic string?

0 commit comments

Comments
 (0)