Why don't the absolute value methods on signed integers return unsigned values?

Question

The following code fails to compile:

fn main() {
    let x = (-5i32).abs();

    let z: u32 = x;
}

with the message:

error[E0308]: mismatched types
 --> src/main.rs:4:18
  |
4 |     let z: u32 = x;
  |                  ^ expected u32, found i32

Reading the documentation, it looks the choice of i32 stems from the fact that i32::min_value() has no positive representation in i32. However, it would have a positive representation in u32, which can represent numbers twice as large.

I'm learning the language, and want to understand why certain design decisions were made so that I can develop good habits. I find this one confusing. Can someone explain why it works this way instead of just returning a u32, which would seem to be the semantically correct type?

Answer 1

There's a link to the development meeting minutes where this was discussed in the proposed RFC "Change abs() to return unsigned integers"

It looks like the main reasons were:

1. Many other languages use i32 -> i32 (for instance, C, Java), because the accidental promotion of other values to u32 might cause bugs. Rust seems to have used i32 -> i32 for this reason originally (i.e. following convention), but doesn't suffer from the same kinds of bugs.
2. This feature request wasn't submitted until after Rust had reached beta. The developers were not willing to introduce a breaking change to the language over what appears to be a rare bug. This looks like the main reason offered for keeping things this way.

It seems like the accepted workaround is to use as u32 to cast.

i32::overflowing_abs i32::wrapping_abs and i32::checked_abs implement other solutions to the i32::min_value() bug, but none of them produces a u32.