Stabilize Result::map_or_else #66322

tesuji · 2019-11-12T03:11:43Z

Stabilized this API:

impl<T, E> Result<T, E> {
    pub fn map_or_else<U, D: FnOnce(E) -> U, F: FnOnce(T) -> U>(self, default: D, f: F) -> U {
        match self {
            Ok(t) => f(t),
            Err(e) => default(e),
        }
    }
}

Closes #53268
r? @SimonSapin

SimonSapin · 2019-11-12T10:46:25Z

This matches the signature of already-stable Option::map_or_else (except that the default callback gets the error value as a parameter)

@rfcbot fcp merge

rfcbot · 2019-11-12T10:46:26Z

Team member @SimonSapin has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

timvermeulen · 2019-11-12T11:45:29Z

src/libcore/result.rs

@@ -539,9 +538,12 @@ impl<T, E> Result<T, E> {
 /// assert_eq!(x.map_or_else(|e| k * 2, |v| v.len()), 42);
 /// ```
 #[inline]
- #[unstable(feature = "result_map_or_else", issue = "53268")]
- pub fn map_or_else<U, M: FnOnce(T) -> U, F: FnOnce(E) -> U>(self, fallback: F, map: M) -> U {
- self.map(map).unwrap_or_else(fallback)


What was wrong with the previous implementation?

The new implementation is consistent with Option::map_or_else: https://doc.rust-lang.org/nightly/src/core/option.rs.html#491-496

So we are following Principle of Least Surprise.

Even less Surprising would be to not change an implementation in a stabilization PR.

Also, IMO the original implementation was better because it more clearly shows the relation between map_or_else, map, and unwrap_or_else. The whole point of these methods is that we don't have to write matches everywhere.

If you like it, we could send a PR later to fix it in both Option and Result.

@timvermeulen That might be true, but following the paradigm of keeping things simple and consistent is also needed. The original idea was to create map_or_else and unwrap_or_else the same as on Option, and then things get switched around. That is just absurd, and makes it harder to deal with because you to constantly ask yourself, "which way arround was this command?!" - and honestly i dont have time for that in a progeramming language.

@tomwhoiscontrary I think that question has been asked before, or a derivative thereof. The conclusion was that Options map_or_else is already in stable and would therefore not be changed, as that would be breaking much more.
Part of the discussion is in here #53268

@KatsuoRyuu My question is the one i asked - why is Option::map_or_else the way it is. I am not suggesting changing it. I want to understand why it is the way it is.

@tomwhoiscontrary sorry for the misunderstanding that, will see if I can find the documentation for that for you, I think I saw it somewhere ;)

@tomwhoiscontrary this is the thread I remembered seeing, rust-lang/rfcs#1025. So the reason for the initially is to follow the convention of map_or, so all parameters are always prepended.

Thanks! The explanation makes sense. If we had keyword arguments, this problem would disappear!

rfcbot · 2019-11-12T22:24:40Z

🔔 This is now entering its final comment period, as per the review above. 🔔

NilsIrl · 2019-11-15T19:07:05Z

Shouldn't the arguments be the other way round to match those of Option?

rfcbot · 2019-11-22T22:25:10Z

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.

tesuji · 2019-11-23T09:13:23Z

r? @dtolnay

dtolnay

Thanks!

Relatedly, I wish that we had more realistic examples for these type of combinator methods. The current example code is:

let k = 21;

let x : Result<_, &str> = Ok("foo");
assert_eq!(x.map_or_else(|e| k * 2, |v| v.len()), 3);

which is so contrived that it doesn't help you understand how the method is intended to be used.

It would be better to find real uses in the wild and distill them into example code. Something like this is where I would expect to encounter map_or_else:

    ...
    .map_or_else(Response::DatabaseError, |id| {
        if id.is_empty() {
            Response::Empty
        } else {
            Response::User(id.to_string())
        }
    })

dtolnay · 2019-11-24T03:52:05Z

@bors r+

bors · 2019-11-24T03:52:06Z

📌 Commit c06a8ea has been approved by dtolnay

bors · 2019-11-24T07:37:07Z

⌛ Testing commit c06a8ea with merge 7d761fe...

@SimonSapin

Stabilize Result::map_or_else Stabilized this API: ```rust impl<T, E> Result<T, E> { pub fn map_or_else<U, D: FnOnce(E) -> U, F: FnOnce(T) -> U>(self, default: D, f: F) -> U { match self { Ok(t) => f(t), Err(e) => default(e), } } } ``` Closes #53268 r? @SimonSapin

bors · 2019-11-24T10:52:05Z

☀️ Test successful - checks-azure
Approved by: dtolnay
Pushing 7d761fe to master...

tesuji added 2 commits November 12, 2019 03:08

make Result::map_or_else consistent with Option::map_or_else

2de6c35

stabilize Result::map_or_else

c06a8ea

rust-highfive assigned SimonSapin Nov 12, 2019

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Nov 12, 2019

tesuji mentioned this pull request Nov 12, 2019

Tracking issue for Result::map_or_else #53268

Closed

Centril added relnotes Marks issues that should be documented in the release notes of the next release. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Nov 12, 2019

Centril added this to the 1.41 milestone Nov 12, 2019

Centril added the needs-fcp This change is insta-stable, so needs a completed FCP to proceed. label Nov 12, 2019

rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Nov 12, 2019

timvermeulen reviewed Nov 12, 2019

View reviewed changes

rfcbot added the final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. label Nov 12, 2019

rfcbot removed the proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. label Nov 12, 2019

rfcbot added finished-final-comment-period The final comment period is finished for this PR / Issue. and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels Nov 22, 2019

rust-highfive assigned dtolnay and unassigned SimonSapin Nov 23, 2019

dtolnay approved these changes Nov 24, 2019

View reviewed changes

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 24, 2019

bors added the merged-by-bors This PR was explicitly merged by bors. label Nov 24, 2019

bors merged commit c06a8ea into rust-lang:master Nov 24, 2019

tesuji deleted the consistent-result-map_or_else branch November 24, 2019 11:15

dtolnay mentioned this pull request Nov 27, 2019

stabilize Result::map_or #66570

Merged

imp mentioned this pull request Dec 10, 2019

Update RELEASES.md for 1.40.0 #66377

Merged

MightyPork mentioned this pull request Aug 22, 2021

Documentation on Result::map_or_else uses very unfortunate wording #88195

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Stabilize Result::map_or_else #66322

Stabilize Result::map_or_else #66322

tesuji commented Nov 12, 2019 •

edited

Loading

SimonSapin commented Nov 12, 2019

rfcbot commented Nov 12, 2019 •

edited by KodrAus

Loading

timvermeulen Nov 12, 2019

tesuji Nov 12, 2019

timvermeulen Nov 12, 2019

tesuji Nov 12, 2019

KatsuoRyuu Nov 13, 2019

KatsuoRyuu Nov 13, 2019

tomwhoiscontrary Nov 13, 2019

KatsuoRyuu Nov 14, 2019

KatsuoRyuu Nov 14, 2019 •

edited

Loading

tomwhoiscontrary Nov 14, 2019

rfcbot commented Nov 12, 2019

NilsIrl commented Nov 15, 2019

rfcbot commented Nov 22, 2019

tesuji commented Nov 23, 2019

dtolnay left a comment

dtolnay commented Nov 24, 2019

bors commented Nov 24, 2019

bors commented Nov 24, 2019

bors commented Nov 24, 2019

Stabilize Result::map_or_else #66322

Stabilize Result::map_or_else #66322

Conversation

tesuji commented Nov 12, 2019 • edited Loading

SimonSapin commented Nov 12, 2019

rfcbot commented Nov 12, 2019 • edited by KodrAus Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

KatsuoRyuu Nov 14, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rfcbot commented Nov 12, 2019

NilsIrl commented Nov 15, 2019

rfcbot commented Nov 22, 2019

tesuji commented Nov 23, 2019

dtolnay left a comment

Choose a reason for hiding this comment

dtolnay commented Nov 24, 2019

bors commented Nov 24, 2019

bors commented Nov 24, 2019

bors commented Nov 24, 2019

tesuji commented Nov 12, 2019 •

edited

Loading

rfcbot commented Nov 12, 2019 •

edited by KodrAus

Loading

KatsuoRyuu Nov 14, 2019 •

edited

Loading