This commit introduces 2 methods - `Option::zip` and `Option::zip_with` with
respective signatures:
- zip: `(Option<T>, Option<U>) -> Option<(T, U)>`
- zip_with: `(Option<T>, Option<U>, (T, U) -> R) -> Option<R>`
Both are under the feature gate "option_zip".
I'm not sure about the name "zip", maybe we can find a better name for this.
(I would prefer `union` for example, but this is a keyword :( )
--------------------------------------------------------------------------------
Recently in a russian rust begginers telegram chat a newbie asked (translated):
> Are there any methods for these conversions:
>
> 1. `(Option<A>, Option<B>) -> Option<(A, B)>`
> 2. `Vec<Option<T>> -> Option<Vec<T>>`
>
> ?
While second (2.) is clearly `vec.into_iter().collect::<Option<Vec<_>>()`, the
first one isn't that clear.
I couldn't find anything similar in the `core` and I've come to this solution:
```rust
let tuple: (Option<A>, Option<B>) = ...;
let res: Option<(A, B)> = tuple.0.and_then(|a| tuple.1.map(|b| (a, b)));
```
However this solution isn't "nice" (same for just `match`/`if let`), so I thought
that this functionality should be in `core`.
Don't use the word "unwrap" to describe "unwrap" methods
It's tautological, and "unwrap" is essentially Rust-specific jargon.
I was teaching a newbie some Rust, and doing the usual hand-waving about error handling using unwrap. They asked what 'unwrap' means. I said look it up in the docs. The docs read (paraphrased) "unwrap unwraps". I was embarrassed.
This changes all the Option/Result functions with unwrapping behavior to use a variation on a single description:
> "Returns the contained `Some/Ok` value [or ...]."
It also renames the closure of `Result::unwrap_or_else` to `default` for consistency with `Option`, and perhaps makes a few other small tweaks.
Previous: https://github.com/rust-lang/rust/pull/68849
It's tautological, and Rust-specific Jargon.
This changes various Option/Result methods to consistently describe unwrapping
behavior using the words "return", "contain", "consume".
It also renames the closure argument of `Return::unwrap_or_else` to `default` to
be consistent with `Option`.
In the docs for option.rs and result.rs, it is noted for all *_or()
functions that they are eagerly evaluated, except for the map_or()
function.
This commit adds this missing documentation to the two files.
Use matches macro in libcore and libstd
This PR replaces matches like
```rust
match var {
value => true,
_ => false,
}
```
with use of `matches!` macro.
r? @Centril
This commit applies rustfmt with default settings to files in
src/libcore *that are not involved in any currently open PR* to minimize
merge conflicts. The list of files involved in open PRs was determined
by querying GitHub's GraphQL API with this script:
https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8
With the list of files from the script in `outstanding_files`, the
relevant commands were:
$ find src/libcore -name '*.rs' | xargs rustfmt --edition=2018
$ rg libcore outstanding_files | xargs git checkout --
Repeating this process several months apart should get us coverage of
most of the rest of libcore.
Stabilize `Option::flatten`
- PR: https://github.com/rust-lang/rust/pull/60256
- Tracking issue: https://github.com/rust-lang/rust/issues/60258
@elahn
> I was trying to `flat_map()` and found `map().flatten()` does the trick. This has been on nightly for 4 months, can we stabilise it?
@ethanboxx
> @Centril Helped me get this merged. What is the stabilization process?
@Centril
> @ethanboxx I'd just file a PR to stabilize it and we'll ask T-libs to FCP.
So here I am.
I am was unsure what number to put in `since = "-"` so I copied what someone had done in a recent PR.
Stabilize `Option::as_deref` and `Option::as_deref_mut`
The tracking issue https://github.com/rust-lang/rust/issues/50264 still has unresolved question for the corresponding `Result` methods.
Use internal iteration in the Sum and Product impls of Result and Option
This PR adds internal iteration to the `ResultShunt` iterator type underlying the `Sum` and `Product` impls of `Result`. I had to change `ResultShunt` to hold a mutable reference to an error instead, similar to `itertools::ProcessResults`, in order to be able to pass the `ResultShunt` itself by value (which is necessary for internal iteration).
`ResultShunt::process` can unfortunately no longer be an associated function because that would make it generic over the lifetime of the error reference, which wouldn't work, so I turned it into the free function `process_results`.
I removed the `OptionShunt` type and forwarded the `Sum` and `Product` impls of `Option` to their respective impls of `Result` instead, to avoid having to repeat the internal iteration logic.
