Closed NWPlayer123 closed 8 months ago
If I create an error type not using SNAFU and check its documentation, it contains those deprecation warnings:
use std::fmt;
#[derive(Debug)]
pub struct Demo;
impl fmt::Display for Demo {
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
"Demo".fmt(f)
}
}
impl std::error::Error for Demo {}
I'm sure you've checked something similar, so I'm not sure I understand what your end goal is here. Can you try and restate so I understand better?
So it does, interesting. I was mostly bringing this up because I found https://github.com/shepmaster/snafu/blob/main/src/no_std_error.rs#L6 as I was digging around how no_std works, and that's what I was mostly taking issue with.
In that case, you should use the same deprecation macro as the official Error does, as library authors are able to use it.
around how no_std works
If possible for your case, I'd recommend that you use the unstable-core-error feature flag to use the version of Error
that lives in the core library. Once that is stable enough, SNAFU will no longer have a reason to create its own Error
trait.
While writing up documentation, I noticed several deprecation warnings concerning description and cause, which have been deprecated since March 2020 and February 2019 respectively, which are coming up on 4 and 5 years ago, so I think it's high time to remove them entirely. Any repositories that still rely on it can either fix to a specific older version, or update their code to remove it.