Repository navigation
Tracking issue for Result::into_ok #61695
Description
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 :)
Activity
Lonami commentedon Jun 9, 2019
How is this different from the never (
!) type? In fact, that page mentions Infallible errors with the same wording.phaylon commentedon Jun 9, 2019
@Lonami I'm not sure I understand the question in relation to the proposal?
core::convert::Infallibleis an existing type that acts as a stand-in for the never type, since the never type itself is still unstable. Core APIs likeTryFromalready useInfallible.I'm proposing an unwrapping
fnonResultthat is specific to dealing withcore::convert::Infallible, and later (when it's stable) the never type.Lonami commentedon Jun 9, 2019
Oh, sorry, I should've checked first, I was unaware of that ^^
phaylon commentedon Jun 9, 2019
No problem! Should've maybe added some background information,
TryFromandInfallibleare rather recent additions :)scottmcm commentedon Jun 11, 2019
Looks like this might be rust-lang/rfcs#1723?
phaylon commentedon Jun 11, 2019
@scottmcm Ah, yes. I didn't go back to 2016, and didn't search in the RFCs :)
mzabaluev commentedon Nov 2, 2019
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.
[-]Add Result::unwrap_infallible[/-][+]Tracking issue for `Result::into_ok`[/+]Auto merge of #66045 - mzabaluev:unwrap-infallible, r=sfackler
Rollup merge of rust-lang#66045 - mzabaluev:unwrap-infallible, r=dtolnay
40 remaining items
Stabilize `Result::into_{ok,err}`
Stabilize `Result::into_{ok,err}`
Rollup merge of rust-lang#161712 - theemathas:stab-into-ok-err, r=nia-e
Rollup merge of rust-lang#161712 - theemathas:stab-into-ok-err, r=nia-e
Rollup merge of rust-lang#161712 - theemathas:stab-into-ok-err, r=nia-e
Rollup merge of rust-lang#161712 - theemathas:stab-into-ok-err, r=nia-e
Rollup merge of #161712 - theemathas:stab-into-ok-err, r=nia-e
Rollup merge of #161712 - theemathas:stab-into-ok-err, r=nia-e
Rollup merge of #161712 - theemathas:stab-into-ok-err, r=nia-e
Stabilize `Result::into_{ok,err}`
Rollup merge of rust-lang#161712 - theemathas:stab-into-ok-err, r=nia-e
Stabilize `Result::into_{ok,err}`
theemathas commentedon Oct 4, 2026
Stabilized in #161712