Skip to content

Commit ab72736

Browse files
committed
Merge branch 'master' of https://github.com/kornelski/rfcs
2 parents c25cfbf + 01434ea commit ab72736

File tree

1 file changed

+48
-0
lines changed

1 file changed

+48
-0
lines changed

0000-bury-description.md

Lines changed: 48 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,48 @@
1+
- Feature Name: optional_error_description
2+
- Start Date: 2017-11-29
3+
- RFC PR: (leave this empty)
4+
- Rust Issue: (leave this empty)
5+
6+
# Default implementation of `Error::description()`
7+
[summary]: #summary
8+
9+
Provide a default implementation of the `Error` trait's `description()` method to save users trouble of implementing this flawed method.
10+
11+
# Motivation
12+
[motivation]: #motivation
13+
14+
The `description()` method is a waste of time for implementors and users of the `Error` trait. There's high overlap between description and `Display`, which creates redundant implementation work and confusion about relationship of these two ways of displaying the error.
15+
16+
The `description()` method can't easily return a formatted string with per-instance error description. That's a gotcha for novice users struggling with the borrow checker, and gotcha for users trying to display the error, because the `description()` is going to return a less informative message than the `Display` trait.
17+
18+
# Guide-level explanation
19+
[guide-level-explanation]: #guide-level-explanation
20+
21+
Let's steer users away from the `description()` method.
22+
23+
1. Change the `description()` documentation to suggest use of the `Display` trait instead.
24+
2. Provide a default implementation of the `description()` so that the `Error` trait can be implemented without worrying about this method.
25+
26+
# Reference-level explanation
27+
[reference-level-explanation]: #reference-level-explanation
28+
29+
Users of the `Error` trait can then pretend this method does not exist.
30+
31+
# Drawbacks
32+
[drawbacks]: #drawbacks
33+
34+
When users start omitting bespoke `description()` implementations, code that still uses this method will start getting default strings instead of human-written description. If this becomes a problem, the `description()` method can also be formally deprecated (with the `#[deprecated]` attribute). However, there's no urgency to remove existing implementations of `description()`, so this RFC does not propose formal deprecation at this time to avoid unnecessary warnings during the transition.
35+
36+
# Rationale and alternatives
37+
[alternatives]: #alternatives
38+
39+
- Do nothing, and rely on 3rd party crates to improve usability of errors (e.g. various crates providing `Error`-implementing macros or the `Fail` trait).
40+
- The default message returned by `description` could be different.
41+
- it could be a hardcoded generic string, e.g. `"error"`,
42+
- it could return `core::intrinsics::type_name::<Self>()`,
43+
- it could try to be nicer, e.g. use the type's doccomment as the description, or convert type name to a sentence (`FileNotFoundError` -> "error: file not found").
44+
45+
# Unresolved questions
46+
[unresolved]: #unresolved-questions
47+
48+
None yet.

0 commit comments

Comments
 (0)