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
Investigate switching IntoError
from an associated type to generics
#399
Labels
Comments
shepmaster
added
enhancement
New feature or request
feedback requested
User feedback desired on a design decision
labels
Aug 20, 2023
As more-or-less expected, with the increased flexibility of the generics, certain pieces of code now become ambigous. For example, this code is no longer valid because nothing constrains let e = trigger().context(SomeSnafu).unwrap_err();
ErrorCompat::backtrace(&e) |
As another attempt, I looked at making the trait closer in concept to // Library code
pub trait IntoError<C> {
type Error;
fn into_error(self, context: C) -> Self::Error;
}
struct NoneError;
// User code
#[derive(Debug)]
struct GenericError<T> {
value: T,
}
// Generated code
struct GenericSnafu<__T0> {
value: __T0,
}
impl<T, __T0> IntoError<GenericSnafu<__T0>> for NoneError
where
__T0: ::core::convert::Into<T>,
{
type Error = GenericError<T>;
#[track_caller]
fn into_error(self, context: GenericSnafu<__T0>) -> Self::Error {
GenericError {
value: ::core::convert::Into::into(context.value),
}
}
} Unfortunately, that runs into a compiler error:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
In #398, we discussed the possibility of changing
IntoError
to look something likeI think this would be needed to support having multiple
#[snafu(from)]
attributes.The text was updated successfully, but these errors were encountered: