branchless .filter(_).count()
I found that the branchless version is only slower if we have little to no branch misses, which usually isn't the case. I notice speedups between -5% (perfect prediction) and 60% (real world data).
Extend Cell to work with non-Copy types
I'm not sure that I did this right but all of the tests pass.
I also had to move the `new()` function so that `Cell`s with non-`Copy` `T`s could be created. That wasn't in the RFC but I assume it needed to be done?
std: Stabilize APIs for the 1.16.0 release
This commit applies the stabilization/deprecations of the 1.16.0 release, as
tracked by the rust-lang/rust issue tracker and the final-comment-period tag.
The following APIs were stabilized:
* `VecDeque::truncate`
* `VecDeque::resize`
* `String::insert_str`
* `Duration::checked_{add,sub,div,mul}`
* `str::replacen`
* `SocketAddr::is_ipv{4,6}`
* `IpAddr::is_ipv{4,6}`
* `str::repeat`
* `Vec::dedup_by`
* `Vec::dedup_by_key`
* `Result::unwrap_or_default`
* `<*const T>::wrapping_offset`
* `<*mut T>::wrapping_offset`
* `CommandExt::creation_flags` (on Windows)
* `File::set_permissions`
* `String::split_off`
The following APIs were deprecated
* `EnumSet` - replaced with other ecosystem abstractions, long since unstable
Closes#27788Closes#35553Closes#35774Closes#36436Closes#36949Closes#37079Closes#37087Closes#37516Closes#37827Closes#37916Closes#37966Closes#38080
This commit applies the stabilization/deprecations of the 1.16.0 release, as
tracked by the rust-lang/rust issue tracker and the final-comment-period tag.
The following APIs were stabilized:
* `VecDeque::truncate`
* `VecDeque::resize`
* `String::insert_str`
* `Duration::checked_{add,sub,div,mul}`
* `str::replacen`
* `SocketAddr::is_ipv{4,6}`
* `IpAddr::is_ipv{4,6}`
* `str::repeat`
* `Vec::dedup_by`
* `Vec::dedup_by_key`
* `Result::unwrap_or_default`
* `<*const T>::wrapping_offset`
* `<*mut T>::wrapping_offset`
* `CommandExt::creation_flags` (on Windows)
* `File::set_permissions`
* `String::split_off`
The following APIs were deprecated
* `EnumSet` - replaced with other ecosystem abstractions, long since unstable
Closes#27788Closes#35553Closes#35774Closes#36436Closes#36949Closes#37079Closes#37087Closes#37516Closes#37827Closes#37916Closes#37966Closes#38080
expect_err for Result.
This adds an `expect_err` method to `Result`. Considering how `unwrap_err` already exists, this seems to make sense. Inconsistency noted in Manishearth/rust-clippy#1435.
Make Peekable remember peeking a None
Peekable should remember if a None has been seen in the `.peek()` method.
It ensures that `.peek(); .peek();` or `.peek(); .next();` only advances the
underlying iterator at most once. This does not by itself make the iterator
fused.
Thanks to @s3bk for the code in `fn peek()` itself.
Fixes#37784
The problem occured due to lines like
```
3400;<CJK Ideograph Extension A, First>;Lo;0;L;;;;;N;;;;;
4DB5;<CJK Ideograph Extension A, Last>;Lo;0;L;;;;;N;;;;;
```
in `UnicodeData.txt`, which the script previously interpreted as two
characters, although it represents the whole range.
Fixes#34318.
Peekable must remember if a None has been seen in the `.peek()` method.
It ensures that `.peek(); .peek();` or `.peek(); .next();` only advances the
underlying iterator at most once. This does not by itself make the iterator
fused.
Implement Iterator::fold for .chain(), .cloned(), .map() and the VecDeque iterators.
Chain can do something interesting here where it passes on the fold
into its inner iterators.
The lets the underlying iterator's custom fold() be used, and skips the
regular chain logic in next.
Also implement .fold() specifically for .map() and .cloned() so that any
inner fold improvements are available through map and cloned.
The same way, a VecDeque iterator fold can be turned into two slice folds.
These changes lend the power of the slice iterator's loop codegen to
VecDeque, and to chains of slice iterators, and so on.
It's an improvement for .sum() and .product(), and other uses of fold.
Chain can do something interesting here where it passes on the fold
into its inner iterators.
The lets the underlying iterator's custom fold() be used, and skips the
regular chain logic in next.
std: Stabilize and deprecate APIs for 1.13
This commit is intended to be backported to the 1.13 branch, and works with the
following APIs:
Stabilized
* `i32::checked_abs`
* `i32::wrapping_abs`
* `i32::overflowing_abs`
* `RefCell::try_borrow`
* `RefCell::try_borrow_mut`
Deprecated
* `BinaryHeap::push_pop`
* `BinaryHeap::replace`
* `SipHash13`
* `SipHash24`
* `SipHasher` - use `DefaultHasher` instead in the `std::collections::hash_map`
module
Closes#28147Closes#34767Closes#35057Closes#35070
This commit is intended to be backported to the 1.13 branch, and works with the
following APIs:
Stabilized
* `i32::checked_abs`
* `i32::wrapping_abs`
* `i32::overflowing_abs`
* `RefCell::try_borrow`
* `RefCell::try_borrow_mut`
* `DefaultHasher`
* `DefaultHasher::new`
* `DefaultHasher::default`
Deprecated
* `BinaryHeap::push_pop`
* `BinaryHeap::replace`
* `SipHash13`
* `SipHash24`
* `SipHasher` - use `DefaultHasher` instead in the `std::collections::hash_map`
module
Closes#28147Closes#34767Closes#35057Closes#35070
Introduce max_by/min_by on iterators
See https://github.com/rust-lang/rfcs/issues/1722 for reference.
It seems that there is `min`, `max` (simple computation of min/max), `min_by_key`, `max_by_key` (min/max by comparing mapped values) but no `min_by` and `max_by` (min/max according to comparison function). However, e.g. on vectors or slices there is `sort`, `sort_by_key` and `sort_by`.
Implement std::convert traits for char
This is motivated by avoiding the `as` operator, which sometimes silently truncates, and instead use conversions that are explicitly lossless and infallible.
I’m less certain that `From<u8> for char` should be implemented: while it matches an existing behavior of `as`, it’s not necessarily the right thing to use for non-ASCII bytes. It effectively decodes bytes as ISO/IEC 8859-1 (since Unicode designed its first 256 code points to be compatible with that encoding), but that is not apparent in the API name.
These fit with other From implementations between integer types.
This helps the coding style of avoiding the 'as' operator that sometimes
silently truncates, and signals that these specific conversions are
lossless and infaillible.
