Skip to content
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 and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue for Result::map_or_else #53268

Closed
Boscop opened this issue Aug 11, 2018 · 14 comments · Fixed by #66322
Closed

Tracking issue for Result::map_or_else #53268

Boscop opened this issue Aug 11, 2018 · 14 comments · Fixed by #66322

Comments

@Boscop
Copy link

@Boscop Boscop commented Aug 11, 2018

Result should also have map_or_else(), like Option (but the closure for the else case should also get the Err as argument, like with unwrap_or_else).

Both Option and Result have unwrap_or_else and unwrap_or, so they should also both have map_or_else.

@frewsxcv frewsxcv added the T-libs label Aug 11, 2018
@withoutboats withoutboats changed the title Result should also have map_or_else(), like Option Tracking issue for Result::map_or_else Aug 29, 2018
@withoutboats

This comment has been minimized.

Copy link
Contributor

@withoutboats withoutboats commented Aug 29, 2018

Implemented in #53777

kennytm added a commit to kennytm/rust that referenced this issue Sep 12, 2018
…xcrichton

Implemented map_or_else for Result<T, E>

Fulfills rust-lang#53268
The example is ripped from `Option::map_or_else`, with the types corrected.
@liigo

This comment has been minimized.

Copy link
Contributor

@liigo liigo commented Sep 21, 2018

I think its parameters should be changed
from
fn map_or_else(self, fallback: F, map: M)
to
fn map_or_else(self, map: M, fallback: F)

@rpjohnst

This comment has been minimized.

Copy link
Contributor

@rpjohnst rpjohnst commented Sep 23, 2018

It would also be good to have Result::map_or.

@Boscop

This comment has been minimized.

Copy link
Author

@Boscop Boscop commented Sep 28, 2018

@liigo Yes, having the fallback as second argument makes more logical sense because it mirrors the if else structure, but this would be a breaking change now :(

@Emerentius

This comment has been minimized.

Copy link
Contributor

@Emerentius Emerentius commented Oct 13, 2018

@Boscop That's not an issue because it's still unstable. In most cases the error is of a different type than the value and it would cause a compile time error, anyway.

@Boscop

This comment has been minimized.

Copy link
Author

@Boscop Boscop commented Oct 15, 2018

@Emerentius I agree that having the ok handler as first arg would make more sense, but I'm not sure how we can change it now.. map_or_else's arg order was chosen to be consistent with map_or. We would have to change the order for both then. I guess you'd have to do a RFC to suggest changing this.

@Emerentius

This comment has been minimized.

Copy link
Contributor

@Emerentius Emerentius commented Oct 15, 2018

map_or was flipped from the obvious order so that the typically short default case would be in front of the potentially long closure. Breaking consistenty with that is less troublesome than the map_or_else precedent from Option which is stable, already.
Looks like we're stuck with it…

@traviscross

This comment has been minimized.

Copy link

@traviscross traviscross commented Oct 25, 2018

Look on the bright side. The original ergonomic argument that the typically longer closure should be at the end is still compelling and provides a reasonable basis for making consistent decisions about this sort of thing.

To second what was mentioned above, it would make a lot of sense to add Result::map_or at the same time.

@ivanbakel

This comment has been minimized.

Copy link
Contributor

@ivanbakel ivanbakel commented Dec 1, 2018

Is there any reason this shouldn't just be the tracking issue for map_or as well? To me, it seems like they can fall under the same feature flag (even if it won't be as accurately named anymore).

@jethrogb

This comment has been minimized.

Copy link
Contributor

@jethrogb jethrogb commented Dec 24, 2018

Seconding map_or request

@lzutao

This comment has been minimized.

Copy link
Contributor

@lzutao lzutao commented Nov 11, 2019

#66292 is adding map_or. Feedback welcomed.

@KatsuoRyuu

This comment has been minimized.

Copy link

@KatsuoRyuu KatsuoRyuu commented Nov 12, 2019

I'm sorry but this implementation of map_or_else is incredibly annoying as it differs from Option.
When the original issue says:

Result should also have map_or_else(), like Option (but the closure for the else case should also >get the Err as argument, like with unwrap_or_else).

Both Option and Result have unwrap_or_else and unwrap_or, so they should also both have >map_or_else.

and the parameters are then switched, is mildly said absurd! - keep things consistent!

@mathstuf

This comment has been minimized.

Copy link
Contributor

@mathstuf mathstuf commented Nov 12, 2019

Oof. Indeed. Not only are they switched from Option, but they're backwards from the name too. I really hope it's not too late. Does it need a new feature gate name or is that considered "nightly problems" too?

@lzutao

This comment has been minimized.

Copy link
Contributor

@lzutao lzutao commented Nov 12, 2019

Stabilization PR in #66322

@bors bors closed this in 7d761fe Nov 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.