I'm quite fond of error-chain (https://github.com/rust-lang-nursery/error-chain), which helps mitigate it somewhat. You can do things like:

    use error::{Error, ErrorKind, Result, ResultExt};
    
    fn some_func(v: &str) -> Result<u32> {
        v.parse::<u32>().chain_err(|| ErrorKind::ParseIntError)
    }

The purpose of `chain_err` here is to add on top of the previous error, to explain what you were trying to do, instead of passing up the previous error (in this case, `std::num::ParseIntError`).

If you don't like that, you can do something like this:

    use std::boxed::Box;
    use std::error::Error;

    fn some_func(v: &str) -> Result<u32, Box<Error>> {
        v.parse::<u32>().map_err(|e| Box::new(e))
    }

But then you'd have to box every error.

? should help a lot with this, but libraries like error-chain, or the newer (and, IMO much better) failure can help even more.

But ? only worked if the function it was used in had the same error type as the function you called, which was mostly not the case...

... I think. I don't remember it that vividly.

It doesn't have to be the same type, there just has to be a suitable implementation of the 'From' trait to perform the conversion if the types don't match.

? calls a conversion function. It only won't work if the error you're trying to return won't convert to the error that's in the type signature. Even then, you have options, like .map_err.

We have gone a bit down a tangent here. My original complaint was about the friction of different error types compared to other languages (like, say, Go).

Having to implement a bunch of From traits (unless you need io::Error, because everything seemed to have conversions from/to that), or having to implement inline error conversion through map_err, is such friction. I might go as far as consider it the most cumbersome error system I have used. Clean idea, cumbersome implementation.

My comment about '?' not working with mismatched types was mostly just to say that it doesn't fix anything, it just adds a bit of convenient syntactic sugar.

There is zero friction if you use either error_chain/failure crate and you can still recover the precise underlying errors. The only thing is it allocates.

I will look into those crates next time!

failure has no_std feature for the no-heap cases.