Match is not smart enough to deduce the only possible catch-all type

[Disasm]

This example compiles successfully:

fn f2() -> Result<i32, String> {
    unimplemented!()
}

fn f1() -> Result<i64, String> {
    match f2() {
        Ok(value) => Ok(value as i64),
        Err(err) => Err(err),
    }
}

However, this example does not:

fn f2() -> Result<i32, String> {
    unimplemented!()
}

fn f1() -> Result<i64, String> {
    match f2() {
        Ok(value) => Ok(value as i64),
        err => err,
    }
}

Obviously, err can only be of Err(e) kind so it's correct to return it from f1().

[estebank]

This is because err is of type Result<i32, String>::Err, which doesn't autocast to Result<i64, String>::Err. They are in effect two different types.

That being said, for this case the idiomatic code would be

fn f1() -> Result<i64, String> {
    f2().map(|v| v as i64)
}

or

fn f1() -> Result<i64, String> {
    Ok(f2()? as i64)
}

[dtolnay]

The Err(err) => Err(err) match arm is not a no-op, it is doing:

match f2() {
    Ok(value) => Ok(value as i64),
    Err::<i32, String>(err) => Err::<i64, String>(err),
}

Accepting err => err when only the error types are the same may break code in which err => err establishes that the ok types are the same. For example:

fn f2<T>() -> Result<T, String> {
    unimplemented!()
}

fn f1() -> Result<i64, String> {
    match f2() {
        Ok(value) => Ok(value as i64),
        err => err,
    }
}

This compiles today but an implicit conversion from Err::<T1, String> to Err::<T2, String> would make the choice of T type parameter for f2 ambiguous.

[estebank]

Cc #47560

[Spoonbender]

Triage: no change

Since the reason is known and is a non-bug, can we close this issue?

[estebank]

@Spoonbender potentially, but I would like it if we had a structured suggestion for the presented cases, but I understand it might be too niche of a situation to make it worth it to handle it.

The original request would probably be better served as a t-lang request (which I would likely expect would be considered a bad idea).

---

Edit: let's close it, at least for now. I would like the suggestion to exist, but don't think this is necessarily the ticket for that.