This commit wraps up the adjustments to the iterator for recent language
changes.
* Moves `rposition` from `ExactSizeIterator` to `IteratorExt` using a
`where` clause, thereby removing the `ExactSizeIterator:
DoubleEndedIterator` constraint.
* Merges `MutableDoubleEndedIterator` into `IteratorExt`, renaming
`reverse_` to `reverse_in_place`.
* Merges `IteratorOrdExt`, `IteratorCloneExt` and `CloneIteratorExt`
into `IteratorExt` using `where` clauses.
Marks as `#[stable]`:
* the `iter` module itself
* `FromIterator`, `Extend`
* `Iterator`, `IteratorExt`
* `map`
* `filter`
* `filter_map`
* `skip_while`
* `take_while`
* `scan`
* `flat_map`
* `inspect`
* `collect`
* `fold`
* `all`
* `any`
* `find`
* `rposition`
* `max`, `min`
* Various adapter types related to the above methods
Because of the trait merging, this is a:
[breaking-change]
This removes a large array of deprecated functionality, regardless of how
recently it was deprecated. The purpose of this commit is to clean out the
standard libraries and compiler for the upcoming alpha release.
Some notable compiler changes were to enable warnings for all now-deprecated
command line arguments (previously the deprecated versions were silently
accepted) as well as removing deriving(Zero) entirely (the trait was removed).
The distribution no longer contains the libtime or libregex_macros crates. Both
of these have been deprecated for some time and are available externally.
post-unboxed-closure-conversion. This requires a fair amount of
annoying coercions because all the `map` etc types are defined
generically over the `F`, so the automatic coercions don't propagate;
this is compounded by the need to use `let` and not `as` due to
stage0. That said, this pattern is to a large extent temporary and
unusual.
This patch marks `clone` stable, as well as the `Clone` trait, but
leaves `clone_from` unstable. The latter will be decided by the beta.
The patch also marks most manual implementations of `Clone` as stable,
except where the APIs are otherwise deprecated or where there is
uncertainty about providing `Clone`.
followed by a semicolon.
This allows code like `vec![1i, 2, 3].len();` to work.
This breaks code that uses macros as statements without putting
semicolons after them, such as:
fn main() {
...
assert!(a == b)
assert!(c == d)
println(...);
}
It also breaks code that uses macros as items without semicolons:
local_data_key!(foo)
fn main() {
println("hello world")
}
Add semicolons to fix this code. Those two examples can be fixed as
follows:
fn main() {
...
assert!(a == b);
assert!(c == d);
println(...);
}
local_data_key!(foo);
fn main() {
println("hello world")
}
RFC #378.
Closes#18635.
[breaking-change]
In US english, "that" is used in restrictive clauses in place of
"which", and often affects the meaning of sentences.
In UK english and many dialects, no distinction is
made.
While Rust devs want to avoid unproductive pedanticism, it is worth at
least being uniform in documentation such as:
http://doc.rust-lang.org/std/iter/index.html
and also in cases where correct usage of US english clarifies the
sentence.
closes#12677 (cc @Valloric)
cc #15294
r? @aturon / @alexcrichton
(Because of #19358 I had to move the struct bounds from the `where` clause into the parameter list)
In US english, "that" is used in restrictive clauses in place of
"which", and often affects the meaning of sentences.
In UK english and many dialects, no distinction is
made.
While Rust devs want to avoid unproductive pedanticism, it is worth at
least being uniform in documentation such as:
http://doc.rust-lang.org/std/iter/index.html
and also in cases where correct usage of US english clarifies the
sentence.
