Why does InvokeError have from_anyhow instead of implementing From<anyhow::Error>?

[CrendKing]

InvokeError has from_anyhow, which converts an anyhow error to itself. It is useful, so that user can call an internal functions that returns anyhow error from a command function. However, it still requires an explicit map_error(InvokeError::from) at the end of every fallible command. Why did tauri decide to not implement From<anyhow::Error> so that the conversion can be implicit?

[adamhp]

Currently struggling with this myself! Would love to have the clean syntax from the implicit conversion.

[FabianLars]

Not an actual answer to the "why" since I wasn't involved in the linked change, but i always thought that you're not supposed to use InvokeError in commands yourself. It looked more like a tauri internal thing which is exposed because it is part of the public api (and needed by those who don't use the command macro).

So from that POV, not having From implementations make sense to prevent unexpected/"hidden" behavior. -> That said, not 100% familiar with the macro etc, so i'm not sure if that would even have direct impact but since InvokeError is what the commands actually return in the end i'd imagine so 🤔

[CrendKing]

In that case, I'll avoid using InvokeError directly. Thanks!

[JonasKruckenberg]

This is not by design, but a consequence of Rust's rules around implementing traits for types from 3rd party crates.

If you look at the code

You will notice we are implementing From<T> for InvokeError for all types that can be serialized. This makes total sense as the requirements around commands is that all parameters and return types (including errors) must be serializable/deserializable. So far so good.

Now if we were to try to add another impl

impl From<anyhow::Error> for InvokeError {
   fn from(value: anyhow::Error) -> Self {
      todo!()
   }
}

You will notice the compiler complains. This is because anyhow::Error doesn't not currently implement Serialize but it might start to anytime in the future
This would then break our code, since we would now have two From implementations for the same type (the generic T would now also match anyhow::Error)
As a consequence the compiler wouldn't know anymore which impl to choose and compilation would fail.

This is why we have the rather verbose from_anyhow and from_serde_json methods.

If you're familiar with Rust RFCs you might have noticed that this sounds and awful lot like specialization and indeed this would solve our issue, as the compiler would now accept our two From impls, simply choosing the more specific one.