[Feature request] Enabling support for transitive "#[from]' handling #435

Activity

1. TuTiuTe commented on Oct 22, 2025

   

   TuTiuTe

   on Oct 22, 2025

   More actions

   I also encountered this issue, but tried to look at it from a feasibility / proc_macro standpoint.

   In your example, your error is called MyError but later called DbError, I'll go with DbError.

   proc_macros only have the context of the object right below them, so when the first derive(Error) looks at DbError, and then at its field ConversionDbError, it has no clue what it is an enum, with a field Uuid, that can be converted to ConversionDbError.

   This could be solved by a macro giving more context to derive(Error), so for instance:

   #[derive(Error, Debug)]
   pub enum MyError {
       #[error("Network error: {0}")]
       Network(String),
   
       #[error("Conversion Error: {0}")]
       #[from(uuid::Error)]
       ConversionError(#[from] ConversionDbError),
   
       // Around 30 other variants

   In which case the macro could expand to

   impl From<uuid::Error> for DbError {
       fn from(e: uuid::Error) -> Self {
           Self::ConversionError(e.into())
       }
   }

   Note that this is only theoretical and I did not try it out nor am I affiliated with this project
2. Grimeh commented on Jul 24, 2026

   

   Grimeh

   on Jul 24, 2026

   More actions

   Would also love to see support for a transitive From impl for a given variant.

   Ideally as a variant of #[from] (eg. #[from_transitive]), since it only works if there are no overlapping From impls between the parent & nested error enums. Eg. if they both have variants with #[from] std::io::Error it will fail to compile with Conflicting implementations of trait `From<std::io::Error>` for type `Parent`..

   I currently use the following when I don't have overlapping From impls:

   impl<E> From<E> for ParentError
   	where E: Into<NestedError>
   {
   	fn from(value: E) -> Self {
   		value.into().into()
   	}
   }