Signed↔Unsigned integer methods

[scottmcm]

Proposal

Problem statement

One common pattern of numeric conversions is having a signed value and needing it in the unsigned type, or vice versa. Things like isize::MAX as usize, for example, or before we added .add(i) needing .offset(i as isize).

Motivating examples or use cases

Unfortunately, doing it like that isn't necessarily great. In particular, if the source value changes to something wider, it'll silently start truncating. Not to mention that it's a big length jump from i as usize to usize::try_from(i).unwrap() to get a checked version, so people will generally do the short thing where we can't give them any help in debug mode because as is defined to truncate, so for all we know the 300_i32 as u8 might be intentional. Or maybe it turns out that i as usize was actually converting from a u16, not doing a signedness change at all.

It would be nice to have a way to express just that you want it as the other-signedness type, nothing more.

Solution sketch

impl uNNNN {
    /// In debug, `self.try_into().unwrap()`.
    /// In release, `self as _`.
    pub const fn to_signed(self) -> iNNNN;

    /// Always `self as _`.
    pub const fn reinterpret_signed(self) -> iNNNN;
}
impl iNNNN {
    /// In debug, `self.try_into().unwrap()`.
    /// In release, `self as _`.
    pub const fn to_unsigned(self) -> uNNNN;

    /// Always `self as _`.
    pub const fn reinterpret_unsigned(self) -> uNNNN;
}

Alternatives

• Do nothing, since it's not strictly wrong as-is
• Solve the as problems by telling people to use a trait like https://github.com/rust-lang/rfcs/pull/3703 instead of as
• Just have the as-equivalent one, saying that try_into is fine for the checking
• Have a full set of wrapping_to_signed, checked_to_signed, saturating_to_signed instead of just reinterpret_signed.
• Add constants for more common cases, like u32::SIGNED_MAX to stop needing i32::MAX as u32.

Links and related work

I vaguely remember some recent conversations about this, but haven't found it :/

Here's an old thread discussing something similar: https://internals.rust-lang.org/t/pre-rfc-add-methods-like-42u32-to-signed-to-the-standard-library/12173?u=scottmcm

What happens now?

This issue contains an API change proposal (or ACP) and is part of the libs-api team feature lifecycle. Once this issue is filed, the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months.

Possible responses

The libs team may respond in various different ways. First, the team will consider the problem (this doesn't require any concrete solution or alternatives to have been proposed):

• We think this problem seems worth solving, and the standard library might be the right place to solve it.
• We think that this probably doesn't belong in the standard library.

Second, if there's a concrete solution:

• We think this specific solution looks roughly right, approved, you or someone else should implement this. (Further review will still happen on the subsequent implementation PR.)
• We're not sure this is the right solution, and the alternatives or other materials don't give us enough information to be sure about that. Here are some questions we have that aren't answered, or rough ideas about alternatives we'd want to see discussed.