Repository navigation
Tracking issue for Result::map_or_else #53268
Description
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.
Activity
[-]Result should also have map_or_else(), like Option[/-][+]Tracking issue for Result::map_or_else[/+]withoutboats commentedon Aug 29, 2018
Implemented in #53777
Rollup merge of rust-lang#53777 - ivanbakel:result_map_or_else, r=ale…
liigo commentedon 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 commentedon Sep 23, 2018
It would also be good to have
Result::map_or.Boscop commentedon Sep 28, 2018
@liigo Yes, having the
fallbackas second argument makes more logical sense because it mirrors theif elsestructure, but this would be a breaking change now :(Emerentius commentedon 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 commentedon Oct 15, 2018
@Emerentius I agree that having the
okhandler 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 withmap_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 commentedon Oct 15, 2018
map_orwas 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 themap_or_elseprecedent fromOptionwhich is stable, already.Looks like we're stuck with it…
traviscross commentedon 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_orat the same time.ivanbakel commentedon Dec 1, 2018
Is there any reason this shouldn't just be the tracking issue for
map_oras 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 commentedon Dec 24, 2018
Seconding
map_orrequesttesuji commentedon Nov 11, 2019
#66292 is adding
map_or. Feedback welcomed.KatsuoRyuu commentedon 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:
and the parameters are then switched, is mildly said absurd! - keep things consistent!
mathstuf commentedon 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?tesuji commentedon Nov 12, 2019
Stabilization PR in #66322
Auto merge of #66322 - lzutao:consistent-result-map_or_else, r=dtolnay
cdbattags commentedon Jan 31, 2020
Looks like this is released with 1.41 but the order flip is really quite a pain.
Any precedent for why error first?
lo48576 commentedon Jan 31, 2020
@cdbattags Seems described in the first comment #53268 (comment).
I think it is "ok second" rather than "error first", similar to
Option::map_or_else.