Tracking Issue for `Result::into_ok_or_err` / `feature(result_into_ok_or_err)`

[thomcc]

Feature gate: #![feature(result_into_ok_or_err)]

This is a tracking issue for Result::into_ok_or_err, a method to get the T out of Result<T, T> regardless of which variant is active.

Public API

impl<T> Result<T, T> {
    pub const fn into_ok_or_err(self) -> T;
}

Steps / History

• Implementation: Add a Result::into_ok_or_err method to extract a T from Result<T, T> #80572
• Final commenting period (FCP)
• Stabilization PR

Unresolved Questions

• What color should the bikeshed be What name should it have?
  Some options that have been suggested:
  • Result::into_ok_or_err
  • Result::ok_or_err
  • Result::into_either
  • Result::into_inner
  • Result::either_value
  • Result::unwrap_either
  • Several more suggested options are listed in the issue.
• Do we want a reference version as well, as add Result::{value, into_value} #79315 proposed?

[thomcc]

Do we want a reference version as well, as #79315 proposed?

I don't feel that strongly, but considered this (it was suggested to me when implementing the PR) and didn't do it because it can be achieved using Result::as_ref, e.g: r.as_ref().into_ok_or_err().

The same is true for a hypothetical &mut version (with Result::as_mut), etc.

[camsteffen]

I would narrow down the names to ones that are into_* which I understand to mean "transform infallibly". unwrap_* means "transform or panic" and ok_or_err to me looks like an Option-returning function like ok and err.

[leonardo-m]

The API surface of Result/Option is quite large already. The bar for adding even more methods for them should be raised because it's getting harder for me to remember and use all of them.

[thomcc]

The API surface of Result/Option is quite large already. The bar for adding even more methods for them should be raised because it's getting harder for me to remember and use all of them.

There are multiple cases in the stdlib (e.g. ignoring external crates) where something like this is beneficial. The alternatives are less clear (r.unwrap_or_else(core::convert::identity)) and/or more verbose (explicit match).

There were also multiple PRs proposing this, showing it's not just me that considers it to meet the bar for addition.

I also think that broadly the current design of these types (and many other APIs in libcore, Iterator as an example, or the functions on the numeric types) favor functionality over minimalism in the API, but that's more of a philosophical question. You also don't have to use them if you fail to remember them.

[leonardo-m]

You also don't have to use them if you fail to remember them.

Please don't say this, it's a fallacy :-)

[faern]

This method became more relevant since deprecating Atomic*::compare_and_swap. Since now people should use compare_exchange which returns Result<T, T>.

[thomcc]

Yeah, that actually motivated this.

Edit: FWIW in the mean time I think r.unwrap_or_else(core::convert::identity) can be used, although it's not as clear.

[memoryruins]

With or_patterns stabilized in #79278, the following is accepted without a feature gate (not yet on a stable release)

let (Ok(x) | Err(x)) = slice.binary_search(&42);

The method this issue tracks could still be useful for chaining, but I thought I may as well mention the above ^^

[TheDan64]

Calling it into_inner seems like it makes the most sense; you don't really care if it was Ok or Err, just that you take ownership to get the inner value out of it

[photino]

It will be more useful if we can impl it for Result<T, E> where E: Into<T>.