Tracking issue for platform-dependent-API TryFrom impls involving usize/isize

[SimonSapin]

Background

For converting between different primitive integer types we have impls of the From trait (and so of TryFrom<Error=!> through the generic impl<T, U> TryFrom<T> for U where U: From<T>) for conversions that always succeed (for example u8 to u32), and TryFrom<Error=TryFromIntError> for other conversions (for example u32 to u8, which return Err(_) on values that would overflow).

When usize or isize is involved however, some conversions can be fallible or infallible depending on the target platform’s pointer width. (For example u64 to usize on 64-bit v.s. 32-bit platforms.)

There is desire to make such impls infallible with From whenever possible. Since APIs would be different on the target platform, their usage should be gated on a portability lint that is not implemented yet. (The lint would additionally need to be able to "see" that a non-portable impl is used indirectly through a generic impl like impl<T, U> TryFrom<T> for U where U: From<T> or impl<T, U> Into<U> for T where U: From<T>.)

A downside of this is that even code that would be portable because it doesn’t care about the error type (because it only tests for the presence of an error, or works in both case though e.g. the From conversion inside the ? operator) would still need top opt into "non-portability" in order to silence the lint.

In order to be able to stabilize the TryFrom trait without waiting for the portability lint to be implemented, #49305 removed the affected impls. They are those marked NP in the table in #49305 (comment):

• TryFrom<usize> for u16, u32, u64, u128, i32, i64, i128
• TryFrom<isize> for i16, i32, i64, i128
• TryFrom<_> for usize: u32, u64, u128
• TryFrom<_> for isize: u16, u32, u64, u128, i32, i64, i128

Alternatives

We want to have these impls eventually, but need to chose between:

• Different APIs based on the target platform, with a portability lint
• Give up on static-infallibility-on-some-platforms and make these impls apparently-fallible with TryFrom<Error=TryFromIntError> on all platforms.

[clarfonthey]

More discussion on this is also in #48593.

[SimonSapin]

Also:

• Policy for assumptions about the size of usize rfcs#1748
• https://internals.rust-lang.org/t/lang-team-minutes-integer-conversion-and-portability-writ-large/4170

[SimonSapin]

Not having these impls at all is a "hole" in the functionality of this trait: #49305 (comment)

[Kixunil]

An idea:

impl TryFrom<u64> for usize {
    type Error = SizeConversionError<u64>;

    // fn try_from ...
}

impl<T> From<SizeConverstionError<T>> for TryFromIntError {
// fn from ...
}

// Mark use of this trait with portability lint
// The philosophy is similar to e.g. AsRawFd trait
trait SizeConversionExt {
    type Value;

    fn conversion_never_fails(self) -> Self::Value;
}

// pseudo attribute - don't know the real one
#[cfg(pointer_size = 64)]
impl SizeConversionExt for Result<u64, SizeConverstionError<u64>> {
    type Value = u64;

    fn conversion_never_fails(self) -> Self::Value {
        match self {
            Ok(val) => val,
            Err(e) => e.uninhabited,
        }
    }
}

// Portable code:
fn portable<T: TryInto<usize>>(val: T) {
    match val.try_into() {
        // ...
    }
}

// For X86-64
fn non_portable(val: u64) {
    #[allow(non-portable)]
    use /*something::something*/SizeConversionExt;
    let val: usize = val.try_into().conversion_never_fails();
    // Do whatever with val
}

[clarfonthey]

I think that making all of these conversions go through TryFrom is the best route. Infallible conversions can be marked as Error = ! and then any matching without an Err branch would trigger the portability lint. We still get the same performance gains, but people know by nature of saying try_from instead of from that it won't always work.

[SimonSapin]

@clarcharr I’m not sure what you mean. Note that though a generic impl, any From conversion also has a corresponding TryFrom<Error=!> conversion. Are you suggesting that the missing impls should not have From, only TryFrom, but with an error type that varies based on the platform? That’s less of a portability hazard than an impl that may or may not be there, but only slightly: if you do anything with the error value it still has a type that varies across platforms. So this would still need a portability lint that does not exit yet.

I also don’t know what you mean by performance: whatever the error type, with sufficiently advanced inlining the optimizer can see that a given impl only ever returns Ok and compile .unwrap() (or whatever) into a no-op. The reason people have been asking for platform-specific impls so to be able to write code that is statically apparent to never fail on the platforms they care about, so that .unwrap() is not needed in the first place.

[ltratt]

Bitter experience over many years of porting code that performs integer conversions suggests to me that people will use infallible conversions on code that will later be run on platforms where the conversion does indeed fail, creating a portability headache. Even in the presence of a lint, this stuff often leaches deeply into the design of a program, including things which a lint won't pick up, where it can become extremely difficult to unpick.

As @SimonSapin says, with sufficiently good optimisations -- which, IIRC the last time I looked at this is already the case -- both the From and TryFrom case have identical performance for infallible conversions. For the few cases where one wants to make clear that a conversion is infallible, I think it's probably even arguable that using a completely different API (e.g. from a crate for this purpose) is a good idea.

[Kixunil]

I agree with @ltratt. I've recently participated on porting some code from 32 to 64 bit and it wasn't fun.

That being said, performance is fine in simple cases, but I guess it would get worse with more complex code where errors are propagated and handled by the caller. That's why I'd prefer what I wrote above: have a special error type with a private field of type ! or () depending on conversion and platform.