add Result::
{value
, into_value
} by llogiq · Pull Request #79315 · rust-lang/rust (original) (raw)
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation11 Commits1 Checks0 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
Recently using binary_search
, I found that I had to manually match the Result
to get the value of the insertion point (and in my use case I didn't need to care about whether it was Ok
or Err
). So I thought this method was missing from Result
.
The implementation might be possible to optimize further, but this is a safe initial version.
r? @sfackler
(rust_highfive has picked a reviewer for you, use r? to override)
The question is whether the name value
is more valuable (heh) for this use-case or to extract it from Result<T, !>
at some point in the future.
Those use cases don't need to clash: We could implement value
for Result<T, !>
, too (at least I think so). We already have into_ok
for Result<T, impl Into<!>>
, though, which has a different meaning than throwing away the discriminant.
Maybe there's a name that's more descriptive of what it does? value
could mean a lot of different things. I wasn't able to guess from the PR title what these new functions would do. (Maybe ok_or_err()
or into_either()
or something in that direction?)
Do you have any examples where this would be useful other than binary_search
? If that's the only motivating example, I'm not sure whether I'd consider this a problem with Result
or with binary_search
. If you're interested in the insertion point and not in finding a specific item, a function like binary_search
that doesn't use Ord
but just bool
(a truly binary search) would fit the use case better, although Rust doesn't have that (yet?). (See also some thoughts here: #74024 (comment))
There's let Ok(n) | Err(n) = result
but it's feature-gated (or_patterns
).
any examples where this would be useful other than binary_search
This could be another use case: #80486
Triage: What's next steps here?
JohnCSimon added S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
Relevant to the cargo team, which will review and decide on the PR/issue.
and removed S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
Relevant to the cargo team, which will review and decide on the PR/issue.
labels
Ah, it looks like #80572 was a duplicate of this.
Thanks again for your PR. I'm closing this, as #80572 was merged, which adds the same function (although with a different name).
The reference version was not added by that PR, but that option was added as an open question to the tracking issue. Feel free to add your comments there.
Labels
Area: Result and Option combinators
Status: Awaiting review from the assignee but also interested parties.
Relevant to the library API team, which will review and decide on the PR/issue.