- Feature Name:
option_result_map_or_default
- Start Date: 2021-07-14
- RFC PR: rust-lang/rfcs#3148
- Rust Issue: rust-lang/rust#0000
Option
has the methods unwrap
, unwrap_or
, unwrap_or_else
and unwrap_or_default
. It
similarly has map
, map_or
, map_or_else
, however map_or_default
is missing. The exact same
problem exists for Result
. This RFC is a proposal to add this method to Option
and Result
.
As mentioned before, a user might reasonably expect this method to exist, based on the existence of
other or_default
methods such as unwrap_or_default
. Furthermore, this is a very common usecase.
Searching for map_or_else
in .rs
files in the official Rust repository it is incredibly common
to see instances like these:
.map_or_else(String::new, ...)
.map_or_else(SmallVec::new, ...)
.map_or_else(Vec::new, ...)
In fact, from a manual count at the time of writing, 25 out of the 57 occurrences of map_or_else
in the Rust codebase could have been replaced with an equivalent call to map_or_default
.
The following implementation would get added to core::option::Option
:
impl<T> Option<T> {
pub fn map_or_default<U: Default, F: FnOnce(T) -> U>(self, f: F) -> U {
match self {
Some(t) => f(t),
None => Default::default(),
}
}
}
The following implementation would get added to core::result::Result
:
impl<T, E> Result<T, E> {
pub fn map_or_default<U: Default, F: FnOnce(T) -> U>(self, f: F) -> U {
match self {
Ok(t) => f(t),
Err(e) => Default::default(),
}
}
}
It adds another method to Option
and Result
, which may be considered as cluttered by some.
.map_or_else(Default::default, ...)
can be written, although it is significantly longer.- In case
feature(default_free_fn)
stabilizes a user can write.map_or_else(default, ...)
afterstd::default::default
, which is a bit shorter.
However, neither alternative solves the discrepancy between unwrap_or_default
existing but
map_or_default
not existing.
We already have unwrap_or_default
.
None.