Attribute macros on enum variants fail

[protodeniz]

Something like this utilizing https://facet.rs fails:

error_set::error_set! {
	#[derive(facet::Facet)] #[repr(u8)]
	pub enum FooError {
		A(#[facet(opaque)] extrenal_crate::TypeThatDoesntImplementFacetError),
		B(#[facet(opaque)] extrenal_crate::TypeThatDoesntImplementFacetError),
	}
}

Relevant error message:

error: unexpected token, expected `)`
  --> src/lib.rs:30:16
   |
30 |         A(#[facet(opaque)] extrenal_crate::TypeThatDoesntImplementFacetError),
   |           ^

If the code above is moved outside of error_set! macro, it works as expected. Thus, I think it should work within in as well.

[mcmah309]

I may jumped the gun with the initial declaration that "Error enums are now also supported", it still uses the same parsing and resolution under the hood, so single tuple variants like this are treated as source variants. We should probably support a different syntax entirely for regular enums - the regular enum syntax.

Regular enums can be treated as an error itself, meaning no source variants (or at least a different syntax e.g. #[source]/#[from] like thiserror uses) that way we can fully support the enum syntax (including regular tuple variants). Though the result of this would be that regular enums will probably fall outside the scope of the set resolution (i.e. don't map to each other with From). This may actually be desired though. For now I updated the README to reflect this.

[protodeniz]

I understand the frustration between maintaining two different syntax. Despite that I admire the shortcut syntax with math flavor, I think the best way to handle things is to be more explicit, or rather be more like regular Rust, so that it feels confortable for everyone, in my honest opinion, of course.

For the moment I am using the said enum type outside the macro to be able to annotate it with the Facet derive macro. Though I would like to mention that the issue remains even though I use the dedicated syntax within the macro (which I forgot to mention, sorry).

This is rather a different issue/opinion, but since you mentioned a possibility of a #[from] attribute macro, I would like to raise another possibility if it better aligns with your opinions/this library's intentions. I use this library to map the error types of those who do not utilize error_set-like approach to error handling, a la "Mega Enum". For instance, the popular sqlx library uses such an enum type for error handling, and often you don't need many of the variants when querying a database, or you don't need most variants when trying to establish a connection or begin a transaction. I often see myself having various enum variants of my own in my errors to reflect different possibilities that could occur that are either relevant to me or not. For instance, when I am querying the database, I might be interested in RowNotFound variant, but less on other variants, and I would encapsulate that variant inside mine with a more descriptive variant, such as UserNotFoundByEmail. I hope you see where I am coming from. It would be very useful to have a dedicated syntax to have code generated for my type to implement From<sqlx::Error> such that the variantRowNotFound would be mapped to UserNotFoundByEmail and the rest could be mapped to Internal or other variants of mine.

[mcmah309]

I think the best way to handle things is to be more explicit, or rather be more like regular Rust,

I've dabble with idea of making things regular rust only, but then it becomes slightly more verbose. e.g.

error_set::error_set! {
    X<G: Debug> := {
        A {
            a: G
        },
        (io::Error) {
            field1: String,
            field2: &'static str,
        }
    }

    Y<H: Debug> := {
        B {
            b: H
        }
    }

    Z<T: Debug> := X<T> || Y<T>
}

->

error_set::error_set! {
    pub enum X<G: Debug> {
        A {
            a: G
        },
        IoError {
            source: io::Error,
            field1: String,
            field2: &'static str,
        }
    }

    pub enum Y<H: Debug>  {
        B {
            b: H
        }
    }

    #[include(X<T>, Y<T>)] // name tbd
    pub enum Z<T: Debug> {}
} 

Maybe this is desired and more flexible though.

It would be very useful to have a dedicated syntax to have code generated for my type to implement From<sqlx::Error> such that the variantRowNotFound would be mapped to UserNotFoundByEmail and the rest could be mapped to Internal or other variants of mine.

Can you give an example of a syntax and generated code you would want?

[maun]

Another use case for additional attribute macros: https://mozilla.github.io/uniffi-rs/latest/proc_macro/errors.html
Is adding this derive already possible with the existing syntax?