-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
add Result::map_or #66292
add Result::map_or #66292
Conversation
822e507
to
b8d7f8b
Compare
b8d7f8b
to
52dc216
Compare
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
52dc216
to
e1a61f2
Compare
r? @SimonSapin |
d8e9ab4
to
900c63a
Compare
I don’t think we have precedent for adding instantly-stable APIs, except in cases where constrained by limitation of the stability tracking implementation. (Specifically: trait impls do not have stability of their own, so a new impl of an existing stable trait for an existing stable type is insta-stable by necessity.) That said, in this case this is very similar to the existing I see you’ve already opened a tracking issue #66293, please change the attribute to unstable in this PR. |
900c63a
to
e8f3a9f
Compare
Done. |
Looks good, thanks! @bors r+ |
📌 Commit e8f3a9f has been approved by |
add Result::map_or This PR adds this API to make it consistent with `Option::map_or`. ```rust impl<T, E> Result<T, E> { pub fn map_or<U, F: FnOnce(T) -> U>(self, default: U, f: F) -> U { match self { Ok(t) => f(t), Err(_) => default, } } } ``` This API is very small. We already has a similar API for `Option::map_or`.
Rollup of 13 pull requests Successful merges: - #65932 (download .tar.xz if python3 is used) - #66074 ([mir-opt] Turn on the `ConstProp` pass by default) - #66094 (Fix documentation for `Iterator::count()`.) - #66166 (rename cfg(rustdoc) into cfg(doc)) - #66227 (docs: Fix link to BufWriter::flush) - #66292 (add Result::map_or) - #66297 (Add a callback that allows compiler consumers to override queries.) - #66317 (Use a relative bindir for rustdoc to find rustc) - #66330 (Improve non-exhaustiveness handling in usefulness checking) - #66331 (Add some tests for fixed ICEs) - #66334 (Move Session fields to CrateStore) - #66335 (Move self-profile infrastructure to data structures) - #66337 (Remove dead code for encoding/decoding lint IDs) Failed merges: r? @ghost
add Result::map_or This PR adds this API to make it consistent with `Option::map_or`. ```rust impl<T, E> Result<T, E> { pub fn map_or<U, F: FnOnce(T) -> U>(self, default: U, f: F) -> U { match self { Ok(t) => f(t), Err(_) => default, } } } ``` This API is very small. We already has a similar API for `Option::map_or`.
add Result::map_or This PR adds this API to make it consistent with `Option::map_or`. ```rust impl<T, E> Result<T, E> { pub fn map_or<U, F: FnOnce(T) -> U>(self, default: U, f: F) -> U { match self { Ok(t) => f(t), Err(_) => default, } } } ``` This API is very small. We already has a similar API for `Option::map_or`.
Rollup of 14 pull requests Successful merges: - #65932 (download .tar.xz if python3 is used) - #66094 (Fix documentation for `Iterator::count()`.) - #66166 (rename cfg(rustdoc) into cfg(doc)) - #66186 (Add long error explanation for E0623) - #66227 (docs: Fix link to BufWriter::flush) - #66248 (add raw ptr variant of UnsafeCell::get) - #66292 (add Result::map_or) - #66297 (Add a callback that allows compiler consumers to override queries.) - #66317 (Use a relative bindir for rustdoc to find rustc) - #66330 (Improve non-exhaustiveness handling in usefulness checking) - #66331 (Add some tests for fixed ICEs) - #66334 (Move Session fields to CrateStore) - #66335 (Move self-profile infrastructure to data structures) - #66337 (Remove dead code for encoding/decoding lint IDs) Failed merges: r? @ghost
☔ The latest upstream changes (presumably #66366) made this pull request unmergeable. Please resolve the merge conflicts. |
Looks like this is out in the wild now with 1.41 but why is default first? |
It matches I believe the rationale was to allow closures to run off the end of the argument list and not be stuck with an awkward formatting decision of what to do after its closing brace. |
This PR adds this API to make it consistent with
Option::map_or
.