|
| 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