Tracking issue for `Result::into_ok`

[phaylon]

This is (now) a tracking issue for
https://doc.rust-lang.org/nightly/std/result/enum.Result.html#method.into_ok
https://doc.rust-lang.org/nightly/std/result/enum.Result.html#method.into_err
#![feature(unwrap_infallible)]

---

I would like to propose adding a unwrap_infallible associated function to core::result::Result. The purpose is to convert Result<T, core::convert::Infallible> to a T, as the error case is impossible.

The implementation would basically be:

impl<T> Result<T, Infallible> {
    #[inline]
    pub fn unwrap_infallible(self) -> T {
        match self {
            Ok(value) => value,
        }
    }
}

An example use-case I have is a wrapper type with generic value verification, like Handle<T:Verify>. Some verifications can fail, but some can not. When verification is infallible, a Result<Handle<T>, Infallible> will be returned.

Since some can fail, the Handle type implements TryFrom and not From. Because of the blanket implementation of TryFrom for all types implementing From, I can't additionally add a From conversion for the infallible cases. This blanket implementation makes sense, as it allows an API to take a T: TryFrom and handle all possible conversions, even infallible ones.

But for the API consumer it would be beneficial to be able to go from an infallible Result<T, Infallible> to a plain T without having to manually match or use expect. The latter is shorter and chainable, but has the disadvantage that it will still compile when the types are changed and the conversion is no longer infallible.

It might be that there is a different solution to infallible conversions via TryFrom in the future, for example via specialization. I believe that having an unwrap_infallible would still be beneficial in many other cases where generically fallible actions can be infallible in certain situations. One example is when working with a library that is based on fallible operations with a user supplied error type, but where the specific implementation from the user is infallible.

I'd be happy to work on a PR for this if it's acceptable to add, though I might require some guidance with regards to stability attributes, feature flags and so on. It's a bit hard to find information on that, and experimentation is costly as it takes me a while to complete a ./x.py test src/libcore :)

[Lonami]

How is this different from the never (!) type? In fact, that page mentions Infallible errors with the same wording.

[phaylon]

@Lonami I'm not sure I understand the question in relation to the proposal?

core::convert::Infallible is an existing type that acts as a stand-in for the never type, since the never type itself is still unstable. Core APIs like TryFrom already use Infallible.

I'm proposing an unwrapping fn on Result that is specific to dealing with core::convert::Infallible, and later (when it's stable) the never type.

[Lonami]

Oh, sorry, I should've checked first, I was unaware of that ^^

[phaylon]

No problem! Should've maybe added some background information, TryFrom and Infallible are rather recent additions :)

[scottmcm]

Looks like this might be rust-lang/rfcs#1723?

[phaylon]

@scottmcm Ah, yes. I didn't go back to 2016, and didn't search in the RFCs :)

[mzabaluev]

Hijacking this as a tracking issue for rust-lang/rfcs#2799
I'm amazed at: 1) myself for never finding this before writing the RFC; 2) anyone who has seen my proposal at internals.rust-lang.org not bringing up this issue either.