-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bury Error::description() #2230
Conversation
0000-bury-description.md
Outdated
# 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not also formally deprecate the method?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- 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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 for eventual formal deprecation
Totally agree on making this method optional/transparent/forgotten/deprecated/dismissed/booted/chopped/kicked/etc. |
@withoutboats can you shepherd this RFC? |
Why not deprecate it also? |
@withoutboats It might be just me... but To make |
@Centril can you point to some code that uses description in that way? |
@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. |
0000-bury-description.md
Outdated
# 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Simon's current PR just returns ""
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? |
I would like The identifier name of a type should not have any consequence on its public output/effect - especially not by default. |
Is is out of the question to have different outputs depending on whether The default output for both the |
I'm thinking about making the message push authors towards switching to |
Hmm.. this is tricky! :)
|
Bury Error::description() Second attempt of #49536 rust-lang/rfcs#2230 The exact wording of the default implementation is still up in the air, but I think it's a detail that can be amended later.
0000-bury-description.md
Outdated
# 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
...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
I have no power... :) |
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 |
Rendered
Thread on internals