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`.
Document try!'s error conversion behaviour
try!'s documentation currently doesn't document the error conversion behaviour of the macro. This patch extends the documentation.
Open questions:
* is it worthwhile to have seperate examples with and without wrapping behaviour? It's not immediately obvious that From<T> for T is always defined. Though this is necessary for the macro to work in any case, is this the place to expect that knowledge.
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.
add evocative examples for `BitOr` and `BitXor`
These are exactly equivalent to PR #35809, with one caveat: I do not believe there is a non-bitwise binary XOR operator in Rust, so here it's expressed as `(a || b) && !(a && b)`.
Alternative decompositions are `(a && !b) || (!a && b)` and `(a || b) && (!a || !b)`. Let me know if you think one of those would be clearer.
r? @GuillaumeGomez
accumulate vector and assert for RangeFrom and RangeInclusive examples
PR #35695 for `Range` was merged, so it seems that this side-effect-free style is preferred for Range* examples. This PR performs the same translation for `RangeFrom` and `RangeInclusive`. It also removes what looks to be an erroneously commented line for `#![feature(step_by)]`, and an unnecessary primitive-type annotation in `0u8..`.
These are exactly equivalent to PR #35809, with one caveat: I do not believe there is a non-bitwise binary "xor" operator in Rust, so here it's expressed as (a || b) && !(a && b).
r? @GuillaumeGomez
improved documentation a la PR #35993
improve `BitAnd` trait documentation
This pull request is based on the discussion in PR #35927.
Add a module-level note that `&&` and `||` are short-circuiting operators and not overloadable.
Add a simple `Scalar` example that lifts the `&` operator to a trivial struct tuple.
Make `BooleanVector` a struct tuple.
Derive `PartialEq` for `BooleanVector` instead of implementing it.
Adds a `fn main` wrapper so that the example can integrate with Rust Playground.
improve documentation for `Fn*` traits
This PR is not yet a serious attempt at contribution. Rather, I'm opening this for discussion. I can think of a few things we may want to accomplish with the documentation of the `Fn`, `FnMut`, and `FnOnce` traits:
- the relationship between these traits and the closures that implement them
- examples of non-closure implementations
- the relationship between these traits and Rust's ownership semantics
show how iterating over `RangeTo` and `RangeToInclusive` fails
Feedback on PR #35701 seems to be positive, so this does the same thing for `RangeTo` and `RangeToInclusive`.
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.
This pull request is based on the discussion in PR #35927.
Add a module-level note that `&&` and `||` are short-circuiting operators and not overloadable.
Add a simple `Scalar` example that lifts the `&` operator to a trivial struct tuple.
Make `BooleanVector` a struct tuple.
Derive `PartialEq` for `BooleanVector` instead of implementing it.
Adds a `fn main` wrapper so that the example can integrate with Rust Playground.
simplified bitand expression
add a comment explaining what "rhs" means
PR #35695 for `Range` was approved, so it seems that this side-effect-free style is preferred for Range* examples. This PR performs the same translation for `RangeFrom` and `RangeInclusive`. It also removes what looks to be an erroneously commented line for `#![feature(step_by)]`, and an unnecessary primitive-type annotation in `0u8..`.
add `fn main` wrappers to enable Rust Playground "Run" button
more evocative examples for `Sub` and `SubAssign`
These examples are exactly analogous to those in PRs #35709 and #35806. I'll probably remove the `fn main` wrappers for `Add` and `Sub` once this is merged in.
Part of #29365.
r? @steveklabnik
r? @steveklabnik
add examples that lift `<<` and `>>` to a trivial struct
replace `Scalar` structs with struct tuples
add `fn main` wrappers to enable Rust Playground "Run" button
I can think of a few things we may want to accomplish with the documentation of the `Fn`, `FnMut`, and `FnOnce` traits:
- the relationship between these traits and the closures that implement them
- examples of non-closure implementations
- the relationship between these traits and Rust's ownership semantics
add module-level documentation for `Fn*` traits
Describe how `Fn*` traits, closure types, and ownership semantics are
linked, and provide examples of higher-level functions that take `Fn*`s.
more examples for `Fn*` traits
create correct (though not yet elegant) examples for `FnMut` and `FnOnce`
add trait links to module-level documentation
third time's a charm!
argument -> capture for trait documentation
This wording will need to be supported with better examples for
capturing eventually.
correct `FnOnce` example
I also fixed some of the trait wording here to make the concept of
capturing clearer; though that still needs more work.
replace `x + x` with `x * 2` for `fn double`
Implement 1581 (FusedIterator)
* [ ] Implement on patterns. See https://github.com/rust-lang/rust/issues/27721#issuecomment-239638642.
* [ ] Handle OS Iterators. A bunch of iterators (`Args`, `Env`, etc.) in libstd wrap platform specific iterators. The current ones all appear to be well-behaved but can we assume that future ones will be?
* [ ] Does someone want to audit this? On first glance, all of the iterators on which I implemented `FusedIterator` appear to be well-behaved but there are a *lot* of them so a second pair of eyes would be nice.
* I haven't touched rustc internal iterators (or the internal rand) because rustc doesn't actually call `fuse()`.
* `FusedIterator` can't be implemented on `std::io::{Bytes, Chars}`.
Closes: #35602 (Tracking Issue)
Implements: rust-lang/rfcs#1581
Implement `CoerceUnsized` for `{Cell, RefCell, UnsafeCell}`
These impls are analogous to the one for `NonZero`. It's occasionally useful to be able to coerce the cell types when they're being used inside another abstraction. See Manishearth/rust-gc#17 for an example.
r? @eddyb
