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
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
Carrier trait (third attempt)
This adds a `Carrier` trait to operate with `?`. The only public implementation is for `Result`, so effectively the trait does not exist, however, it ensures future compatibility for the `?` operator. This is not intended to be used, nor is it intended to be a long-term solution.
Although this exact PR has not been through Crater, I do not expect it to be a breaking change based on putting numerous similar PRs though Crater in the past.
cc:
* [? tracking issue](https://github.com/rust-lang/rust/issues/31436)
* [previous PR](https://github.com/rust-lang/rust/pull/35056)
* [RFC issue](https://github.com/rust-lang/rfcs/issues/1718) for discussion of long-term Carrier trait solutions.
r? @nikomatsakis
replace `Add` example with something more evocative of addition
Currently most of the operator traits use trivial implementation
examples that only perform side effects. Honestly, that might not be too
bad for the sake of documentation; but anyway, here's a proposal to move
a slightly modified version of the module-level point-addition example
into the `Add` documentation, since it's more evocative of addition
semantics.
Part of #29365
