-
Notifications
You must be signed in to change notification settings - Fork 120
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
Make TryInto use better error type #173
Milestone
Comments
I ran into this today as well, would love it if it returned a proper error instead. |
I think you are both right and what we want instead is to have a generic error type provided by derive_more. Something like this (untested code): struct TryIntoError<T> {
pub input: T
variant_names: &str
output_type: &str
}
impl fmt::Display for Point {
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
write!(f, "Only {} can be converted to {}", self.variant_names, self.output_type)
}
} |
This was referenced Oct 15, 2022
Added 1.0 milestone, since i agree that this should be the default. But changing the default would be a breaking change. |
JelteF
added a commit
that referenced
this issue
Oct 23, 2022
proc-macro crates are loaded by the compiler instead of by the crate that depends on it. This means it's not possible to use anything else than exported anything else than exported proc-macros. But in some cases we want the generated derives to use structs or traits that are provided by the library. Two examples of this are: 1. An error type that can be used by the `Into` derive ([#173][173]) 2. Or to support trait objects for the `source` of the `Error` derive ([#122][122]) This change splits the layout of this crate in two. One crate that only exports proc-macros and is loaded by the compiler. And a second crate that re-exports all these macros but is also able to export different things such as structs and traits. [173]: #173 [122]: #122
JelteF
added a commit
that referenced
this issue
Oct 23, 2022
proc-macro crates are loaded by the compiler instead of by the crate that depends on it. This means it's not possible to use anything else than exported anything else than exported proc-macros. But in some cases we want the generated derives to use structs or traits that are provided by the library. Two examples of this are: 1. An error type that can be used by the `Into` derive ([#173][173]) 2. Or to support trait objects for the `source` of the `Error` derive ([#122][122]) This change splits the layout of this crate in two. One crate that only exports proc-macros and is loaded by the compiler. And a second crate that re-exports all these macros but is also able to export different things such as structs and traits. NOTE: This only refactors the code in this repo. No functional changes happen in this change. These will be done in follow-up PRs. [173]: #173 [122]: #122
JelteF
added a commit
that referenced
this issue
Oct 23, 2022
proc-macro crates are loaded by the compiler instead of by the crate that depends on it. This means it's not possible to use anything else than exported anything else than exported proc-macros. But in some cases we want the generated derives to use structs or traits that are provided by the library. Two examples of this are: 1. An error type that can be used by the `Into` derive ([#173][173]) 2. Or to support trait objects for the `source` of the `Error` derive ([#122][122]) This change splits the layout of this crate in two. One crate that only exports proc-macros and is loaded by the compiler. And a second crate that re-exports all these macros but is also able to export different things such as structs and traits. NOTE: This only refactors the code in this repo. No functional changes happen in this change. These will be done in follow-up PRs. [173]: #173 [122]: #122
JelteF
added a commit
that referenced
this issue
Nov 14, 2022
proc-macro crates are loaded by the compiler instead of by the crate that depends on it. This means it's not possible to use anything else than exported anything else than exported proc-macros. But in some cases we want the generated derives to use structs or traits that are provided by the library. Two examples of this are: 1. An error type that can be used by the `Into` derive ([#173]) 2. Or to support trait objects for the `source` of the `Error` derive ([#122]) This change splits the layout of this crate in two. One crate that only exports proc-macros and is loaded by the compiler. And a second crate that re-exports all these macros but is also able to export different things such as structs and traits. NOTE: This only refactors the code in this repo. No functional changes happen in this change. These will be done in follow-up PRs. [#173]: #173 [#122]: #122 Required for #173 #122 Co-authored-by: tyranron <tyranron@gmail.com>
tyranron
added a commit
that referenced
this issue
Nov 15, 2022
Instead of returning a string as the error, this returns a dedicated error type. This has the big benefit that in case of an error it's possible to get back the original value by using `error.input`. Previously, the original value would be dropped in case of an error. Additionally: - introduce `std` and `all_no_std` default Cargo features - add `no_std` CI job to track regressions of `no_std` builds Co-authored-by: Kai Ren <tyranron@gmail.com>
liveseed
added a commit
to liveseed/derive_more
that referenced
this issue
Aug 20, 2024
proc-macro crates are loaded by the compiler instead of by the crate that depends on it. This means it's not possible to use anything else than exported anything else than exported proc-macros. But in some cases we want the generated derives to use structs or traits that are provided by the library. Two examples of this are: 1. An error type that can be used by the `Into` derive ([#173]) 2. Or to support trait objects for the `source` of the `Error` derive ([#122]) This change splits the layout of this crate in two. One crate that only exports proc-macros and is loaded by the compiler. And a second crate that re-exports all these macros but is also able to export different things such as structs and traits. NOTE: This only refactors the code in this repo. No functional changes happen in this change. These will be done in follow-up PRs. [#173]: JelteF/derive_more#173 [#122]: JelteF/derive_more#122 Required for #173 #122 Co-authored-by: tyranron <tyranron@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Rather than returning a string as an error, might it not be better to use a struct that stores the type and variant names as strings, which implements Display to show a full error message? That struct can then easily implement
std::error::Error
too.Perhaps this can be enabled as an optional feature, as suggested in #130? Although it kinda feels like this should be the default behaviour
The text was updated successfully, but these errors were encountered: