What happens if A || B have variants with the same name?

[Byron]

Hi! First of all, let me say that I am very intrigued!

thiserror gives me a lot of trouble and it's something on the list of things to change, and even though I have some ideas myself on how that could be done, error_set should be the right step to take to ease the pain.

However, knowing the deep hierarchies that gitoxide errors can form, variant name conflicts are going to happen.

What happens if two errors use the same variant name but store different data. Or worse, have the same and the same data, but different display implementations and different semantics?

Thank you.

[mcmah309]

thiserror gives me a lot of trouble and it's something on the list of things to change, and even though I have some ideas myself on how that could be done, error_set should be the right step to take to ease the pain.

Agreed definitively a motivation that led me to create this crate.

What happens if two errors use the same variant name but store different data.

If two errors use the same variant name but store different data || only includes the first one that occupies that space - || works like an "or" operation for the set space.

error_set::error_set! {
    Error1 = {
        Variant(std::io::Error),
    };
    Error2 = {
        Variant(std::fmt::Error),
    };
    Error3 = Error1 || Error2;
    // Equal to the above
    // Error3 = {
    //     Variant(std::io::Error),
    // };
}

If this is not what one wants, there are a few ways to currently approach this.

1. Minimize the probability. Like in Zig, take a different approach to group naming. Understanding that enums should not give additional information about the error, but instead only rely on the variant. e.g. UserLoginError::UserNotFound is better than UserLoginError::NotFound. i.e. variant names should try to be unique for the use case.
2. Wrap the errors instead of ||

Error3 = {
    Error1(Error1),
    Error2(Error2),
};

From's will still be automatically generated.
3. Define the variant structure you want and manually implement From

Error3 = {
    Variant1(std::io::Error),
    Variant2(std::fmt::Error),
};

impl From<Error1> for Error3 {
    fn from(e: Error1) -> Self {
        match e {
            Error1::Variant(err) => Error3::Variant1(err),
        }
    }
}
...

Or worse, have the same and the same data, but different display implementations and different semantics?

Display messages are not considered when determining what can be converted into the other. So in

error_set::error_set! {
    Error1 = {
        #[display("Some unique message: {0}")]
        Variant(std::io::Error),
    };
    Error2 = {
        #[display("Another unique message: {0}")]
        Variant(std::io::Error),
    };
}

Error1 and Error2 both have From implementations between each other, but different display messages for the variant.

[Byron]

Thanks a lot for elaborating, the answer is much appreciated!

I think I understand the concept now and it makes sense that error_set treats each variant as part of the same set, with error types acting like a grouping. As opposed to thiserror, it's a flat hierarchy as long as one chooses to work with ||, but it's possible to break out and return to the usual nesting by simply nesting the errors in question.

For plumbing crates, it's probably usually feasible to have one errors.rs per crate, whereas in gix, the crate that brings all the plumbing crates together, one can consider to have many well-defined error_set usages to group together multiple related errors.

I presume that the variant-handling can't cross crate boundaries, so plumbing level errors will not be 'flattened', which is probably very desirable as well.

All in all, I think error_set will do exactly what I'd hope it could, and will simplify the collection of errors and error variants significantly, while making error definitions at least 50% less cumbersome :).

What a wonderful crate, thank you!

[Byron]

I tried it, planning to bring it into gix as it would help there most. Unfortunately, RustRover completely fails its code-completion with anything created from the macro. And without that, I can't use it as I definitely rely on completion quite a bit.

It makes me sad, but I will be sure to revisit it as it should only be a matter of time until it the IDE catches up.

[mcmah309]

I think I understand the concept now and it makes sense that error_set treats each variant as part of the same set, with error types acting like a grouping. As opposed to thiserror, it's a flat hierarchy as long as one chooses to work with ||, but it's possible to break out and return to the usual nesting by simply nesting the errors in question.

Exactly.

I presume that the variant-handling can't cross crate boundaries, so plumbing level errors will not be 'flattened', which is probably very desirable as well.

Yes.

Unfortunately, RustRover completely fails its code-completion with anything created from the macro.

Curious, so starting to type Diff.. does not complete or DiffTreeToTreeError::? That would be unfortunate, maybe defining it in a different module would help. In vscode it works and I haven't seen any IDE related issues. I just did a quick test, defining errors with the macro and without to see if there is any IDE differences and didn't detect any, tool-tips and all.

[Byron]

Unfortunately it just doesn't work in RustRover, and I have no idea why. Probably it's different with RustAnalyser, but that's not a backend I use just yet. Maybe it's the same issue with thiserror, but due to the way it works, it's just an enum even without the Derive macro doing its magic so completion would work.

Also I wouldn't be surprised if RustRover had crate-specific hacks to make common crates work better, which is a good explanation for error_set not working at all even though I thought it can resolve macros and proc-macros.

[mcmah309]

In principle it should be the same since both take token streams and spit out a new token stream, regardless if the input for thiserror is more similar to a regular Rust enum.

I was able to take a look at this today and download RustRover. Could you elaborate more on what type of behavior are you expecting?