| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
Fixes #45860
|
|
|
|
This also implements ExactSizeIterator where applicable.
Addresses most of the Iterator traits mentioned in #23708.
|
|
Closes #43738.
|
|
Rollup of 14 pull requests
- Successful merges: #48403, #48432, #48546, #48573, #48590, #48657, #48727, #48732, #48753, #48754, #48761, #48474, #48507, #47463
- Failed merges:
|
|
|
|
FusedIterator is a marker trait that promises that the implementing
iterator continues to return `None` from `.next()` once it has returned
`None` once (and/or `.next_back()`, if implemented).
The effects of FusedIterator are already widely available through
`.fuse()`, but with stable `FusedIterator`, stable Rust users can
implement this trait for their iterators when appropriate.
|
|
Tried to be fancy with print statements.
|
|
The choice of string is arbitrary, so all references to a number
in the string were removed. The string is now the standard "Hello
world!".
|
|
A user in a reddit thread was confused by the name of the variable
"num_as_int"; they thought the example was trying to convert the
string "10" as if it were binary 2 by calling str::len(). In reality,
the example is simply demonstrating how to take an immutable reference
to the value of an Option. The confusion comes from the coincidence
that the length of the string "10" is also its binary representation,
and the implication from the variable names that a conversion was
occuring ("num_as_str" to "num_as_int").
This PR changes the example number to 12 instead of 10, and changes
the variable name from "num_as_int" to "num_length" to better
communicate what the example is doing.
The reddit thread:
https://www.reddit.com/r/rust/comments/7zpvev/notyetawesome_rust_what_use_cases_would_you_like/dur39xw/
|
|
Add transpose conversions for nested Option and Result
These impls are useful when working with combinator
methods that expect an option or a result, but you
have a `Result<Option<T>, E>` instead of an `Option<Result<T, E>>`
or vice versa.
|
|
`map_or` and `map_or_else` don't use `Default::default`, but `unwrap_or_default` does.
|
|
These impls are useful when working with combinator
methods that expect an option or a result, but you
have a Result<Option<T>, E> instead of an Option<Result<T, E>>
or vice versa.
|
|
Recommends lazily evaluated alternatives for `Option::or` and `Result::or`
Adds language to docs for `Option` and `Result` recommending the use of lazily evaluated alternatives when appropriate. These comments are intended to echo a [clippy lint] on the same topic. The [reddit discussion] may also be of interest.
[clippy lint]: https://rust-lang-nursery.github.io/rust-clippy/master/index.html#or_fun_call
[reddit discussion]: https://www.reddit.com/r/rust/comments/7hutqn/perils_of_optionor_and_resultor/
|
|
|
|
the use of lazily evaluated alternatives when appropriate. These
comments are intended to echo a clippy lint on the same topic (see
https://rust-lang-nursery.github.io/rust-clippy/master/index.html#or_fun_call)
|
|
|
|
|
|
|
|
|
|
|
|
libcore: Implement cloned() for Option<&mut T>
None
|
|
|
|
|
|
|
|
|
|
Stabilized:
* `Option::get_or_insert`
* `Option::get_or_insert_with`
Closes #39288
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Provide Entry-like API for Option
This implements #39288.
I am wondering whether to use std::intrinsics::unreachable!() here. Both seems fine to me (the second match optimizes away in release mode).
|
|
This implements #39288.
Thanks to @steveklabnik and @oli-obk for their review comments :)
|
|
|
|
|
|
Add Iterator trait TrustedLen to enable better FromIterator / Extend
This trait attempts to improve FromIterator / Extend code by enabling it to trust the iterator to produce an exact number of elements, which means that reallocation needs to happen only once and is moved out of the loop.
`TrustedLen` differs from `ExactSizeIterator` in that it attempts to include _more_ iterators by allowing for the case that the iterator's len does not fit in `usize`. Consumers must check for this case (for example they could panic, since they can't allocate a collection of that size).
For example, chain can be TrustedLen and all numerical ranges can be TrustedLen. All they need to do is to report an exact size if it fits in `usize`, and `None` as the upper bound otherwise.
The trait describes its contract like this:
```
An iterator that reports an accurate length using size_hint.
The iterator reports a size hint where it is either exact
(lower bound is equal to upper bound), or the upper bound is `None`.
The upper bound must only be `None` if the actual iterator length is
larger than `usize::MAX`.
The iterator must produce exactly the number of elements it reported.
This trait must only be implemented when the contract is upheld.
Consumers of this trait must inspect `.size_hint()`’s upper bound.
```
Fixes #37232
|
|
|
|
Most of the Rust community agrees that the vec! macro is clearer when
called using square brackets [] instead of regular brackets (). Most of
these ocurrences are from before macros allowed using different types of
brackets.
There is one left unchanged in a pretty-print test, as the pretty
printer still wants it to have regular brackets.
|
|
|
|
|
|
Documentation of what Default does for each type
Addresses #36265
I haven't changed the following types due to doubts:
1)src/libstd/ffi/c_str.rs
2)src/libcore/iter/sources.rs
3)src/libcore/hash/mod.rs
4)src/libcore/hash/mod.rs
5)src/librustc/middle/privacy.rs
r? @steveklabnik
|
|
|
|
|
|
|
