Skip to content
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

Closed
bravely-beep opened this issue Oct 6, 2021 · 3 comments · Fixed by #220
Closed

Make TryInto use better error type #173

bravely-beep opened this issue Oct 6, 2021 · 3 comments · Fixed by #220
Milestone

Comments

@bravely-beep
Copy link

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

@orlp
Copy link

orlp commented Dec 24, 2021

I ran into this today as well, would love it if it returned a proper error instead.

@JelteF JelteF added this to the 1.0.0 milestone Oct 15, 2022
@JelteF
Copy link
Owner

JelteF commented Oct 15, 2022

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

@JelteF
Copy link
Owner

JelteF commented 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>
JelteF added a commit that referenced this issue Nov 14, 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.

Fixes #173
Fixes #130
JelteF added a commit that referenced this issue Nov 14, 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.

Fixes #173
Fixes #130
JelteF added a commit that referenced this issue Nov 14, 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.

Fixes #173
Fixes #130
JelteF added a commit that referenced this issue Nov 14, 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.

Fixes #173
Fixes #130
JelteF added a commit that referenced this issue Nov 14, 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.

Fixes #173
Fixes #130
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
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants