Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upBury Error::description() #2230
Conversation
This comment has been minimized.
This comment has been minimized.
dtolnay
added
the
T-libs
label
Nov 29, 2017
kornelski
referenced this pull request
Nov 29, 2017
Closed
Provide better guidance for `Error::description` #45249
durka
reviewed
Nov 29, 2017
| # Drawbacks | ||
| [drawbacks]: #drawbacks | ||
|
|
||
| When users start omitting bespoke `description()` implementations, code that still uses this method will get machine-generated rather than human-written descriptions, so success of this change depends also on steering authors away from using this method as well. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
kornelski
Nov 29, 2017
Author
Contributor
- It could create too many warnings. Perhaps it would be OK to do it after a while?
- Some projects may still like using a static string for description. I'm concerned about saving time users who don't want to use it, but don't want to get in the way of users who still want it.
This comment has been minimized.
This comment has been minimized.
joshtriplett
Nov 30, 2017
Member
I would like to see the method formally deprecated at some point, but I agree that we should give it several releases before doing so, and make sure it has minimal impact on the ecosystem.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
jnicholls
commented
Nov 30, 2017
|
Totally agree on making this method optional/transparent/forgotten/deprecated/dismissed/booted/chopped/kicked/etc. |
CAD97
referenced this pull request
Dec 18, 2017
Open
nom4: the trait `std::error::Error` is not implemented for `nom::internal::Err<&[u8]>` #591
aturon
assigned
withoutboats
Feb 14, 2018
This comment has been minimized.
This comment has been minimized.
|
@withoutboats can you shepherd this RFC? |
This comment has been minimized.
This comment has been minimized.
|
Why not deprecate it also? |
This comment has been minimized.
This comment has been minimized.
|
@withoutboats It might be just me... but To make |
This comment has been minimized.
This comment has been minimized.
|
@Centril can you point to some code that uses description in that way? |
This comment has been minimized.
This comment has been minimized.
|
@sfackler Not really; If you have such a unit-variant enum, then I guess you can use an inherent method instead - the bound isn't important wrt. |
SimonSapin
referenced this pull request
Apr 15, 2018
Closed
Soft-deprecate the description() method of the Error trait #49536
Mark-Simulacrum
reviewed
Apr 20, 2018
| # Reference-level explanation | ||
| [reference-level-explanation]: #reference-level-explanation | ||
|
|
||
| The description method can have default implementation returning `core::intrinsics::type_name::<Self>()`. This preserves basic functionality of this method for backwards compatibility. |
This comment has been minimized.
This comment has been minimized.
Mark-Simulacrum
Apr 20, 2018
Member
Are we comfortable somewhat stabilizing type_name? This makes it at least somewhat easy to (abuse) this to get it's functionality on stable for non-error types in at least binaries where the impl of Error doesn't matter too much from an exposed API perspective.
Either way, we should explicitly state that this method's default return value is not stable and should not be relied on from version to version.
This comment has been minimized.
This comment has been minimized.
kornelski
added a commit
to kornelski/book
that referenced
this pull request
Apr 20, 2018
This comment has been minimized.
This comment has been minimized.
U007D
commented
Apr 20, 2018
•
|
Overall, I like this. Although I'm not sure why we'd steer people away from implementing
would seem to apply any time any feature is deprecated, no? The above-mentioned warning would also serve to reinforce the updated documentation, essentially ensuring discovery. Overall, things are currently a bit messier than I think we'd all like around errors and error handling--moving as swiftly as we can (but not recklessly) seems to me to be a good way to realizing the full potential of Rust's error handling--to that end, I'd (also) support official deprecation of Procedural question: Should I review with "change requested", or just leave this feedback as it is? |
This comment has been minimized.
This comment has been minimized.
repax
commented
Apr 20, 2018
|
I would like The identifier name of a type should not have any consequence on its public output/effect - especially not by default. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
repax
commented
Apr 21, 2018
|
Is is out of the question to have different outputs depending on whether The default output for both the |
This comment has been minimized.
This comment has been minimized.
|
I'm thinking about making the message push authors towards switching to |
This comment has been minimized.
This comment has been minimized.
U007D
commented
Apr 21, 2018
•
|
Hmm.. this is tricky! :)
|
bors
added a commit
to rust-lang/rust
that referenced
this pull request
Apr 30, 2018
This comment has been minimized.
This comment has been minimized.
U007D
suggested changes
Apr 30, 2018
| # Drawbacks | ||
| [drawbacks]: #drawbacks | ||
|
|
||
| When users start omitting bespoke `description()` implementations, code that still uses this method will start getting empty 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. |
This comment has been minimized.
This comment has been minimized.
U007D
Apr 30, 2018
•
...code that still uses this method will start getting empty strings instead of human-written description
No longer--the implementation merged into master now returns "description() is deprecated; use Display" as a default message.
Suggest: s/empty strings/.description() deprecated message
U007D
approved these changes
Apr 30, 2018
U007D
approved these changes
Apr 30, 2018
This comment has been minimized.
This comment has been minimized.
U007D
commented
Apr 30, 2018
|
I have no power... :) |
alexcrichton
merged commit 01434ea
into
rust-lang:master
May 3, 2018
This comment has been minimized.
This comment has been minimized.
|
It turns out that the implementation for this RFC has already merged! In light of that I'm going to go ahead and merge the RFC |

kornelski commentedNov 29, 2017
•
edited by Centril
Rendered
Thread on internals