-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Fallible try_map on Option #1815
Comments
I've done this before and find it more generally useful (e.g., when using match statements). However, |
I was informed recently that this function is called @Stebalien If there would be a method that flipped the types, what would you call it? I think that both would be useful. |
I just published a |
Very nice! Makes sense to use values; I don't even recall why I write it with references in the first place.
… Am 14.12.2016 um 14:00 schrieb Pyry Kontio ***@***.***>:
I just published a try_map crate that implements try_map and flip methods. This is a slightly different from @killercup's implementation, since that used references whereas this one uses values. (In accordance with the original map method. Values are more flexible anyway, since if you want to map over refernces, you can always call as_ref for the Option.)
https://github.com/golddranks/try_map
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Haskell's |
Just tried to implement Curiously, the I didn't have any problem tweaking the trait that provides However, this brings up the following question: if some new helper methods would be added on |
Btw. released a version 0.2 of |
One more thing: obviously a |
@golddranks I think you can change the trait to have an associated type impl<T, U, E> FallibleMapExt<T, U, E> for Vec<T> {
type Target = Result<Vec<U>, E>;
fn try_map<F>(self, f: F) -> Self::Target where
F: FnOnce(T) -> Result<U, E>
{
let res = Vec::with_capacity(self.len());
for item in self {
res.push(f(item)?);
}
Ok(res)
}
} People should probably prefer |
(This is a re-post of rust-lang/rust#38282, just in the correct place.) Using
Option::map
together with the?
operator is a pain. If you are mapping over an optional type, you can't use?
inside the closure to signal error. This means that it's often impractical to map functions that returnResult
s over optional types. Here's a way to alleviate that:...but as noted in the comment, in the cases where the error matters, this is bad, and needs to be refactored into a
match
statement.It would help the ergonomics, if
Option<T>
had a method – let's call itEDIT: a better name was suggested by @killercup:fallible_map
try_map
– like this:What it would do, it would map the function over
T
, but wrap anOk
result intoOption
and return thatOption
wrapped into aResult
. This would allow mapping fallible functions overOption
s:...which, combined with
?
, allows neat, fluid APIs while handling errors properly.Does adding this kind of an API to
Option
need an RFC?A simple implementation was demonstrated by @killercup here. As he mentioned, it could live in a 3rd party crate, but as a simple helper method that is in many ways similar to the already-existing
Option::map
,Option::and_then
and others, helping with massaging the types in the right shape, I could easily imagine it being part of the standard API.Note that alternative to this would be a method over
Option<Result<T, E>>
that would "flip" the types toResult<Option<T>, E>
.The text was updated successfully, but these errors were encountered: